Please find the answers for the below questions

Question

What is process Model?

Dude · Accepted Answer

What is process Model? 
 A process model is the primary tool in Appian for describing a workflow. Developers graphically lay out the workflow, which may assign user tasks, manipulate data, post system events, or update other design objects. Process models are frequently used with record types to provide users with tools to act on the information shown by the record. 
 In single sentence its a executable workflow with different activities involved. 
 docs.appian.com/.../Process_Modeling_Tutorial.html 
 Different type of gateway in apian? and what are its uses? 
 
 XOR &mdash; Exclusive Decision/Merge (Exclusive OR) This type of Gateway node allows one incoming path to continue, while excluding any others. It executes a single outgoing path determined by the conditions you set. 
 OR &mdash; Inclusive Decision/Merge This type of Gateway directs incoming flows to one of many possible output paths, based on the condition(s) you set. 
 COMPLEX &mdash; Complex Decision/Merge This type of Gateway allows you to selectively accept (or restrict) incoming paths and evaluate rules to determine outgoing paths. For example, you can restrict the node to accept only the first 3 out of 4 incoming paths, or require input from certain nodes before continuing. Outgoing paths can be configured in the same manner as other Gateway nodes. 
 AND &mdash; Parallel Fork/Join This type of Gateway directs all incoming workflow(s) to all of the possible branches. If more than one incoming path is used, all incoming paths must reach the node before the process can continue. It can also be used to join all incoming paths into a single workflow. 
 
 docs.appian.com/.../Gateways.html 
 Process model best Practices? 
 There are various best practices for process modeling with respect to process model and process nodes. It also depends on the activity we are using like messaging. Following are a few basic best practices. 
 Process Models Process model has labeled swim-lanes with default assignment Process model display name is set and is dynamic (e.g. &ldquo;Started by pp!initiator&rdquo;) All process flows have been tested and no errors occurred All models have custom Alert settings configured using groups Processes that contain user input tasks or a significant portion of log: Archive after 3 days. Everything else: Delete after 0 days. Process models are split into sub-processes to compartmentalize sets of functionality and large cumbersome process models are avoided Models contain no more than 30 nodes Models contain no more than 50 process variables XOR gateways are used in front of MNI nodes to check for empty/null values Process flow will always reach at least one terminating end event Process-to-process messages are targeted to a specific process instance using PID All complex logic is documented using annotations (anything that isn't obvious) All external integrations are contained in their own subprocesses to minimize the impacts of the external systems changing their interfaces. E.g. anything other than query rules and data stores should be encapsulated. If the external integration points are using CDTs to exchange data (such as integration with web services), use these CDTs locally within the integration process models or rules and create business CDTs to be used by the rest of the application. This prevents changes in external systems data structures from having widespread impacts in the application. Best practices for creating memory efficient models have been followed Design short-lived processes to perform actions and maintain the data. Consider using process model based related actions instead of quick task related actions when possible. Ensure there is no way to unintentionally loop through a smart service node (db write, create document, etc) 
 Process Nodes Nodes are named with verb-noun format Task display name is set and dynamic Every SAIL form node has all inputs specified as process variables or activity class parameters All XOR/OR gateways have a single incoming flow All outgoing flows from a gateway are labeled XOR gateways are used instead of OR Node inputs do not make the same query call more than once CDTs are not passed by reference between parent and sub-process Looping functions are used instead of Multiple Node Instances where possible On the Other Tab for Forms, check the "Delete previous instances" and do not check &ldquo;Keep a record of the form&rdquo; Use rules and constants instead of hard-coded values in the process nodes 
 Different between loads with evaluated? 
 load(): Lets you define local variables within an expression for an interface and evaluate the expression with the new variables, then re-evaluate the function with the local variables' values from the previous evaluation. 
 with(): Lets you define local variables within a function and evaluate the expression with the new variables . Note: In interfaces, this function differs from the load() function because it recalculates the local variable values after interactions. This recalculation always happens, even if the interaction's updates could not have impacted the variable's value. This means data queries and other slow operations in with() variables can have important performance impacts. 
 Have a look at the new evaluation function, a!localVariables() . It does everything load() does but with additional refresh options that may drastically simplify your design. 
 what is CDT? 
 Its one of the data objects. 
 As opposed to a primitive or system data type, a custom data type (CDT) is a developer-defined data structure. Data Types allow designers to create a logical grouping of related data that can then be used by other objects to share data. Data can be shared internally, for instance between an interface and process model, or a web service that uses a CDT. 
 Because a data type will always be used in context of another object, it does not have individual security settings.

Please find the answers for the below questions

Top Replies