Pattern 24 (Persistent Trigger)
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.
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.
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.
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
There are no specific context conditions associated with the pattern.
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.
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.
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.
|Staffware||10||-||Not supported. However, by adding a dummy step, a transient trigger can be made persistent.|
|Websphere MQ||3.4||-||Not supported. There is no means of triggering an activity from outside the process instance.|
|FLOWer||3.51||+||Triggers can be modeled by setting data elements. There are various ways to wait for data, e.g., using guards on arcs or mandatory data elements of a milestone. This naturally corresponds to persistent triggers.|
|COSA||5.1||+||Supported through trigger construct in asynchronous mode.|
|iPlanet||3.0||-||No trigger support.|
|SAP Workflow||4.6c||+||It is possible to use the "wait for event" step with the setting "event via workflow". When waiting for an event via the workflow, the event is initially received and temporarily saved by the workflow. Once the wait step has been activated, the event is forwarded to the wait step.|
|FileNet||3.5||+||Directly supported via <WaitForCondition> and <Receive> steps.|
|BPEL||1.1||+||Supported by <pick> construct waiting on specific message type.|
|Websphere Integration Developer||6.0||+||Supported by the <pick> activity waiting on specific message type.|
|Oracle BPEL||10.1.2||+||Supported by the <pick> activity waiting on specific message type.|
|BPMN||1.0||+||Supported through the use of message events.|
|XPDL||2.0||+||Supported via message events.|
|UML ADs||2.0||+||Supported via signals.|
|EPC (implemented by ARIS toolset 6.2)||+/-||EPCs allow for multiple input events and these could be interpreted as persistent triggers. However, since it is not possible to differentiate between the creation of an instances an subsequent events and there is no implementation of this concept, we rate this as partial support.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support Persistent Triggers. In order to receive a trigger (such as a deadline expiration or a mail reception), a flow needs to be executing a specific task that can handle that trigger. This behaviour corresponds to the notion of transient trigger.|