All posts · OIC Integrations

Parallel vs Sequential Processing in OIC Integrations

Choosing between parallel and sequential execution in OIC orchestrations can have a significant impact on performance and reliability — here's when to use each.

Anurag Jangra · February 22, 2026 · 6 min read · ... views

The default: sequential

In a standard OIC orchestration, activities execute one after another. Each invoke completes before the next begins. This is predictable, easy to debug, and appropriate for most integrations — especially when downstream calls depend on the output of previous ones.

sequenceDiagram
    participant OIC
    participant HCM as Oracle HCM
    participant ERP as Fusion ERP
    participant DB  as ATP DB

    OIC->>HCM: GET employee details
    HCM-->>OIC: employee record
    OIC->>ERP: GET project assignments
    ERP-->>OIC: assignments
    OIC->>DB: GET timesheet data
    DB-->>OIC: timesheet rows
    OIC->>OIC: Map all three → payload
    Note over OIC: Total time = sum of all three calls

When parallel processing helps

Parallel branches let you fire multiple independent calls simultaneously. The integration time becomes the duration of the slowest branch, not the sum of all branches.

sequenceDiagram
    participant OIC
    participant HCM as Oracle HCM
    participant ERP as Fusion ERP
    participant DB  as ATP DB

    par Parallel Scope
        OIC->>HCM: GET employee details
    and
        OIC->>ERP: GET project assignments
    and
        OIC->>DB: GET timesheet data
    end
    HCM-->>OIC: employee record
    ERP-->>OIC: assignments
    DB-->>OIC: timesheet rows
    OIC->>OIC: Map all three → payload
    Note over OIC: Total time = max of all three calls

Good candidates:

  • Fetching reference data from multiple endpoints simultaneously
  • Sending the same payload to multiple target systems
  • Running independent validations concurrently

Implementing parallel branches

Use the Parallel scope activity in OIC’s action palette. Each branch executes concurrently. The flow continues only when all branches complete (or fault).

Parallel Scope
├── Branch A: Invoke HCM REST  → employee details
├── Branch B: Invoke custom REST → project assignments
└── Branch C: Invoke DB Adapter → timesheet data
→ Map all results → invoke downstream system

Real-world result

An ERP integration fetching employee name, department, and cost centre from three separate Fusion modules:

ApproachTime
Sequential (3 × 1.4s)4.2 seconds
Parallel (max of 1.4s)1.8 seconds

A 57% improvement with no logic change — just adding a parallel scope.

Variables and fault handling in parallel

Variables assigned inside a branch are scoped to that branch — not visible in siblings. Faults in any branch propagate to the parallel scope’s fault handler. Design branches to be self-contained.

When NOT to use parallel

  • When Branch B depends on Branch A’s output
  • When the downstream system doesn’t support concurrent calls from the same source
  • When debugging complex issues — sequential is far easier to trace in OIC monitoring

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