DEV Community

Cover image for One integration, N partners — routed at runtime by dynamic connections
Naveen
Naveen

Posted on

One integration, N partners — routed at runtime by dynamic connections

#productivity #oic #oracle

Let's DO it Dynamic Connections in OIC & Build Multi-tenant partner router Project

⬇️ click on it

The core idea

Ten partners used to mean ten integrations same logic, copy-pasted, diverging quietly over time.
This build collapses them into one: a single orchestration that decides, per request, which connection to call and which path to call it on, by reading one lookup table.

This works today for FTP and REST adapters

How the resolution mechanism actually works

Every adapter invoke activity that supports this has an Enable Dynamic Connection checkbox in its configuration wizard. Once checked, a new field appears: Dynamic Connection ID.

At runtime, OIC evaluates whatever expression you put there and uses that value to pick which saved connection to actually use for this specific invocation overriding the design-time default.

Two ways to populate that field:

  1. Direct XPath drag a field straight from the incoming payload (e.g., a partnerId element) if the connection ID is literally present in your data.

  2. *Lookup table (DVM) * resolve a business key (partner ID, tenant ID, environment name) to a connection ID via a lookup table, using the lookupValue() function:

lookupValue("PartnerRoutingTable", "PartnerId", partnerId, "ConnectionId", "")
Enter fullscreen mode Exit fullscreen mode

The project: a multi-tenant partner router

What happens per request, at runtime

To make this concrete, I built and tested an integration that takes an inbound order and routes it to one of three partners — two over FTP, one over REST — using a single lookup table to decide both the connection and the destination path.

Connections:

The routing table(Lookup)

PartnerId ConnectionId TargetPath AdapterType
PARTNER_A FTP_PartnerA_Conn / FTP
PARTNER_B REST_PartnerB_Conn /orders REST
PARTNER_C FTP_PartnerC_Conn / FTP

OIC Lookup

This table is the only partner-specific knowledge in the whole system. Everything else is generic.

The flow 

Trigger (REST, receives order + partnerId)
        │
        ▼
Assign: lookupValue(partnerId) → adapterType, connectionId, targetPath
        │
        ▼
Switch on adapterType
   ├── "FTP"  → Map → Invoke (dynamic connection) → Map
   ├── "REST" → Map → Invoke (dynamic connection) → Map
   └── otherwise → fault: unknown partner
        │
        ▼
   Return response
Enter fullscreen mode Exit fullscreen mode

Entire OIC Flow

TEST Results:

  1. Let Pass "partnerId": "PARTNER_C" in request payload

As per partnerId it invoked the C FTP.

  1. Let Pass "partnerId": "PARTNER_B" in request payload

As expected, it went to REST with same dynamic connection.

Requets Payload:

{
  "totalAmount": 99.95,
  "orderId": "ORD-10023",
  "partnerId": "PARTNER_B",
  "orderDate": "2026-08-02",
  "items": [{
    "unitPrice": 19.99,
    "quantity": 5,
    "description": "Sample Widget",
    "sku": "SKU-1001"
  }],
  "customerName": "Test Customer"
}
Enter fullscreen mode Exit fullscreen mode

Lessons from actually building and testing this

The reference docs don't spell out, discovered by hitting them:

  • ConnectionId in your lookup must match the connection's name exactly. It's resolved as a literal string at runtime, not validated against existing connections at design time — a typo here fails silently in production, not on save.

Where else this pattern applies

The router doesn't actually know it's routing "partners" — it only knows "resolve a lookup row, then pick a connection and a path." Swap what the row contains and the same skeleton solves:

  • Credential rotation — one lookup key, two connections (old/new creds); flip the row to cut over instantly
  • Environment promotion — key the lookup by environment instead of partner; promote dev → test → prod by editing a row, not maintaining three integrations
  • DR/failover — a health-check flag in the lookup redirects traffic to a standby endpoint the moment it's toggled
  • Tiered routing — premium accounts resolve to a dedicated connection, everyone else shares one

Top comments (0)