# Handling Exceptions

Business Process exceptions are Java exceptions that are not caught by the Java handler methods. This section describes the ways in which you can handle exceptions in your business processes. It includes the following topics:

- Types of Exception Handlers
- Creating Exception Handler Paths
- Deleting Exception Handler Paths
- Order of Execution of Exception Handlers
- Handling Exceptions in Transaction Blocks
- Using Exception Handlers for Compensation
- Unhandled Exceptions

## Types of Exception Handlers

You can use the Design View to create exception paths on business process nodes, collapsible groups of nodes, and the Start node. Specifically, using the Design View, you can create the following types of exception handlers in your business process:

- Global exception handler

You can create a global exception handler for your business process by creating an exception path for the Start node. You create logic for the exception handler path to define the flow of execution in case of an exception. A global exception handler responds to exceptions that are otherwise not handled in the business process.

- Exception handler for a group of nodes

You can associate an exception path with a group of nodes and create logic for the exception path that defines the flow of execution in case of an exception.

- Exception handler for an individual node

You can associate an exception path with an individual node and create logic for the exception path that defines the flow of execution in case of an exception.

In general, exceptions propagate upwards from a node exception path, to a group exception path, to a global exception path until they are handled. In other words, the exception path associated with a node executes first, then the path associated with a group executes, and then the path associated with a start node (global path) executes. The exception is only handled once, unless the exception path throws an exception, then the exception propagates upward again in the same order. You can take advantage of this behavior and create exception path logic that satisfies the particular exception handling necessary for your business process. For more information, see Order of Execution of Exception Handlers.

Note: The graphical design environment does not support or represent the design of exception paths on the following nodes in the process language: <if> and <default> blocks inside Decision nodes, <branch> blocks inside Parallel nodes, <finish> nodes, <messageEvent>, <timeoutEvent>, and the <onException> path itself.

## Creating Exception Handler Paths

You can associate an exception handler path with individual nodes in your business process and with groups of nodes. An exception path that you associate with a Start node is a special case. That is, the exception path associated with a Start node is the global exception handler for the business process. To learn more about Start nodes, see Starting Your Business Process. This section contains the following steps and procedures:

- To Create an Exception Path
- To Configure an Exception Path

To Create an Exception Path

1. Select the node or groups of nodes for which you want to great an exception path. (For information on how to group nodes, see Grouping Nodes in Your Business Process)
2. Right-click the node or group of nodes and select Add Exception Path from the drop-down menu.

An exception path is added to your node or group of nodes and is displayed as follows.

You can rename the exception path to anything you like by double-clicking OnException and entering the new name. You can also change the name in the name field of the Property Editor.

To Configure an Exception Path

1. Select the exception path which you want to configure.

The related properties are displayed in the Property Editor. If the Property Editor is not visible in WebLogic Workshop, choose View —> Property Editor from the menu bar.

2. In the Property Editor, configure the following properties:

- name—Enter the name you want displayed in the graphical design environment for this exception path.
- notes—Enter any notes you want associated with this exception path. These notes can then be accessed through the WebLogic Integration Administration Console.
- after execute—Select the action you want to take place after an exception path is executed and all retries have been exhausted. Choose from:

skip—Skip the node or group with which the exception path is associated. That is, resume execution of the process at the node following the node or group for which the exception path is defined.

resume—Execution resumes after the closest transaction block, exception block, or failing node on the stack. In other words, the execution of the process resumes at the node following the one that threw the exception (this could be within a group, or if the node that threw the exception is the last in a group, the node following a group of nodes).

rethrow—Nodes on the exception path are executed and then the same exception is rethrown and handled by the exception handler at the next level up.

- retry count—Specify how many times, after the first attempt, the process engine tries to execute the node or group of nodes contained in the path, before the afterExecute path is taken. The counter is evaluated and incremented at the end of handler execution.
- execute on rollback—Set this to true if you want this exception path executed when the associated transaction is rolled back.

The execute on rollback parameter enables exception handlers to be used for compensation. By grouping nodes and adding an exception path to that group with the execute on rollback property set to true, you can specify that the exception handler should be run before transaction rollback, thereby providing an opportunity to clean-up non-transactional resources that would otherwise not be effected by the rollback. For more information, see Using Exception Handlers for Compensation.

Note: Be aware of the following behavior when you specify a retry count in combination with setting the after execute parameter to resume: Specifying a retry count on an exception handler that is attached to a group causes the retry to start at the beginning of the group—not at the offending node. However, if you also specify the resume option for the after execute property, after all the retries are exhausted, the execution can continue from a point within the group, following the offending node.

3. Add any business process nodes to the exception path, as required to define the exception handling logic. If you want your process to stop after catching an exception, place a Finish node on the exception path. For information about how to create a Finish node, see To Create a Finish Node in Your Business Process.

Viewing Exception Handlers in the Design View

When you create an exception handler path, the following icon appears beside a node (or group of nodes) in the Design View, which indicates that an exception path is activated for the specified node:

| This icon represents the exception path in your business process. In this case, the path appears empty, indicating that the logic to handle an exception is not defined yet. To define the exception handling logic, add business process nodes by dragging the nodes from the Business Process Palette and dropping them on the exception path.

To collapse the view of any exception handler (or message or timeout path), click the grey arrow of the exception path icon. The following figure shows the icon associated with your node to indicate a collapsed path.

| You can toggle between collapsed and expanded views of paths in the Design View by clicking the exception path icon.

## Deleting Exception Handler Paths

To Delete an Exception Path:

1. If the exception path that you want to delete is collapsed, expand it.
2. Right-click the exception path, then select Delete from the drop-down menu.

The exception path is deleted and removed from the Design View.

Warning: Deleting an exception path deletes any business process nodes you defined on that path. When you attempt to delete an exception path, a dialog box displays a warning message that you must acknowledge before proceeding with the deletion.

## Order of Execution of Exception Handlers

If an exception occurs, the normal flow of execution stops. The business process executes the activities inside the exception handler path defined closest to the point of the exception.

You typically define a number of exception handlers in your business process. The following sequence defines the order of their execution when an exception is thrown:

1. The business process engine first executes the exception handler at the node on which the exception occurs.
2. If the exception handler path completes execution normally, the business process resumes execution at the node following the node associated with the executed exception handler, based on the post-execute parameter setting.
3. If the exception handler throws an exception while it is executing, the exception is propagated upwards to be handled either by an exception handler on the group of nodes in which the node is contained, or by the global exception handler defined on the Start node.

Note: If you have the after execute property set to rethrow, the exception itself will also propagate upwards.

4. When a business process fails and there is no exception handler configured to handle the exception thrown, the business process is placed into an aborted state and no recovery is possible. However, if the business process is configured to freeze on failure, the business process rolls-back to the last commit point and the state is persisted if it fails. The process can then be restarted from the WebLogic Integration Administration Console. To learn more about the freeze on failure property see, Setting the Business Process Properties.

Note: If an exception occurs within a transaction block, the transaction is rolled back and the exception handler is called at a later time. However, if the business process is marked freeze on failure, instead of calling the exception handler later, the process freezes and the exception handler is never called. In this case, when freeze on failure is configured inside a transaction block, you should either not use a transaction block or include global transaction logic within your transaction blocks.

## Handling Exceptions in Transaction Blocks

If a node or group within a transaction throws an exception, the transaction will only see the exception if the exception is not handled or if an exception handler throws an exception. The following algorithm is used to handle the exception:

- If the transaction is not marked for rollback only, the exception is dispatched to the exception handlers defined within the transaction block, if any.
- If an exception handler within the transaction block does not throw or rethrow an exception, the transaction is not rolled back, and execution resumes after the block that enclosed the exception handler.
- If the transaction is marked for rollback only, or if there is no exception handler within the transaction block, or if all the exception handlers throw exceptions, the transaction is rolled back. After exhausting a specified number of retries, a business process exception is thrown from the transaction block in a new transaction. The business process exception is a generic exception, because there is no way to retain the root cause exception on a rollback.

Note: Whether a transaction is marked for rollback only depends on the types of transactional resources you use in your business process.

For transactional resources that force a transaction to roll back immediately in the case of an error, an exception handler on a node or group of nodes does not run before the transaction rolls back. However, you can use exception handlers with the execute on rollback property for compensation and to clean up the non-transactional resources. For more information, see Using Exception Handlers for Compensation.

## Using Exception Handlers for Compensation

Transactional resources are any resources that communicate with your business process through a Control Request node or any of the transactional controls: Database, JMS, Application View (if JCA adapter is transactional), Worklist, Timer, EJB, Message Broker, and Transformation.

For transactional resources that force a transaction to roll back immediately in the case of an error, an exception handler on a node or group of nodes does not run by default. However, you can force the exception handler to run before the rollback occurs by placing an exception path inside an explicit transaction block in your business process, and setting the execute on rollback property of that path to true. In this way, the exception path has access to the current state (the process variables, and so on) and the logic added to the exception path can be used for compensation and to clean up the non-transactional resources, as described in the Compensation Example.

To learn about the Control Request node, and about controls and transactions see Create a Client Request Node in Your Business Process and Controls and Transactions.

### Compensation Example

The following figure shows an example of how to use an exception path for compensation.

In the example, two nodes are running in the same transaction. The first node writes to a file (non-transactional) and the second node updates a database (transactional). Both nodes are within a group that has an associated exception handler. The exception handler execute on rollback property is set to true to force the exception handler to run before any rollback occurs.

In this example, if the database operation fails and marks the transaction for rollback only, the following sequence of events occurs:

1. The exception handler runs before the rollback occurs.
2. The transaction handler path is executed and the node on the path deletes the file that was written earlier.
3. The transaction rolls back.

Note: The above example is for an implicit transaction. You can use the same technique for compensation with explicit transactions. However, be sure that you put the exception handler path inside the explicit transaction. Putting it on the explicit transaction itself does not result in the desired behavior. The following figure shows an example of an explicit transaction with an exception handler path with compensation logic.

## Unhandled Exceptions

If you do not handle exceptions in a business process, the exception will be wrapped in one of the following:

- com.bea.wli.bpm.runtime.UnhandledProcessException
- ProcessControlException
- ServiceControlException
- JpdProxyException

If you need to obtain the original exception, you can call getCause() on the unhandled process exception. To learn more about this method, see getCause() in the Java 2 Platform, Standard Edition, v 1.4.2 API Specification, which is available at the following URL:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Throwable.html#getCause()

Related Topics

Grouping Nodes in Your Business Process

Writing Custom Java Code in Perform Nodes

Adding Message Paths

Adding Timeout Paths

Transaction Boundaries