Handling a system exception—Fault Management Framework

The purpose of the Fault Management Framework is to provide error handling that is external to SOA and does not impact the SOA/BPEL design or runtime. The framework is implemented using policies defined in XML.

These policies are reusable across composites/components and can catch both runtime and business faults. Once a fault is caught, the policy defines actions that can be used for the SOA instance, such as retry, human intervention, replay scope, rethrow fault, abort, and custom Java actions.

These policies can be bound to composites and/or components. When the policies have been defined and bound to composites and/or components, the framework will intercept the fault before the standard fault handler comes into play.

You will create two XML policy files required to set up the Fault Management Framework in SOA, the first of which is fault-policies.xml. This file contains one or more Fault Policy definitions, fault definitions (which can also include conditions), and actions. The second policy file that is required by the Fault Management Framework is 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 the following:

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

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.

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.

When binding to a component, 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 process.

Handling a system exception—Fault Management Framework

How to do it...

You have created a service task ValidateStock in the salesrepresentative swimlane. This task invokes the Stockvalidator_EBS service. If Stockvalidator_EBS throws a binding or remote fault, you will use the fault-policy framework to catch the exception.

  1. Create a fault-policy.xml file. For the sample scenario, you will keep this file as simple as possible and would create it only for system faults binding and remote faults.
    <?xml version="1.0" encoding="windows-1252" ?>
    <faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
    <faultPolicy version="2.0.1" id="SystemFaults"
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Conditions>
    <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:remoteFault">
    <condition>
    <action ref="ora-retry"/>
    </condition>
    </faultName>
    <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:bindingFault">
    <condition>
    <action ref="ora-terminate"/>
    </condition>
    </faultName>
    <!-- Business faults -->
    </Conditions>
    <Actions>
    <Action id="ora-retry">
    <retry>
    <retryCount>3</retryCount>
    <retryInterval>2</retryInterval>
    <exponentialBackoff/>
    <retryFailureAction ref=" ora-human-intervention "/>
    <retrySuccessAction ref=" ora-terminate"/>
    </retry>
    </Action>
    <Action id="ora-rethrow-fault">
    <rethrowFault/>
    </Action>
    <Action id="ora-human-intervention">
    <humanIntervention/>
    </Action>
    <Action id="ora-terminate">
    <abort/>
    </Action>
    <Action id="ora-java">
    <!-- this is user provided class-->
    </Action>
    </Actions>
    <Properties></Properties>
    </faultPolicy>
    </faultPolicies>
    
  2. Create a fault-binding.xml file, as follows:
    <?xml version="1.0" encoding="windows-1252" ?>
    <faultPolicyBindings version="2.0.1"
    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="SystemFaults"/>
    <!-- Below listed component names use polic SystemFaults -->
    <component faultPolicy="SystemFaults">
    <name>Stockvalidator_EBS</name>
    </component>
    </faultPolicyBindings>
    

    You can find that the component Stockvalidator_EBS is bound with fault-policy.xml, as the value of the faultPolicy attribute matches the policy ID defined in the fault-policies.xml file.

  3. Add two properties in composite.xml, to let the composite use them.
  4. The fault-policy files are loaded at start-up, so when any changes are made to them, a server restart is required. The location for the Fault Policy files can be in the same directory as composite.xml or in a location identified by a property in composite.xml:
    <property name="oracle.composite.faultPolicyFile">fault-olicies.xml></property>
    <property name="oracle.composite.faultBindingFile">faultbindings.xml></property>
    

How it works...

When the process token reaches the ValidateStock service task and invokes the StockValidator_EBS service, if the service throws a binding/remote fault, it gets propagated as no boundary catch events are defined. For this component, Fault Policies are defined and hence the Fault Policy framework will handle the exception. As per your definition, in fault-policy.xml, on infusion of binding or remote fault, you would just terminate the process. Hence, in an error scenario this process will get terminated.

How it works...

Note

Once a fault is caught, the policy defines actions that can be used for the SOA instance, such as retry, human intervention, replay scope, throw fault again abort, and custom Java actions.

At present, fault-policies.xml can catch and act on both system and business faults for the BPEL and Mediator components. However, they cannot manage business faults in a BPMN process. They have to be handled within the process.

There's more...

You can use MDS location for Fault Policy files. In this way, the same files can be used across different composite projects.

Use MDS location for Fault Policy files

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

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

<property name="oracle.composite.faultPolicyFile">
oramds://apps/faultfiles/fault-policies.xml </property>
<property name="oracle.composite.faultBindingFile">
oramds://apps/faultfiles/fault-bindings.xml
</property>

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.195.34