Handling error events

When you configure a BPD that uses external systems, you have to handle possible exceptions that might be generated in order to prevent errors or crashes.

For example, if a BPD includes an integration with a database system, that database may not be available when each new instance of the BPD runs. When you develop the integration in IBM® BPM, you need to build in exception handling to detect errors and recover in a predictable manner.

You can build error event handling capabilities into both BPDs and services.

Handling exceptions in BPDs

There are two main constructs for building error handling into your BPDs: error events and error event subprocesses.

For BPDs, you can attach an intermediate error event to an activity and connect that event to an error handling flow or activity. You can also use an error end event to throw an exception to the parent process for handling.

Table 1. Usage of error events in business process definitions
BPD event	Description
Intermediate error event	Use to catch process execution exceptions and handle exceptions with an error handler activity or further process flow.
End error event	Use to throw an exception to parent processes.

When including error events in your BPDs, keep the following points in mind:

Intermediate error events must be attached to an activity. Do not include intermediate error events in the process flow as generic error handlers. Generic error handlers do not work in BPDs.
You can attach only one intermediate error event to an activity.
If an exception occurs while a process is executing an activity with an attached error event, the process flows along the sequence line that is attached to the error event.
If an exception occurs and there is no error event attached to the activity where the exception occurs, the exception is propagated up the BPD call stack until it reaches an event subprocess that contains an activity with an error event attached to it, or the top of the stack is reached. If an exception is not caught before it reaches the top of the stack, the BPD execution fails.
IBM BPM creates an XML representation of process exceptions that occur. An exception is captured as an XMLElement in tw.system.step.error .

An event subprocess is a specialized type of subprocess that is not part of the normal sequence flow of its parent process. An error event subprocess is an event subprocess that contains an error start event. The event subprocess is not connected by sequence flow, and only runs if the start event in the event subprocess is triggered. You can use error event subprocesses to handle exceptions in your BPD.

Advantages to event subprocesses:

Event subprocesses enable you to define a cleaner process with less effort because the receiving error event is located within the event subprocess instead of having it defined within the process.
If you want to reuse the exception handling flow for multiple tasks in your process, event subprocesses are more efficient than intermediate error events. To reuse an exception handling flow using attached events you must attach an intermediate event for each of the tasks and then connect those events to the exception handling flow.
Event subprocesses also enable you to define data objects that you can access only from within the event subprocess, in the same way that subprocess enable you to define their own data objects. This prevents unnecessary clutter in the set of variables defined for the parent process.

When including error event subprocesses in your BPDs, keep the following points in mind:

For a general event subprocess that you want to be triggerable throughout the execution of the entire process (and subprocesses) put your event subprocess at the top level of the process.
If you have an event subprocess that is contained within a linked process, it can only be triggered during the execution of the linked process.

In all cases, when working with either error events or event subprocesses, the best way to implement error handling is from the bottom up. Build each linked process and service so that exceptions can be captured and corrected. If a correction is not possible at the lowest level implementation, you can allow the exception to bubble up (by not including an error event) or include an error event to re-throw the error to the calling service or process, as shown in the following section.

For example, to ensure that any exceptions that might occur during process execution are captured, you can create a high-level BPD that includes an activity (to call the main process as a linked process) and then one additional activity (with an underlying service) to implement error handling as shown in the following image:

This screen capture shows a diagram of the BPD described in the preceding paragraph.

This type of design ensures that any exceptions thrown from underlying processes and services are propagated up and handled appropriately.

Using exception components in services

For services, you can include the following exception components:

Table 2. Usage of exception components in services
Service component	Description
Catch Exception	Listens for exceptions from the service component to which it is attached.
Throw Exception	Use to purposely throw an error and end processing. You might, for example, use a Throw Exception component if you return too many rows from a database (over a limit that is normal and would bog down the server).

When including exception components in your services, keep the following points in mind:

You should attach Catch Exception components to other components in your service. It is possible to include Catch Exception components in the service flow so that they can act as global error handlers within the service. However, this practice is not recommended.
You can attach only one Catch Exception component to another component in a service, such as a script or integration component.

When building services that include integrations with external systems or other complex implementations, you should use the Catch Exception component to ensure that errors are captured and users (such as administrators) are informed and, when possible, given an opportunity to correct the problems. Be sure to include the appropriate logic and a Throw Exception component in your services to throw exceptions in cases where they still exist after attempts to handle them. Throwing the exceptions ensures that the errors are passed up to parent processes and services and are eventually handled by a high-level process.

For example, the following image shows a service that catches an exception for a database query, attempts to handle the exception with a special script, and then (if the handler script fails) throws the exception for further processing by higher level services or processes.

This screen capture shows a diagram of the service described in the preceding paragraph.