SAP Workflow Evaluation Results

Evaluation results for SAP Workflow version 4.6c against the workflow control-flow patterns

Pattern

Rating

Motivation
Sequence + Directly supported. In SAP one can connect activities using arcs, thus creating a sequence.
Parallel Split + Directly supported. SAP allows for structured parallel processes, using the fork construct one can create multiple parallel branches. Since there has to be a one-to-one correspondence between splits and joins, some parallel processes need to be modified to make them structured.
Synchronization + Directly supported via the fork construct. However, there has to be a one-to-one correspondence between split and join.
Exclusive Choice + Directly supported through three constructs: (1) the condition step type, (2) the multiple condition step type, (3) a choice directly following an activity. The condition step type can only be used for binary conditions based on a single Boolean expression. The multiple condition step type can be used to select from more than two alternatives. There is default branch that is selected if none of the other branches can be taken. The choice directly following an activity is similar to the multiple condition step type but is not shown graphically in the workflow model. As for the parallel split and synchronization constructs, each split needs to correspond to a join, i.e. again only block structured models are supported.

Simple Merge

+ Directly supported. However, there has to be a one-to-one correspondence between splits and joins.
Multi-Choice - Not supported. Although there are three constructs to model choices, it is not possible to select multiple exits for a choice (other than the fork). Hence a multi-choice requires a combination of fork and condition constructs.
Structured Synchronizing Merge - Not supported for two reasons. First of all, it is not possible to create optional parallel branches other than explicitly skipping the branches that are not selected. Second, the join construct of a fork is unaware of the number of truly active branches. Therefore, any synchronizing merge needs to be rewritten as a mix of forks and conditions.
Multi-Merge - Not supported because the block structure of SAP Workflow forces the model to be "safe" (in Petri-net terms), i.e. it is not possible to enable or activate an activity in parallel with itself.
Structured Discriminator +/- This is supported by the fork construct which allows for the specification of the number of branches that needs to be complete or some other end condition, i.e. a fork can start 10 branches and terminate 9 branches upon completion of the first branch. Note that all remaining branches are cancelled hence this construct only achieves partial support.
Arbitrary Cycles - SAP workflow models are inherently block structured, i.e. any split corresponds to a join and only structured loops (while/until loops) are possible using the loop step type.
Implicit Termination - Not supported because processes are block structured with a single start and end node.
Multiple Instances without Synchronization +/- The pattern is partially supported through data objects and events triggering workflows, i.e. a state change of an object may trigger a workflow. By changing states in a loop it is possible to trigger multiple instances. Note that the newly created instances run in a distinct process instances that has no relation to the instance of the activity activating them. Hence only partial support is given.
Multiple Instances with a Priori Design-Time Knowledge + This pattern is supported in two ways: (1) indirectly via the use of loop construct together with a counter variable indicating how many instances are to be synchronized by the subsequent join and (2) via "dynamic processing with a multi-line container element". Based on a multi-line data element (i.e., a table), an activity or sub-process is executed as many times are there are lines in the multi-line data element (i.e. the number of rows). There is a maximum of 99 instances. Through this "dynamic processing with a multi-line container element" dynamic support is achieved.
Multiple Instances with a Priori Run-Time Knowledge + Supported directly via the "dynamic processing with a multi-line container element" as indicated for the previous pattern. The number of rows is only relevant at the moment of activitation and does not need to be fixed before.
Multiple Instances without a Priori Run-Time Knowledge - Not supported. The only way to realize this is through the use of loop construct together with a counter variable indicating how many instances are to be synchronized by the subsequent join. This number can be modified at run-time. However, the designer has to do the book-keeping to link events to activities.
Deferred Choice - Not supported. It can only be realized by starting multiple branches in parallel using the fork construct and then commencing each branch with a "wait for event" step. Once the first event completes and the subsequent activity completes, the other branches can be cancelled by setting the required number of complete branches to 1 in the join node of the fork. However, when using this approach it is still possible that multiple activities run in parallel. Clearly, this is not sufficient support for this pattern.
Interleaved Parallel Routing - Not supported, the concept of a state is completely missing and there seems no way to influence the fork construct to only allow for interleavings (and not true concurrency).
Milestone - Not supported, because the concept of a state is completely missing.
Cancel Activity + Supported through the use of the "process control" step. A process control step can be configured such that is forces another work item of the same workflow into the status "logically deleted", i.e. another activity is cancelled. This completes this other work item and subsequent steps of this work item are not executed. To indicate the activity to be cancelled, you specify the node number of the corresponding step.
Cancel Case + Also supported through the use of the "process control" step. A process control step can be set to "terminate workflow" which forces all work items of the same workfow into the status "logically deleted" and terminates the current process instance by setting it to status completed. If the terminated workflow was a sub-workflow of a superior workflow, the system executes the binding between the container of the sub-workflow and the container of the superior workflow in accordance with the definition, and continues the superior workflow.
Structured Loop + This pattern is supported through the loop construct. There are two types of loops: (1) the until loop and (2) the while loop. The until loop has a "body" that is first executed. After executing the body a Boolean condition is evaluated. If it evaluates to true, the process continues with the next step. Otherwise, the process the "loopback body" is executed and then the process is repeated from the beginning. The while loop is similar to the until loop, however, the "body" is always empty. Therefore, the "loopback body" is the only part inside the loop and this part is executed zero or more times.
Recursion + A "multistep task" (i.e. an activity that is decomposed into a sub-workflow) contains a reference to a workflow definition hence a workflow could be decomposed into itself.
Transient Trigger + SAP offer a "wait for event" step that can be used to wait for an event. This step has different settings. The standard mechanism is that events are not queued. There is an event queue but this is just there for performance reasons.

