Error handling and reprocessing in Oracle Integration 3: a model that neither loses nor duplicates work

An integration can receive a request, modify the target system and fail immediately afterwards. If recovery consists only of running it again, the possible outcomes are a duplicated operation or part of the process left pending with nobody aware of it.

This article proposes an error-handling model for Oracle Integration 3 in four stages: classify the fault, preserve its visibility, identify pending work and recover without duplication. At each stage it separates what the platform provides from what the integration team must design.

Fault classification

Not all faults admit the same treatment. A connectivity outage may justify another attempt once the service is restored; a document rejected for invalid data needs correction; a transformation error requires reviewing the mapping or its dependencies. Oracle describes these scenarios in About Error Management.

We recommend an operational classification that assigns an action and an owner to each category. A missing mandatory field belongs to the business area that produces it; a dropped connection, to the technical team. Putting both through the same retry cycle consumes capacity without resolving either.

There is a third category that is often overlooked: the unknown outcome. The target may have accepted the write and the response may have been lost on the way back. In that case, the absence of a technical response does not prove that the business change did not happen, and repeating the write without checking may duplicate it.

For each integration, it should be documented which operations can be repeated and which require prior verification, who handles pending states and how their closure is decided. These rules belong to the operating procedure and must be available to whoever handles the incident.

Scopes, propagation and the meaning of success

The Scope action groups actions and invocations and supports local fault handlers. It allows separating an operation whose failure is recoverable from one that must stop the flow. The Scope documentation notes a relevant restriction: for invocations through the Connectivity Agent, faults must be handled in the default handler, because named handlers are not processed.

The local handler has two jobs: capture context and decide. If an auxiliary lookup can be skipped, the decision is recorded according to the process contract. If the mandatory operation failed, the flow must not continue as if the result were confirmed.

The Re-throw Fault action propagates the fault to error handling, through the global handler if one exists, according to Catch Faults with a Re-throw Fault Action. Notifying and propagating are different decisions; when the operator needs to keep the failed instance for analysis, both must be designed.

One detail has consequences: a global handler that absorbs the error can leave the instance as Succeeded, according to the global faults guide. Technical success is not business success. If the fault is absorbed, a durable, queryable business state must remain, independent of the instance's technical status.

Tracking pending work

Oracle Integration requires at least one tracking identifier per integration and allows filtering instances by those values, as explained in Track Integration Instances. The choice matters: an order number known to the user is more useful to support than an isolated internal reference.

The identity of the work and that of each technical run should be recorded separately. The same document may go through several attempts; all of them correspond to a single business intent and must be relatable to one another and to the confirmations received from the targets.

The error pages show faults, identifiers and the activity flow; the available content depends on the tracing configuration, documented in Manage Errors. The tracing level should be set together with access control, because payloads may contain sensitive data.

When tracking must outlast the platform's retention, we recommend a dedicated pending-work register with three minimum fields: business reference, point reached and pending action. An email notification is not evidence that the incident was resolved.

Resubmit and replay: two different mechanisms

Resubmit, on the Errors page, recovers failed instances identified as recoverable. Oracle Integration does not resubmit them automatically, and the mechanism does not apply to synchronous flows or to scheduled flows with schedule parameters, according to Resubmit Failed Messages.

Recovery may continue from a saved point in the run, for example after a wait, or restart from the beginning, depending on the design. It should not be assumed that only the failed invocation will be repeated. The recovery window and resubmission limits are taken from the current documentation, not fixed in internal manuals.

Replay is a different feature: it restarts the run from the beginning and applies to eligible synchronous instances. It requires enabling Allow to run again, a REST or AS2 trigger and structured content; its restrictions include use of the Connectivity Agent. The replay guide details the requirements and the comparison with recovery.

The operating procedure should state which mechanism each integration allows and which checks precede it. If an instance supports neither, an authorized resend from the source or from a durable record is needed. A discarded instance can no longer be recovered with Resubmit.

Idempotency of the second attempt

An operation is idempotent when repeating the same intent does not apply its effect again. It is implemented with a stable key agreed with the target or with a state check specific to the operation. The key represents the work; if it is regenerated on each attempt, it loses its purpose.

The sequence «check, then write» admits race conditions when two runs advance at the same time. Whenever the target allows it, an atomic mechanism is preferable: key acceptance, a uniqueness constraint or an operation with idempotent semantics. Reprocessing is declared safe only after verifying the capabilities of the specific interface.

Retries within the flow should be limited to transient errors, with a defined delay and an exit condition. This policy is design logic, not a guarantee of automatic recovery from the platform. When attempts are exhausted, the work must remain visible for intervention, with the information needed to decide the next step.

For batches with partial results, the starting point is identifying which records were confirmed and which remain pending. Resending the whole file is only safe if the target recognizes what was already applied or if an equivalent rule has been tested. The same caution applies to integrations that write to more than one system.

Testing the recovery procedure

The procedure is validated with the team that will operate the system, using controlled data and checking the result in the target, not only the instance status.

• Failure before writing: the pending work can be located by its business reference.
• Lost response after writing: the second attempt does not duplicate the effect.
• Business rejection: the record waits for correction, outside the retry cycle.
• Recovery mechanism: confirm whether Resubmit, replay or a controlled resend from the source applies.
• Closure: it is recorded who verified the final confirmation and who closed the incident.

A complete test leaves evidence of both the business operation and the fault handling. If the operator had to improvise any step, the procedure is not yet ready for production.

Xterra Engine designs and rehearses recovery procedures for Oracle Integration, with failure tests included in the delivery.