Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite
11g Release 1 (11.1.1.7)

Part Number E10224-20
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

22 Using Oracle Mediator Error Handling

This chapter describes the error handling capabilities of Oracle Mediator and provides instructions for defining error handling for both business faults and system faults.

This chapter includes the following sections:

22.1 Introduction to Mediator Error Handling

Mediator provides sophisticated error handling capabilities that enable you to configure a Mediator service component for error occurrences and corresponding corrective actions. Error handling enables a Mediator to handle errors that occur during the processing of messages and also the exceptions returned by outside web services. You can handle both business faults and system faults with Mediator.

Business faults are application-specific and are explicitly defined in the service WSDL file. You can handle business faults by defining the fault handlers in Oracle JDeveloper at design time. System faults occur because of some problem in the underlying system such as a network not being available. Mediator provides fault policy-based error handling for system faults.

Fault policies enable you to handle errors automatically or through human intervention. Mediator fault policy-based error handling consists of the following three components:

22.1.1 Fault Policies

A fault policy defines error conditions and corresponding actions. Fault policies are defined in the fault-policies.xml file, which should be created based on the XML schema shown in Section 22.4.1, "Schema Definition File for fault-policies.xml."

Fault policies for sequential routing rules are handled differently than for parallel routing rules, as described below:

  • Due to the single threading of sequential routing rules, only three actions (Abort, Rethrow, and Java) are supported for handling errors, and the specified actions are executed immediately in the caller's thread.

  • Mediator messages are not persisted in sequential routing.

  • Asynchronous and one-way Mediator components cannot handle system faults thrown from other SOA Suite components, such as a BPEL business process.

For more information about available error handling actions, see Section 22.1.1.2, "Actions."

A sample fault policy file is shown in Example 22-1:

Example 22-1 Sample Fault Policy File

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies>
  <faultPolicy version="2.0.1" id="CRM_ServiceFaults">
    <Conditions>
      <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
 name="medns:mediatorFault">
        <condition>
         <test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
          <action ref="ora-retry"/>
        </condition>
      </faultName>
     </Conditions>
    <Actions>
        <Action id="ora-retry">
          <retry>
            <retryCount>3</retryCount>
            <retryInterval>2</retryInterval>
            <exponentialBackoff/>
            <retryFailureAction ref="ora-java"/>
            <retrySuccessAction ref="ora-terminate"/>
          </retry>
        </Action>
    </Actions>
  </faultPolicy>
</faultPolicies>

The two components of the fault policy (conditions and actions) are described in the following sections.

22.1.1.1 Conditions

Conditions allow you to identify error or fault conditions and then specify the actions to be taken when a particular error or fault condition occurs. For example, for a particular error occurring because of a service not being available, you can perform an action such as a retry. Similarly, for another error occurring because of the failure of Schematron validation, you can perform the action of human intervention. This fault can be recovered manually by editing the payload and then resubmitting it through Oracle Enterprise Manager Fusion Middleware Control.

Conditions are defined in the fault-policies.xml file, as shown in Example 22-2:

Example 22-2 Conditions

<Conditions>
      <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
       name="medns:mediatorFault">
          <condition>
            <test>contains($fault.mediatorErrorCode,"TYPE_DATA_TRANSFORMATION")</test>
             <action ref="ora-java"/>
          </condition>
      </faultName>
      <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
        <condition>
         <test>contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")</test>
          <action ref="ora-retry"/>
        </condition>
      </faultName>
      <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
        <condition>
         <test>contains($fault.mediatorErrorCode,"TYPE_DATA_ASSIGN")</test>
          <action ref="ora-retry-crm-endpoint"/>
        </condition>
      </faultName>
</Conditions>

Identifying Fault Types Using Conditions 

