Manually Creating a Fault Policy File for Automated Fault Recovery

To manually create a fault policy file for automated fault recovery:

Create a fault policy file (for example, named fault-policies.xml). This file includes condition and action sections for performing specific tasks.

Place the file in the same directory as the composite.xml file or place it in a different location and define the oracle.composite.faultPolicyFile property.

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

If the fault policy file is located in a file system, use the following format.

<property
name="oracle.composite.faultPolicyFile">file:/project/apps/fault-policies.xml
</property>

Define the condition section of the fault policy file.

Note the following details about the condition section:

This section provides a condition based on faultName.
Multiple conditions may be configured for a faultName.
Each condition has one test section (an XPath expression) and one action section.
The test section (XPath expression) is evaluated for the fault variable available in the fault.
The action section has a reference to the action defined in the same file.
You can only query the fault variable available in the fault.
The order of condition evaluation is determined by the sequential order in the document.
You can associate a single or multiple alerts with a condition to be delivered (by email, JMS queue, or log file) when a specific error condition occurs.

Table 12-5 provides examples of the condition section in the fault policy file. All actions defined in the condition section must be associated with an action in the action section.

Table 12-5 Use of the condition Section in the Fault Policy File

Condition Example	Fault Policy File Syntax
This condition is checking a fault variable for `code = "WSDLFailure"` An `action` of `ora-terminate` is specified.	<condition> <test>$fault.code="WSDLReading Error" </test> <action ref="ora-terminate"/> </condition>
No `test` condition is provided. This is a catchAll condition for a given `faultName`.	<condition> <action ref="ora-rethrow"/> </condition>
Two user notification alerts are defined for the condition. Select the type of user notification alert to create when a fault occurs (for example, an email alert, a JMS queue alert, or a log file alert).	<condition> <alert ref = "ora-jms"/> <alert ref = "ora-email"/> <action ref="ora-rethrow"/> </condition>
If the `faultName` name attribute is missing, this indicates a catchAll activity for faults that have any `QName`.	<faultName > . . . </faultName>

Define the action section of the fault policy file. Validation of fault policy files is done during deployment. If you change the fault policy, you must redeploy the SOA composite application that includes the fault policy.

Table 12-6 provides several examples of the action section in the fault policy file. You can provide automated recovery actions for some faults. In all recovery actions except retry and human intervention, the framework performs the actions synchronously.

Table 12-6 Use of action Section in the Fault Policy File

Recovery Actions	Fault Policy File Syntax
Retry: Provides the following actions for retrying the activity. Retry a specified number of times. Provide a delay between retries (in seconds). Increase the interval with an exponential back off. Chain to a retry failure action if retry N times fails. Chain to a retry success action if a retry is successful. Note: Exponential back off indicates that the next retry attempt is scheduled at `2` x the delay, where delay is the current retry interval. For example, if the current retry interval is `2` seconds, the next retry attempt is scheduled at `4`, the next at `8`, and the next at `16` seconds until the `retryCount` value is reached.	<Action id="ora-retry"> <Retry> <retryCount>3</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-java"/> <retrySuccessAction ref="ora-java"/> </Retry> </Action> Note the following details: The framework chains to the retry success action if the retry attempt is successful. If all retry attempts fail, the framework chains to the retry failure action.
Human Intervention: Causes the current activity to stop processing. You can now go to Oracle Enterprise Manager Fusion Middleware Control and perform manual recovery actions on this instance.	<Action id="ora-human-intervention"> <humanIntervention/></Action>
Terminate Process: Terminates the process	<Action id="ora-terminate"><abort/></Action>
Java Code: Enables you to execute an external Java class. `returnValue`: The implemented Java class must implement a method that returns a string. The policy can chain to a new action based on the returned string. For additional information, see How to Use a Java Action Fault Policy.	<Action id="ora-java"> <!-- this is user provided custom java class--> <javaAction className="mypackage.myClass" defaultAction="ora-terminate"> <returnValue value="REPLAY" ref="ora-terminate"/> <returnValue value="RETRHOW" ref="ora-rethrow-fault"/> <returnValue value="ABORT" ref="ora-terminate"/> <returnValue value="RETRY" ref="ora-retry"/> <returnValue value="MANUAL" ref="ora-human-intervention"/> </javaAction> </Action>
Rethrow Fault: The framework sends the fault to the BPEL fault handlers (catch activities in scope activities). If none are available, the fault is sent up.	<Action id="ora-rethrow-fault"><rethrowFault/></Action>
Replay Scope: Raises a replay fault.	<Action id="ora-replay-scope"><replayScope/></Action>

Note:

The preseeded recovery action tag names (ora-retry, ora-human-intervention, ora-terminate, and so on) are only samples. You can substitute these names with ones appropriate to your environment.

A fault policy file with fully-defined condition, action, and alert sections looks as follows:

Note:

Fault policy file names are not restricted to one specific name. However, they must conform to the fault-policy.xsd schema file.
This fault policy file provides an example of catching faults based on fault names. You can also catch faults based on message types, or on both:
```
<faultName name="myfault" type="fault:faultType">
```

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <faultPolicy version="2.0.1" id="ModifyAndRecover"
               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>
      <!-- Handle remoteFault system exceptions -->
      <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:remoteFault">
        <condition>
        <!--<test>$fault.code="1"</test>-->
          <alert ref = "ora-jms"/> 
          <alert ref = "ora-email"/>
       <action ref="default-human-intervention"/>
        </condition>
      </faultName>
           <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
 name="bpelx:bindingFault">
        <condition>
          <action ref="default-human-intervention"/>
        </condition>
      </faultName>          </Conditions>
       <Alerts>
          <Alert id="ora-email">
           <email>
             <To>joe.smith@example.com</To>
                 <CC>joe.smith@example.com</CC>
           </email>
          </Alert>
          <Alert id="ora-jms">
        <JMS propertySet="jms-props">
          <Headers>
            <property name="correlationId">myvalue</property>
             <property name="correlationId1">myvalue1</property>
          </Headers>
        </JMS>
      </Alert>
    </Alerts>
    <Actions>
      <!-- Generics -->
      <Action id="default-terminate">
        <abort/>
      </Action>
      <Action id="default-replay-scope">
        <replayScope/>
      </Action>
      <Action id="default-rethrow-fault">
        <rethrowFault/>
      </Action>
      <Action id="default-human-intervention">
        <humanIntervention/>
      </Action>
      <Action id="ora-retry-with-human-intervention">
        <retry>
          <retryCount>1</retryCount>
          <retryInterval>2</retryInterval>
          <exponentialBackoff/>
          <retryFailureAction ref="default-terminate"/> 
        </retry>
      </Action>
      </Actions>
      <Properties>
       <propertySet name="jms-props">
         <property name="jmsDestination">MyQueue</property>
         <property
 name="connectionFactory">jms/fabric/ehconnectionfactory</property>
     </propertySet>
     </Properties>
  </faultPolicy>
</faultPolicies>