Infor LX (BPCS) Oracle Fusion Integration — Real-Time and Batch

Both, and the answer depends on the customer's strategic plan. For customers committed to retiring BPCS, Infor LX (BPCS) Oracle Fusion integration is the migration data-pipeline that moves transactions, masters and history from BPCS on IBM i to Fusion. For customers running BPCS and Fusion in steady-state (BPCS for shop-floor manufacturing, Fusion for Financials and Order Management — a common hybrid for F&B, CPG and process-manufacturing customers), Infor LX (BPCS) Oracle Fusion integration is the ongoing real-time and batch data exchange between the two systems. Syntra ETL supports both patterns with the same platform: pre-built BPCS extractors and Fusion FBDI / REST emitters handle migration; the same platform's real-time delta-capture (IBM i journal reader) and Fusion REST / FBDI loaders handle steady-state two-way integration. Customers can transition from steady-state hybrid to full retirement without re-platforming the integration.

Batch integration runs on a schedule (typically nightly or hourly) — extract a delta from BPCS via IBM i journal or LST-UPD-DATE / LST-UPD-TIME watermark, transform to Fusion FBDI / HDL payload, submit to Fusion ESS, reconcile. End-to-end latency: typically 1–24 hours. Best for non-time-critical data: GL history sync, supplier / customer master sync, inventory-balance snapshot, cost master update. Real-time integration uses event streams or short-poll deltas — IBM i journal reader captures every BPCS insert / update / delete with 5–60 second latency, transforms to Fusion REST API payload, calls Fusion REST endpoint, captures result. End-to-end latency: typically 5–60 seconds. Best for time-critical: sales-order creation, inventory transactions affecting available-to-promise, shipment confirmations, work-order completion. The Infor LX (BPCS) Oracle Fusion integration platform handles both modes for the same scope — you choose batch or real-time per data object.

The IBM i database journal records every insert, update and delete against journaled physical files with timestamp, user profile, terminal and before / after image. BPCS files in scope are typically journaled to QSQJRN or BPCS-specific application journals. The Syntra Infor LX integration platform reads the journal receivers via the IBM i RTVJRNE / DSPJRN APIs and SQL journal services, decodes the delta records (insert / update / delete by table, by primary key, by user), transforms them through the same crosswalk used for migration, and publishes them to Fusion via REST API or via Kafka / Kinesis for downstream consumers. Typical end-to-end latency from BPCS commit to Fusion REST acknowledgement: 5–60 seconds. The journal-reader approach is non-invasive (no BPCS source-side modifications, no database triggers, no IBM i performance impact) and reads what BPCS already records natively for SOX / FDA audit purposes.

For the common hybrid pattern (BPCS shop-floor, Fusion Financials + Order Management), the integration handles eight typical two-way flows. BPCS → Fusion: GL journal posting from BPCS inventory transactions (raw-material consumption, finished-good production, scrap), AP voucher creation from BPCS three-way-match against PO + receipt, inventory-value snapshot for Fusion period-end revaluation, work-order WIP balance for Fusion cost management, shipment confirmation triggering Fusion AR invoice. Fusion → BPCS: sales-order creation triggering BPCS production-planning load, customer master sync from Fusion TCA to BPCS CIM, supplier master sync from Fusion TCA to BPCS ACL, item master sync from Fusion Item Master to BPCS IIM. Each flow has its own latency tolerance, batch vs real-time choice, and reconciliation cadence — locked in the integration design document.

The Syntra Infor LX (BPCS) Oracle Fusion integration platform emits Fusion-native loaders matched to the latency requirement of each data object. For batch loads (nightly / hourly): FBDI ZIPs for Journal Import, Supplier Import, Customer Import, Item Import, AP Invoice Import, Receivables Invoice Import, Inventory Balance Import, Item Structure Import, Routing Import, Work Definition Import — submitted to Fusion ESS, monitored to completion, reconciled. For real-time loads: Fusion REST endpoints for Sales Order create / update, Inventory Transaction post, Work Order operation transactions, Shipment confirmation, Customer / Supplier create — called with 5–60 second latency, retry logic on failure, full request / response logged for audit. Same crosswalk rules apply to both — there is no separate transformation layer for batch vs real-time. The integration platform handles authentication (OAuth 2.0 for REST, basic auth or certificate for ESS) and rate-limiting transparently.

BPCS shop-floor typically captures data via barcode scanners on the production line (HRM hours, MHD work-order detail posts) and via DDS-defined 5250 green screens for direct operator entry. In the hybrid pattern where Financials moves to Fusion but shop-floor stays on BPCS, the data-collection stack stays on BPCS (no shop-floor re-training, no new hardware), and the Infor LX (BPCS) Oracle Fusion integration captures the resulting BPCS transactions (work-order completions, inventory transactions, scrap reports, HRM hours) via IBM i journal reader and posts them to Fusion Financials in real-time or near-real-time depending on the latency tolerance per flow. Inventory transactions that affect available-to-promise (raw-material consumption, finished-good production) go real-time; period-end work-order WIP rollups go batch nightly. The shop-floor user experience is unchanged.

Every integration call (REST, FBDI, ESS) is wrapped in retry-with-exponential-backoff plus dead-letter-queue for permanent failures. REST failures retry 3–5 times over 30 minutes; if all retries fail, the message lands in a dead-letter queue with full payload, error context and suggested fix, and an alert fires to the integration team via email, Slack, PagerDuty or webhook. FBDI failures (validation errors in the FBDI ZIP) surface row-level diagnostics — the specific row with the specific Fusion validation error and the suggested fix — and the failed rows are queued for bulk fix and re-submit while the successful rows are loaded. Idempotency keys on every message ensure retries are safe. SOC 2-compliant audit logging captures every send, every receive, every retry and every dead-letter — your security and audit teams have full visibility.

The Syntra Infor LX integration is built to be a good IBM i citizen. The journal reader uses the standard IBM i RTVJRNE / SQL journal services through QZDASOINIT server jobs which respect IBM i workload management — the integration runs in a dedicated subsystem (commonly QUSRWRK or a custom subsystem you assign) with configurable activity-level cap and can be throttled at peak times. No CL commands are submitted, no RPG programs are called, no BPCS user activity is interrupted. Live order entry, MRP runs, shop-floor data collection and label printing continue uninterrupted. Real-time integration runs continuously; batch integration runs on cron scheduled to off-peak windows. Customers routinely run Infor LX (BPCS) Oracle Fusion integration against live production IBM i for years without a single user-experienced slowdown.