Available Rejection Handlers for Message Errors Web Service Handler

2-34 Oracle Fusion Middleware Users Guide for Technology Adapters invokeWS uri=WebServiceURI -- format - Absolute wsdl path|service name|port name -- Action The WSDL Interface for the Web Service handler must have one port type, only one input operation, and a schema for the input message. This is shown in the following example. ?xml version=1.0? schema xmlns=http:www.w3.org2001XMLSchema targetNamespace=http:xmlns.oracle.compcbpelerrorHandling xmlns:tns=http:xmlns.oracle.compcbpelerrorHandling elementFormDefault=qualified element name=RejectedMessage type=tns:RejectedMessageType complexType name=RejectedMessageType sequence element name=MessageHeader type=string -- base64 encoded string -- element name=MessagePayload type=string -- base64 encoded string -- element name=RejectionReason type=string sequence attribute name=RejectionId type=string complexType schema

2.22.2.1.3 Custom Java Handler

Another option to handle errors is to create a predefined Java framework, an interface, that will forward errors. You can implement a Java interface by the target class, as shown in the following example. Action id=ora-custom javaAction className=mypackage.myClass defaultAction=ora-terminate returnValue value=SUCCESS ref=ora-file returnValue value=FAILED ref=ora-ws javaAction Action The interface itself specifies a fault recovery class. See the following snippet for an example of the interface. package oracle.integration.platform.faultpolicy; public interface IFaultRecoveryJavaClass { public void handleRetrySuccess IFaultRecoveryContext ctx; public String handleFault IFaultRecoveryContext ctx;}

2.22.2.1.4 JMS Queue

You can enqueue a rejected message to a JMS queue as a JMS message with the appropriate context and payload, as shown in the following two examples. The first example uses a standalone database: Action id=ora-queue enqueue uri=QueueURI -- QueueURI format - jdbc:oracle:thin:host:port:sidunpwqueue -- Action ADAPTER Life-Cycle Management 2-35 The second example is used in the context of a RAC database: Action id=ora-queue enqueue uri=QueueURI -- QueueURI format - jdbc:oracle:thin:DESCRIPTION=LOAD_BALANCE=onADDRESS_ LIST=ADDRESS=PROTOCOL=TCPHOST=host1PORT=port1ADDRESS=PROTOCOL=TCPH OST=host2PORT=port2CONNECT_DATA=SERVICE_NAME=service_ nameunpwqueue -- Action

2.22.2.1.5 File

You create an error handler for messages by storing a rejected message by storing it in a file. You can store the payload with the proper context, as shown in the following example. The Payload file will be created at the configured location. Action id=ora-file fileAction locationFOLDER_LOCATIONlocation fileNameFILE_NAMEfileName -- FILE_NAME will support IDrejected message instance id or TIMESTAMP wildcards -- fileAction Action Error payload persistence in the Database is available by default. Only the File Adapter handler creates a metadata file that contains all the properties of the rejected message. For example, for the Oracle File Adapter, this metadata file could include information such as the inbound direction and filename. The location of metadata file is same as the payload file and the naming pattern is FILE_NAME_metadata. For resubmitting rejected messages, payload persistence is imperative. Payloads are stored in the Database and a facility to view the payloads is available through the Fusion Middleware Control Console. The messagepayload will be provided in full to each configured error handler, in addition to providing the payload to the default error handler.

2.22.2.2 Inbound Retryable Errors

Inbound retryable errors are typically transient connectivity errors. Only retryable errors for a synchronous process thrown by the outbound binding will be subject to retry by the inbound adapter an indefinite number of times by default, which is limited by setting the jca.retry.count property. Any JTA transaction will be rolled back prior to a retry. Examples of retryable errors thrown by outbound adapters include connection errors but include also termporary permission errors andor resource constraint errors. Errors such as Data already exists for example, Primary Key Errors are not retryable. In addition, message correlation ID errors are not retryable. Only when a set number of retries have been exhausted, will the error be handled by the rejection mechanism.

2.22.2.2.1 Configuring Inbound Adapters to Handle Retryable Errors