All posts · OIC Integrations

OIC Error Hospital: Safe Resubmission Strategies

Every team running OIC in production encounters the error hospital. Used carelessly, resubmissions can create duplicate records and trigger downstream side effects.

Anurag Jangra · December 15, 2025 · 6 min read · ... views

The OIC Error Hospital

The Error Hospital is OIC’s centralized dashboard for failed integration instances. Every instance that faults ends up here, grouped by the error type and integration.

flowchart TD
    INST[Integration Instance] --> RUN{Execution}
    RUN -->|Success| DONE[✓ Completed]
    RUN -->|Fault| ERR[Error Hospital]
    ERR --> INV[Investigate root cause]
    INV --> DEC{Decision}
    DEC -->|Fix required first| FIX[Fix data/config/system]
    FIX --> RESUB
    DEC -->|Transient error| RESUB[Resubmit instance]
    DEC -->|Discard| ABORT[Abort instance]
    RESUB --> RUN

    style DONE fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style ERR fill:#2d0f0f,stroke:#EF4444,color:#e2e8f0
    style ABORT fill:#1e293b,stroke:#475569,color:#94A3B8

Safe resubmission process

Before resubmitting, always verify:

checklist
  1. Identify the exact failure point from the instance activity trace
  2. Check downstream system state — did any partial writes occur before the fault?
  3. If partial writes occurred — manually reconcile or compensate first
  4. Resubmit a limited batch — test with 1 instance before bulk resubmitting

Configuring automatic retry

The safest approach: configure retry logic in the integration itself so the error hospital is rarely needed:

Integration trigger configuration:
  On Fault:
    Retry Count: 3
    Retry Interval: 30 seconds (exponential: 30s, 60s, 120s)
    Retry On: HTTP 5xx, Connection Timeout
    No Retry On: HTTP 4xx (bad data — retry won't help)

For the exponential backoff in a custom error handler:

// JavaScript action in fault handler
var attempt = $input.retryCount || 0;
var baseDelay = 30;
var delay = baseDelay * Math.pow(2, attempt); // 30, 60, 120, 240...
return {
  shouldRetry: attempt < 3,
  delaySeconds: Math.min(delay, 300), // cap at 5 minutes
  nextAttempt: attempt + 1
};

Bulk resubmit via OIC REST API

For resubmitting many failed instances at once — don’t click through the UI:

# Get all failed instances for an integration
curl -u "$OIC_USER:$OIC_PASS" \
  "https://$OIC_HOST/ic/api/integration/v1/monitoring/instances?\
    integrationId=INVOICE_SYNC|01.00.0000&status=FAILED&limit=100" \
  | jq '.items[].id' > failed_instance_ids.txt

# Resubmit each
while read id; do
  curl -u "$OIC_USER:$OIC_PASS" \
    -X POST \
    "https://$OIC_HOST/ic/api/integration/v1/monitoring/instances/$id/resubmit"
  echo "Resubmitted: $id"
done < failed_instance_ids.txt

Automation opportunity

For integrations with predictable transient failure patterns, configure OIC’s retry capability — exponential backoff retries before the instance is marked as failed. This handles the majority of transient errors without any manual intervention or Error Hospital visits.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp