OIC Gen3: Multiple Callback Integrations for the Same FBDI Job — How to Route by Source
A practical pattern for Oracle ERP Cloud Adapter callbacks when multiple upstream sources submit the same FBDI process
Problem statement
In Oracle Integration Cloud (OIC) Gen3, it’s common to have multiple upstream systems that load the same business object into Oracle Fusion ERP using FBDI. A typical example is journal creation from multiple source systems, where each source requires a separate completion notification and separate handling of log files.
Source A → Integration INTA → FBDI Import Journals → notify Source A + deliver log files to Source A location
Source B → Integration INTB → FBDI Import Journals → notify Source B + deliver log files to Source B location
Many teams implement two callback receiver integrations (CBCK-A and CBCK-B) using the ERP Cloud Adapter trigger option: “Receive Callback Message upon Completion of FBDI bulk Import Job submitted via another Integration.”
Why both callback integrations trigger (even if only one source submits)
This behavior is expected if both callback integrations are subscribed to the same “process completion” callback event for the same bulk import process. When you configure callback integrations using the “Receive Callback Message upon completion of FBDI bulk import job submitted via another integration” option, the subscription is set up at activation time and the event is raised by ERP Cloud whenever that load/import process completes, regardless of success or failure.
In short:
The callback is event-driven and the subscription is created automatically when the callback integration is activated.
If multiple callback integrations subscribe to the same bulk import process, each can receive the completion event.
Oracle-recommended pattern: Subscribe to ERP business events and filter by document name
Oracle documents a supported approach for exactly this scenario (“multiple data sources, different callbacks for each data source”). Instead of using the generic “FBDI completion callback” trigger option in multiple integrations, the guidance is to:
Configure the callback trigger as “Receive Business Events raised within ERP Cloud” (not the generic completion callback option).
Select the “ERP Integration Inbound event”.
Add a filter expression based on the document name in the event payload.
Ensure the document name contains a source-identifying pattern (so each callback integration can filter and route correctly).
Step 1 — Enforce a source-identifying document naming convention
This pattern relies on the fact that the ERP Integration Inbound event payload includes the document name. Therefore, the easiest and most reliable routing key is a standardized document/zip name that encodes the source system.
Example naming conventions:
SRC_A_IMPORT_JOURNALS_<YYYYMMDDHH24MISS>_<requestId>.zip
SRC_B_IMPORT_JOURNALS_<YYYYMMDDHH24MISS>_<requestId>.zip
Step 2 — Create separate callback receiver integrations with event filters
Create CBCK-A and CBCK-B as ERP Cloud Adapter trigger-based integrations. On the trigger Request page:
Select “Receive Business Events raised within ERP Cloud”.
Choose the event: “ERP Integration Inbound event”.
Configure an event filter that matches only documents for that source.
Example filter logic (conceptual):
CBCK-A: documentName startsWith “SRC_A_”
CBCK-B: documentName startsWith “SRC_B_”
End-to-end flow (reference architecture)
INTA (Source A)
→ Create FBDI ZIP with documentName = SRC_A_…
→ Upload to UCM + Submit Import Journals ESS job
→ ERP raises ERP Integration Inbound event (includes documentName + requestId/status)
→ CBCK-A triggers (filter matches SRC_A_)
→ CBCK-A fetches logs, notifies Source A
INTB (Source B)
→ Create FBDI ZIP with documentName = SRC_B_…
→ Upload to UCM + Submit Import Journals ESS job
→ ERP raises ERP Integration Inbound event
→ CBCK-B triggers (filter matches SRC_B_)
→ CBCK-B fetches logs, notifies Source B
Why your tracking-table approach works (and how to strengthen it)
Your current approach—writing the requestId into a tracking table in INTA/INTB and checking it in CBCK-A/CBCK-B—implements idempotency and correlation. This is a valid safeguard and is especially useful when dealing with retries or unexpected duplicate deliveries.
Recommended enhancements:
Make the tracking record include (sourceSystem, requestId, documentName, createdTimestamp, status).
Set a retention policy (e.g., purge records older than X days) to keep the table manageable.
Add a uniqueness constraint on (requestId) or (sourceSystem, requestId) to prevent double inserts.
Log “ignored callback” cases explicitly for auditability.
Best practice for Gen3: filters first, tracking as a safety net
The cleanest design is to prevent irrelevant callback integrations from triggering using event filters, and still keep the tracking-table check as a safety net. This gives you both correctness (no double-processing) and efficiency (fewer unnecessary runs).
Implementation checklist
Update both INTA/INTB to generate a source-specific document name and preserve it end-to-end (UCM upload + job submission).
Create CBCK-A/CBCK-B using “Receive Business Events raised within ERP Cloud” + “ERP Integration Inbound event”.
Apply event filters based on document name (SRC_A_ vs SRC_B_).
Keep the requestId tracking-table guard in each callback integration.
Validate with test runs: submit from A only → only CBCK-A should trigger; submit from B only → only CBCK-B should trigger.
Add observability: log correlation keys (documentName, requestId, sourceSystem) in both loader and callback integrations.
References
Oracle ERP Cloud Adapter documentation: Configure callbacks and “Receive Callback Message upon completion of FBDI bulk import job submitted via another integration”.
Oracle ERP Cloud Adapter documentation: Use multiple callback integrations for the same FBDI job (recommended approach: ERP Integration Inbound event + document-name filter).