Workflow Patterns

Overview

Defining Alternate Paths

Overview

Path Selection Based on Status

Path Selection Based on Expression Evaluation

Defining Parallel Paths

Overview

Adding Merge/Fork Gateways

Defining Convergent Paths

Overview

Merging Paths without Synchronization

Merging Paths with Synchronization

Additional Information about Workflow Patterns

Overview

Only the most basic workflows can be represented as a single, sequential flow (Workflow Pattern: Sequence). More realistic workflows generally contain varying combinations of tasks, and a path through the tasks is based on business decisions derived from the business data. The path is determined at run time by specific outcomes from each task or by expression evaluation at decision points.

Sequential Workflow Example

Another common flow pattern is parallel processing, when two or more workflow paths execute in parallel in contrast to alternate path selection supported by statuses and decisions. SAS Workflow Studio supports both alternate and parallel flow patterns, as detailed in the following sections.

Defining Alternate Paths

Overview

Many workflows contain multiple paths where each path represents one potential case or workflow instance. The specific path taken is based on the relevant business logic evaluated at run time.

Path Selection Based on Status

You can define a status for each path to indicate unique outcomes.

For example, assume that you are defining a basic approval workflow with two possible outcomes: approved or denied. You can define two status values: Approve, and Reject. Then, add the relevant status to the appropriate case in the workflow by assigning it to the connection for that path. At run time, the workflow continues to the next task based on the status corresponding to the action.

Path Selection Based on Status

The status values are unique, so there is only a single choice possible for this example (Workflow Pattern: Exclusive Choice). SAS Workflow Studio also supports multiple paths for the same status value (Workflow Pattern: Parallel). Using multiple paths is similar to using a merge/fork gateway, which might not have status assignments.

See Basic Workflow Examples for a detailed example.

Note: Most SAS products that leverage workflow use status values for every transition. Without status assignments, the task execution is controlled purely by sequence flow—the order in which elements are connected—and gateways. SAS Workflow Studio allows significant flexibility for defining workflow flow logic, so workflow designers should carefully validate that the workflow behaves as expected.

Path Selection Based on Expression Evaluation

In contrast to status evaluation, decisions can be used to route the workflow execution by means of evaluated expressions based on real-time business data values. Decision gateways in SAS Workflow Studio contain Boolean expressions that drive actions based on the calculated value. Thus, decision nodes can be used to route workflow execution to one (Workflow Pattern: Exclusive Choice) or more (Workflow Pattern: Inclusive Choice) of several alternate outgoing paths, depending on the condition.

To add and configure decisions, follow these steps:

Select the Add Decision Gateway icon () on the toolbar.
Click on an empty space in the drawing area to add a decision gateway to the diagram.

To define the properties of a decision node, follow these steps:

Right-click on the figure in the drawing area and then select Edit.

Alternatively, double-click on the decision node.
In the Edit Decision Gateway dialog box, enter the desired values.
Enter a name for the decision in the Label field. The default name of the first decision is Decision0. The second decision is Decision1, and so on.
To define Boolean expressions for a decision node, follow these steps:
1. Select Add to open the Add Boolean Expression dialog box.
2. Enter the desired logical expression.
3. (Optional) Provide a name for the expression in the Label field.
  
  (The default value is the expression itself.)
4. Select OK to save the current expression.
  
  The newly defined Boolean expression should be visible in the list box.
Repeat these steps to associate additional Boolean expressions with the current decision figure.
Select OK to save the decision definition.

All expressions must evaluate to a Boolean value and must conform to the Java language syntax. In summary, each expression must comply with the following rules:

The expression must evaluate to true or false.
The expression can use comparison operators (<, =, ==, or >).

Note: The = and == operators are evaluated in an identical manner.
The expression can contain logical combinations (&&, ||, !) of some set of comparisons.
The expression can contain arithmetic expressions on each side of the comparison. The arithmetic expression can be any combination of the following operators: +, -, *, /, or %. Arithmetic expressions can also contain functions, integers, floating point numbers, and data objects.

