Pattern 20 (Cancel Case)

FLASH animation of Cancel Case pattern

Description

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.

Synonyms

Withdraw case.

Examples

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.

Motivation

This pattern provides a means of halting a specified process instance and withdrawing any tasks associated with it.

Overview

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

Context

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.

Implementation

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.

Issues

None identified.

Solutions

N/A

Evaluation Criteria

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.

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.