Oracle EBS and Fusion Cloud Coexistence Patterns

TL;DR

• Bottom line: Running EBS and Fusion Cloud simultaneously requires Oracle Integration Cloud (OIC) as the middleware layer, with clear source-of-truth designations per data entity and bidirectional sync flows for shared master data.
• Key limit: OIC Connectivity Agent is mandatory for on-premise EBS; OIC message pack consumption roughly doubles during coexistence due to bidirectional flows.
• Watch out for: ID conflicts when both systems generate document numbers independently — implement non-overlapping number ranges or cross-reference mapping tables.
• Best for: Organizations migrating module-by-module from EBS to Fusion Cloud over 6-24 months needing seamless cross-system operations.
• Authentication: OIC handles credential management — EBS via ISG username/password through Connectivity Agent, Fusion via OAuth 2.0 JWT bearer.

System Profile

This card covers the technical architecture and integration patterns for running Oracle E-Business Suite 12.2 and Oracle Fusion Cloud ERP simultaneously during a phased migration. It addresses data synchronization, master data governance, cross-system transaction flow, and reporting consolidation.

API Surfaces & Capabilities

Rate Limits & Quotas

Per-Request Limits

Rolling / Daily Limits

Authentication

Authentication Gotchas

• EBS ISG services must be deployed and granted before OIC can discover them [src4]
• OIC Connectivity Agent credentials expire — monitor heartbeat failures [src1]
• If EBS uses OAM SSO, integration user must bypass OAM for API access [src4]

Constraints

• Every shared data entity must have exactly one designated source-of-truth system
• Cross-system document numbering requires non-overlapping ranges or mapping tables
• GL period close must be synchronized across both systems
• Fusion quarterly updates are mandatory — coexistence flows must be regression-tested quarterly
• OIC message consumption approximately doubles during coexistence
• Reporting requires unified data warehouse or FDI with ODI feeds from EBS

Integration Pattern Decision Tree

START — Running EBS and Fusion Cloud in coexistence
├── Which modules are in each system?
│   ├── Financials in Fusion, Procurement in EBS
│   │   ├── AP Invoices → EBS → OIC → Fusion GL
│   │   └── Supplier master → EBS is source of truth
│   ├── Procurement in Fusion, Financials in EBS
│   │   ├── PO/Invoice → Fusion → OIC → EBS GL
│   │   └── Supplier master → Fusion is source of truth
│   └── HCM in Fusion, ERP in EBS
│       ├── Employee → Fusion HCM → OIC → EBS HR
│       └── Payroll → Fusion → OIC → EBS GL
├── What data needs to sync?
│   ├── Master data → Designate source of truth + OIC flow
│   ├── Transactional data → One-way from source module
│   └── Reference data → Sync before go-live; event-driven after
├── Sync frequency?
│   ├── Real-time (< 30s) → OIC event-driven
│   ├── Near-real-time (1-15 min) → OIC scheduled poll
│   └── Batch (hourly/daily) → OIC scheduled + FBDI
└── Conflict resolution?
    ├── Source-of-truth wins
    ├── Last-write-wins (timestamp)
    └── Manual review queue

Quick Reference

Coexistence Integration Flows by Module Split

Step-by-Step Integration Guide

1. Deploy OIC Connectivity Agent

Install the agent on a VM with access to EBS and outbound HTTPS to OIC. [src1]

./oic_agent_installer.sh \
  --agent-group-identifier=EBS_AGENT_GROUP \
  --oic-url=https://<oic-instance>.integration.ocp.oraclecloud.com

Verify: Agent status shows CONNECTED in OIC Console.

2. Configure EBS ISG Services

Deploy and grant required services in ISG so OIC can discover and invoke them. [src4]

BEGIN
  fnd_soa_util.grant_service(
    p_service_id => '<service_id>',
    p_grantee_type => 'USER',
    p_grantee_key => 'OIC_INTEGRATION_USER'
  );
END;

Verify: OIC EBS Adapter connection test succeeds.

3. Create OIC Integration Flow for Master Data Sync

Build a scheduled integration polling EBS for changed entities and syncing to Fusion. [src1]

Verify: Test record created in EBS appears in Fusion within sync interval.

4. Implement Cross-Reference ID Mapping

Create mapping table linking EBS and Fusion IDs for shared entities. [src5]

CREATE TABLE erp_xref (
  xref_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  entity_type VARCHAR2(50) NOT NULL,
  ebs_id VARCHAR2(100) NOT NULL,
  fusion_id VARCHAR2(100),
  sync_status VARCHAR2(20) DEFAULT 'PENDING',
  last_synced TIMESTAMP,
  source_system VARCHAR2(10) NOT NULL,
  CONSTRAINT uq_xref UNIQUE (entity_type, ebs_id)
);

Verify: SELECT COUNT(*) FROM erp_xref WHERE sync_status = 'SYNCED' shows records after first sync.

Code Examples

