sap business one fusion integration for the transitional reality SMBs face — Service Layer real-time bridges, DI API legacy gap-filling, B1iF retirement, OIC-based Fusion integration. Built for parallel-run, hybrid co-existence, and post-migration integration continuity.
Migration isn't a single weekend event for most SMBs. It's a months-long transition during which B1 and Fusion both live — and need to talk to each other and to the same external systems.
The clean cutover ideal — Friday B1, Monday Fusion, nothing in between — is rare for SMB B1-to-Fusion migrations. More common: finance cuts to Fusion in March, operations stays on B1 through Q2 while warehouse processes are validated, manufacturing finally moves in late Q3. During those 6–9 months, B1 and Fusion both serve live business processes, both feed downstream systems (CRM, e-commerce, banking, payroll, EDI partners, marketplaces), both consume from upstream (purchase requisitioning, manufacturing schedules, third-party inventory feeds). Without sap business one fusion integration glue, this hybrid window becomes a manual-reconciliation nightmare.
Syntra ETL's integration platform handles the hybrid window as a first-class scenario. Outbound from B1: Service Layer change-tracking captures every relevant create/update on OCRD, OITM, OINV, OPCH, ORDR, OPOR with sub-minute latency, applies the same data-mapping crosswalk used during migration, and pushes to Fusion via REST API. Inbound to B1: Fusion-originated events flow back to B1 via Service Layer for any entity still running in B1. The same crosswalk runs in both directions, ensuring data shape consistency across the hybrid window.
After migration, the integration platform doesn't disappear. The B1-facing endpoints retire with B1, but the Fusion-side OIC integration flows that handled external-system connections (CRM sync, e-commerce sync, EDI, banking, payroll) continue running. For the small subset of SMBs choosing long-term hybrid (one entity permanently on B1 because of a vertical-specific add-on), the platform supports that indefinitely. Migration tooling that disappears at go-live forces SMBs into a second integration project they didn't budget for.
Every common B1-to-Fusion integration pattern as a configurable flow. Configure, deploy, monitor.
OCRD changes flow real-time via Service Layer to Fusion HZ_CUST_ACCOUNTS + POZ_SUPPLIERS_ALL_M. CardType split applied inline. Fusion changes flow back to B1 OCRD for any entity still on B1. Sub-minute latency typical.
OITM changes flow to Fusion EGP_SYSTEM_ITEMS_B with item-class mapping. Per-warehouse organisation assignment maintained. Fusion item changes flow back to B1 OITM for hybrid entities. Costing-method preservation maintained.
OJDT/JDT1 posts replicate as Fusion GL journals in the originating BU during parallel-run and hybrid windows. OACT-to-6-segment crosswalk applied. Sub-ledger source preserved via TransType. End-of-day batch reconciliation.
OINV/INV1 changes flow to Fusion AR via REST. Customer reference mapped. Revenue routing through Fusion COA. Fusion-side AR invoices flow back to B1 for any hybrid entity. Real-time + end-of-day reconciliation.
OPCH/PCH1 changes flow to Fusion AP via REST. Vendor reference mapped. Expense routing through Fusion COA. PO match status preserved. Fusion-side AP flows back to B1 hybrid entities.
ORDR + OPOR changes flow bi-directionally between B1 and Fusion during the hybrid window. Full document chain preserved (quotation → order → delivery → invoice). Configurable per-order-line routing.
A typical sequence for deploying B1 ↔ Fusion integration during migration and beyond.
Discovery enumerates existing B1 integrations: Service Layer consumers, scheduled DI API jobs, B1iF flows, database-trigger-driven integrations. Each classified by business purpose and target disposition (cut to Fusion / keep on B1 / fan-out during hybrid).
Service Layer change-tracking strategy designed per entity. REST endpoint mapping to Fusion HZ/POZ/AR/AP/GL surfaces. OIC integration flow patterns selected. Latency targets agreed per integration (real-time / hourly / end-of-day).
Service Layer + REST + OIC flows implemented per the design. Bi-directional sync patterns deployed for hybrid entities. End-of-day batch reconciliation jobs scheduled. Monitoring + alerting wired.
EDI, marketplace, banking, payroll, e-commerce integrations re-pointed: finance-side integrations cut to Fusion via OIC, operations-side integrations kept on B1 during hybrid window, fan-out flows where both systems need to feed.
Real-time bridges active during parallel-run cycles. Hybrid co-existence enters business hours operation. Sub-minute latency monitored. Reconciliation pack produced daily during the hybrid window.
B1-facing Service Layer endpoints retired with B1 decommissioning. Fusion-side OIC integration flows continue running. Platform pivots to ongoing Fusion integration: EDI, marketplace, banking, payroll, e-commerce, partner ecosystem.
The architectural decisions that drive long-term cost, latency, and supportability of B1 ↔ Fusion integration.
B1 Service Layer is SAP-supported, REST/OData based, modern. DI API is legacy COM. Default: Service Layer for everything, DI API only for Service Layer gaps. Long-term supportability much better.
Oracle Integration Cloud is Oracle-supported, deeply integrated with Fusion, low-code. Custom middleware (Mule, Boomi, custom Java) adds licence cost and another team to coordinate. Default: OIC.
Real-time for user-facing latency-sensitive sync (master data updates, transactional events). Batch for bulk reconciliation (GL trial balance, period close). Both run from the same configuration-driven platform.
During hybrid co-existence, sync flows in both directions unless explicit one-way logic applies. Reduces user surprise (an address update made in B1 shouldn't be reverted by a Fusion-to-B1 sync the next minute).
All integration flows are idempotent. Replaying an event has no double-counting risk. Critical for parallel-run replay cycles and for recovering from intermittent failures.
Every event logged with source row hash, target row hash, transformation applied, latency. Full lineage queryable for IRS/HMRC/GoBD audit during retention window. Not just migration-grade — operations-grade.
SAP Business One Fusion integration covers the connective tissue between B1 and Oracle Fusion during and after migration: real-time event flow for hybrid co-existence (e.g. one entity stays on B1 while others move to Fusion), batch synchronisation for parallel-run validation, and bridge connectors for external systems that are mid-migration to Fusion. Syntra ETL builds sap business one fusion integration on B1's native interfaces — Service Layer REST/OData for outbound events, DI API for legacy COM-based bridges, B1iF flows for the deprecated middleware layer — and lands them on Fusion's REST APIs and OIC integration patterns. The integration is designed for the transitional reality most SMBs face: B1 and Fusion both live for weeks or months, both feeding the same downstream systems, both reading from the same trading-partner master.
Real-time event flow uses B1's Service Layer change-tracking. Outbound: Service Layer's UpdateDate-based polling or webhook-like patterns trigger as soon as a B1 record (OCRD, OINV, OPCH, ORDR) is created or updated. The Syntra ETL bridge consumes the event, applies the data-mapping crosswalk inline, and pushes to Fusion via REST API (Customer REST for HZ_CUST_ACCOUNTS, Supplier REST for POZ_SUPPLIERS_ALL_M, Invoice REST for AR/AP). Latency is typically 30 seconds to 2 minutes depending on event volume. Inbound: Fusion-originated events (sales orders, AR invoices created in Fusion) flow back to B1 via Service Layer for any entity still running in B1. This supports the standard parallel-run + hybrid co-existence patterns SMB B1-to-Fusion projects need.
Service Layer is B1's modern REST/OData interface and is the preferred integration entry point for SAP Business One Fusion integration. Syntra ETL connects to Service Layer with a dedicated read-only or read-write B1 user (configurable per direction), authenticates via session-based login, and consumes/produces JSON payloads against Service Layer endpoints (e.g. /b1s/v1/BusinessPartners, /b1s/v1/Items, /b1s/v1/ChartOfAccounts, /b1s/v1/Invoices, /b1s/v1/PurchaseInvoices, /b1s/v1/Orders). Service Layer's pagination, filtering, and projection capabilities are used to bound payload sizes. Service Layer change tracking via $filter on UpdateDate gives near-real-time event capture. Service Layer is supported by SAP and is the right long-term integration surface — DI API is used only for endpoints Service Layer doesn't yet cover.
B1iF (B1 Integration Framework) was SAP's middleware layer for B1 integrations through the 2010s. Many SMBs still have B1iF flows running — typically deployed by their SAP Partner Edge partner — handling EDI, marketplace integrations, payroll, banking, e-commerce. SAP has been steadily de-emphasising B1iF in favour of Service Layer and the SAP Integration Suite. Syntra ETL's sap business one fusion integration playbook retires B1iF flows during migration: each B1iF flow is inventoried (typical SMB has 5–20 flows), classified by business purpose, and re-implemented on OIC (Oracle Integration Cloud) for Fusion-side integration or directly on REST endpoints. The B1iF runtime is then decommissioned with the rest of B1, freeing the SMB from a deprecated middleware product.
Yes — hybrid co-existence is the most common transitional scenario for SMB B1-to-Fusion projects. A typical pattern: finance moves to Fusion first, operations stays on B1 for 3–6 months while operational processes are validated, manufacturing or warehousing moves last. During the hybrid window, sap business one fusion integration provides: trading-partner master sync (OCRD changes flow to Fusion supplier/customer master, Fusion changes flow back), inventory item sync (OITM changes mirror to Fusion items), AR/AP transaction sync (invoices created in either system flow to the other for consolidation reporting), GL sync (B1 OJDT posts replicate as Fusion GL journals in the originating BU). Latency is configurable per integration based on business criticality.
Batch and real-time are complementary, not competing. Real-time event flow (Service Layer outbound + REST inbound) handles user-facing latency-sensitive sync: a salesperson updating a customer address in B1 should see that change in Fusion within minutes, not overnight. Batch synchronisation handles bulk reconciliation: end-of-day OJDT trial balance sync, end-of-period closed-invoice archival, monthly inventory roll-forward. The Syntra ETL integration platform runs both patterns concurrently from the same configuration: real-time events flow via Service Layer + REST with sub-minute latency, batch jobs run on scheduled cron (typically end-of-day, end-of-week, end-of-period) for bulk reconciliation. Both produce audit-grade lineage.
Existing B1 integrations — EDI, marketplace connectors, banking integrations, payroll feeds, e-commerce — get inventoried and re-pointed during the migration. Each integration is classified: ones that should follow finance to Fusion (banking, GL feeds) get cut to Fusion via OIC integration flows; ones that follow operations and operations stays on B1 keep running on B1 during the hybrid window; ones that need to feed both systems during the transition get a fan-out implemented on OIC. SAP Partner Edge partners often own these integrations, so their knowledge transfer is critical — the discovery phase enumerates every integration, identifies the partner-built ones, and arranges knowledge transfer or replacement during the migration timeline.
Both. During migration, sap business one fusion integration powers the bridge between B1 and Fusion for parallel-run, hybrid co-existence, and external-system rewire. Post-migration (after B1 is decommissioned), the integration platform pivots to ongoing Fusion integration: Service Layer connectors retire with B1, but OIC integration flows that landed Fusion-side endpoints continue running. For SMBs running long-term hybrid scenarios (one entity stays on B1 indefinitely because of a vertical-specific add-on), the integration platform supports that pattern indefinitely — same Service Layer + REST + OIC architecture, same audit-grade lineage, same configuration-driven deployment. The platform isn't a migration-only tool.
Book a 60-minute walkthrough. We'll scope sap business one fusion integration for your migration shape — parallel-run, hybrid co-existence duration, external-system inventory, B1iF retirement, and long-term integration model — and show you the Service Layer + OIC architecture running against a representative subset of your data.