Right-click soa-infra from the SOA Folder in the navigator in the left pane. Select oracle.as.soainfra.config, Server , AdapterConfig, and then adapter, as

2-38 Oracle Fusion Middleware Users Guide for Technology Adapters Figure 2–12 The soa-infra Page: System MBean Browser oracle.as.soainfra.config, Server, AdapterConfig, and adapter selected.

5. Modify the GlobalInboundJcaRetryCount attribute as an example of a Global

Property

2.22.2.3 Inbound Non-Retryable Errors

Typically non-retryable errors are a result of either transformation or message parsing. Inbound adapters handle non-retryable errors thrown from EIS by rejecting the inbound messages. If the error is a non-retryable error, you need to use the rejection handler to handle the non-retryable error.

2.22.2.3.1 Examples of Non-Retryable Errors

Examples of non-retryable errors thrown from interaction with an Enterprise Information System include the following: ■ Primary key violation ■ Queue does not exist ■ Master record does not exist ■ Unable to serialize payload Non-retryable errors do not resolve themselves until after the operation is retried. For example, messages can be sent from a file to an inbound file adapter via a Mediator. The Mediator, in turn, has sequential routing to an outbound Database Adapter that inserts data to a database table. The DB adapter might encounter a unique constraint error as it is performing the insert operation. This unique constraint error is: ■ Considered by the outbound Database Adapter as a non-retrybable error ■ Propagated back to the inbound Adapter ■ Considered by the inbound adapter as a non-retryable error as well, using a rejection handler. The adapter will use a fault policy if one is defined. 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