Fault handling in a BPEL process is reverse work, undoing the partial and unsuccessful work of a scope in which a fault has occurred. When a fault occurs, normal processing is terminated, and control is transferred to the associated fault handler.
So far in the tutorial, you have completed a BPEL process definition that contains all the steps for normal processing. Now you will add a fault handler to handle a service invocation fault.
If the loan process throws a fault, it terminates the process using a standard fault, and turns over control to the fault handler activity.
In the
loanprocess.wsdl
file, there is a fault name and a fault message defined for the WSDL's operation, namely the request operation. The loan process uses the fault name and message in defining fault handling activities for the assessor and approver services.
In the Project Explorer view, you should have the following files:
tutorial.bpel
that you created in Part 2
tutorialCompleted.bpel
, which is a completed version of the file (optional)
After completing Part 6 of the tutorial, you will be able to:
Add a Catch fault handler for the process.
Add a fault variable.
Add a fault handling activity to the Catch handler.
Step 1: Add a Catch Fault Handler and Fault Variable
When a fault handler receives an inbound fault message, it assigns the fault message to a variable before proceeding to perform an activity enclosed by the catch.
Click on the Fault Handlers tab of the Process Editor.
From the Catch Event palette, drag an Error activity to the canvas.
Select the activity.
In the Properties view, select Fault Variable Definition, and click the dialog (
...
) button at the end of the row.
Fill in the
Fault Variable Definition
dialog as follows and click OK:
Select the Element radio button.
From the list of messages, select
loan:errorMessage
.
In the Properties view, select Fault Name, and click the dialog (
...
) button at the end of the row.
In the Fault Name list, notice that the WSDL fault name associated with both the assessor and approver services is the same, but each is in a different namespace. For convenience, the WSDL for each service used the same fault name, but usually if you are orchestrating two different services the fault names would be different. Select the
loanApproval:loanProcessFault
, as shown in the example.
In the Fault Variable field, type
errorApprove
, which is the name we will associate with the fault variable definition. The properties for the Catch activity should look like the following example:
Notice that a new variable named
errorApprove
was to Process Variables view. This variable is exclusively for fault handling, and this is shown using an icon that differs from normal process variables.
Step 2: Add a Fault Handling Activity
When a fault is caught, the fault handler must execute an activity. You will add a Reply activity to tell the customer that the process was unable to handle the request.
From the Throw Event palette, drag a Message activity into the Catch handler and name the activity
ReplywithApprovalFault
, as shown.
Fill in the properties for the reply activity to handle the fault, as shown in the example. You must select them in the following order:
Participant (loanProcessor)
Operation (request)
Fault Name (unableToHandleRequest)
On the Data tab, select the new variable (
errorApprove
).
Add a similar Fault handler for the risk assessment service by selecting the same fault variable definition and the new fault name
riskAssessment:loanProcessFault
and naming the fault variable
errorRisk
. Name the Reply
ReplywithRiskFault
.
Your Fault Handlers view should be similar to the following: