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:
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.
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.
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>
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.
composite.xml
, to let the composite use them.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>
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.
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.
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.
18.189.195.34