Persistent Trigger

 + It is possible to use the "wait for event" step with the setting "event via workflow". When waiting for an event via the workflow, the event is initially received and temporarily saved by the workflow. Once the wait step has been activated, the event is forwarded to the wait step.
Cancel Region - The process control step can terminate/cancel a specific activity of the whole process instance. It is not possible to cancel everything in a region other than by enumerating the region using a sequence of process control steps.
Cancel Multiple Instance Activity + Via "dynamic processing with a multi-line container element" it is possible to create an instance for each row in a table. The termination of the parent activity can be passed on to the child objects.
Complete Multiple Instance Activity - Not supported. An activity set to "logicaly deleted" is recursively scanned for items that do not yet have the status completed. These work items are then also set to the status "logically deleted". Hence it is not possible to complete the multiple instances still running.
Blocking Discriminator - The block structured nature of SAP workflow does not allow for concurrent execution treads within the same instance. Hence a discriminator cannot be activated multiple times.
Cancelling Discriminator + This pattern is supported by the fork construct which allows for the specification of the number of branches that needs to complete. This can be set 1 one thus resulting in a discriminator. When completing the first branch all remaining branches are cancelled.
Structured N-out-of-M Join +/- SAP workflow only supports structured workflows. In the case of the N-out-of-M join, this is supported by a fork that can start M branches in parallel and the fork completes after the completion of the first N branches. The remaining branches are cancelled hence this construct only achieves partial support.
Blocking N-out-of-M Join - Not supported because of the structured/safe nature of SAP workflow.
Cancelling N-out-of-M Join + SAP workfow only supports structured workflows. In the case of the N-out-of-M join, this is supported by a fork that can start M branches in parallel and the fork completes after the completion of N of these branches. The remaining branches are cancelled.
Generalised AND-Join - Not supported because of the structured/safe nature of SAP workflow.
Static Partial Join for Multiple Instances - Not supported. Via "dynamic processing with a multi-line container element" it is possible to create an instance for each row in a table. However, these instances are supposed to complete and there is no setting for a threshold value.
Cancelling Partial Join for Multiple Instances - Not supported. Via "dynamic processing with a multi-line container element" it is possible to create an instance for each row in a table. However, these instances are supposed to complete.
Dynamic Partial Join for Multiple Instances - Not supported. Note that "dynamic processing with a multi-line container element" does not allow for dynamic changes of the number of instances.
Acyclic Synchronizing Merge - Not supported for two reasons. First of all, it is not possible to create optional parallel branches other than explicitly skipping the branches that are not selected. Second, the join construct of a fork is unaware of the number of truly active branches. Therefore, any synchronizing merge needs to be rewritten as a mix of forks and conditions.
General Synchronizing Merge - None of the variants of the synchronizing merge are supported.
Critical Section - Not supported. There are no mechanisms other than events and cancellations to support interactions between parallel branches.
Interleaved Routing - Not supported. There are no mechanisms other than events and cancellations to support interactions between parallel branches.
Thread Merge - Not supported because of the structured/safe nature of SAP workflow.
Thread Split - Not supported because of the structured/safe nature of SAP workflow.
Explicit Termination + Directly supported. Processes are block structured with a single start and end node.