The blog discuss on the handling of SOA Composite run time fault error and fault recovery mechanism provided by the Oracle SOA Server. Oracle SOA provides the automated SOA Fault recovery with the usage of Fault Policy Wizard. 

We will discuss the BPEL Standard faults, classification of BPEL Faults  (Business Fault and Run-time Faults) with the help of SOA Composite example using Fault Policy Wizard. 

Error handling in Oracle SOA Composite is one of the common pain area. SOA provides the Fault Handling mechanism to capture error message / run time exceptions returned by the invoked web services in BPEL Process Service components. The BPEL provides the below given standard faults

• bindingFault
• conflictingReceive
• conflictingRequest
• correlationViolation
• forcedTermination
• invalidReply
• joinFailure
• mismatchedAssignmentFailure
• remoteFault
• repeatedCompensation
• selectionFailure
• uninitializedVariable

The 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 are the error when the application executes a throw activity or when an invoke activity returns Fault as a response. The invoked service returns error when the required information is not received Example – The Purchase Order Number is not available.
A business fault can be caught with a faultHandler using the faultName and a faultVariable.

<catch faultName="ns1:BusFaultName" faultVariable="varBusinessFault">

Run Time Faults are the error received by the BPEL Process Service Component or Web Service at the run time returned by the system, not user-defined. The invoked service is not available, the transformation error occurs at run time, etc.
Run Time Faults are provided in the http://schemas.oracle.com/bpel/extension namespace and are associated with the messageType RuntimeFaultMessage

<?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="detail" type="xsd:string" />
</message>
</definitions>

To handle the above mentioned Business Faults and Run Time Faults, we were required to create Fault Policy and Fault binding files manually in SOA 11g. But now with SOA 12c, the Fault Policy Wizard has been provided to create the Fault Policy with ease for the composites.
Let’s create a sample application which invokes the Remote Service. The Service will handle the RemoteFault using the SOA 12c Fault Policy Wizard and link it to the Fault Binding File

• Create the SOA Application and Project – FaultPolicyRemoteInvocPrj
• Select the options with No Composite
• Create the synchronous BPEL Process – RemoteFaultPolicyBPELProcess

Create the Partner Link with the enabled WSDL. Create the Invoke Activity and provide the details for the created partner link.
Create the Invoke Input Variable – InvokeCustomSupplierSrvc_updateSupplier_InputVariable
Now, let’s utilize the Fault Policy Wizard. Right click on the SOA project and click on New ->From Gallery. Choose SOA Tier -> Faults -> Fault Policy Document to create new fault policy file.
Below given are the actions which can be used for the custom fault policy. Multiple Fault Policies can be created.

The Alerts can be created with any of the 3 given types (JMS, Log and email). Let’s use JMS Alert to see the required details to be entered.
Provide the Alert Id and then click on ‘Create Required Properties’. Enter the Property Name and then select the Web Logic Server and the JMS Queue and JMS Connection factory created in the Web Logic JMS Module.

Click OK and these details will be shown in the Alert Window. Now link the created JMS Alert to the Fault which need to be captured.
Enter the Fault Name: bpelx: remoteFault
Enter the description:
Enter the Default Action: [abort] default-termination
Below given are the available action to be selected.

The below screenshot provides the complete details entered for handling the Remote Fault.

Similarly, you can select the Alert for Email and Log also.

You can map the Created Remote Fault accordingly with any of the created Alert. You can select 1 Alert for the 1 Fault Policy. Set the Alert Property Set similar to JMS Property Set.

Now, we need to create the fault binding file and link the created RemoteFaultPolicy to the available composite, components, services and references.
Now click on the highlighted icon to Edit the Fault Policies and map the value of RemoteFaultPolicy to composite, components, services and references

As the scenario is shown for the RemoteFault, the remote service which will be invoked thorough this application should be down to get the fault policy invoked.

Deploy the application and test the SOA Composite application