Custom Java Handler Message Error Rejection Handlers

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