You can categorize the faults that can be captured using conditions into the following types:

  • Mediator-specific faults

    For all Mediator-specific faults, the Mediator service engine throws only one fault, namely {http://schemas.oracle.com/mediator/faults}mediatorFault. Every Mediator fault is wrapped into this fault. The errors or faults generated by a Mediator can be captured by using the format shown in Example 22-3:

    Example 22-3 Oracle Mediator-Specific Faults

    <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
    <!-- mediatorFault is a bucket for all the mediator faults -->
         <condition>
           <test>
     contains($fault.mediatorErrorCode, "TYPE_FATAL_MESH")
     </test> 
    <!-- Captures TYPE_FATAL_MESH errors -->
           <action ref="ora-retry"/>
         </condition>
       </faultName>
    
  • Business faults and SOAP faults

    These errors or faults can be captured by defining an XPath condition, which is based on the fault payload. Example 22-4 provides details.

    Example 22-4 Business Faults and SOAP Faults

    <faultName xmlns:ns1="http://xmlns.oracle.com/Customer"
     name="ns1:InvalidCustomer"> <!-- Qname of Business/SOAP fault -->
           <condition>
             <test>
    contains($fault.<PART_NAME>/custid, 1011)
     </test>
    <!-- xpath condition based on fault payload -->
             <action ref="ora-retry"/>
           </condition>
       </faultName>
    

    When a reference service returns a business fault, the fault can be handled in the Mediator service component. The returned fault can be forwarded to another component, redirected to an adapter service such as a file adapter, or an event can be raised. However, if both a fault policy and fault handler are defined for a business fault, then the fault policy takes precedence over the fault handler. In such a case, the fault handlers in the Mediator service component are ignored, if the fault policy is successfully executed.

  • Adapter-specific fault

    The errors or faults generated by an adapter can be captured by using the format shown in Example 22-5:

    Example 22-5 Capturing Errors or Faults Generated by an Adapter

    <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
       <condition>
         <test>$fault.faultCode = "1"</test> <!-- unique constraint violation in DB adapter-->
         <action ref="ora-retry"/>
       </condition>
     </faultName>
    

22.1.1.2 Actions

Actions specify the tasks to perform when an error occurs. Mediator supports retry, human intervention, abort, and Java code actions for parallel routing rules. For sequential routing rules, fault policies can contain these actions: abort, rethrow, and Java code.

If retry or human intervention action is chosen with sequential routing rules, the fault goes back to the caller directly, and the policy is not applied. The fact that an incompatible action was chosen is recorded in the log. This is consistent with BPEL fault policy behavior. It is the responsibility of the caller to handle the fault. If the caller is an adapter, you can define rejection handlers on the inbound adapter to take care of the messages that error out (that is, the rejected messages). For more information about rejection handlers, see Oracle Fusion Middleware User's Guide for Technology Adapters.

Fault policy actions are described in the following sections.

22.1.1.2.1 Retry Action

Retry actions such as enqueueing a message to a JMS queue that is stopped, inserting a record with a unique key constraint error, and so on, enable you to retry a task that caused the error. A new thread is started with every retry action. Therefore, with every retry action, a new transaction starts. Table 22-1 describes the options available with the retry action. Retry actions are applicable to parallel routing rules only.

Table 22-1 Retry Action Options

Option Description

Retry Count

Retry N times.

Retry Interval

Delay in seconds for a retry.

Exponential Backoff

Retry interval increase with an exponential backoff.

Retry Failure Action

Chain to this action if a retry N times fails.

Retry Success Action

Chain to this action if a retry succeeds.


Note:

Exponential backoff 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.

Example 22-6 shows how to specify the retry action:

Example 22-6 Retry Action

<Action id="ora-retry">
 <retry>
 <retryCount>3</retryCount>
 <retryInterval>2</retryInterval>
 <exponentialBackoff/>
 <retryFailureAction ref="ora-java"/>
 <retrySuccessAction ref="ora-java"/>
 </retry>
 </Action>

If you set the retry interval in the fault policy to a duration of less than 30 seconds, then the retry may not happen within the specified intervals. This is because the default value of the org.quartz.scheduler.idleWaitTime property is 30 seconds, and the scheduler waits for 30 seconds before retrying for available triggers, when the scheduler is otherwise idle. If the retry interval is set to a value of less than 30 seconds, then latency is expected.

If you want the system to use a retry interval that is less than 30 seconds, add the following property under the section <property name="quartzProperties"> in the fabric-config-core.xml file:

org.quartz.scheduler.idleWaitTime=<value>
22.1.1.2.2 Rethrow Action

Rethrow executes the fault policy in the caller's thread and returns the original exception to the user.

An example of a rethrow action is shown below:

<Action id="ora-rethrow-fault"><rethrowFault/></Action>
22.1.1.2.3 Human Intervention Action

The human intervention action allows you to manually recover the fault by correcting the error (for example, altering the payload) and then manually retrying the message. This action is applicable to parallel routing rules only.

An example of a human intervention action is shown below:

<Action id="ora-human-intervention"><humanIntervention/></Action>
22.1.1.2.4 Abort Action

The abort action enables you to terminate the message flow. This action is applicable to both parallel and sequential routing rules.

When the abort action is executed for a sequential routing rule, the exception FabricInvocationException is thrown back to the caller, and the mediator component state changes to terminated. The fault policy is executed in the caller's thread.

An example of an abort action is shown below:

<Action id="ora-terminate"><abort/></Action>
22.1.1.2.5 Java Code Action

The Java code action lets you call a customized Java class that implements the oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass interface. This action is applicable to both parallel and sequential routing rules. Example 22-7 shows how Java code actions can be implemented.

Notes:

The implemented Java class must implement a method that returns a string. The policy can be chained to a new action based on the returned string.

The Java code action first looks for the implemented class in the domain class library. If the class is not found there, the action looks in the Composite Application's class library.

Example 22-7 Customized Java Class Calling

<Action id="ora-java">
        <javaAction className="mypackage.myClass" defaultAction="ora-terminate">
          <returnValue value="ABORT" ref="ora-terminate"/>
          <returnValue value="RETRY" ref="ora-retry"/>
          <returnValue value="MANUAL" ref="ora-human-intervention"/>
        </javaAction>
      </Action>

For more information, see Example 22-8 and Example 22-9.

For a sequential routing rule fault policy, the returnValue action must be one of Abort, Rethrow, or Java action. If the returnValue is other than these valid values, then the defaultAction is checked. If the defaultAction is also not a valid action (Abort, Rethrow, or Java action), then no action is performed by default, and the original fault is thrown back to the caller.

Example 22-8 oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass Interface

oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass {
 
    public void handleRetrySuccess(IFaultRecoveryContext ctx);   
    public String handleFault(IFaultRecoveryContext ctx);
}

Example 22-9 oracle.integration.platform.faultpolicy.IFaultRecoveryContext Interface

public interface IFaultRecoveryContext {
   
    /**
     * Gets implementation type of the fault. 
     * @return
     */
    public String getType();
   
    /**
     * @return Get property set of the fault policy action being executed.
     */
    public Map getProperties();
 
    /**
     * @return Get fault policy id of the fault policy being executed.
     */
    public String getPolicyId();
 
    /**
     * @return Name of the faulted reference.
     */
    public String getReferenceName();
 
    /**
     * @return Port type of the faulted reference link.
     */
    public QName getPortType();
}

Mediator Service Engine Implementation 

Example 22-10 shows the Oracle Mediator service engine implementation of the IFaultRecoveryContext interface.

Example 22-10 IFaultRecoveryContext Interface Implementation

package oracle.tip.mediator.common.error.recovery;
public class MediatorRecoveryContext implements IFaultRecoveryContext{
   ... 
}

You can use the methods shown in Example 22-11 to retrieve additional Mediator-specific data available with the MediatorRecoveryContext class:

Example 22-11 Methods for Retrieving Data

public Fault getFault()
public CalloutMediatorMessage getMediatorMessage()

Example 22-12 shows how to retrieve data using the CalloutMediatorMessage interface:

Example 22-12 Data Retrieval Using the CalloutMediatorMessage Interface

/**
     * Accessing Mediator Message properties by providing the property name
     * @param propertyName
     * @return
     * @throws MediatorException
     */
    public Object getProperty(String propertyName);
   
    /**
     * Accessing Mediator Message properties
     * @return
     * @throws MediatorException
     */
    public Map getProperties();
 
    /**
     * Accessing instance id of the mediator message
     * This will be the mediator instance id created for that particular message
     * object
     * @return
     * @throws MediatorException
     */
    public String getId() throws MediatorException;
   
    /**
     * Accessing payload of the mediator message
     * object
     * @return
     * @throws MediatorException
     */
    public Map getPayload();
   
    /**
     * Accessing header of the mediator message
     * object
     * @return
     * @throws MediatorException
     */
    public List<Element> getHeaders();
   
    /**
     * Accessing componentDN for mediator component
     * @return
     * @throws MediatorException
     */
    public String getComponentDN( 
    /**
     * Setting payload to the mediator message
     * @return
     * @throws MediatorCalloutException
     */
    public void addPayload(String partName,Object payload) throws MediatorCalloutException;
   
    /**
     * Adding property to the mediator message
     * @return
     * @throws MediatorCalloutException
     */
    public void addProperty(String name,Object value) throws MediatorCalloutException;
   
    /**
     * Adding header to the mediator message
     * @return
     * @throws MediatorCalloutException
     */
    public void addHeader(Object header) throws MediatorCalloutException;

22.1.2 Fault Bindings

Fault bindings associate fault policies with composites or components, and are defined in the fault-bindings.xml file. Create the fault-bindings.xml file based on the XML schema defined in Section 22.4.2, "Schema Definition File for fault-bindings.xml."

Fault policies can be created at the following levels:

  • Composite: You can define one fault policy for all Mediator components in a composite. You can specify this level in the following way:

    <composite faultPolicy="ConnectionFaults"/>
    
  • Component: You can define a fault policy exclusively for a Mediator service component. A component-level fault policy overrides the composite-level fault policy. You can specify this level as shown in Example 22-13.

    Example 22-13 Definition of a Fault Policy for a Mediator

    <component faultPolicy="ConnectionFaults">
            <name>Component1</name>
            <name>Component2</name>
    </component>
    
  • Reference: You can define a fault policy for the references of a Mediator component. You can specify this level as shown in Example 22-14.

    Example 22-14 Definition of a Fault Policy for a Reference

    <reference faultPolicy="policy1">
        <name>DBAdapter3</name>
      </reference>
    

Note:

Human intervention is the default action for errors that do not have a fault policy defined.

A sample fault binding file is shown in Example 22-15.

Example 22-15 Sample Fault Binding File

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
 xmlns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>

22.1.3 Error Groups in Mediator

You can specify an action for an error type or error group while defining the conditions in a fault policy. In the previous examples, medns:mediatorFault indicates that the error is a Mediator error, whereas medns:TYPE_FATAL_MESH refers to an error group. An error group consists of one or more child error types. TYPE_ALL is an error group that contains all Mediator errors.

The following list describes various error groups contained in the TYPE_ALL error group:

  • TYPE_DATA: Contains errors related to data handling.

    • TYPE_DATA_ASSIGN: Contains errors related to data assignment.

    • TYPE_DATA_FILTERING: Contains errors related to data filtering.

    • TYPE_DATA_TRANSFORMATION: Contains errors that occur during a transformation.

    • TYPE_DATA_VALIDATION: Contains errors that occur during payload validation.

  • TYPE_METADATA: Contains errors related to Mediator metadata.

    • TYPE_METADATA_FILTERING: Contains errors that occur while processing the filtering conditions.

    • TYPE_METADATA_TRANSFORMATION: Contains errors that occur while getting the metadata for a transformation.

    • TYPE_METADATA_VALIDATION: Contains errors that occur during validation of metadata for Mediator (.mplan file).

    • TYPE_METADATA_COMMON: Contains other errors that occur during the handling of metadata.

  • TYPE_FATAL: Contains fatal errors that are not easily recoverable.

    • TYPE_FATAL_DB: Contains database-related fatal errors, such as a Datasource not found error.

    • TYPE_FATAL_CACHE: Contains Mediator cache-related fatal errors.

    • TYPE_FATAL_ERRORHANDLING: Contains fatal errors that occur during error handling such as Resubmission queues not available.

    • TYPE_FATAL_MESH: Contains fatal errors from the Service Infrastructure such as Invoke service not available.

    • TYPE_FATAL_MESSAGING: Contains fatal messaging errors arising from the Service Infrastructure.

    • TYPE_FATAL_TRANSACTION: Contains fatal errors related to transactions such as Commit can't be called on a transaction which is marked for rollback.

    • TYPE_FATAL_TRANSFORMATION: Contains fatal transformation errors such as an error occurring because of the XPath functions used in a transformation.

  • TYPE_TRANSIENT: Contains transient errors that can be recovered on a retry.

    • TYPE_TRANSIENT_MESH: Contains errors related to the Service Infrastructure.

    • TYPE_TRANSIENT_MESSAGING: Contains errors related to JMS such as enqueuing and dequeuing.

  • TYPE_INTERNAL: Contains internal errors.

22.2 Using Error Handling with Mediator

You can enable error handling for an Oracle Mediator by using the fault-policies.xml and fault-bindings.xml files.

22.2.1 How to Use Error Handling for a Mediator Service Component

To use error handling for a Mediator service component:

  1. Create a fault-policies.xml file based on the schema defined in Section 22.4.1, "Schema Definition File for fault-policies.xml."

  2. Create a fault-bindings.xml file based on the schema defined in Section 22.4.2, "Schema Definition File for fault-bindings.xml."

  3. Copy the fault-policies.xml and the fault-bindings.xml file to your SOA composite application project directory.

  4. Deploy the SOA composite application project.

22.2.2 What Happens at Runtime

All the fault policies for a composite are loaded when the first error occurs. When an error occurs, the Mediator Service Engine checks for the existence of the fault policy files (fault-policies.xml and fault-bindings.xml). The fault policy bindings are checked to determine the fault policy associated with the component or composite. If a fault policy is associated with the component or composite, then Mediator performs the action defined in the fault policy corresponding to the fault condition. If no fault policy bindings are found for the component or composite, then no action is performed and the behavior is the same as if the fault policies did not exist.

If there is no fault policy defined and the routing rule is executed in parallel, the default action of human intervention is performed. If there is no fault policy defined and the routing rule is executed sequentially, the error is thrown back to the caller.

Note:

All sequential routing transactions that encounter an error are rolled back, even if a fault policy has been used to handle the errors.

For more information about how fault policies are processed, see Section 22.1.1.2, "Actions."

22.3 Fault Recovery Using Oracle Enterprise Manager Fusion Middleware Control

Apart from policy-based recovery using the fault policy file, you can also perform fault recovery actions on Oracle Mediator faults identified as recoverable in Oracle Enterprise Manager Fusion Middleware Control. Use any of the following ways to recover faults:

22.4 Error Handling XML Schema Definition Files

This section describes the schema files for the fault-policies.xml and fault-bindings.xml files.

22.4.1 Schema Definition File for fault-policies.xml

The fault-policies.xml file should be based on the XSD file shown in Example 22-16.

Example 22-16 XSD File for fault-policies.xml

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <!-- Conditions contain a list of fault names -->
    <xs:element name="Conditions">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="faultName" type="tns:faultNameType"
 maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <!-- action Ref must exist in the same file -->
    <xs:complexType name="actionRefType">
        <xs:attribute name="ref" type="xs:string" use="required"/>
    </xs:complexType>
    <!-- one condition has a test and action, if test is missing, this is the
 catch all condition -->
    <xs:complexType name="conditionType">
        <xs:all>
            <xs:element name="test" type="tns:idType" minOccurs="0"/>
            <xs:element name="action" type="tns:actionRefType"/>
        </xs:all>
    </xs:complexType>
    <!-- One fault name match contains several conditions -->
    <xs:complexType name="faultNameType">
        <xs:sequence>
            <xs:element name="condition" type="tns:conditionType"
 maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="name" type="xs:QName"/>
        <xs:attribute name="type" type="xs:QName"/>
    </xs:complexType>
    <xs:complexType name="ActionType">
        <xs:choice>
            <xs:element name="retry" type="tns:RetryType"/>
            <xs:element ref="tns:rethrowFault"/>
            <xs:element ref="tns:humanIntervention"/>
            <xs:element ref="tns:abort"/>
            <xs:element ref="tns:replayScope"/>
 <xs:element name="fileAction" type="tns:FileActionType"/>
 <xs:element name="invokeWS" type="tns:InvokeWSType"/>
 <xs:element name="enqueue" type="tns:EnqueueType"/>
            <xs:element name="javaAction" type="tns:JavaActionType">
                <xs:key name="UniqueReturnValue">
                    <xs:selector xpath="tns:returnValue"/>
                    <xs:field xpath="@value"/>
                </xs:key>
            </xs:element>
        </xs:choice>
        <xs:attribute name="id" type="tns:idType" use="required"/>
    </xs:complexType>
    <xs:element name="Actions">
        <xs:annotation>
            <xs:documentation>Fault Recvorey Actions</xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element name="Action" type="tns:ActionType"
 maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:complexType name="JavaActionType">
        <xs:annotation>
            <xs:documentation>This action invokes java code
 provided</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="returnValue" type="tns:ReturnValueType"
 minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="className" type="tns:idType" use="required"/>
        <xs:attribute name="defaultAction" type="tns:idType" use="required"/>
        <xs:attribute name="propertySet" type="tns:idType"/>
    </xs:complexType>
    <xs:complexType name="RetryType">
        <xs:annotation>
            <xs:documentation>This action attempts retry of activity
 execution</xs:documentation>
        </xs:annotation>
        <xs:all>
            <xs:element ref="tns:retryCount"/>
            <xs:element ref="tns:retryInterval"/>
            <xs:element ref="tns:exponentialBackoff" minOccurs="0"/>
            <xs:element name="retryFailureAction"
 type="tns:retryFailureActionType" minOccurs="0"/>
            <xs:element name="retrySuccessAction"
 type="tns:retrySuccessActionType" minOccurs="0"/>
        </xs:all>
    </xs:complexType>
    <xs:complexType name="FileActionType">
        <xs:annotation>
            <xs:documentation>This action stores the rejected message on the file
 system.</xs:documentation>
        </xs:annotation>
        <xs:all>
            <xs:element ref="tns:location"/>
            <xs:element ref="tns:fileName"/>
        </xs:all>
    </xs:complexType>
    <xs:element name="location" type="xs:string">
        <xs:annotation>
            <xs:documentation>This value indicates the location of directory which
 will be used to store the rejected messages.</xs:documentation>
        </xs:annotation>
    </xs:element>
    <xs:element name="fileName" type="xs:string">
        <xs:annotation>
            <xs:documentation>This value indicates the filename or the pattern for
 the filenames which will be used to store the rejected
 messages.</xs:documentation>
        </xs:annotation>
    </xs:element>
    <xs:simpleType name="idType">
        <xs:restriction base="xs:string">
            <xs:minLength value="1"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="InvokeWSType">
        <xs:annotation>
            <xs:documentation>The Webservice to handle the rejcted
 messages.</xs:documentation>
        </xs:annotation>
        <xs:attribute name="uri" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:complexType name="EnqueueType">
        <xs:annotation>
            <xs:documentation>Rejected message will be enqueued to a queue as a
 JMS message with the proper context and payload.</xs:documentation>
        </xs:annotation>
        <xs:attribute name="uri" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:complexType name="ReturnValueType">
        <xs:annotation>
            <xs:documentation>Return value from java code can chain another action
 using return values</xs:documentation>
        </xs:annotation>
        <xs:attribute name="value" type="tns:idType" use="required"/>
        <xs:attribute name="ref" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:element name="exponentialBackoff">
        <xs:annotation>
            <xs:documentation>Setting this will cause retry attempts to use
                     exponentialBackoff algorithm</xs:documentation>
        </xs:annotation>
        <xs:complexType/>
    </xs:element>
    <xs:element name="humanIntervention">
        <xs:annotation>
            <xs:documentation>This action causes the activity to
 freeze</xs:documentation>
        </xs:annotation>
        <xs:complexType/>
    </xs:element>
    <xs:element name="replayScope">
        <xs:annotation>
            <xs:documentation>This action will replay the immidiate enclosing
 scope</xs:documentation>
        </xs:annotation>
        <xs:complexType/>
    </xs:element>
    <xs:element name="rethrowFault">
        <xs:annotation>
            <xs:documentation>This action will rethrow the
 fault</xs:documentation>
        </xs:annotation>
        <xs:complexType/>
    </xs:element>
    <xs:element name="retryCount" type="xs:positiveInteger">
        <xs:annotation>
            <xs:documentation>This value is used to identify number of
 retries</xs:documentation>
        </xs:annotation>
    </xs:element>
    <xs:complexType name="retryFailureActionType">
        <xs:annotation>
            <xs:documentation>This is the action to be chained if retry attempts
 fail</xs:documentation>
        </xs:annotation>
        <xs:attribute name="ref" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:complexType name="retrySuccessActionType">
        <xs:annotation>
            <xs:documentation>This is the action to be chained if retry attempts
 is successful</xs:documentation>
        </xs:annotation>
        <xs:attribute name="ref" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:element name="retryInterval" type="xs:unsignedLong">
        <xs:annotation>
            <xs:documentation>This is the delay in milliseconds of retry
 attempts</xs:documentation>
        </xs:annotation>
    </xs:element>
    <xs:element name="abort">
        <xs:annotation>
            <xs:documentation>This action terminates the
 process</xs:documentation>
        </xs:annotation>
        <xs:complexType/>
    </xs:element>
    <xs:element name="Properties">
        <xs:annotation>
            <xs:documentation>Properties that can be passes to a custom java
 class</xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element name="propertySet" type="tns:PropertySetType"
 maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:complexType name="PropertySetType">
        <xs:sequence>
            <xs:element name="property" type="tns:PropertyValueType"
 maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="name" type="tns:idType" use="required"/>
    </xs:complexType>
    <xs:complexType name="PropertyValueType">
        <xs:simpleContent>
            <xs:extension base="tns:idType">
                <xs:attribute name="name" type="tns:idType" use="required"/>
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>
    <xs:element name="faultPolicies">
        <xs:annotation>
            <xs:documentation>Fault Policies</xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="tns:faultPolicy" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:element name="faultPolicy">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="tns:Conditions"/>
                <xs:element ref="tns:Actions"/>
                <xs:element ref="tns:Properties" minOccurs="0"/>
                <!--Every policy has on Conditions and and one Actions, however,
 Properties is optional -->
            </xs:sequence>
            <xs:attribute name="id" type="tns:idType" use="required"/>
            <xs:attribute name="version" type="xs:string" default="2.0.1"/>
        </xs:complexType>
        <xs:key name="UniqueActionId">
            <xs:selector xpath="tns:Actions/tns:Action"/>
            <xs:field xpath="@id"/>
        </xs:key>
        <xs:key name="UniquePropertySetId">
            <xs:selector xpath="tns:Properties/tns:property_set"/>
            <xs:field xpath="@id"/>
        </xs:key>
        <xs:keyref name="RetryActionRef" refer="tns:UniqueActionId">
            <xs:selector
 xpath="tns:Actions/tns:Action/tns:retry/tns:retryFailureAction"/>
            <xs:field xpath="@ref"/>
        </xs:keyref>
        <xs:keyref name="RetrySuccessActionRef" refer="tns:UniqueActionId">
            <xs:selector
 xpath="tns:Actions/tns:Action/tns:retry/tns:retrySuccessAction"/>
            <xs:field xpath="@ref"/>
        </xs:keyref>
        <xs:keyref name="JavaActionRef" refer="tns:UniqueActionId">
            <xs:selector
 xpath="tns:Actions/tns:Action/tns:javaAction/tns:returnValue"/>
            <xs:field xpath="@ref"/>
        </xs:keyref>
        <xs:keyref name="ConditionActionRef" refer="tns:UniqueActionId">
            <xs:selector
 xpath="tns:Conditions/tns:faultName/tns:condition/tns:action"/>
            <xs:field xpath="@ref"/>
        </xs:keyref>
        <xs:keyref name="JavaDefaultActionRef" refer="tns:UniqueActionId">
            <xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
            <xs:field xpath="@defaultAction"/>
        </xs:keyref>
        <xs:keyref name="JavaPropertySetRef" refer="tns:UniquePropertySetId">
            <xs:selector xpath="tns:Actions/tns:Action/tns:javaAction"/>
            <xs:field xpath="@property_set"/>
        </xs:keyref>
    </xs:element>
</xs:schema>

22.4.2 Schema Definition File for fault-bindings.xml

The fault-bindings.xml file should be based on the XSD file shown in Example 22-17.

Example 22-17 XSD File for fault-bindings.xml

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:tns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <xs:element name="faultPolicyBindings">
        <xs:annotation>
            <xs:documentation>Bindings to a specific fault policy
 </xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element name="composite" type="tns:compositeType"
 minOccurs="0" maxOccurs="1"/>
                <xs:element name="component" type="tns:componentType"
 minOccurs="0" maxOccurs="unbounded"/>
                <xs:element name="reference" type="tns:referenceType"
 minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="version" type="xs:string" default="2.0.1"/>
        </xs:complexType>
        <xs:key name="UniquePartnerLinkName">
            <xs:selector xpath="tns:reference/tns:name"/>
            <xs:field xpath="."/>
        </xs:key>
        <xs:key name="UniquePortType">
            <xs:selector xpath="tns:reference/tns:portType"/>
            <xs:field xpath="."/>
        </xs:key>
        <xs:key name="UniquePolicyName">
            <xs:selector xpath="tns:reference"/>
            <xs:field xpath="@faultPolicy"/>
        </xs:key>
    </xs:element>
    <xs:simpleType name="nameType">
        <xs:restriction base="xs:string">
            <xs:minLength value="1"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="propertyType">
        <xs:simpleContent>
            <xs:extension base="tns:nameType">
                <xs:attribute name="name" type="xs:string" use="required"
 fixed="faultPolicy"/>
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>
 
    <xs:complexType name="referenceType">
        <xs:annotation>
            <xs:documentation>Bindings for a partner link. Overrides composite
 level binding.</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:annotation>
                <xs:documentation>Specification at partner link name overrides
 specification for a port type</xs:documentation>
            </xs:annotation>
            <xs:element name="name" type="tns:nameType" minOccurs="0"
 maxOccurs="unbounded"/>
            <xs:element name="portType" type="xs:QName" minOccurs="0"
 maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
    </xs:complexType>
 
    <xs:complexType name="componentType">
        <xs:annotation>
            <xs:documentation>Binding for a component </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="name" type="tns:nameType" minOccurs="0"
 maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
    </xs:complexType>
    <xs:complexType name="compositeType">
        <xs:annotation>
            <xs:documentation>Binding for the entire composite</xs:documentation>
        </xs:annotation>
        <xs:attribute name="faultPolicy" type="tns:nameType" use="required"/>
    </xs:complexType>
</xs:schema>