How to Work with Multipart Target Messages

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 21-4 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite test containsfault.PART_NAMEcustid, 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 Oracle 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 Oracle 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 21–5 : Example 21–5 Capturing Errors or Faults Generated by an Adapter faultName xmlns:medns=http:schemas.oracle.commediatorfaults name=medns:mediatorFault condition testfault.faultCode = 1test -- unique constraint violation in DB adapter-- action ref=ora-retry condition faultName

21.1.1.2 Actions

Actions specify the tasks to perform when an error occurs. Oracle Mediator provides a list of actions that you can use in a fault policy. These predefined actions are described in the following list: ■ Retry: 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 21–1 describes the options available with the retry action. Table 21–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.