Pattern 19 (Cancel Task)

FLASH animation of Cancel Task pattern


An enabled task is withdrawn prior to it commencing execution. If the task has started, it is disabled and, where possible, the currently running instance is halted and removed.


Withdraw task.


The access damage task is undertaken by two insurance assessors. Once the first assessor has completed the task, the second is cancelled;

The purchaser can cancel their building inspection task at any time before it commences.


The Cancel Task pattern provides the ability to withdraw a task which has been enabled or is already executing. This ensures that it will not commence or complete execution.


The general interpretation of the Cancel Task pattern is illustrated by Figure 25. The trigger which has enabled task B is removed, preventing the task from proceeding.

Figure 25: Cancel task pattern (variant 1)

There is also a second variant of the pattern where the task has already commenced execution but has not yet completed. This scenario is shown in Figure 26, where a task which has been enabled or is currently executing can be cancelled. It is important to note for both variants that cancellation is not guaranteed and it is possible that the task will continue executing to completion. In effect, the cancellation vs continuation decision operates as a Deferred Choice with a race condition being set up between the cancellation event and the much slower task of resources responding to work assignment. For all practical purposes, it is much more likely that the cancellation will be effected rather than the task being continued.

Figure 26: Cancel task pattern (variant 2)

Where guaranteed cancellation is required, the implementation of tasks should take the form illustrated in Figure 27. The decision to cancel task B can only be made after it has been enabled and prior to it completing. Once this decision is made, it is not possible for the task to progress any further. For obvious reasons, it is not possible to cancel a task which has not been enabled (i.e. there is no "memory" associated with the action of cancelling a task in the way that there is for triggers) nor is it possible to cancel a task which has already completed execution.

Figure 27: Cancel task pattern with guaranteed termination



There are no specific context conditions associated with the pattern.


The majority of the offerings examined provide support for this pattern within their process models. Most support the first variant as illustrated in Figure 25: Staffware does so with the withdraw construct, COSA allows tokens to be withdrawn from the places before tasks, iPlanet provides the AbortActivity method, FileNet provides the <Terminate Branch> construct and SAP Workflow provides the process control step for this purpose although it has limited usage. BPEL supports the second variant via fault compensation handlers attached to tasks, as do BPMN and XPDL using error type triggers attached to the boundary of the task to be cancelled. UML 2.0 ADs provide a similiar capability by placing the task to be cancelled in an interruptible region triggered by a signal or another task. FLOWer does not directly support the pattern although tasks can be skipped and redone.


None identified.



Evaluation Criteria

An offering achieves full support for this pattern if it provides a construct that satisfies the description for the pattern. If there are any side-effects associated with the cancellation (e.g. forced completion of other tasks, the cancelled task being marked as complete), the offering is rated as having partial support.

Product Evaluation

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 + Supported through the withdraw construct, i.e., a line entering a step from above.
Websphere MQ 3.4 - Not supported. There is no means of denoting activity cancellation with a process model.
FLOWer 3.51 +/- It is possible to skip or redo activities. However, it is not possible to withdraw an activity in one branch triggered by an activity in another branch. Skip and redo are explicit user actions. Therefore, they provide only partial support.
COSA 5.1 + Supported by removing tokens from input places.
iPlanet 3.0 + Supported via the AbortActivity method
SAP Workflow 4.6c + 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.
FileNet 3.5 + Directly supported via <Terminate Branch> step.
BPEL 1.1 + Supported through fault and compensation handlers.
Websphere Integration Developer 6.0 + Supported through fault and compensation handlers.
Oracle BPEL 10.1.2 + Supported by associating a fault or compensation handler with an activity.
BPMN 1.0 + Supported via an error type intermediate event trigger attached to the boundary of the activity to be cancelled.
XPDL 2.0 + Supported via an error type trigger attached to the boundary of the activity to be cancelled.
UML ADs 2.0 + Supported by incorporating the activity in an interruptible region triggered either by a signal or execution of another activity.
EPC (implemented by ARIS toolset 6.2) - Not supported. There is no cancellation feature.
jBPM 3.1.4 +

In jBPM a task can be forcibly ended using the Monitoring mode at runtime. A forcibly ended task (through the "End" command) remains in the execution log.

OpenWFE 1.7.3 - OpenWFE Cancellation of an activity can in practice be done by a system administrator through the command-line control program, but as this form of cancellation is rather a maintenance measure than a normal process activity, it is not considered to provide support for the cancel activity pattern.
Enhydra Shark 2 - Enhydra Shark does not support this pattern. At design time it is not possible to indicate cancellation of activities. (At run time, the options under Activity Management console, among them "terminate activity", are not enabled in the evaluated version of Shark.)