Pattern 25 (Cancel Region)

FLASH animation of Cancel Region pattern

Description

The ability to disable a set of tasks in a process instance. If any of the tasks are already executing (or are currently enabled), then they are withdrawn. The tasks need not be a connected subset of the overall process model.

Examples

Stop any tasks in the Prosecution process which access the evidence database from running

Withdraw all tasks in the Waybill Booking process after the freight-lodgement task

Motivation

The option of being able to cancel a series of (potentially unrelated) tasks is a useful capability, particularly for handling unexpected errors or for implementing forms of exception handling.

Figure 39: Cancel region implementation

Overview

The general form of this pattern is illustrated in Figure 39. It is based on the premise that every task in the required region has an alternate "bypass" task. When the cancellation of the region is required, the process instance continues execution, but the bypass tasks are executed instead of the original tasks. As a consequence, no further work occurs on the tasks in the cancellation region. However, as shown for the Cancel Case (WCP20) pattern, there are several alternative mechanisms that can be used to cancel parts of a process.

Context

There are no specific context conditions associated with the pattern.

Implementation

The concept of cancellation regions is not widely supported. Staffware offers the opportunity to withdraw steps but only if they have not already commenced execution. FLOWer allows individual tasks to be skipped but there is no means of cancelling a group of tasks. UML 2.0 Activity Diagrams is the only offering examined which provides complete support for this pattern: the InterruptibleActivityRegion construct allow a set of tasks to be cancelled. BPMN and XPDL offer partial support by enclosing the tasks that will potentially be cancelled in a subprocess and associating an error event with the subprocess to trigger cancellation when it is required. In both cases, the shortcoming of this approach is that the tasks in the subprocess must be a connected subgraph of the overall process model. Similarly BPEL only supports cancellation of tasks in the same scope hence it also achieves a partial rating. As COSA has an integrated notion of state, it is possible to implement cancellation regions in a similar way that presented in Figure 39 however the overall process model is likely to become intractable for cancellation regions of any reasonable scale hence this is viewed as partial support.

Issues

One issue that can arise with the implementation of the Cancel Region pattern occurs when the cancelling task lies within the cancellation region. Although this task must run to completion and cause the cancellation of all of the tasks in the defined cancellation region, once this has been completed, it too must be cancelled.

Solutions

The most effective solution to this problem is to ensure that the cancelling task is the last of those to be processed (i.e. the last to be terminated) of the tasks in the cancellation region. The actual cancellation occurs when the task to which the cancellation region is attached completes execution.

Evaluation Criteria

An offering achieves full support if it provides a construct that satisfies the description for the pattern. It rates as partial support if the process model must be changed in any way (e.g. use of subprocesses, inclusion of bypass tasks) in order to accommodate cancellation regions.

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.