OIC Monitoring Guide (2026) — Tracking, Resubmission & Production Support

OIC monitoring lives or dies on three things most guides gloss over. One: resubmission restarts the flow from the beginning, not from the point of failure — so if your integration already inserted a row or called a downstream API before it faulted, a blind resubmit creates a duplicate. Two: synchronous flows cannot be resubmitted at all — the resubmit and abort actions simply don't appear for them, because there's no persisted message to replay. Three: aborting (discarding) a message is irreversible — an aborted instance can never be recovered, so never abort something you might want to resubmit. Everything else in production support flows from understanding those three constraints.

Key facts at a glance

• Maximum 3 business identifiers per integration; exactly one must be primary. Without at least one, the integration cannot be activated at all.
• Business identifiers can only be assigned to source (trigger) payload fields — never to target payloads.
• They can only be added or edited while the integration is inactive. Once active, you can view them but not change them.
• Resubmission restarts the flow from the beginning — design for idempotency or you'll create duplicates.
• If a local scope is defined, resubmission starts at that local scope level rather than the very beginning.
• Synchronous flows show no resubmit/abort option — only asynchronous flows can be resubmitted.
• Abort/discard is permanent. After a period, aborted messages are deleted from the server entirely.
• Tracing levels are Production, Audit, and Debug — and you can raise the tracing level for a single resubmitted instance without changing the integration's activation setting.
• Faulted instances are only resubmittable within OIC's retention window — beyond it, you need your own persistence layer.

Why Production Support Is the Real Job

Building an integration is the part everyone trains for. Supporting it is the part that actually consumes your career.

The tickets don't arrive as stack traces. They arrive as: "The employee wasn't created." "The supplier import failed." "It says completed but finance never got the email." And the first question — the one that determines whether you resolve it in ten minutes or three hours — is always the same: can I trace this instance?

If you configured business identifiers up front, you search by employee number and you're looking at the failure in seconds. If you didn't, you're scrolling through instance IDs trying to correlate timestamps, and the business is waiting.

That gap — between an integration that's supportable and one that merely works — is what this guide is about. Everything below is verified against Oracle's OIC documentation and A-Team error-handling guidance, not just recalled from a training deck.

Business Identifiers: The Design Decision That Defines Your Support Experience

What they are: payload fields you designate at design time as searchable tracking values. Instead of hunting by OIC's internal instance ID (meaningless to a support analyst), you search by Invoice Number, Employee Number, PO Number, Supplier ID — whatever the business actually references in the ticket.

The hard rules that trip people up:

That last constraint is the one that hurts. If an integration is live in production and you realize you tracked the wrong field, you can't just fix it — you have to deactivate, edit, reactivate, which means a change window and a brief outage. This is exactly why business identifiers are a design-time decision, not something to bolt on later.

How to choose the right three: pick the values that appear in the support ticket. Not the ones that are technically convenient. If finance calls about "invoice INV-88213," then invoice number is your primary — not the internal transaction GUID that happens to be easier to map.

Tracing Levels: Production vs. Audit vs. Debug

The activity stream's usefulness is entirely determined by the tracing level you activated with — and this is where most teams get the trade-off wrong.

The "Include Payload" option at activation is what makes payload details visible in the activity stream. Without it, you can see where the flow failed but not what data caused it — which for a data-driven failure (bad cost center, malformed date, missing supplier site) is the difference between diagnosing it and guessing.

The trade-off nobody states plainly: payload tracking stores your actual business data in OIC's activity stream. For flows carrying PII, salary data, or bank details, that's a genuine security and compliance consideration, not a checkbox. The mature approach is Audit-level tracing with payload on for flows where the data is non-sensitive and diagnosis depends on it, and Production-level for flows where it isn't — plus a deliberate Logger action to push only the specific, safe fields you need into the log.

The detail worth knowing for interviews: when you resubmit a failed instance, you can raise the tracing level for just that resubmitted instance (to Debug, say) without touching the integration's activation setting. This is enormously useful — you get full diagnostic detail on the retry of a real failure, without turning on Debug for every instance in production.

Resubmit vs. Abort: The Distinction That's Irreversible

