Pattern 19 (Cancel Task)

FLASH animation of Cancel Task pattern

Description

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.

Synonyms

Withdraw task.

Examples

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.

Motivation

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.

Overview

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

Context

There are no specific context conditions associated with the pattern.

Implementation

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.

Issues

None identified.

Solutions

N/A

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.