| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Integration > BPM Topics > Using the Studio > Handling Workflow Exceptions |
|
Using the Studio
|
Handling Workflow Exceptions
The following sections explain how to handle internally and externally generated workflow exception conditions:
About Workflow Exception Handling
The workflow exception handling facility enables you to define, trap, and respond to internally and externally generated exception conditions at run time. Exceptions may be specific abnormal conditions that you can target within the workflow, or they may be typical run-time server exceptions that you trap and respond to accordingly.
Exception handling within WebLogic Integration is performed at the workflow level, rather than at the task level. All workflow template definitions have at least one exception handler, the system exception handler. The system exception handler, is by default, the initial exception handler and is invoked whenever an exception occurs. The concept of the initial exception handler is required, since exceptions can occur prior to a specific exception handler being invoked from within the workflow. For example, exceptions can occur during the initialization of variables in a Start node. The system exception handler responds to exceptions by marking the active transaction for rollback only and rethrowing the exception to the client.
The workflow exception handling facility allows you to define customized exception handlers that specify actions to be executed in response to exceptions. Exception handlers have commit and rollback processing paths. You specify certain actions within a workflow to be executed in each of these paths. When an exception occurs, if the currently active transaction is marked for rollback only, the exception handler executes the rollback processing path for the transaction. If the transaction is not marked for rollback only, the exception handler executes its commit path. For information on the workflow transaction model, see Understanding the BPM Transaction Model in Programming BPM Client Applications.
You can also use workflow functions in conditional expressions to identify particular exceptions that you want to catch, by type, severity, text, and other criteria. For more information, see Obtaining Run-time Workflow Data.
Once you have defined the custom exception handler and its actions, you can invoke it in three ways:
Overview of Exception Handler Definition Tasks
Exception Handlers are like sub-workflows within a workflow in which you can specify various actions on commit and/or rollback paths of the transaction in which an exception has occurred. The exception handler can respond to general exception occurrences, or the handler can use a condition to specify a specific exception to trap. To use a custom exception handler in your workflows, you need to do the following:
Note: You may also want to familiarize yourself with the workflow expression language and the Studio's Expression Builder and XPath Wizard tools before beginning to define exception handlers and actions that reference them. Many of the tasks described in this section, such composing an XML document in the Invoke Exception Handler action, or initializing variables in an exception handlers, require entering expressions into dialog box fields. For complete information on workflow expressions, see Using Workflow Expressions.
Defining Exception Handlers
You use the exception handler definition facility to define custom exception handlers. If you do not define any exception handlers, the system exception handler is, by default, used.
You can set the custom exception handler to be the initial exception handler, that is, the one that is active as soon as a workflow is instantiated. The template definition can change its active exception handler throughout the course of the workflow by using the Set Exception Handler action. (See Setting the Workflow Exception Handler for information.)
Custom exception handlers defined for the current template definition are displayed in the folder tree under the Exception Handlers folder, and in the properties dialog box for a Template Definition.
Figure 9-1 Template Definition Properties Dialog Box: Exception Handlers Tab
When you define a custom exception handler, you can specify actions to be performed for both commit and rollback exception situations. For a commit paths, all workflow actions are available to be performed. For a rollback path, only the following actions are available: Post XML Event, Call Program, Perform Business Operation, Exit Exception Handler, No Operation, and Make Audit Entry. For more information about actions, see Defining Actions. Note: Certain Enterprise Java Beans (EJBs) can either mark a transaction for rollback only by calling a UserTransaction method, or they can throw an unchecked exception across a container boundary. In either of these two cases, WebLogic Server rolls back the transaction. You can also define workflow variables to be populated by values from the XML message defined within the Invoke Exception Handler action. For more information, see Invoking an Exception Handler. Creating a Custom Exception Handler To create an exception handler for a workflow template definition:
to invoke the XPath Wizard, from which you can generate XPath expressions automatically from a sample incoming document. For information, see Creating XPath Expressions Using the XPath Wizard.Exiting an Exception Handler
You use the Exit Exception Handler action, which is only available from within the Exception Handler Properties dialog box, to exit an exception handler. (For information, see Defining Exception Handlers.) Be sure to add this action to the Actions on Commit or Actions on Rollback tab of the Exception Handler to return control to the main flow.
In a Rollback path, the only exit option available is Rollback. In a Commit path, you can choose from four options:
Note: Certain Enterprise Java Beans (EJBs) can either mark a transaction for rollback only by calling a UserTransaction method, or they can throw an unchecked exception across a container boundary. In either of these two cases, WebLogic Server rolls back the transaction.
Figure 9-3 Exit Exception Handler
Updating a Custom Exception Handler
Viewing Exception Handler Usage
To see where an exception handler is referenced within the workflow:
Figure 9-4 Exception Handler Usage Dialog Box
Deleting a Custom Exception Handler
Once defined, an exception handler can only be deleted if it is not referenced by either the Invoke Exception Handler action or the Set Workflow Exception Handler action (for more information, see Invoking an Exception Handler). To see a list of places where an exception handler is referenced, follow the procedure in Viewing Exception Handler Usage.
To delete an exception handler:
Invoking an Exception Handler from a Workflow
To invoke an exception handler from a workflow, you use the following exception handling actions:
Setting the Workflow Exception Handler
You use the Set Workflow Exception Handler action to make a specified exception handler the active exception handler for a workflow template definition. If this action is not used in the workflow template definition and no other exception handler is defined and marked as the initial exception handler, the system exception handler, by default, is used and invoked whenever an exception occurs.
The exception handler you set for the workflow persists throughout the instance of the workflow until you use a subsequent Set Workflow Exception Handler action to reset the exception handler to the system handler or to another custom-defined one.
Figure 9-5 Set Workflow Exception Handler
To set the workflow exception handler to a custom handler:
Invoking an Exception Handler
You use the Invoke Exception Handler action to invoke a specific exception handler within the workflow and, optionally, send an XML document that you define to the exception handler. You can use the XML document to send values that will be used to populate variables when the exception handler is invoked. (For information, see Defining Exception Handlers.)
Note that this action does not override the exception handler that is set as the active one. Any exceptions that occur are still handled by that exception handler. Furthermore, upon execution of the Invoke Exception Handler action, actions defined in the exception handler are executed, regardless of whether an exception occurs. Thus, you typically use this action in a conditional situation where you want to invoke the actions defined in the exception handler as a result of an exception being thrown from within the workflow itself. This action will not handle exceptions thrown by business operations.
You can also use this action to simply send an XML document to any exception handler you select.
Figure 9-6 Invoke Exception Handler Dialog Box
To invoke a custom exception handler:
System Error Messages
As described in Obtaining Run-time Workflow Data, the WorkflowAttribute() function may be used with four attributes that allow the exception handler to interrogate the following information:
The following table lists workflow error messages by number and text.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
