Pattern 23 (Transient Trigger)

FLASH animation of Transient Trigger pattern

Description

The ability for a task instance to be triggered by a signal from another part of the process or from the external environment. These triggers are transient in nature and are lost if not acted on immediately by the receiving task. A trigger can only be utilized if there is a task instance waiting for it at the time it is received.

Examples

Start the Handle Overflow task immediately when the dam capacity full signal is received.

If possible, initiated the Check Sensor task each time an alarm trigger signal is received.

Motivation

Transient triggers are a common means of signalling that a pre-defined event has occured and that an appropriate handling response should be undertaken - comprising either the initiation of a single task, a sequence of tasks or a new thread of execution in a process. Transient triggers are events which must be dealt with as soon as they are received. In other words, they must result in the immediate initiation of a task. The process provides no form of memory for transient triggers. If they are not acted on immediately, they are irrevocably lost.

Overview

There are two main variants of this pattern depending on whether the process is executing in a safe execution environment or not. Figure 35 shows the safe variant, only one instance of task B can wait on a trigger at any given time. Note that place p2 holds a token for any possible process instance. This place makes sure that at most one instance of task B exists at any time.

Figure 35: Transient trigger pattern (safe variant)

The alternative option for unsafe processes is shown in Figure 36. Multiple instances of task B can remain waiting for a trigger to be received. However only one of these can be enabled for each trigger when it is received.

Figure 36: Transient trigger pattern (unsafe variant)

Context

There are no specific context conditions associated with the pattern.

Implementation

Staffware provides support for transient triggers via the Event Step construct. Similarly COSA provides a trigger construct which can operate in both synchronous and asynchronous mode supporting transient and persistent triggers respectively. Both of these offerings implement the safe form of the pattern (as illustrated in Figure 35). SAP Workflow provides similar support via the "wait for event" step construct. UML 2.0 ADs provide the ability for signals to be discarded where there are not immediately required through the explicit enablement feature of the AcceptEventAction construct which is responsible for handling incoming signals.

Issues

One consideration that arises with the use of transient triggers is what happens when multiple triggers are received simultaneously or in a very short time interval. Are the latter triggers inherently lost as a trigger instance is already pending or are all instances preserved (albeit for a potentially short timeframe).

Solutions

In general, in the implementations examined (Staffware, COSA and SAP Workflow) it seems that all transient triggers are lost if they are not immediately consumed. There is no provision for transient triggers to be duplicated.

Evaluation Criteria

An offering achieves full support if it provides a construct that satisfies the description for the pattern.

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.