IBM BPM, V8.0.1, All platforms > Create processes in IBM Process Designer > Modeling processes > Modeling events
Handing 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.
When you develop an application in IBM BPM, build error handling into BPDs and services to detect errors, to specify how errors are thrown and caught in your runtime environment, and to recover in a predictable manner.
For example, if a BPD involves filling orders, an item might be out of stock during one instance of the BPD, which causes an error. Error handling that you build into the BPD could create notifications to replenish items that are out of stock.
There are three types of error events: error end events in BPDs and services that throw errors, error intermediate events in BPDs and services that catch errors, and error start events in BPD event subprocesses that catch errors.
You can assign error codes and error data to errors that are thrown by the error end events.
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.
However you decide to catch errors, designate the error behavior for the events on the Properties tab in your diagram. Under Implementation, go to the Error Properties section to designate the following error handling behavior:
- 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.
If the error code has changed, 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.
Errors are caught in the following order in your runtime environment:
- 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.
Error event components 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
Multiple events that are defined in the same context and with the same constraints cause nondeterministic runtime behavior.
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.
- Handling errors in BPDs
When modeling error handling as part of your business process definitions (BPDs), you can catch errors using error intermediate events or event subprocesses, and you can throw errors using error end events.- Handling errors in services
For services, you can use error intermediate events to catch errors, and you can use error end events to throw errors.- Use error events in models from V7.5.x and earlier
If you have Process Designer models from V7.5.x or earlier that use error events, the earlier error handling behavior is still available.