Pattern 24 (Persistent Trigger)

FLASH animation of Persistent Trigger pattern

Description

The ability for a task to be triggered by a signal from another part of the process or from the external environment. These triggers are persistent in form and are retained by the process until they can be acted on by the receiving task.

Examples

Initiate the Staff Induction task each time a new staff member event occurs

Start a new instance of the Inspect Vehicle task for each service overdue signal that is received.

Motivation

Persistent triggers are inherently durable in nature, ensuring that they are not lost in transit and are buffered until they can be dealt with by the target task. This means that the singalling task can be certain that the trigger will result in the task to which the are directed being initiated either immediately (if it already has received the thread of control) or at some future time.

Overview

There are two variants of the persistent triggers. Figure 37 illustrates the situation where a trigger is buffered until control-flow passes to the task to which the trigger is directed. Once this task has received a trigger, it can commence execution. Alternatively, the trigger can initiate a task (or the beginning of a thread of execution) that is not contingent on the completion of any preceding tasks. This scenario is illustrated by Figure 38.

Figure 37: Persistent trigger pattern

Context

There are no specific context conditions associated with the pattern.

Implementation

Of the offerings examined, COSA provide support for persistent triggers via its integrated trigger construct, SAP Workflow has the "wait for event" step construct, FLOWer and FileNet provide the ability for tasks to wait on specific data conditions that can be updated from outside the process. The business process modelling formalisms BPMN, XPDL and BPEL all provide a mechanism for this form of triggering via messages and in all cases the messages are assumed to be durable in nature and can either trigger a standalone task or can enable a blocked task waiting on receipt of a message to continue. UML 2.0 Activity Diagrams provide a similar facility using signals. Although EPCs provide support for multiple input events which can be utilized as persistent triggers, it is not possible to differentiate between them hence this is viewed as partial support.

Figure 38: Persistent trigger pattern (new execution thread variant)

Note that if the pattern is not directly supported, it is often possible to implement persistent triggers indirectly by adding a dummy task which "catches" the trigger.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support for this pattern if it has a construct that satisfies the description for the pattern. If triggers do not retain a discrete identity when received and/or stored, an offering is viewed as providing 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.