Event
Flow Event
Start Event
A start event is the starting point of a process. It is a basic event which does nothing special if its shape is set to none as we see in a section below.
A start event must start a process flow and can define a data output mapping to a data object in order to capture the message payload. A single start event is currently only supported.
Message
A start message event is a start event specialized shape. It is used to get data when starting a process.
When creating a message start event, a Message Event must be set in the attributes as seen in the figure above. No item definition is needed.
No data type must be set to the start event shape, but a Data Output must be set. Data type binding is then done automatically depending on the output’s data type.
Also, no operation needs to be set.
Message events allow to specify correlation filters to be able to properly target process instances based on incoming messages.
-
Message content filter - filters message content based on defined FEEL expression to identify if the message should be consumed
Timer
A timer set to a start event allows to specify when to start a published process. It means that once the process is published, no action is needed to start the service. The triggering of the service relies on the timer’s configuration.
A timer event acts like an alarm. It can be programmed to be triggered at a specific date, through a cycle or a duration:
-
Specific date option triggers an event once and only once at, as its name says, a specific date
-
Duration triggers an event after a certain amount of time
-
Cycle allows to specify an interval between triggering of an event and occurrences
It must be noted that the timer event supports two norms: ISO8601 and iCalendar Recurrence Rule.
The cycle option is the most complete and complex of the three options available and offers great flexibility on when to trigger an event.
In the figure above, we can see that a start date can be set. At the time of publishing the process, if the start date is overdue and the timer is associated with a start event, the process is immediately triggered.
End behavior can also be set. If set to “Never”, the events are triggered indefinitely.
If set to “After a specific number of occurrences”, the event will be triggered a specified number of occurrences and after that will not be triggered again. In this case, the event will be triggered after a certain amount of time specified the “Repeats every” section. In that section, a lap can be set from years to seconds.
|
Time expression can be relative to two points in time:
|
Escalation
| Escalation event is only available on start event embedded in event sub process. |
This event can specify Escalation code and/or time expression.
When escalation code is set, this event node will wait until matching escalation is thrown (by either intermediate or end escalation event).
When time expression is set, this event node will wait until given time elapses and then trigger escalation automatically.
When both (escalation code and time expression) are set then which ever arrives earlier will trigger the escalation.
|
Time expression can be relative to two points in time:
|
Intermediate Event
An intermediate event is integrated in a process flow but does not start the process flow. It would be triggered by an event or throw an event, depending on what has been set (message, timer…).
Some data output and data output mapping can be done.
Message
| Catching | Throwing |
|---|---|
Yes |
No |
A message can be set to an intermediate event. If so, a message event must be set. Contrary to a start event, an item definition must be set. It must be noticed that a data output must also be set, and the data output mapping must be handled consequently.
Message events allow to specify correlation filters to be able to properly target process instances based on incoming messages.
-
Message content filter - filters message content based on defined FEEL expression to identify if the message should be consumed
-
Process instance tag matching - FEEL expression used to extract part of the message that should be used to find process instances based on tags
-
Process instance data filter - FEEL expression used to filter process instances that have data objects that match the expression
| It is highly recommended to make use of Message correlation in all cases |
Timer
| Catching | Throwing |
|---|---|
Yes |
No |
If set to an intermediate event, when reached in the process flow, it will create a resume point and the process instance will be paused. From that point, two possibilities are available to resume the process:
-
The resume point is triggered through a resume point before the timer’s expected trigger time. Then, the process flow will continue until one or multiple ends are reached.
-
The resume point is triggered by the timer itself. Then, the process flow will continue until one or multiple ends are reached. After that, the resume point will not be available anymore.
|
Time expression can be relative to two points in time:
|
Escalation
| Catching | Throwing |
|---|---|
No |
Yes |
When an escalation event is triggered by an escalation throwing event, an escalation event is thrown and catch by an escalation catching event. For that behavior to happen, the throwing event and the catching event must be set with the same escalation event.
It must be noticed that an intermediate event can only be a throwing escalation event and cannot be a catching event. The thrown escalation event can be then be caught by an escalation start event shape in an event sub-process.
If an escalation event is thrown, an escalation start event set with the same escalation event and starting an event sub-process can then be triggered. Also, if an escalation event is thrown from a sub-process, it can be caught in the main process by a boundary event attached to the sub-process shape and set with the same escalation event.
Conditional
| Catching | Throwing |
|---|---|
Yes |
No |
A conditional event can be defined based on the process variables to trigger when the value of an expression is evaluated to true:
Link
| Catching | Throwing |
|---|---|
Yes |
Yes |
A link event can be set to an intermediate event shape. In the case of a throwing link event, the event shape is integrated in a main flow. In the case of an intermediate catch event, the intermediate event shape must start a subpar process.
In the figure above, a link event has been set. In the main flow, when reached, the intermediate event node will trigger a link event which then would be caught by the intermediate catch link event set with the same link event. The two paths will be triggered during the execution of the process.
End Event
An end event closes a process flow. It comes at the end of the process, but multiple ends could be available in the same process.
Terminate
Terminate end event will end entire process instance regardless if there were any active tasks.
Escalation
An escalation event can set to an end event. It works just like an intermediate escalation event. The event thrown can be caught in the parent process by an intermediate escalation catch event attached to the sub-process shape and/or in an event sub-process.
Error
As seen in the figure above, an error event must be set. A name and an error code are mandatory. When the end point is triggered, the defined error event is then being thrown.
Error end events can be used to indicate a business error that will be considered a valid response of the service.
The error code attribute is used to decide which HTTP code is returned by the service:
-
numeric error codes within the range of 100 to 999 will be directly set as response code on the service response (HTTP response)
-
non-numeric or outside of the above range will be represented as
500service response
When an error end event is processed, service response will only include the data mapped to the error end event and no other data outputs. Thus it is recommended to always map relevant data to error end events to provide meaningful service response.
When using numeric error code there is a probability of selecting a code that is already used by the engine e.g. 401 (that is used to indicate not authorized). In that case, the service definition (OpenAPI) will indicate that the HTTP code could return either of the responses.
|
Boundary Event
If an intermediate event is attached to a task’s shape, it is then labeled as a boundary event. A boundary event is allowed on certain types of task shape which create a resume point such as human or manual task. It is also allowed on a sub-process’s shape.
The main difference with an intermediate event is that when triggered, a boundary event will resume the process flow but instead of completing all the available paths, the one associated to the boundary event will be used.
In the figure above, a boundary event is attached to the manual task’s shape. When the manual task is reached in the process flow, a resume point will be created for the manual task and a resume point will also be created for the attached boundary event.
If the resume point created for the manual task is triggered, then the path ending with the end point E1 will be followed. Instead, if the resume point created for the boundary event is triggered, then the path leading to the end point E2 will be followed.
If one resume point is triggered, whichever one, the other one will then not be available any more.
Boundary events can be
-
interrupting - will cancel activity that it is attached to
-
non interrupting - will leave the activity it is attached to running
Message
Just like intermediate message catching event, a message event must be set, and an item definition must be attached to it. Data output and data output mapping must be handled too.
Signal
Just like intermediate signal catching event allows to receive an trigger from outside to continue execution.
Timer
Timer’s configuration is the same as in the case of a timer start event. When the shape which it is attached to is reached, a specific resume point will be created for the boundary timer event.
|
Time expression can be relative to two points in time:
|
Escalation
An escalation event can be attached to a sub-process or a call activity shape. If so, it would catch an escalation event thrown from the sub-process. It can also be attached to a task to catch escalation thrown within the scope of the process instance.
This event can specify Escalation code and/or time expression.
When escalation code is set, this event node will wait until matching escalation is thrown (by either intermediate or end escalation event).
When time expression is set, this event node will wait until given time elapses and then trigger escalation automatically.
When both (escalation code and time expression) are set then whichever arrives earlier will trigger the escalation.
|
Time expression can be relative to two points in time:
|
Conditional
Conditional boundary event allows to define condition based on the process data to be triggered as soon as the condition is met.