How to Work with Multipart Reply, Fault, and Callback Source Messages

21-2 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite A sample fault policy file is shown in Example 21–1 : Example 21–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.commediatorfaults name=medns:mediatorFault condition testcontainsfault.mediatorErrorCode, TYPE_FATAL_MESHtest action ref=ora-retry condition faultName Conditions Actions Action id=ora-retry retry retryCount3retryCount retryInterval2retryInterval 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.

21.1.1.1 Conditions

Conditions identify error or fault conditions along with a reference to the actions to be taken. You can use conditions to identify the action 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 21–2 : Example 21–2 Conditions Conditions faultName xmlns:medns=http:schemas.oracle.commediatorfaults Note: Fault policies are applicable to parallel routing rules only. For sequential routing rules, the fault goes back to the caller. It is the responsibility of the caller to handle the fault. If the caller is an adapter, then 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 the Oracle Fusion Middleware Users Guide for Technology Adapters. Using Oracle Mediator Error Handling 21-3 name=medns:mediatorFault condition testcontainsfault.mediatorErrorCode,TYPE_DATA_ TRANSFORMATIONtest action ref=ora-java condition faultName faultName xmlns:medns=http:schemas.oracle.commediatorfaults name=medns:mediatorFault condition testcontainsfault.mediatorErrorCode, TYPE_FATAL_MESHtest action ref=ora-retry condition faultName faultName xmlns:medns=http:schemas.oracle.commediatorfaults name=medns:mediatorFault condition testcontainsfault.mediatorErrorCode,TYPE_DATA_ASSIGNtest 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: ■ Oracle Mediator-specific faults For all Oracle Mediator-specific faults, the Oracle Mediator service engine throws only one fault, namely {http:schemas.oracle.commediatorfaults}mediatorFault. Every Oracle Mediator fault is wrapped into this fault. The errors or faults generated by an Oracle Mediator can be captured by using the format shown in Example 21–3 : Example 21–3 Oracle Mediator-Specific Faults faultName xmlns:medns=http:schemas.oracle.commediatorfaults name=medns:mediatorFault -- mediatorFault is a bucket for all the mediator faults -- condition test containsfault.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 21–4 provides details. Example 21–4 Business Faults and SOAP Faults faultName xmlns:ns1=http:xmlns.oracle.comCustomer name=ns1:InvalidCustomer -- Qname of BusinessSOAP fault -- condition