Handling errors using error events

When you design a process or a service, provide logic to recover from possible errors that might be generated in the runtime application.

When you develop an application in Business Automation Workflow, build error handling into processes and services to do the following things:

Detect errors.
Specify how errors are thrown and caught in your runtime environment.
Recover in a predictable manner.

For example, if a process involves filling orders, an item might be out of stock during one instance of the process, which causes an error. Error handling that you build into the process could create notifications to replenish items that are out of stock.

There are three types of error events:

Error end events in processes and services that throw errors. You can assign error codes and error data to errors that are thrown by the error end events.
Error intermediate events in processes and services that catch errors
Error start events in processes event subprocesses that catch errors

To catch specific 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 means they 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 process or service diagram in Process Designer, you can use an error intermediate event that is attached to the boundary of an activity 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 you build your service, you can attach an error intermediate event to the boundary of a step to catch all errors for that step, and you can use an error intermediate event as part of the service to catch all the errors that are raised by service steps that are not handled by the error intermediate event at the boundary of the step.

In processes, you also can catch errors by using error event subprocesses. 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:

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, make sure to select the variable again so that it is mapped properly.
Note: The error data cannot be mapped to a variable that is of a list type. If you want to pass information that has the structure of a sequence as error data, create a business object that contains a parameter that is of a list type and then use this business object as the variable's type.

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

Table 1. 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

Note: 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.