SAP S/4HANA Oracle Fusion Integration — Hybrid Co-existence

SAP S/4HANA Oracle Fusion integration is the connectivity layer that keeps S/4HANA and Oracle Fusion synchronised during a phased migration where both systems run in parallel. A typical pattern: Finance migrates to Fusion in phase 1 while SCM (Procurement, Inventory, Manufacturing) stays on S/4HANA in phase 2 (often 6–18 months later). During the gap, S/4HANA continues posting goods movements that need to land in Fusion GL; S/4HANA continues paying invoices that need to update Fusion AP; Fusion approves journals that need to inform S/4HANA controlling. The integration bridges this — usually via SAP Cloud Integration (CPI on BTP) or Oracle Integration Cloud (OIC) with bidirectional message flow, error handling, and reconciliation. Real-time API integration and batch file integration both have roles.

Real-time integration via APIs makes sense for transactional events where downstream business waits for the upstream — a purchase order created in S/4HANA needs to inform Fusion GL within minutes so commitment accounting is current; a supplier approved in Fusion needs to propagate to S/4HANA MM within minutes so purchase requisitions can reference it. Real-time uses OData services (S/4HANA's primary REST surface), SOAP via SAP Cloud Integration, or BAPIs wrapped in REST. Batch integration makes sense for high-volume, lower-urgency synchronisation — daily reconciliation of GL postings, weekly customer master sync, monthly inventory valuation transfer. Batch uses file-based exchange (IDoc XML, CSV, EDI) with file landing zones in cloud object storage. Most production integrations use a mix: real-time for transactional events, batch for high-volume reconciliation.

SAP BTP (Business Technology Platform) Cloud Integration (formerly CPI — Cloud Platform Integration) is SAP's strategic integration platform. For S/4HANA-to-Fusion bridging, CPI acts as the orchestration hub: pulls events from S/4HANA via OData / IDoc / event-mesh, transforms to Fusion-compatible payloads (typically REST JSON), pushes to Fusion via the appropriate REST endpoint (Suppliers REST API, Invoices REST API, etc.), captures responses, handles errors, retries failures, and logs the full transaction trail. The reverse direction works the same: Fusion fires events via BIP integration or REST callbacks, CPI receives them, transforms to S/4HANA-compatible IDocs or OData calls, pushes to S/4HANA, captures responses. Oracle Integration Cloud (OIC) plays an equivalent role on the Oracle side — some customers use both, some pick one as the strategic hub.

OData passthrough is the lightweight pattern where Fusion (or a third party) directly consumes an S/4HANA OData service over HTTPS — no intermediary integration platform involved. Pattern: S/4HANA exposes the service (e.g., the API_SUPPLIER_SRV for supplier master, API_JOURNALENTRYITEMBASIC_SRV for journal entries), Fusion authenticates with OAuth 2.0 or basic auth, queries the service via OData query parameters ($filter, $select, $top), receives the JSON response, and persists or processes it. OData passthrough works well for low-to-medium volume read-heavy patterns: lookups, reference-data syncs, on-demand data pulls. It struggles with high-volume scenarios (throughput-limited by S/4HANA OData runtime) and complex transformations (no transformation layer between source and target). For those, the CPI/OIC bridge pattern is better.

Co-existence is the operational state where both S/4HANA and Fusion are simultaneously authoritative for different business areas. Common pattern: Finance fully on Fusion (Fusion is system of record for GL, AP, AR, FA, Tax), SCM fully on S/4HANA (S/4HANA is system of record for Procurement, Inventory, Manufacturing, Quality). The integration layer keeps the two in sync: every S/4HANA goods movement (MBEW change) generates a journal entry in Fusion within minutes; every Fusion supplier approval propagates to S/4HANA LFA1; every period close in Fusion triggers a reconciliation extract from S/4HANA. Co-existence is a non-trivial operational mode — it adds latency, reconciliation overhead, and integration complexity. But it's the only viable approach for organisations too large to cut everything in a single weekend.

Period close synchronisation is the hardest co-existence problem. When Fusion is closing period 03 and S/4HANA is closing period 03 in parallel, integration must ensure (a) all S/4HANA goods movements affecting period 03 have generated Fusion GL entries before Fusion's period 03 closes; (b) all Fusion journal entries affecting S/4HANA-side reporting have flowed to S/4HANA before S/4HANA's period 03 closes; (c) accruals on both sides are reconciled so total liabilities match; (d) inter-company eliminations net to zero across both systems. The integration platform runs a 'period close coordinator' that paces close activities, blocks premature close on one side until the other side has caught up, and produces a reconciliation evidence pack per close. This is what makes phased migration work — without it, period close becomes a multi-week reconciliation exercise.

Yes, but it requires explicit upgrade discipline. SAP releases S/4HANA upgrades (Feature Pack Stacks, Cloud quarterly updates) that occasionally change OData service signatures, BAPI structures, or IDoc segment formats. The integration architecture mitigates this by versioning every interface (e.g., API_SUPPLIER_SRV v1 vs v2), pinning the integration layer to a specific S/4HANA version during deployment, testing integration changes in a non-prod S/4HANA against the upgraded API surface before production cutover, and maintaining a deprecation calendar that aligns with SAP's mainstream support roadmap. SAP commits to mainstream support for 2027/2030 horizons, with extended support windows for stable customers — integration architecture is designed assuming a 5–7 year lifecycle minimum, with the structural decision to migrate to Fusion typically completing well within that window.

The operational support model has three layers. Layer 1 (monitoring): the integration platform (CPI or OIC) provides built-in monitoring dashboards showing message throughput, error rates, latency percentiles, and queue depths. Syntra ETL adds business-level monitoring — per-process throughput trends, reconciliation variance per integration, SLA compliance per business event. Layer 2 (incident response): defined runbooks per integration with named escalation contacts, integration-platform-vendor support contracts (SAP for CPI, Oracle for OIC), and on-call rotations for high-criticality flows like payment processing. Layer 3 (change management): every integration change goes through versioned deployment with rollback capability, regression testing against representative payloads, and stakeholder sign-off from both S/4HANA and Fusion teams. The total cost of ownership for integration in steady state is typically 0.5–1.5 FTE equivalent for mid-sized customers.