Python: Cross-System Supplier Sync

# Input:  EBS supplier changes, Fusion REST endpoint
# Output: Synced supplier records with cross-reference mapping

def sync_suppliers(last_sync_time):
    ebs_resp = requests.get(f"{EBS_URL}/suppliers",
        params={"modifiedAfter": last_sync_time.isoformat()}, auth=EBS_AUTH)
    for supplier in ebs_resp.json().get("items", []):
        fusion_id = lookup_xref("SUPPLIER", supplier["VendorId"])
        if fusion_id:
            requests.patch(f"{FUSION_URL}/suppliers/{fusion_id}",
                json=map_fields(supplier), headers=FUSION_HEADERS)
        else:
            resp = requests.post(f"{FUSION_URL}/suppliers",
                json=map_fields(supplier), headers=FUSION_HEADERS)
            save_xref("SUPPLIER", supplier["VendorId"], resp.json()["SupplierId"])

cURL: Test Cross-System Connectivity

# Test EBS ISG
curl -s -w "\nHTTP: %{http_code}\n" \
  "http://<ebs-host>:<port>/webservices/rest/supplier/v1/suppliers?limit=1" \
  -u "<user>:<password>"

# Test Fusion Cloud
curl -s -w "\nHTTP: %{http_code}\n" \
  "https://<pod>.fa.us2.oraclecloud.com/fscmRestApi/resources/latest/suppliers?limit=1" \
  -H "Authorization: Bearer $FUSION_TOKEN"

Data Mapping

Cross-System Entity Mapping

Data Type Gotchas

• EBS VENDOR_ID is NUMBER; Fusion SupplierId is also NUMBER but in a different sequence — never assume ID equivalence [src5]
• EBS stores multi-org data with ORG_ID context; Fusion uses Business Unit — map ORG_ID to BU [src2]
• EBS dates use database timezone; Fusion REST returns UTC — convert explicitly [src3]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• OIC Agent VM restart loses in-flight messages: Fix: Idempotent flows + checkpoint tracking; agent HA. [src1]
• GL period close timing mismatch: Fix: Pre-close reconciliation job verifying all journals received. [src2]
• Cross-reference table drift: Fix: Monthly reconciliation comparing xref against both systems. [src5]
• Fusion quarterly update breaks OIC flows: Fix: Test all flows in Preview environment before each update. [src3]

Anti-Patterns

Wrong: Direct database replication without transformation

# BAD — Table structures are incompatible between EBS and Fusion
Oracle GoldenGate: EBS.AP_SUPPLIERS → Fusion.POZ_SUPPLIERS
# Data models are completely different

Correct: API-mediated synchronization through OIC

# GOOD — OIC handles field mapping, ID xref, error handling
EBS (ISG REST) → OIC (Transform) → Fusion (REST API)

Wrong: Overlapping document number sequences

# BAD — Both systems generate PO-2026-001
# Creates reconciliation nightmares

Correct: Non-overlapping number ranges

# GOOD — EBS: PO-E-000001, Fusion: PO-F-000001
# Clear system origin in every document number

Wrong: No source-of-truth designation

# BAD — Both systems accept updates independently
# Sync overwrites one change with the other

Correct: Single source of truth per entity

# GOOD — Suppliers mastered in EBS until Procurement migrates
# EBS: Full CRUD | Fusion: Read-only (synced from EBS)

Common Pitfalls

• Not planning for OIC message consumption: Bidirectional flows consume 2x message packs. Fix: Batch transactions to reduce message count. [src6]
• Timezone differences in reconciliation: EBS and Fusion may report different timestamps for same transaction. Fix: Normalize all timestamps to UTC. [src3]
• Parallel period close without coordination: Causes subledger-to-GL discrepancies. Fix: Verify cross-system journals before closing periods. [src2]
• Single-point-of-failure OIC Agent: Any downtime stops all data flow. Fix: Deploy 2+ agent instances in HA group. [src1]

Diagnostic Commands

# Check OIC Agent status
curl -s "https://<oic-url>/ic/api/integration/v1/monitoring/agents" \
  -H "Authorization: Bearer $OIC_TOKEN" | jq '.items[] | {name, status}'

# Check failed OIC integration flows
curl -s "https://<oic-url>/ic/api/integration/v1/monitoring/instances?status=FAILED&limit=10" \
  -H "Authorization: Bearer $OIC_TOKEN" | jq '.items[] | {flowName, status, startTime}'

# Check cross-reference table health
# SELECT entity_type, sync_status, COUNT(*) FROM erp_xref GROUP BY entity_type, sync_status;

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• Coexistence is inherently temporary — document everything for teardown
• OIC licensing costs during coexistence can be significant — budget for 2x message consumption
• Fusion quarterly updates are mandatory and may break coexistence flows
• Cross-system reconciliation is labor-intensive — budget dedicated resources
• The longer coexistence runs, the more complex and costly it becomes — set hard deadlines