WebSphere Lombardi Edition 7.2 > Modeling processes > Advanced modeling tasks
Handling exceptions
When the processes that you develop in Lombardi include integrations with external systems, server scripts, and other complex implementations, you need to anticipate potential exceptions and create the components required to handle those exceptions when they occur. 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 executes. So, when you develop the integration in Lombardi, you need to build in exception handling to detect errors and recover in a predictable manner.
You can build error handling capabilities into both BPDs and services
using the available exception components. For more information, see:
Use exception events in BPDs
For BPDs, you can include the following exception events:
| BPD event | Description |
|---|---|
| Use to catch process execution exceptions and handle exceptions with an error handler activity or further process flow. |
| Use to throw an exception to parent processes. |
When including exception events in your BPDs, keep the following
points in mind:
- You should attach intermediate exception events to an activity.
- Do not include intermediate exception events in the process flow as generic error handlers. Generic error handlers do not work in BPDs.
- You can attach only one intermediate exception event to an activity.
- If an exception occurs while a process is executing an activity with an attached exception event, the process flows along the sequence line that is attached to the exception event.
- If an exception occurs and there is no exception event attached to the activity where the exception occurs, the exception is propagated up the BPD call stack until it reaches a nested process that contains an activity with an exception 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.
- Lombardi creates an XML representation of process exceptions that occur. An exception is captured as an XMLElement in tw.system.error.
The best way to implement error handling is from the bottom up. Build each nested 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 exception event) or include an exception event to re-throw the error to the calling service or process. ( Use exception components in services shows how to design a service so that active exceptions are thrown.)
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 nested process) and then one additional activity (with an underlying service) to implement error handling as shown in the following image:
This type of design ensures that any exceptions thrown from underlying processes and services are propagated up and handled appropriately. See Use exception components in services to learn more about catching and throwing exceptions in services.
Use exception components in services
For services, you can include the following exception components:
| Service component | Description |
|---|---|
| Listens for exceptions from the service component to which it is attached. |
| 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 end 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 like the one shown in Use exception events in BPDs.
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.
Parent topic: Advanced modeling tasks