This is the most consequential thing in this guide, and the original framing of "Resubmit / Clone & Resubmit / Replay" that circulates online misstates it. Here's what actually exists.

Resubmit

Available on the Errors page for asynchronous faulted instances. It reprocesses the original message.

The critical mechanic: resubmission starts the flow from the beginning. Not from the failure point. If your integration inserted a database row, called a downstream REST API, or triggered an ESS job before the fault occurred, a blind resubmit does all of that again.

There's one important nuance: if a local scope is defined in the integration, resubmission starts at that local scope level rather than the very start of the flow — which is a design lever you can deliberately use to control the replay boundary.

Abort (Discard)

Removes the error from the Errors page; the instance shows as aborted on the Tracking page.

It is permanent. You cannot perform any further operation on an aborted message — including recovery. After a period, it's deleted from the server entirely. Oracle's own documentation states it plainly: do not discard a message you want to resubmit.

I've seen a support engineer bulk-select an entire error page and hit Abort to "clean up the dashboard." Those messages were gone. Permanently. The source system had already marked them as sent. That's a data-loss incident created by a UI button, and it's the reason this distinction deserves more than a bullet point.

Synchronous flows: neither option exists

Synchronous integration instances show no resubmit or discard action at all. There's no persisted message to replay — the caller was waiting, got a response (or an error), and the transaction is over. If a sync flow fails, recovery means the caller retries, not OIC.

This is a genuinely common interview question, and "just resubmit it from Monitoring" is the wrong answer for a synchronous flow.

The Idempotency Problem (And the Parking Lot Pattern)

Given that resubmission replays from the start, any asynchronous flow you intend to be resubmittable must be idempotent — safely repeatable without side effects. Oracle's A-Team guidance says exactly this.

For simple flows, that's achievable natively: use a database MERGE instead of an INSERT, check for existence before creating, make the downstream API call with an idempotency key.

But some real use cases can't be made idempotent cheaply. Oracle explicitly names them:

• Resubmission must retry from the last point of failure, not the beginning
• Completed steps aren't repeatable, or compensating for them is expensive
• Faulted instances are needed beyond OIC's retention period
• You need to change the payload before resubmitting (e.g., fix a bad cost center)

For any of these, OIC's built-in resubmission isn't enough and you need custom error handling with your own persistence layer — the parking lot pattern:

CREATE TABLE INT_PARKING_LOT (
    STAGING_ID     NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    SOURCE_REF_ID  VARCHAR2(100) NOT NULL,   -- natural key from the source system
    PAYLOAD_JSON   CLOB NOT NULL,            -- editable before retry
    STATUS         VARCHAR2(20) DEFAULT 'NEW' NOT NULL,  -- NEW / PROCESSING / SUCCESS / ERROR_RETRY / FAILED
    ERROR_MESSAGE  VARCHAR2(4000),
    RETRY_COUNT    NUMBER DEFAULT 0,
    LAST_STEP      VARCHAR2(100),            -- enables retry-from-failure-point
    CREATED_DATE   TIMESTAMP DEFAULT SYSTIMESTAMP,
    CONSTRAINT uq_source_ref UNIQUE (SOURCE_REF_ID)   -- enforces idempotency at the DB layer
);

The UNIQUE constraint on the natural key is what actually guarantees idempotency — even if a dispatcher fires twice for the same record, the insert fails safely rather than producing a duplicate downstream call. The PAYLOAD_JSON column is what lets support correct bad data and retry, which OIC's native resubmit can't do. And because you own the table, records survive well past OIC's retention window.

Real Production Scenario: The Supplier Import That "Completed" But Imported Nothing

The flow: SFTP → Scheduled Integration → Stage File → ERP Adapter → UCM → ESS job.

The ticket: "Suppliers didn't come through. The integration says it succeeded."

This is a genuinely instructive case because OIC is telling the truth — the integration did succeed. It uploaded the file and submitted the ESS job. The failure happened downstream, inside Fusion, after OIC's job was done.

The actual diagnostic order:

