Explain EBS to Fusion Coexistence Integration Patterns in Oracle Applications

39 / 60

Integrationadvanced

EBS to Fusion Coexistence Integration Patterns

Explain common integration patterns for organizations running EBS and Fusion Cloud side-by-side during a phased migration

Few organisations move from EBS to Fusion in one cutover. They run both for months or years, which means keeping shared data in step across two very different architectures.

EBS-Fusion coexistence integration is like two countries with different currencies and legal systems needing to conduct ongoing trade before a full economic union is complete — you need a reliable, well-documented exchange mechanism (integration bridge) and a way to track that 'this dollar amount here equals that amount there' (ID mapping) until the transition to a single shared system is finally complete.

Key Concepts

The architectures do not meet naturally.

    Fusion out   REST, HCM Extract, BI Publisher to a file
    EBS in       interface tables, PL/SQL APIs

    EBS out      a query, or a concurrent program producing a file
    Fusion in    FBDI, HDL, REST

So every coexistence interface is a bridge between a file-and-REST world and an interface-table world.

Pattern one: HCM first. Fusion HCM becomes the system of record for workers; EBS still runs payroll or financial processes that reference employees.

    Fusion HCM
        |  HCM Extract, nightly, changes only
        v
    a file
        |  a custom program
        v
    EBS interface tables -> employee records

Pattern two: financial consolidation. Subsidiaries on one system, the parent on the other, with summarised journals moving between them.

    EBS GL   -> extract summary journals -> Fusion Journal Import FBDI
    Fusion   -> extract -> EBS GL_INTERFACE

Identifier mapping is the problem that defines these projects. The same employee has a different internal id in each system.

    Fusion   PersonId 300000012345
    EBS      PERSON_ID 8821

Neither knows about the other. So something must hold the mapping, and it has to be maintained as people are created in either system.

The usual answer is a cross-reference table and one designated source of truth per entity, with a natural key — employee number, supplier number — as the link. Getting this wrong is what produces duplicate suppliers and orphaned employees a year into a coexistence.

And the rule that keeps it coherent. One system owns each entity. Not "both can update employees, and we sync" — that is a conflict-resolution problem nobody wins.

Fusion owns workers; EBS consumes them. EBS owns suppliers; Fusion consumes them. Whichever way round, decide it per entity and enforce it, because bidirectional sync of the same field is where coexistence projects fail.

What the interviewer is probing.1. "Why does coexistence happen at all?" Probing: the context. Stalls: "Indecision." *Moves up:* phased migration — HCM moves to Fusion while ERP stays on EBS, so both must share workers, costing and financial postings.

2. "What is the hardest part?" Probing: experience. Stalls: "The technology." Moves up: deciding the system of record per data domain, because two systems that both think they own a record will diverge.

3. "What integration style fits?" Probing: the design. Stalls: "Real time." Moves up: usually scheduled extracts and imports for mass data with events for time-critical items — real time everywhere adds cost without benefit.

4. "How do you keep the two reconciled?" Probing: the control. Stalls: "Trust it." *Moves up:* a scheduled reconciliation comparing counts and key totals, because drift is silent until a period close fails.