Pattern 20 (Cancel Case)
A complete process instance is removed. This includes currently executing tasks, those which may execute at some future time and all sub-processes. The process instance is recorded as having completed unsuccessfully.
During an insurance claim process, it is discovered that the policy has expired and, as a consequence, all tasks associated with the particular process instance are cancelled;
During a mortgage application, the purchaser decides not to continue with a house purchase and withdraws the application.
This pattern provides a means of halting a specified process instance and withdrawing any tasks associated with it.
Cancellation of an entire case involves the disabling of all currently enabled tasks. Figure 28 illustrates one scheme for achieving this. It is based on the identification of all possible sets of states that the process may exhibit for a process instance. Each combination has a transition associated with it (illustrated by C1, C2... etc) that disables all enabled tasks. Where cancellation of a case is enabled, it is assumed that precisely one of the cancelling transitions (i.e. C1, C2...) will fire cancelling all necessary enabled tasks. To achieve this, it is necessary that none of the cancelling transitions represent a state that is a superset of another possible state, otherwise tokens may be left behind after the cancellation.
Figure 28: Cancel case pattern (variant 1)
An alternative scheme is presented in Figure 29, where every state has a set of cancellation transitions associated with it (illustrated by C1, C2 ... etc). When the cancellation is initiated, these transitions are enabled for a very short time interval (in essence the difference between time t and t + epsilon where epsilon is a time interval approaching zero), thus effecting an instantaneous cancellation for a given state that avoids the potential deadlocks that might arise with the approach in Figure 28.
Figure 29: Cancel case pattern (variant 2)
A more general approach to cancellation is illustrated in Figure 30. This may be used to cancel individual tasks, regions or even whole cases. It is premised on the creation of an alternative "bypass" task for each task in a process that may need to be cancelled. When a cancellation is initated, the case continues processing but the "bypass" tasks are executed rather than the normal tasks, so in effect no further work is actually achieved on the case.
Figure 30: Cancel region implementation
There is an important context condition associated with this pattern: cancellation of an executing case must be viewed as unsuccessful completion of the case. this means that even though the case was terminated in an orderly manner, perhaps even with tokens reaching its endpoint, this should not be interpreted in any way as a successful outcome. For example, where a log is kept of events occuring during process execution, the case should be recorded as incomplete or cancelled.
There is reasonable support for this pattern amongst the offerings examined. SAP Workflow provides the process control step for this purpose, FileNet provides the <Terminate Process> construct, BPEL provide the <terminate> construct, BPMN and XPDL provide support by including the entire process in a transaction with an associated end event that allows all executing tasks in a process instance to be terminated. Similarly UML 2.0 ADs achieve the same effect using the InterruptibleActivityRegion construct. FLOWer provide partial support for the pattern through its ability to skip or redo entire cases.
Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. If there are any side-effects associated with the cancellation (e.g. forced completion of other tasks, the process instance being marked as complete), then the offering is rated as having partial support.
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 directly supported, steps can be called via API calls.|
|Websphere MQ||3.4||-||Not supported. There is no means of cancelling an entire process instance.|
|FLOWer||3.51||+/-||It is possible to skip or redo an entire plan. However, skip and redo actions are always explicit user actions. Therefore, they provide only partial support. Note that by defining a data element named cancel and using this data element as a precondition for every activity in the flow it is possible to block a case. Although this is an elegant solution, it is still considered to be indirect.|
|COSA||5.1||-||Only supported through an API call.|
|iPlanet||3.0||-||Not supported. There is no means of terminating a process instance.|
|SAP Workflow||4.6c||+||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.|
|FileNet||3.5||+||Directly supported via <Terminate Process> step. Furthermore, if none of the conditions could be satisfied, the workflow terminates.|
|BPEL||1.1||+||Supported by <terminate> construct.|
|Websphere Integration Developer||6.0||+||Supported by the <terminate> activity.|
|Oracle BPEL||10.1.2||+||Supported by the <terminate> activity.|
|BPMN||1.0||+||Directly supported by including the entire process in a transaction. Triggering the cancel end event associated with the transaction will effectively terminate all activities associated with a process instance.|
|XPDL||2.0||+||Directly supported by including the entire process in a transaction. Triggering the cancel end event associated with the transaction will effectively terminate all activities associated with a process instance.|
|UML ADs||2.0||+||Supported by incorporating all of the activities in an interruptible region triggered either by a signal or execution of another activity.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||In jBPM a process can be forcibly ended at runtime using the Monitoring mode. A forcibly ended process (through the "Delete" command) is removed from the execution log. Therefore the Cancel Case pattern is not considered to be supported.|
|OpenWFE||1.7.3||+/-||OpenWFE supports this pattern through the notion of <cancel-process/>. However, any subprocesses invoked and running when <cancel-process/> is reached do not get cancelled. Therefore, the support is only considered to be partial.
Cancellation of a case can in practice be done by a system admininstrator through the command-line control program, but as this form of cancellation is rather a maintainance measure than a normal process activity, it is not considered to provide support for the cancel case pattern.
|Enhydra Shark||2||+||Enhydra Shark does not support cancel case during design time. However, it supports cancel case during run-time. A case can be cancelled through the administration console by selecting "Terminate" for a specific instance. The case's status is logged as closed.terminated.|