|
|
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:
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:
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.
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.
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 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. |
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:
An exception path is added to your node or group of nodes, as shown in Figure 15-1.
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.
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.
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.
| Note: | when there is an exception path attached to a node and the exception is rethrown ( afterExecute="rethrow") the context_onException() will not be called. |
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 .
afterExecute path is taken. The counter is evaluated and incremented at the end of handler execution.| 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. |
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:
|
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.
| 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. |
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:
| Note: | If you have the after execute property set to rethrow, the exception itself will also propagate upwards. |
| 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. |
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. |
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.
Figure 15-2 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:
| 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. |
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:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Throwable.html#getCause()
Grouping Nodes in Your Business Process
Writing Custom Java Code in Perform Nodes
|
