All topics
36 / 60
Integrationintermediate

Oracle Integration Cloud (OIC) Fundamentals

Understand Oracle Integration Cloud's role as the primary iPaaS for connecting Fusion and other systems

OIC is Oracle's integration platform — the cloud successor to SOA Suite, used to connect Fusion to everything else.

OIC is like a universal translator and courier service standing between different countries (systems) that each speak different languages (data formats) and have different postal systems (protocols) — it receives a package in one format, translates and repackages it appropriately, and delivers it via whichever adapter (courier) the destination system understands.

Key Concepts

1
The shape of an integration: trigger, then invoke.
    trigger                         invoke
    a schedule                 ->   Fusion adapter
    a REST endpoint you expose      a REST or SOAP service
    a file arriving by FTP          an FTP drop
    an event                        a database
2
Between them sit mapping and orchestration — transform the payload, branch on content, loop over records, handle errors.
3
Adapters are the reason to use it rather than writing code. The Fusion adapter understands Fusion's REST structure, its authentication and its payloads, so you select an object and an operation rather than constructing calls by hand.
4
There are adapters for FTP, databases, SOAP, and third-party services such as Salesforce and ServiceNow.
5
A worked scenario, which is what interviews ask for. "Nightly sync of approved expense reports from Fusion to a reimbursement system":
6
    trigger    a schedule, 02:00 daily
    invoke 1   Fusion adapter -- GET expense reports where
               status = APPROVED and exported = N
    map        Fusion's payload -> the target's format
    invoke 2   the target system's REST API, per report
    invoke 3   Fusion -- PATCH the report to exported = Y
    errors     a fault handler: log it, continue with the rest,
               and notify at the end
7
The parts people leave out of that answer, and which matter more than the happy path:
8
Marking what has been sent. Without step 3 the next run resends everything. Whether the flag lives in Fusion or in OIC is a design decision, and it has to exist somewhere.
9
Partial failure. One report failing should not abandon the other four hundred. A fault handler that logs and continues, with a summary at the end, is the normal pattern.
10
Restart. A run that fails halfway must be safe to rerun — which is the same question as the flag.
11
Beyond integration. OIC includes Process Automation for human-task workflows and Visual Builder for building applications over Fusion data. Both are real; integration is the primary use and the one usually tested.
12
When not to use it. A one-off data conversion is FBDI or HDL, not an integration flow. OIC is for something that runs repeatedly.
13
What the interviewer is probing.1. "What are the main parts of OIC?" Probing: the structure. Stalls: "Integrations." *Moves up:* integrations with adapters, connections, lookups, a visual mapper, plus process automation, file server and a monitoring console.
14
2. "What is the difference between an app-driven and a scheduled integration?" Probing: the vocabulary. Stalls: "Timing." Moves up: app-driven is triggered by an event or inbound call; scheduled runs on a schedule and typically does batch extraction.
15
3. "How do you handle failures?" Probing: the engineering. Stalls: "Retry." Moves up: fault handlers with a defined retry policy, business identifiers for tracking, and resubmission from the monitoring console.
16
4. "Why are business identifiers important?" Probing: the operational angle. Stalls: "They are not." Moves up: they let support find one business transaction among thousands of instances, which is the difference between minutes and hours to diagnose.
Use cases:oicipaasadaptersintegration-design