Pattern 23 (Transient Trigger)
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.
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.
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.
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)
There are no specific context conditions associated with the pattern.
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.
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).
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.
An offering achieves full support if it provides a construct that satisfies the description for the pattern.
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||+||The event step construct allows external signals to trigger steps, cases and also to resume suspended steps.|
|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. The data elements can be considered as persistent. To model transient triggers one needs to reset the data value shortly after it has been set.|
|COSA||5.1||+||Supported through trigger construct in synchronous mode.|
|iPlanet||3.0||-||No trigger support.|
|SAP Workflow||4.6c||+||SAP offer a "wait for event" step that can be used to wait for an event. This step has different settings. The standard mechanism is that events are not queued. There is an event queue but this is just there for performance reasons.|
|BPEL||1.1||-||Not supported. Messages are durable in form.|
|Websphere Integration Developer||6.0||-||Not supported. Messages are durable in form.|
|Oracle BPEL||10.1.2||-||Not supported. Messages are durable in form.|
|BPMN||1.0||-||Not supported. Triggers are supported through durable messages.|
|XPDL||2.0||-||Not supported. Triggers are supported through durable message events.|
|UML ADs||2.0||+||Supported using the AcceptEventAction construct for singal processing with explicit enablement.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||+||jBPM supports transient triggers through the notion of State. When a process instance reaches a state on its execution path, it awaits for a signal in order to leave the state and continue execution.
The concept of Timer is also present in jPDL. However, currently timers does not work in the engine when XML process definitions have been deployed to the engine and instances of them initiated from the web console interface.
|OpenWFE||1.7.3||+||OpenWFE provides support for this pattern through the notion of <sleep until="date"/> construct.|
|Enhydra Shark||2||-||Enhydra Shark supports transient triggers through Deadline on activities. Deadlines can be put on routing activities, which will then act as waiting states for a process expiring at the defined time point. However, we did not manage to get the deadline functionality working. (The example provided by Enhydra on Deadline expiration did not work in our tests.)
Another typical example of transient triggers is activities denoting email reception. Enhydra Shark provides a set of Tool Agents. A Tool Agent defines the interface to a data source or an application in the operational environment. A MailToolAgents is dedicated for implementing the connectivity needed for sending and receiving mails. However, in the evaluated version of the tool, the MailToolAgent did not work.