About Fault Handling

Fault Handling

                             Hi Friends today lets see about Fault Handling. First lets see what is Fault,

Fault : Fault is an disturbance occurred during the happy path execution of a process which result in a signal being sent from the system. Disturbance can for various reasons like

- Technical error, programming error, Fault operation by client, Exceptional business behavior.

Fault Handling : It allows a BPEL Process service component to handle error messages or other exceptions returned by outside webservices , & to generate error messages in response to business your runtime faults.

- You can also define a fault management framework to catch faults & perform user - specified actions defined in a fault policy file.

Fault Types : Business Faults /User defined Faults, Technical Faults/System Faults

1. Business Faults: Faults generated in business scenarios(like From Partnerlink, From process)             Or                                                                                                                                           Business Faults are application specific faults that are generated when there is a problem  with the information being processed (eg: when a society security number is not found in the dbase   Userdefined  faults which are defined by the user(eg: Invalid Age Exception).
2. Technical Faults: Fault generated by the product or Fault generated from system. There are two types Standard Faults & Runtime Faults                                                                                        Standard Faults: These are the Faults that directly from BPEL Specification.                                Runtime Faults: These are the Result of problem within the running of the BPEL                                                   Component. these are thrown by the system. we need to define parts in the                                   process to handle them.(eg: Binding Faults, Remote Faults)                                Binding Faults:  is thrown inside an activity if the preparation of the invocation fails, it is                                     not retryable, this type of fault usually fixed by human intervention(eg: the                                 WSDL of the process fails to load)                                                                      Remote Faults: it is also thrown inside an activity, it can be configured to be retried. it is                                     thrown because the invocation fails.(eg: a SOAP Fault is returned by the                                     remote service).                                  

   About Throw Activity: Throw activity is used to generate a fault from inside the business process.

Fault Handling: 

                   Fault Handling can be global or local. you can add fault handlers to the process as a whole or to a scope within the process. when a fault occurs, normal processing is terminated  & control is transferred to the corresponding fault handler.Two types of fault handlers

1. Catch: It can catch single type or optional fault name or fault or exception variable. if the fault name is missing, than the catch intercepts all faults with the same type of fault data.                     or     Catch is used to catch specific faults individually such as business faults, runtime or binding faults.
2. Catchall: it can catch any type of fault. it does not specify a fault name or variable to catch.        or            It catches all the faults that are not being catch in other catch activities.

Oracle SOA Suite gives us an option of configuring fault and fault actions using policies. This means that we can create policies in response to a specific type of exception. Policies are defined in a file that by default is called fault-policies.xml

BPEL Standard Faults

The Business Process Execution Language for Web Services Specification defines the following standard faults in the namespace ofhttp://schemas.xmlsoap.org/ws/2003/03/business-process/:

■ bindingFault

■ conflictingReceive

■ conflictingRequest

■ correlationViolation

■ forcedTermination

■ invalidReply

■ joinFailure

■ mismatchedAssignmentFailure

■ remoteFault

■ repeatedCompensation

■ selectionFailure

■ uninitializedVariable

Note:

    While system faults are better handled using the policy-based fault-handling framework, handling exceptions in BPEL is the preferred approach for most application-generated exceptions, also called Business faults

    A fault policy configured with the fault management framework overrides any fault handling defined in catch activities of scope activities in the BPEL process. The fault management framework can be configured to rethrow the fault handling back to the catch activitie

If a fault occurs during runtime in any invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity.

Q)Well I have an exception handling then why this fault polices?

 Okay, using exception handling i can throw or catch an exception ( in programatic way i can say to avoid the abnormal termination of an program exceution) but I cant overcome the problem

Example:

Lets consider the scenario BPEL process is invoking Database and we have some service level agreements like databse will down one hour on every day

Above scenario with Exception handling

So i will use remote or binding to catch the exception( Here i will catch the exception not to over come the problem)

With Fault polices

Here i will use Fault polices in the polices i will tell to my BPEL process that keep trying to connect the databse in particular time ( In our case one hour ) so i over come the problem

