Examples of Non-Retryable Errors

ADAPTER Life-Cycle Management 2-39 A mediator could have errors on a transformation. This type of error is a non-retryable error. The error will go back to the inbound adapter where it is handled, depending on the signature of the WSDL.

2.22.3 Outbound Adapter Interaction Error Handling

Outbound Interaction errors occur with messages that have interactions outbound from an adapter. This section addresses the retryability and non-retryability of these Outbound Interaction errors and provides a basis for understanding the related properties you can set.

2.22.3.1 Retryable Errors for Outbound Adapter Error Handling

Outbound retryable errors can be retried based on the value of jca.retry.count in the composite.xml file.

2.22.3.1.1 Setting Retryable Properties for Outbound Error Handling in the composite.xml File

For retryable exceptions for outbound error handling, you must set the value of jca.retry.count to the number of times that you want the retry to be carried out. For example, if you set the value of jca.retry.count to 10, the retry occurs 10 times, if needed. However, if you have not set any value for jca.retry.count, the retry is carried out by the fault policy, if you have included the fault policy as part of the composite.

2.22.3.1.2 Example: How to Set Values for Retryable Exceptions for Outbound Interactions

The following code snippet is an example of how to set values in the composite.xml file for retryable exceptions for outbound interactions. The retry is set to 5 minutes with an interval of 1 minute, and the other properties are appropriately configured. As stated before, the additional properties only have meaning once the jca.retry.count property is specified. reference name=Outbound interface.wsdl interface=http:xmlns...wsdl.interfaceOutbound_PortType binding.jca config=Outbound_jms.jca property name=jca.retry.count5property property name=jca.retry.interval1property property name=jca.retry.backoff2property property name=jca.retry.maxInterval6property property name=jca.retry.maxPeriod30property binding.jca reference

2.22.3.2 Non-Retryable Errors for Outbound Interaction Handling

You can handle non-retryable exceptions for outbound interactions by defining the maximum number of reconnection attempts that can be made in the fault-policy.xml file, which establishes the expected behavior for non-retryable errors. In this fault policy file, you specify the parameters for reconnection attempts, as shown in the following example. This includes: ■ The number of reconnection retries retryCount ■ Intervals between reconnection retries retryInterval 2-40 Oracle Fusion Middleware Users Guide for Technology Adapters ■ An exponential backoff value for the connection retries exponentialBackoff Note that all time measurements are specified in seconds. faultName xmlns:bplex=http:schemas.oracle.combpelextension name=bplex;bindingFault condition action ref=ora-retry faultName condition Actions Action id=ora-retry retry retryCount10retryCount retryInterval2retryInterval exponentialBackoff2exponentialBackoff retry Action Actions You must associate a fault policy with a reference end point of the composite in fault-bindings.xml file, as shown in the following example, with the faultPolicy ConnectionFaults and the reference name writeMessageToQueue. ?xml version=1.0 encoding=UTF-8? faultPolicyBindings version=2.0.1 xmlns=http:schemas.oracle.combpelfaultpolicy xmlns:xsi=http:www.w3.org2001XMLSchema-instance reference faultPolicy=ConnectionFaults namewriteMessageToQueuename reference faultPolicyBindings After the configured number of retries is reached without a positive result, the Service Infrastructure Invocation exception is thrown.

2.22.3.2.1 Fault Propagation

The propagation of the type of the Service Infrastructure Invocation exception is important to allow inbound adapters to respond to errors reported by outbound adapters. Figure 2–13, Fault Propagation shows the fault propagation when an adapter calls the service infrastructure synchronously, after which the Oracle BPEL Process Manager calls a down-stream adapter. In this figure, a Service Infrastructure Invocation exception propagates from the down-stream adapter, through Oracle BPEL Process Manager, and to the caller adapter.