OIC Throttling, Fault Isolation and Replay Framework

This case study describes a custom reliability framework engineered within Oracle Integration Cloud to protect downstream ERP services from workload overload generated by upstream source applications. The framework provided immediate acknowledgement to sources, persisted processing state, dispatched transactions to ERP at a controlled rate, classified failures, and supported operational replay without requiring re-submission from the originating system.

The framework was not a product feature—it was engineering built on top of standard OIC capabilities to address a gap that standard integration patterns could not fill without custom design.

Source applications could generate transactional workloads faster than downstream ERP services could safely process them. Under sustained high volume, ERP performance degraded for all users—not just those affected by the integration workload. Standard synchronous integration passed this problem directly to ERP. Standard retry logic amplified it.

Some source systems could safely reduce their submission rate or retry on a rejection response. Others required the integration platform to accept their submission unconditionally and manage the queuing and dispatch internally. A single solution was needed that worked for both source types.

The framework had to accept source submissions immediately without making the source wait for ERP confirmation. It had to persist enough state to support recovery without relying on the source to resubmit. It had to distinguish between a transient ERP connectivity failure—which should be retried—and a business validation failure—which should be parked and reported rather than retried indefinitely. It had to support an operator replaying a specific transaction or a range of transactions without replaying successfully processed ones. And it had to provide operations with enough visibility to manage the backlog and identify processing health without requiring access to ERP directly.

The framework separates intake from dispatch. Intake accepts submissions, validates the integration contract, assigns a correlation identifier, provides an immediate acknowledgement to the source and persists the transaction in a processing queue. The source is decoupled from ERP at this point.

Dispatch runs on a controlled cadence, retrieving queued transactions and invoking ERP at a rate that the target can safely absorb. Each ERP response is evaluated and the transaction state updated accordingly. Transient failures—connectivity timeouts, temporary unavailability—are returned to the retry queue with their retry count incremented. Business validation failures are moved to a parking lot where they await operator review or correction.

Replay allows an operator to return a specific transaction or a range of transactions from the parking lot to the dispatch queue without losing the original audit trail or creating duplicate submissions. Every state transition is recorded.

API gateway throttling is preferred when the source application can safely reduce its submission rate or retry on a rejection response. In that case, the gateway controls load at the entry point and no middleware persistence is required.

Middleware persistence is used when the source application cannot safely resubmit—either because it lacks retry capability, because a rejection would represent a business failure in the source system, or because the submission is time-sensitive and cannot be held at the source. In those cases the integration platform accepts unconditionally and manages the workload internally.

Business errors are never retried indefinitely. Parking them preserves audit state and allows human judgment to determine whether correction and reprocessing is appropriate. This distinction between transient and business failures is fundamental to the framework's design.