1. Search Monitoring by business identifier (the batch or file reference — this is why you configured one). Confirm the instance completed.
2. Open the Activity Stream. Confirm the ERP Adapter invoke succeeded and note the UCM document ID and the ESS Request ID returned in the response. If you didn't capture these in your flow, this is where you learn why you should have.
3. Check the ESS job status in Fusion using that Request ID — not in OIC. This is the step people skip, and it's where the real failure almost always is.
4. If the ESS job processed zero rows: the most likely cause is a wrong UCM account — the file uploaded successfully to one account, and the ESS job scanned a different one. It reports success having found nothing to do.
5. If the ESS job ran but rejected rows: download the error output from UCM (via getDocumentForDocumentId or File Import and Export) and inspect the interface/error CSVs for the validation failures.
6. Fix and resubmit — but resubmit the corrected data, which is exactly the case where OIC's native resubmit (which replays the original payload unchanged) can't help you, and a parking-lot pattern can.

The lesson worth internalizing: a "Succeeded" instance in OIC only means OIC did its part. For any flow that hands off to an asynchronous downstream process (ESS, a queue, a batch job), your integration must capture and log the downstream job's identifier, or you've built something you cannot support.

The Monitoring Surfaces and What Each Is Actually For

• Dashboard — aggregate health: message counts, success/failure rates, errors over time. Use it to spot a trend (a rising failure rate), not to diagnose an individual case.
• Integrations / Monitor Integrations — per-integration throughput and error counts. Tells you which integration is misbehaving.
• Instances (Track Instances) — the per-execution view, searchable by primary business identifier. This is where support actually lives.
• Errors — faulted instances, filterable by time window, integration, error type (recoverable / nonrecoverable / recovery job), and instance ID. This is where Resubmit and Abort live. Errors can also be grouped by integration or by connection — grouping by connection is the fast way to spot "everything hitting System X is failing," which points at an endpoint or credential problem rather than a logic bug.
• Activity Stream — the step-by-step message flow for one instance, showing exactly where it failed. Green arrows for success, red for the failure point. With payload tracing on, you see the actual data.
• Scheduled Integrations — run history, next scheduled run, and past-run status for scheduled flows.

A note on error types: the "recoverable vs. nonrecoverable" distinction on the Errors page is doing real work. Recoverable errors can be resubmitted; nonrecoverable ones can't, and filtering by this tells you immediately whether resubmission is even on the table before you start planning a recovery.

Scheduled Integration Monitoring: The Failures That Are Invisible

Here's the trap with scheduled flows: the most dangerous failure is the one that produces no error at all.

If a nightly file never arrives on the SFTP server, a naively-built scheduled integration polls, finds nothing, and completes successfully. No fault. No error on the dashboard. Nothing to resubmit. And nobody notices until finance asks where the invoices are — three days later.

The design fix: build an explicit "no file found" branch that raises a notification (or writes to your parking-lot table with a distinct status), rather than silently completing. A successful run that did nothing should be visible, not indistinguishable from a successful run that did everything.

The same principle covers late files, partial files, and missed schedules: absence of error is not evidence of success, and a support-ready scheduled integration asserts what it expected to happen rather than quietly accepting whatever it found.

Notifications and Beyond-Retention Logging

Native options: the Notification action (email), OCI Events, and webhook callouts from a fault handler. The standard pattern is a global fault handler that emails an admin with the instance ID, business identifier, and error summary — enough to act on without opening the console.

The retention problem: OIC retains monitoring data and activity streams for a limited window. For a regulated client (SOX-relevant financial flows, for instance), "we can't tell you what happened in that integration four months ago" is not an acceptable answer.

The mature solution: push activity stream logs to OCI Logging, which can then feed OCI Logging Analytics or Object Storage for long-term retention and querying. You can filter by business identifier value in OCI Logging, giving you searchable integration history well beyond OIC's native window. For flows where compliance demands specific fields be recoverable, use a deliberate Logger action to push exactly those fields into the stream — rather than turning on full payload tracing and hoping.

Common Monitoring Mistakes

Interview Questions (With the Answers That Signal Real Experience)

"How do you troubleshoot a failed OIC integration?" Search Monitoring by business identifier → open the instance → read the Activity Stream to find the exact failing step → inspect the payload (if tracing included it) → check the fault handler's captured error → determine whether it's recoverable → assess idempotency before resubmitting. The tell of a weak answer is jumping straight to "resubmit it."

