Error events
Error Events expand the capabilities of process modeling and error handling within BPMN processing. These Error Event nodes enhance the BPMN standard and offer improved control over error management.
Intermediate event - error event (interrupting)
Compatibility matrix for Error Events
Error Events are used to handle error scenarios within BPMN processes. The following table outlines their compatibility with different node types:
| Node Type | Error Boundary Event |
|---|---|
| User Task | Yes |
| Service Task | Yes |
| Send Message Task | Yes |
| Receive Message Task | Yes |
| Subprocess | Yes |
| Call Activity | Yes |
Key characteristics
-
Boundary of an Activity node or Subprocess:
- Error Events can only be used on the boundary of an activity, including subprocesses nodes. They cannot be placed in the normal flow of the process.
-
Always Interrupt the Activity:
- It’s important to note that Error Events always interrupt the activity to which they are attached. There is no non-interrupting version of Error Events.
-
Handling Thrown Errors:
- A thrown error, represented by an Error Event, can be caught by an Error Catch Event. This is achieved specifically using an Error Boundary Event, which is placed on the boundary of the corresponding activity.
-
Using error events on Subprocesses nodes:
- An error catch event can be linked to a subprocess, with the error source residing within the subprocess itself, denoted by the presence of an error end event, signifying an abnormal termination of the subprocess.
Configuring an Error Intermediate boundary event
- Name: Assign a name to the event for easy identification.
- Condition: Specify the condition that triggers the error event. Various script languages can be used for defining conditions, including:
- MVEL
- JavaScript
- Python
To draw a sequence from an error event node and link it to other nodes, simply follow these steps: right-click on the node, and then select the option to “Add Sequence.”
When crafting a condition, use a predefined key as illustrated below:
For instance, in the example provided, we’ve taken a process key defined on a switch UI element and constructed a user-defined condition like this: input.application.switch == true.
- Priority: Determine the priority level of this error event in relation to other error events added on the same node.
When multiple error events are configured for a node, and multiple conditions simultaneously evaluate to true, only one condition can interrupt the ongoing activity and advance the token to the next node. The determination of which condition takes precedence is based on the “priority” field.
If the “priority” field is set to “null,” the system will randomly select one of the active conditions to trigger the interruption.
-
input.application.switch: This represents a key to bind a value to the Switch UI element within the “application” part of the “input”. It is used in this example to capture input or configuration from a user. -
==: This is an equality operator, and it checks if the value on the left is equal to the value on the right. -
trueis a boolean value, which typically represents a state of “true” or “on.”
So, when you put it all together, the statement is checking if the value of the “input.application.switch” is equal to the string “true.” If the value of “input.application.switch” is indeed “true” (as a string), the condition is considered true. If the value is anything other than “true,” the condition is false and the error is triggered.
Use case: handling errors during User Task execution
Description: This use case pertains to a page dedicated to collecting client contact data. Specifically, it deals with scenarios where users are given the opportunity to verify their email addresses and phone numbers.
In this scenario we will create a process to throw an error if an email address is not valid.
Example configuration
-
Error Boundary Event: We will set an error boundary event associated with a user task.
-
Error Node: The node will be responsible to redirect the user to other flows after the user’s email address is validated based on the conditions defined.
The expression checks if the email address configured in application.client.contactData.email.emailAddress key is not equal to “john.doe@email.com.” If they are not the same, it evaluates to true, indicating a mismatch.
- Flow Control: Depending on the outcome of the validation process, users will be directed to different flows, which may involve displaying error modals as appropriate.