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:

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:

  1. The boundary events catch errors that are raised by the attached activity, as described in the following table.

  2. 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.

  3. 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.

Modeling events