Fault Handling in a BPEL Process

Fault handling allows a BPEL process service component to handle error messages or other exceptions returned by outside web services, and to generate error messages in response to business or runtime faults.
 We will see how to use the fault management framework to catch faults and perform user-specified actions defined in a fault policy file

Fault Handler :

Fault handlers define how the BPEL process service component responds when web services return data other than what is normally expected (for example, returning an error message instead of a number). An example of a fault handler is where the web service normally returns a credit rating number, but instead returns a negative credit message.

<faultHandlers>
     <catch faultName="services:NegativeCredit" faultVariable="crError">
      <assign name="crin">
         <copy>
           <from expression="-1000">
           </from>
           <to variable="input" part="payload"
               query="/autoloan:loanApplication/autoloan:creditRating"/>
         </copy>
       </assign>
     </catch>
</faultHandlers>

The faultHandlers tag contains the fault handling code. Within the fault handler is a catch activity, which defines the fault name and variable, and the copy instruction that sets the creditRating variable to -1000.
When you select web services for the BPEL process service component, determine the possible faults that may be returned and set up a fault handler for each one.

Business and Runtime Fault Categories of BPEL Faults :

A BPEL fault has a fault name called a Qname (name qualified with a namespace) and a possible messageType. 

There are two categories of BPEL faults:

• Business faults
• Runtime faults

Business Faults :

Business faults are application-specific faults that are generated when there is a problem with the information being processed (for example, when a social security number is not found in the database).

 A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. 

The fault name of a business fault is specified by the BPEL process service component. 

The messageType, if applicable, is defined in the WSDL file. 

A business fault can be caught with a faultHandler using the faultName and a faultVariable

<catch faultName="ns1:faultName" faultVariable="varName">

Runtime Faults :

Runtime faults are the result of problems within the running of the BPEL process service component or web service (for example, data cannot be copied properly because the variable name is incorrect). These faults are not user-defined, and are thrown by the system. They are generated for a variety of reasons, including the following:

• The process tries to use a value incorrectly.
• A logic error occurs (such as an endless loop).
• A Simple Object Access Protocol (SOAP) fault occurs in a SOAP call.
• An exception is thrown by the server.

Several runtime faults are automatically provided. These faults are included in the http://schemas.oracle.com/bpel/extension namespace. 

These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown in Example  defines the messageType:

<?xml version="1.0" encoding="UTF-8" ?> 

<definitions name="RuntimeFault"

  targetNamespace="http://schemas.oracle.com/bpel/extension"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns="http://schemas.xmlsoap.org/wsdl/">

  <message name="RuntimeFaultMessage">

   <part name="code" type="xsd:string" /> 

   <part name="summary" type="xsd:string" /> 

   <part name="detail" type="xsd:string" /> 

  </message>

</definitions>

If a faultVariable (of messageType RuntimeFaultMessage) is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.

1 bindingFault

A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.

2 remoteFault

A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.

3 replayFault

A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.



BPEL Standard Faults :

This section identifies the standard faults for BPEL 1.1. Unless otherwise noted below, the Business Process Execution Language for Web Services Specification Version 1.1 defines the following standard faults in the namespace of http://schemas.xmlsoap.org/ws/2003/03/business-process/:

bindingFault (BPEL extension fault defined in http://schemas.oracle.com/bpel/extension)
conflictingReceive
conflictingRequest
correlationViolation
forcedTermination
invalidReply
joinFailure
mismatchedAssignmentFailure
remoteFault (BPEL extension fault defined in http://schemas.oracle.com/bpel/extension)
repeatedCompensation
selectionFailure
uninitializedVariable

Standard faults are defined as follows:

Typeless, meaning they do not have associated messageTypes

Not associated with any Web Services Description Language (WSDL) message

Caught without a fault variable:

<catch faultName="bpws:selectionFailure">