Data objects are specified by their label and might contain spaces.

See Decision Expression Examples for detailed operator and function support and Boolean expression examples.

Tip

To use data objects when writing Boolean expressions, press the F3 key to access a menu of valid data objects for the current workflow.

Tip

Use the Edit and Delete buttons to modify the contents of the list of expressions.

To assign the expressions to the relevant workflow paths, follow these steps:

Ensure that you have defined all the required Boolean expressions for the decision gateway.
Define the necessary workflow execution paths.
Connect the decision to the relevant tasks for each path.
For each connection, right-click on the connection, select Change status, and select the appropriate expression.

Each expression corresponds to a calculated value or outcome and is represented as a label in a similar manner to status values. In addition to these user-defined calculations, the special status of Otherwise can be assigned. Use this value to designate the logical path that should be traversed when all defined expressions evaluate to false. In summary, the Otherwise path represents the default execution path when none of the expression values are true.

Note: All paths with expressions that evaluate to true are executed.

For the following example, any order total that exceeds $500 requires manager approval before it is fulfilled. The decision gateway is based on an Order Total data object of type Number where the Yes path corresponds to a value exceeding the threshold and No, where the order total is below the threshold, is approved automatically.

Expression	Resulting Action
Order Total <= 500	Automated approval
Order Total > 500	Requires Manager approval

Example of Path Selection Based on Expression (Exclusive Choice)

See the examples provided with SAS Workflow Studio for details of this example.

For a workflow where one or more paths from a decision can be followed at the same time, an inclusive choice decision might be used. For example, a mail order company receives orders with combinations of items (books, music [CDs], movies [DVDs]) with distinct fulfillment tasks initiated for each item type. A typical order contains quantities of more than one product type.

Example of Path Selection Based on Expression (Inclusive Choice)

However, this divergence pattern (Workflow Pattern: Inclusive Choice) has two potential problems:

There is a deadlock if none of the choice expressions are realized.
Convergence requirements might be complex resulting in deadlock or surplus executions.

The first issue can be resolved by providing a default path. SAS Workflow Studio supports this with the (Otherwise) choice, which is available with all decision gateways. Most importantly, the business logic must be captured accurately and should cover all possible outcomes.

Avoiding Deadlock with a Default Path

Defining Parallel Paths

Overview

Frequently, a workflow consists of a sequence of tasks where each task is activated upon completion of the preceding task. At other times, a workflow might require multiple tasks or paths to be initiated in parallel after a specific task has completed. SAS Workflow Studio supports parallel paths via the merge/fork gateway element.

Adding Merge/Fork Gateways

To add a merge/fork gateway, follow these steps:

Select the Merge/Fork Gateway icon () on the toolbar.
Click on an empty space in the drawing area to add a merge/fork gateway to the diagram.
On the left side of the bar, draw the desired task structure and connect to the merge/fork gateway.
On the right side, create the desired task set and create a sequence flow line from the merge/fork gateway figure to each task.

If more than one task exists before the bar, then all tasks must complete before any tasks on the other side are initiated.

Here is an example of a workflow that splits into three parallel tasks (Generate Invoice, Complete Order, Send Bill). The tasks start only after the Receive Order task has completed.

Example of Parallel Paths

See Basic Workflow Examples for a more detailed example using parallel paths.

Note: Statuses cannot be assigned to connections leading from a merge/fork gateway. All subsequent paths are executed.

Tip

To change the orientation of the merge/fork gateway from vertical to horizontal (and vice versa), right-click the bar and then select Change orientation option.

The following table summarizes common divergence workflow patterns:

Workflow Pattern	Workflow Element	Description
Sequence	Sequence Flow (Connection)	Simple sequence where the subsequent task is triggered after the current task preceding it is competed.
Exclusive Choice	Decision Gateway or unique Status values	Alternate paths where only one is taken (logical XOR).
Inclusive Choice	Decision Gateway	Alternate paths where more than one might be taken, but not necessarily all paths (logical OR).
Parallel	Merge/Fork Gateway	Parallel structure where all paths are executed concurrently (logical AND).

Defining Convergent Paths

Overview

In general, divergent paths eventually converge either by processing the inputs as they are received (no synchronization) or by coordinating and consolidating the inputs (synchronization) into a single execution path. These convergence pattern types are detailed in the following sections.

Merging Paths without Synchronization

As a rule, alternate paths should converge without synchronization to prevent deadlocks. This means that exclusive choice decisions (exactly one path is selected) should require only a single input upon convergence (Workflow Pattern: Exclusive Merge). This can be accomplished in two ways:

Explicitly specify an OR-type logic gateway ().
Configure the inputs to flow into a single task directly (no gateway).

SAS Workflow Studio currently supports logical XOR (exclusive) for the first option and logical OR (inclusive) for the second option. So, for a single execution of the convergent path, the logical OR gateway should be used. If multiple executions are desired (one for each path), then the paths should converge directly into a task. In other words, any policies associated with the convergent task are executed multiple times if the logical gateway is not used.

To add and configure a logic gateway, follow these steps:

Select the Logic Gateway icon ().
Click on an empty space in the drawing area to add a logic gateway to the diagram.

Note: The gateway is AND by default.
Configure the logic gateway as OR by right-clicking the gateway and then selecting the OR option from the Change logic menu.
On the left side of the bar, create the desired task set and connect each path to the logic gateway.
On the right side, draw the desired task structure and create a sequence flow line from the logic gateway figure to the first task in the converged path.

The following example results in only a single work item (task instance) for Process Payment after both Calculate Account Balance and Verify Credit have been completed. However, any actions associated with the Process Payment task are executed twice.

Example of Inclusive Merge (OR)

The following example executes a single action triggered by the first of the preceding tasks that completes. If the other task completes before Process Payment is performed, then no additional action is taken.

Example of Exclusive Merge (XOR)

Merging Paths with Synchronization

Finally, parallel execution paths that require all tracks to complete should be joined and synchronized before initiating the convergent path. This can be accomplished by either using a merge/fork gateway or an AND-type logic gateway.

The parallel workflow in Example of Parallel Paths illustrates the use of a merge/fork gateway. In that example, the Ship Order task is not executed until all three of the preceding tasks (Generate Invoice, Complete Order, and Send Bill) complete. If more than one task exists after the gateway, then the tasks are started together and run independently. The following example shows a workflow where a set of tasks (B1, B2) starts only after another set of tasks (A1, A2) finishes:

Example of a Complex Parallel Workflow

Another variation on the inclusive merge convergence pattern, which controls partial synchronization, is sometimes referred to as the Discriminator model. This pattern supports multiple inputs that trigger multiple executions, but not necessarily one-to-one (selective execution). In other words, three inputs might lead to the converged path, but there might be only two trigger actions. The remaining input is ignored, if present. This pattern is not supported by SAS Workflow Studio.

In summary, the common convergence workflow patterns are as follows:

Workflow Pattern	Workflow Element	Description
Exclusive Merge	OR Logic Gateway	Merging of alternate paths where only the first input is used to trigger the converged path. Single execution (logical XOR)
Inclusive Merge	No gateway	Merging of alternate paths where each input is used to trigger the converged path. Multiple executions with no synchronization (logical OR)
Join	Merge/Fork Gateway AND Logic Gateway	Parallel structure where all inputs are required before proceeding on converged path. Complete synchronization (logical AND)

Additional Information about Workflow Patterns

For more information about workflow patterns, see the Workflow Patterns Initiative website. The following documents are of particular interest:

Nick Russell, Arthur H.M. ter Hofstede, Wil M.P. van der Aalst, and Nataliya Mulyar “Workflow Control-Flow Patterns: A Revised View.” 2006. Available http://www.workflowpatterns.com/documentation/documents/BPM-06-22.pdf.

W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros “Workflow Patterns.” 2003. Available http://www.workflowpatterns.com/documentation/documents/wfs-pat-2002.pdf.

Last updated: March 5, 2020