Fault Handling with Web Services

BPEL introduces fault handlers in order to let you deal with exceptional situations, such as the following:

• A fault recognized as the result of a Web service invocation

• A fault thrown explicitly by the process logic

• A fault caused by a problem encountered by the runtime infrastructure

Let's take a closer look at these three potential sources of faults in BPEL.

Fault Situations

The outcome of a Web service invocation is either regular output or a fault, as specified by the WSDL operation. The example shows the definition of a WSDL operation with two faults. WSDL faults have a name and a reference to a message definition, as shown in the following snippet:

<wsdl:operation name="doSubmission"> 
<wsdl:input message="pos:poSubmissionRequest"/>
<wsdl:output message="pos:poSubmissionResponse"/>
<wsdl:fault name="invalidPO"

message="pos:poSubmissionFaultInvalidPO"/>
<wsdl:fault name="outOfStock"

message="pos:poSubmissionFaultOutOfStock"/>
</wsdl:operation>

BPEL also lets you raise faults explicitly by means of the throw activity. The throw activity declares a qualified name of a fault and optionally provides a variable to associate data with the fault. The following BPEL snippet shows a throw activity. It's used to end the execution of the normal path in the process because the validation of the received purchase order has failed:

<throw faultName="pos:invalidPO"/>

Finally, the BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are

• mismatchedAssignmentFailure—Incompatible types in an assign activity

• forcedTermination—Fault in an enclosing scope

• correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data

• uninitializedVariable—Attempt to access an uninitialized part of a message variable

• invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed

Fault Handlers

In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.

When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.

A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.

Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.

Following is an example of a fault handler declaration for the overall process:

<process ...>
...
<faultHandlers>
<catch faultName="pos:invalidPO">
<reply partnerLink="buyer" 
portType="pos:purchaseOrderPortType"
operation="submitPurchaseOrder" 
faultName="pos:invalidPO" 
variable="purchaseOrderFaultInvalidPO"/>
</catch>
<catch faultName="pos:outOfStock">
<reply partnerLink="buyer" 
portType="pos:poSubmissionPortType" 
operation="poSubmission" 
faultName="pos:outOfStock" 
variable="poSubmissionFaultOutOfStock"/>
</catch>
</faultHandlers>
...
</process>

Fault handlers can be declared in the same way for scopes. They can also be declared for invoke activities, which is a shorthand notation for defining an enclosing scope with the fault handler.