Pattern 43 (Explicit Termination)
A given process (or sub-process) instance should terminate when it reaches a nominated state. Typically this is denoted by a specific end node. When this end node is reached, any remaining work in the process instance is cancelled and the overall process instance is recorded as having completed successfully, regardless of whether there are any tasks in progress or remaining to be executed.
The rationale for this pattern is that it represents an alternative means of defining when a process instance can be designated as complete. This is when the thread of control reaches a defined state within the process model. Typically this is denoted by a designated termination node at the end of the model. Where there is a single end node in the process, its inclusion in other compositions is simplified.
There is one context condition associated with this pattern: every task in a process must be on a path fro a designated start node to a designated end node.
COSA, iPlanet, SAP Workflow, BPMN, XPDL and UML 2.0 ADs support this pattern although other than iPlanet, none of these offerings enforce that there is a single end node.
One consideration that does arise where a process model has multiple end nodes is whether it can be transformed to one with a single end node.
For simple process models, it may be possible to simply replace all of the end nodes for a process with links to an OR-join which then links to a single final node. However, it is less clear for more complex process models involving multiple instance tasks whether they are always able to be converted to a model with a single terminating node. Potential solutions to this are discussed at length in [KtHvdA03].
An offering achieves full support for this pattern if it demonstrates that it can meet the description and context criterion for the pattern.
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
|Staffware||10||-||Not supported. A workflow case terminates when all of its branches have terminated.|
|Websphere MQ||3.4||-||Not supported. Process instances terminate when there is no remaining work.|
|FLOWer||3.51||-||Not supported. Plans complete when all end nodes have completed.|
|COSA||5.1||+||Directly supported, a process instance completes when an end activity is reached.|
|iPlanet||3.0||+||Directly supported. There is a designated last activity which causes process termination.|
|SAP Workflow||4.6c||+||Directly supported. Processes are block structured with a single start and end node.|
|FileNet||3.5||-||Not supported. Workflow terminates after all steps have finished.|
|BPEL||1.1||-||Process instances complete when no activity instances remain to complete.|
|Websphere Integration Developer||6.0||-||Process instances complete when no activity instances remain to complete.|
|Oracle BPEL||10.1.2||-||Process instances complete when no activity instances remain to complete.|
|BPMN||1.0||+||Supported via a terminate end event.|
|XPDL||2.0||+||Supported via a terminate end event.|
|UML ADs||2.0||+||Supported via the ActivityFinalNode construct.|
|EPC (implemented by ARIS toolset 6.2)||-||Process instances complete only when no remaining element are enabled.|
|jBPM||3.1.4||-||jBPM does not support this pattern. A process instance completes when there is not any work item left for execution.|
|OpenWFE||1.7.3||-||OpenWFE does not support explicit termination. If several sub-processes are invoked, the main process completes when all its sub-processes complete (not when its end </process> tag is reached).|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|