Pub/Sub Integration Patterns in OIC

Why pub/sub matters

Tightly-coupled point-to-point integrations create fragile architectures:

graph LR
    A[Fusion ERP] -->|direct call| B[System B]
    A -->|direct call| C[System C]
    A -->|direct call| D[System D]
    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e293b,stroke:#475569,color:#e2e8f0
    style C fill:#1e293b,stroke:#475569,color:#e2e8f0
    style D fill:#1e293b,stroke:#475569,color:#e2e8f0

If System B is down, System A fails. Adding System E means changing System A.

Pub/Sub solves this:

graph LR
    A[Fusion ERP] -->|publish event| Q[(Oracle Stream)]
    Q -->|subscribe| B[System B]
    Q -->|subscribe| C[System C]
    Q -->|subscribe| D[System D]
    Q -->|subscribe| E[System E - new!]
    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style Q fill:#1e293b,stroke:#F59E0B,color:#e2e8f0
    style B fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style C fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style D fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style E fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0

The publisher doesn’t know or care who’s listening.

OIC pub/sub with Oracle Streaming

Publisher integration:

// OIC JavaScript Action — build the event payload
var event = {
  eventType: "OrderCreated",
  eventTime: new Date().toISOString(),
  correlationId: input.orderId,
  payload: {
    orderId: input.orderId,
    customerId: input.customerId,
    amount: input.amount,
    currency: input.currency
  }
};
return JSON.stringify(event);

Subscriber integration trigger — configure the Oracle Streaming trigger in OIC:

Trigger: Oracle Streaming
  Stream: orders-events
  Partition Key: orderId  ← ensures ordering per order
  Consumer Group: order-processor
  Batch Size: 50
  Polling Interval: 30s

OIC Event Framework — native pub/sub

OIC itself can raise integration events that trigger other integrations simultaneously:

sequenceDiagram
    participant T as Trigger (REST/Schedule)
    participant I1 as Integration: Create PO
    participant OIC as OIC Event Bus
    participant I2 as Integration: Notify Approver
    participant I3 as Integration: Update Inventory

    T->>I1: invoke
    I1->>OIC: raise "PO_CREATED" event
    par Event Subscribers
        OIC->>I2: trigger (send notification)
    and
        OIC->>I3: trigger (reserve stock)
    end
    Note over OIC: Both subscribers fire in parallel

Dead-letter handling pattern

Every pub/sub implementation needs a plan for failed messages:

flowchart TD
    S[(Stream)] --> SUB[Subscriber Integration]
    SUB --> PROC{Processing OK?}
    PROC -->|Yes| DONE[✓ Commit offset]
    PROC -->|No, retry 1| R1[Retry after 30s]
    R1 --> PROC
    PROC -->|No, retry 2| R2[Retry after 5min]
    R2 --> PROC
    PROC -->|No, max retries| DLQ[(Dead Letter Queue)]
    DLQ --> ALERT[Alert OIC Admin]
    DLQ --> REPROCESS[Manual Reprocess Integration]

    style DONE fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style DLQ fill:#2d0f0f,stroke:#EF4444,color:#e2e8f0
    style ALERT fill:#2d0f0f,stroke:#EF4444,color:#e2e8f0

Ordering considerations

Oracle Streaming partitions by a key. Messages within a partition are ordered. Use the entity ID as the partition key to ensure all events for the same order are processed in sequence:

// OIC Publish action configuration
{
  "partitionKey": "$body.orderId",  // same order → same partition → ordered
  "messageKey": "$body.correlationId",
  "value": "$body"
}