Guide to Building Business Processes

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

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

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:

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 exception path is not applicable to the following: <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
  1. Select the node or groups of nodes for which you want to create 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.
  3. An exception path is added to your node or group of nodes, as shown in Figure 15-1.

    Figure 15-1 Exception Path

    Exception Path

    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 Properties view.

To Configure an Exception Path
  1. Select the exception path which you want to configure.
  2. The related properties are displayed in the JPD Configuration view. If the JPD Configuration view is not visible in BEA WorkSpace Studio, choose Window > Show View > JPD Configuration from the BEA WorkSpace Studio menu bar.

  3. In the JPD Configuration view, configure the following properties:
  1. 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:

Table 15-1 Exception Path

Explicit Transaction

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

Table 15-2 Collapse and Expanded View

Explicit Transaction

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.
  3. 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.
  4. Note: If you have the after execute property set to rethrow, the exception itself will also propagate upwards.
  5. 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. In 8.x, Supports Global Transaction with Emulate Two-Phase Commit was the default setting, however on 10.2 Supports Global Transaction is off by default, so you need to enable it, when using the non-XA drivers.


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:

Note: Whether a transaction is marked for rollback only depends on the types of transactional resources you use in your business process.
Note: 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, 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, see Create a Client Request Node in Your Business Process.

Compensation Example

Figure 15-2 shows an example of how to use an exception path for compensation.

Figure 15-2 Exception Path for Compensation

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. Figure 15-3 shows an example of an explicit transaction with an exception handler path with compensation logic.
Figure 15-3 Explicit Transaction

Explicit Transaction


Unhandled Exceptions

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

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:

Related Topics

Grouping Nodes in Your Business Process

Writing Custom Java Code in Perform Nodes

Adding Message Paths

Adding Timeout Paths

Transaction Boundaries

  Back to Top       Previous  Next