Handling errors using error events
When you design a business process definition (BPD) or a service, provide logic to recover from possible errors that might be generated in the runtime application.
- To detect errors.
- To specify how errors are thrown and caught in your runtime environment.
- To recover in a predictable manner.
- Error end events in BPDs and services that throw errors
- Error intermediate events in BPDs and services that catch errors
- Error start events in BPD event subprocesses that catch errors
To catch errors using error intermediate events, select an error code from a list of previously defined errors and map the error data to a variable. The error intermediate events are boundary events, which are intermediate events that are attached to the boundary of an activity. Each boundary event can be triggered only while the activity is running, interrupting the activity. From the BPD diagram or a service diagram in Process Designer, you can use an error intermediate event that is attached to the boundary of an active to catch specific errors and error data from a linked process, a subprocess, or a service.
Another way to catch errors is by using error intermediate events in services that catch all errors. When building services, you can attach an error intermediate event to the boundary of a step to catch all errors for the step, and you can use an error intermediate event as part of the service flow to catch all errors that are raised by steps of the service flow that are not handled by an error intermediate event at the boundary of the step.
You also can catch errors using error event subprocesses in BPDs. In the subprocess, you use an error start event that catches errors if the start event is triggered.
- Catch all errors or specific errors. To catch specific errors, you can select the error code, map the error data, or both, as described in the following bullets.
- Filter the specific errors that are caught by selecting an error code from a list of all thrown errors for the linked process, subprocess, or service.
- Map the error data into a variable by selecting an error mapping
variable that was previously defined on the Variables tab. Important: If the error code has changed, make sure to select the variable again so that it is mapped properly.
If there are multiple error events defined to catch errors for an error that is thrown in a linked process, subprocess, or service, the catching event is determined by the precedence rules in the order that they are listed in the Error event components table.
- The boundary events catch errors that are raised by the attached activity, as described in the following table.
- If there is no error boundary event that handles the error, and a subprocess is in a BPD or in an unattached intermediate error event in a service, errors are caught in the error event subprocesses, as described in the following table.
- If there is no error event subprocess that handles the error in an event subprocess, linked process, or service, errors are propagated to the next level.
Specify | Errors caught |
---|---|
error code and error data |
Only errors with the same code and data type |
error code |
Errors with the same code, unless they are already caught by an event, as specified by the preceding rule |
error data |
Errors with the same data type, unless they are already caught by an event, as specified by the preceding rules |
neither code nor error data or the Catch All Errors option on error properties |
All errors that are not already caught by an event, as specified by the preceding rules |
Specifying the variable name in the mapping controls the filtering by error data type. If the type of the variable and the type of the error data that is displayed on the Properties tab do not match, the variable type determines the behavior.