"What's the difference between resubmitting and aborting?" Resubmit reprocesses the message from the beginning of the flow (or from the local scope, if one is defined). Abort permanently discards it — no recovery is possible, ever. Never abort something you might need to resubmit.

"Can you resubmit a synchronous integration?" No. Resubmit and abort actions don't appear for synchronous flows at all. Recovery has to come from the calling system retrying.

"An async flow inserts a record then calls an API. The API call fails. You resubmit. What happens?" The flow restarts from the beginning — so the insert runs again, creating a duplicate, unless the flow was designed to be idempotent (MERGE instead of INSERT, an existence check, or a unique constraint on a natural key). This question is specifically designed to catch people who know the feature but not the consequence.

"The integration shows Succeeded but the business says nothing was imported. Where do you look?" OIC's part succeeded — the failure is downstream. Pull the ESS Request ID (or equivalent downstream job identifier) from the Activity Stream and check the job status in Fusion, not in OIC. For an FBDI flow, the most common root cause is a wrong UCM account: the file uploaded fine, but the ESS job scanned a different account and found nothing.

"How would you handle failures that need to be recovered beyond OIC's retention period, or with a corrected payload?" Native resubmission can't do either — it replays the original payload, within the retention window only. This calls for custom error handling with your own persistence (a parking-lot table), which lets you edit payloads, retry from a recorded failure point, and retain records indefinitely.

Best Practices for Production-Ready Integrations

1. Configure business identifiers at design time — pick the fields that appear in support tickets, not the ones that are easy to map. You cannot change them without deactivating.
2. Capture downstream job identifiers (ESS Request ID, UCM document ID, external API reference) into the activity stream or your own log — otherwise a downstream failure is untraceable.
3. Design every async flow for idempotency — assume it will be resubmitted, because eventually it will be.
4. Use local scopes deliberately to control where resubmission restarts.
5. Default to Audit-level tracing for production; reserve Debug for targeted troubleshooting — and use per-instance tracing elevation on resubmits rather than turning Debug on globally.
6. Be deliberate about payload tracing on flows carrying sensitive data; use the Logger action to capture only safe, necessary fields.
7. Never bulk-abort to clean up a dashboard.
8. Make silent success impossible in scheduled flows — assert that expected work actually happened.
9. Push logs to OCI Logging when audit history must outlive OIC's retention window.
10. Build the parking-lot pattern for any flow where payload correction, retry-from-failure-point, or long-term recovery is a real requirement.

FAQ

How many business identifiers can you define in an OIC integration? Up to three, one of which must be designated primary. At least one is mandatory — without it, the integration cannot be activated.

Can business identifiers be changed after an integration is activated? No. They can only be added or edited while the integration is inactive. On an active integration you can view them but not modify them, so changing one requires deactivating and reactivating.

Does resubmitting a failed OIC instance retry from the point of failure? No — it restarts the flow from the beginning. The exception is when a local scope is defined, in which case resubmission starts at that local scope level. This is why async flows must be designed to be idempotent.

Can synchronous integrations be resubmitted in OIC? No. Resubmit and abort actions are not available for synchronous flows. Recovery must come from the calling system.

Is aborting a failed message reversible? No. An aborted message cannot be recovered by any means, and is eventually deleted from the server. Never abort a message you may want to resubmit.

How do I keep OIC monitoring data beyond the retention period? Push activity stream logs to OCI Logging (and onward to Logging Analytics or Object Storage), and/or persist messages in your own parking-lot table for long-term recovery.

Why does my integration show "Succeeded" when the business says nothing happened? OIC succeeded at its part. If the flow hands off to an asynchronous downstream process (like a Fusion ESS job), that process can fail independently. Capture and check the downstream job's request ID — for FBDI flows, a wrong UCM account is the classic cause of a silent zero-row import.

Closing Thoughts

The consultants who become indispensable on support teams aren't the ones who can build the most elegant flow. They're the ones whose integrations can be diagnosed at 2 AM by someone who didn't build them — because the business identifiers are the right ones, the downstream job IDs are captured, the fault handler said something useful, and resubmitting won't create a duplicate payment.

Monitoring isn't a feature you learn after the build. It's a set of design decisions you make during it, and most of them can't be retrofitted without a change window.