Catching events are placed in between activities, pausing the sequence flow until they are triggered.
Intermediate Timer Catching Event
![Intermediate timer](/image/1817/Intermediate-timer-catching-event/gi-responsive__100.png?lastModified=1443106842463)
An intermediate timer event acts as a stopwatch. When an execution arrives in catching event activity, a timer is started. When the timer fires (e.g. after a specified interval), the sequence flow going out of the timer intermediate event is followed.
Property | Description |
---|---|
ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
Name | A name for this element |
Description | An optional description for this element |
Start Date | The date and time on which this timer should fire. Note that if the execution arrives at the timer after the date/time set in the timer, it will have no effect |
Time Duration | The time between the execution arriving at this element and the timer firing. The duration will start counting down as soon as the timer is reached |
Time Cycle | Once execution has arrived at the element to which the timer is attached, fire this timer on a repeating cycle. This property doesn't make much sense here. Once the cycle has fired once, the execution will move on |
Time Cycle End Time | Can be used to override the end time set in the time cycle property |
Intermediate Signal Catching Event
![Intermediate signal](/image/1816/Intermediate-signal-catching-event/gi-responsive__100.png?lastModified=1443110051083)
An intermediate signal catching event catches signals with the same signal name as the referenced signal definition. Signals are defined in the advanced tab when editing the properties of the model itself. They can be used to pause a process execution, only allowing the flow to continue once a signal has been received.
Unlike other intermediate events, an intermediate signal event does not only catch signal events thrown from the scope it is attached to. A signal event can have a global scope (broadcast semantics) meaning that the signal can be thrown from any place, even from a different process instance. A signal is not consumed if it is caught. If you have two active signal events catching the same signal event, both intermediate events are triggered, even if they are part of different process instances.
There's a more detailed look at signals in the Messages and Signals knowledge base article.
Property | Description |
---|---|
ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
Name | A name for this element |
Description | An optional description for this element |
Signal Reference | The name of the signal that will be caught. Note that signal references have to first be defined in the advanced tab when editing the properties of the model itself |
Example
![Example Intermediate Signal Event](/image/2328/Example-Intermediate-Signal-Event/gi-responsive__100.png?lastModified=1482325133187)
In the above example the exam paper can be marked, but the result email won't be released until a signal is received.
Intermediate Message Catching Event
![a](/image/1845/Intermediate-message-catching-event/gi-responsive__100.png?lastModified=1443109768393)
An intermediate message catching event catches messages with a specified name. They can be used to pause a process execution, only allowing the flow to continue once a message has been received. Note that unlike signals, messages are sent to a specific process instance.
There's a more detailed look at messages in the Messages and Signals knowledge base article.
Property | Description |
---|---|
ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
Name | A name for this element |
Description | An optional description for this element |
Message Reference | The name of the message that will be caught |
Sending Messages
There are a number of ways in which a workflow can be sent a message:
- A form script or End Point can message a workflow by sending an API Server request to the workflow worker
- Another workflow or the same workflow can send the message via a workflow script
- Template code can message a workflow following a form submission - this has been implemented in the support for cancel forms in the GOSS Self Service Template.
- The workflow worker automatically sends a message in the format
_<taskid>_claimed ,_<taskid>_released , or_<taskid>_completed when a task is claimed, released, or completed. A corresponding process variable is also generated.