Boundary events are catching events that are attached to an activity (a boundary event can never be throwing). This means that while the activity is running, the event is listening for a certain type of trigger. When the event is caught, the activity is interrupted and the sequence flows going out of the event are followed.
Boundary Timer Event
A boundary timer event acts as a stopwatch and alarm clock. When an execution arrives in the activity that the boundary event is attached to, a timer is started. When the timer fires (e.g. after a specified interval), the activity is interrupted and the boundary event sequence flows are 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 has not yet arrived at the element to which the timer is attached, the timer will not fire. Similarly, if the execution arrives at the element to which the timer is attached 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 element is reached. |
| Time Cycle | Once execution has arrived at the element to which the timer is attached, fire this timer on a repeating cycle |
| Time Cycle End Time | Can be used to override the end time set in the time cycle property |
| Cancel Activity | If checked the activity to which the timer is attached will be cancelled |
The Workflow Engine and UTC
- The workflow engine works in UTC - it is recommended that all ISO8601 time strings include the "Z" at the end to make this clear
- Local times must be converted to UTC when scheduling activities to happen at specific times. This can be done using a workflow script activity.
- If we change from GMT to BST while a repeating timer that runs every day is running, it will begin running an hour later in local time after the change, and the reverse will apply if we change from BST to GMT.
- Where a job must run at the same local time every day, a script activity must be used to compute the next time to run - this can make use of standard Java classes.
Boundary Error Event
An intermediate catching error on the boundary of an activity catches errors that are thrown within the scope of the activity on which it is defined. Errors can be thrown explicitly by the End Error Event, or by the iCM API Server Task, iCM API Data Integration Task, or iCM API Server History task where this has been configured.
Defining a boundary error event makes most sense on an embedded subprocess, or a call activity, as a subprocess creates a scope for all activities inside the subprocess. Errors are thrown by error end events. Such an error will propagate its parent scopes upwards until a scope is found on which a boundary error event is defined that matches the error event definition.
When an error event is caught, the activity on which the boundary event is defined is destroyed, also destroying all current executions within (e.g. concurrent activities, nested subprocesses, etc.). Process execution continues following the outgoing sequence flow of the boundary error event.
| 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 |
| Error Reference | The name of the error that will be caught |
Boundary Signal Event
An attached intermediate catching signal on the boundary of an activity 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.
Unlike other boundary events, a boundary signal event does not only catch signal events thrown from the scope it is attached to. A signal event has 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 boundary events catching the same signal event, both boundary events are triggered, even if they are part of different process instances.
| 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 |
| Cancel Activity | If checked the activity to which the event is attached will be cancelled |
Boundary Message Event
An attached intermediate catching message on the boundary of an activity catches messages with the same message name as the referenced message definition. Note that unlike signals, messages are sent to a specific process instance.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | The name of the form that will be used to send this message |
| Description | An optional description for this element |
| Message Reference | The name of the message that will be caught The special GOSS_StarterCancel reference is used by the GOSS Self Service and user Request Templates. You should include this reference in the "Workflow - Message Action" field type of the cancellation form you are planning to use |
| Cancel Activity | If checked the activity to which the event is attached will be cancelled |
Sending Messages
There are a number of ways in which a workflow can be sent a message:
- Scripts in forms or end points can message a process instance by sending an API Server request to the workflow worker using sendMessage
- Another workflow, or the same workflow, can send the message via a workflow script activity
- Template code can message a workflow following a form submission - this has been implemented in the support for cancel forms in Self Service and User Requests, see Building Cancellation into your Workflow Models
- The workflow worker automatically sends a message back to the relevant process instance with a reference in the format
_<taskid>_claimed ,_<taskid>_released , or_<taskid>_completed when a task is claimed, released, or completed in that process instance. You could catch these messages elsewhere in your model. A corresponding process variable is also generated which can be used following receipt of this message to identify the user who performed the operation, as described in Standard Process Variables
Boundary Cancel Event
An attached intermediate catching cancel on the boundary of a transaction subprocess is triggered when a transaction is cancelled. When the boundary cancel event is triggered, it first interrupts all executions active in the current scope. Next, it starts compensation of all active compensation boundary events in the scope of the transaction. Compensation is performed synchronously, i.e. the boundary event waits before compensation is completed before leaving the transaction. When compensation is completed, the transaction sub process is left using the sequence flow(s) running out of the cancel boundary event.
Note
Only a single boundary cancel event is allowed for a transaction subprocess.
If the transaction subprocess hosts nested subprocesses, compensation is only triggered for subprocesses that have completed successfully.
If a boundary cancel event is placed on a transaction subprocess with multi instance characteristics, if one instance triggers cancellation, the boundary event cancels all instances.
Boundary Compensation Event
An attached intermediate catching compensation on the boundary of an activity can be used to attach a compensation handler to an activity.
The boundary compensation event must reference a single compensation handler using a directed association.
A boundary compensation event has a different activation policy from other boundary events. Other boundary events like, for example, the boundary signal event, are activated when the activity they are attached to is started. When the activity is left, they are deactivated and the corresponding event subscription is cancelled. The boundary compensation event is different. The boundary compensation event is activated when the activity it is attached to completes successfully. At this point, the corresponding subscription to the compensation events is created. The subscription is removed either when a compensation event is triggered or when the corresponding process instance ends. From this, it follows:
- When compensation is triggered, the compensation handler associated with the boundary compensation event is invoked the same number of times the activity it is attached to completed successfully.
- If a boundary compensation event is attached to an activity with multiple instance characteristics, a compensation event subscription is created for each instance.
- If a boundary compensation event is attached to an activity which is contained inside a loop, a compensation event subscription is created for each time the activity is executed.
- If the process instance ends, the subscriptions to compensation events are cancelled.
Note, the boundary compensation event is not supported on embedded subprocesses.
Share this page
