This blog presents a real-world
integration architecture designed by Bizinsight Consulting, where Transfer
Orders originate in a custom application, are orchestrated through Oracle
Integration Cloud (OIC), fulfilled by Supply Chain Orchestration (SCO)
in Oracle Fusion SCM, and continuously synchronized back to external systems
using business events and scheduled tracking—with Autonomous Data
Warehouse (ADW) acting as the control plane.
👉Video Overview of complete process available at out youtube Channel
Architecture
Overview
Core
Components
- Custom Application (UI) – Captures transfer demand from users
- Oracle Integration Cloud (OIC) – Orchestration, validation, API calls, event
subscriptions
- Oracle Fusion SCM
– Supply Chain Orchestration and execution
- Oracle Autonomous Data Warehouse (ADW) – Validation, logging, error handling, reconciliation
This design intentionally avoids tight coupling between the custom UI and Oracle Fusion APIs
1.
Transfer Demand Created in Custom Application
- Users create a transfer request in a custom
application.
- The application sends the request to Oracle
Integration Cloud via REST.
- The payload represents demand intent, not a Transfer Order.
2.
OIC Intake, Persistence, and Deduplication
Once OIC receives the request:
- Payload is stored in Oracle Autonomous Data Warehouse
- A custom PL/SQL API in ADW:
- Checks for duplicate requests
- Enforces idempotency
- Determines whether the request is eligible for processing
If a duplicate is detected,
processing stops cleanly—no Fusion API call is made.
3.
Supply Request Creation (TRANSFER Only)
- OIC constructs the final payload with: "SupplyType": "TRANSFER"
- OIC invokes:/fscmRestApi/resources/11.13.18.05/supplyRequests, OPeration : POST
- A Supply Order exists
- No Transfer Order exists yet
4.
Supply Chain Orchestration (SCO)
- Picks up the Supply Request
- Applies sourcing and fulfillment rules
- Creates a single Transfer Order
- Does not split or partially fulfill requests
This is an asynchronous, system-driven step.
Event-Driven
Synchronization (Outbound Only)
❗ The custom application does not consume real-time
APIs or callbacks.
Instead, all outbound communication
is event-driven and controlled by OIC.
5.
Transfer Order Created → Outbound Sync
- OIC subscribes to the Create Transfer Order
business event.
- When triggered:
- Transfer Order details are retrieved
- Data is pushed to the custom application
- ADW is updated with document references
6.
Transfer Order Updated → Outbound Sync
- OIC subscribes to the Update Transfer Order
event.
- Any change in Fusion is:
- Captured
- Logged
- Sent downstream
7.
Shipping Status Tracking (Scheduled Control)
Because partial shipments are not
supported:
- A scheduled OIC job monitors:
- Pick release
- Shipment readiness
- Status is periodically sent to the custom application
- ADW acts as the reconciliation layer
8.
Shipment Confirmed → Final Event Sync
- OIC subscribes to the Shipment Advice event.
- When shipment is confirmed:
- Shipment details are sent to the custom application
- The transfer lifecycle is closed in ADW
Failure
& Reprocessing Strategy (Clarified)
This model prioritizes data correctness and business control over automation-at-all-costs.
Why
This Design Is Strong (Even Without Advanced Automation)
This architecture intentionally
avoids:
- Over-automation
- Complex retry chains inside SCO
- Partial fulfillment logic that complicates
reconciliation
Instead, it delivers:
- Deterministic behavior
- Clear ownership boundaries
- Predictable operations
- Clean audit trails
Bizinsight
Consulting Value Proposition (Reinforced)
This solution highlights what
Bizinsight Consulting does best:
- Deep understanding of Fusion SCM orchestration
- Correct use of Supply Requests with explicit
TRANSFER intent
- Practical idempotency using ADW + PL/SQL
- Event-driven integrations that scale
- Designs that prioritize operational reality, not
theoretical perfection
Enterprise integrations succeed not
by doing everything automatically, but by doing the right things predictably.