Lets go deep in to Fault polices

we will have two file

1) fault-policies.xml

2) fault-bindings.xml

1)fault-policies.xml

  1)The fault condition that activates the policy block—we specify what type of fault(s) the policy is relevant for. We can then apply even more finer grained policy and actions based on error codes, error messages etc.

  2)The action(s) that should be performed when the condition is satisfied. An action for an fault may be to retry it for a certain number of time at a specified interval, or to mark it in recovery for human intervention, use a custom Java code or simply to throw the fault back. If the fault is rethrown then if we have specified any explicit ‘catch’ block in our BPEL process that will be executed.

example

  

    <Conditions>

     

          <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"

                 name="bpelx:remoteFault">  (Exception name)              

        <condition>(Condtion)                                                                   

          <action ref="ora-retry"/> *  (Action to be done when the exception occurs)                 

        </condition>

      </faultName>

     

    </Conditions>

   

   ----------------------------------------------------------------------------------------------------------------------------

   

   

    <Actions>

      <Action id="ora-retry"> * (Occurs when the condtion satisfies)

        <retry>

          <retryCount>3</retryCount>

          <retryInterval>60</retryInterval>

          <exponentialBackoff>2</exponentialBackoff>

        </retry>

      </Action>

     

          

    </Actions>

In the above example if the remote fault occurs it will retry with the conditons specified.

2) fault-bindings.xml

This second policy file that is required by the Fault Management Framework is the fault-bindings.xml.  This policy file will bind (or map) policies defined in the fault-policies.xml file to levels within the composite.  These levels include:

• Composite Application
• Component
• Reference
• BPEL Process
• Mediator

Composite Application Binding

When binding to a composite application, use the <composite> element with an attribute called faultPolicy.  The value of the faultPolicy attribute must match a policy id defined in the fault-policies.xml:

  <composite faultPolicy="FusionMidFaults"/>

Reference Binding

When binding to a reference, use the <reference> element with an attribute called faultPolicy.  The value of the faultPolicy attribute must match a policy id defined in the fault-policies.xml.  You will also need to specify a <name> or <portType> element:

  <reference faultPolicy="FusionMidFaults">

    <name>creditRatingService</name>

    <portType xmlns:credit="http://services.otn.com">credit:CreditRatingService</portType>

  </reference>

  <reference faultPolicy="FusionMidFaults">

    <name>CreditApprovalService</name>

  </reference>

BPEL Process Binding

When binding to a BPEL Process, use the <component> element with an attribute called faultPolicy.  The value of the faultPolicy attribute must match a policy id defined in the fault-policies.xml.  You will also need to specify a <name> element containing the name of the BPEL process:

  <component faultPolicy="FusionMidFaults">

    <name>HelloWorld</name>

    <name>ShippingComponent</name>

  </component>

Mediator Binding

When binding to a mediator, use the <component> element with an attribute called faultPolicy.  The value of the faultPolicy attribute must match a policy id defined in the fault-policies.xml.  You will also need to specify a <name> element containing the name of the meditor:

  <component faultPolicy="FusionMidFaults">

    <name>RouteToShippingMediator</name>

  </component>

This file associates fault policies with composites or components.

example

<component faultPolicy="ComponentFaults"> (Name of the fault police)

<name>CallerBpel</name> (Name of the component)

</component>

</faultPolicyBindings>

Finally we have to add two properties in the composite.xml to let the composite know about them

<property name=”oracle.composite.faultPolicyFile”>fault-policies.xml></property>

<property name=”oracle.composite.faultBindingFile”>fault-bindings.xml></property>

We can use different names and locations for the fault policies and fault bindings files, by setting the properties oracle.composite.faultPolicyFile and oracle.composite.faultBindingFile in the composite.xml to configure these custom files.

For example we can refer to these files even from the MDS.

<property name=”oracle.composite.faultPolicyFile”>oramds://apps/policy/fault-policies.xml></property>

<property name=”oracle.composite.faultBindingFile”>oramds://apps/policy/fault-bindings.xml></property>