Oracle JCA Adapters - Rejected Message Handling

Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-63 1. Commit the removal of the message from the inbound adapter endpoint, for example, table and queue. 2. Commit the execution of the composite instance. If anything fails during this process, both of these actions are rolled back based on XA guarantees. Outbound Transactions For transactional adapters, outbound JCA interactions the invoke activities are scoped with the global JTA transaction of the Composite instance. This means that all composite activities, including Oracle JCA adapter invocations, are part of a global transaction, and as such all activities are either committed or rolled back if an error occurs. Therefore, one can guarantee exactly-once message delivery when both inbound and outbound adapters are transactional and the connection factories have been configured to support XA global transactions. Nontransactional The Oracle File Adapter picks up a file from an inbound directory, processes the file, and sends the processed file to an output directory. However, during this process if a failover occurs in the Oracle RAC backend or in an SOA managed server, then the file is processed twice because of the nontransactional nature of Oracle File Adapter. As a result, there can be duplicate files in the output directory.

5.10.1.3 Oracle JCA Adapters - Rejected Message Handling

The messages that error out before being posted to the Oracle SOA Service Infrastructure mesh are referred to as rejected messages. For example, Oracle File Adapter picks a file having data in CSV format and tries to translate it to the XML format using NXSD. Now, if there is any errors in the translation, the message is rejected and is not posted to the target composite. All rejected messages are stored in the database with payload. There are two destinations for rejected messages: ■ Adapter Rejection Table - Messages are stored in the Adapter Rejection table when there is a binding error related to a corrupt message. In case the database hosting the Rejected Message Table is offline, rejected messages are temporarily stored in the local file system as a backup and eventually loaded back into the database when it is detected as being online again. ■ Composite Instance Failure Table - This table is part of instance tracking, populated by each component detecting a failure. In the case of errors being thrown by the SOA Service Infrastructure layer, the Adapter framework behavior depends on whether or not the error is marked as retriable. If the error is not retriable, the message is treated as a rejected message and persisted to the Rejected Message Table. Configuring Rejection Handlers Rejection handlers are defined and configured by using fault policies as described in the following steps: 1. Define a fault policy for the rejected messages in the fault-policies.xml file, which is stored along with composite.xml in the Oracle JDeveloper project directory. 5-64 Oracle Fusion Middleware High Availability Guide 2. Associate the fault policy with a service endpoint of the composite in the fault-bindings.xml file. 3. Copy the fault-policies.xml file and the fault-bindings.xml file to Oracle SOA Composite project directory. 4. Deploy the Oracle SOA Composite project. Retry frequency and retry interval are both configurable. Service engines can mark an invocation as retriable. In a clustered environment, if rollback occurs, it may be picked up by another instance. If another node picks up the message, it generates a unique ID. The number of retries are configured within the composite, under the binding.jca element. For more information, see the Oracle Fusion Middleware User’s Guide for Technology Adapters. System-Defined Rejected Message Handlers The following system-defined error handlers can be configured in fault policies: ■ Web Service Handler - A predefined WSDL interface must be implemented by the target service ■ Custom Java Handler - A predefined Java interface must be implemented by the target class. ■ JMS Queue - The rejected message is enqueued to a queue as a JMS message with the appropriate context and payload. ■ File - The rejected message is stored in the file system with the proper context and payload. Payload Persistence For resubmitting rejected messages, payload persistence is imperative. Payloads are stored in the database and be viewed through Oracle Enterprise Manager Fusion Middleware Control. Error handlers invoked during automatic error handling also receive the payload during their invocation. Error payload persistence in the database is enabled by default.

5.10.2 Oracle JCA Adapters High Availability Architecture and Failover Considerations