The Infor LX (BPCS) ETL connector that handles every BPCS module, every EBCDIC / CCSID, every COMP-3 packed-decimal, every CYYMMDD zoned-decimal date and every customer UDF. Cloud ERP, data warehouse, lake, streaming and archive targets — same connector, same governance.
Build-your-own BPCS ETL always starts cheap and ends expensive. The BPCS-specific complexity — EBCDIC, COMP-3, CYYMMDD, UDF discovery, audit-trail handling, multi-member files — eats the savings in the first quarter.
Build-your-own BPCS ETL — whether based on a generic JDBC connector, an RPG export-program suite, a Talend / Informatica / DataStage job, or a Python script — always looks tractable at the start. DB2 for i is queryable via JDBC. BPCS file names are documented in the LX file glossary. RPG and CL aren't difficult languages for someone who knows them. The challenges are knowable. The first developer assigned to the project produces working extracts for GL and AP inside two weeks. The project plan gets signed off.
Then reality hits. The Manufacturing extracts fall over on multi-member physical files. The shop-floor HRM extract crashes the IBM i because the developer used a predicate that forces a table scan. The supplier extract corrupts a euro-symbol in a French supplier name because the CCSID was 037 instead of 1140. The work-order WIP balance is off by a factor of 100 because COMP-3 precision was misread on a customer-added UDF. The CYYMMDD-vs-YYYYMMDD date confusion on MHM versus PSM produces 100-year date jumps in the BOM history. Every BPCS-specific quirk surfaces one at a time, each consuming a developer-week to diagnose and fix. By month four, the build-your-own ETL has cost more than the connector licence would have and is still finding new edge cases.
Syntra ETL's Infor LX (BPCS) ETL connector ships with every BPCS quirk handled — every EBCDIC CCSID, every COMP-3 precision rule, every CYYMMDD century-flag interpretation, every multi-member physical file pattern, every customer UDF discovery rule, every audit-trail file structure. Refined across dozens of customer deployments. Backed by an SLA. Quarterly releases pick up Infor LX 8.x patch-level updates automatically. Most customers pay back the connector cost in 2–3 months versus equivalent custom development.
What the connector ships with. Each pillar maps directly to a BPCS-specific complexity that build-your-own ETL routinely gets wrong.
JDBC via IBM i Access drivers, no proprietary middleware. Read-only *USRPRF authentication with library-scoped object authority. Workload-manager aware, runs in dedicated subsystem, never throttles live BPCS users.
CCSID-aware translation handling 037 (US), 285 (UK), 1140 (US Euro), 1148 (Multilingual Euro) and the long tail of regional code pages. Per-field CCSID override where the BPCS file mixes encodings.
Packed-decimal (COMP-3) and zoned-decimal numerics unpacked with full precision preserved through round-trip. CYYMMDD century-flag interpretation. Multi-precision UDF support.
IBM i database journal reader (richest, lowest source impact). LST-UPD-DATE / LST-UPD-TIME watermark (simpler). Full-snapshot diff (fallback). Chosen per BPCS file at configuration time.
Parquet, JSON Lines, FBDI ZIPs, HDL bundles, CSV, Avro, REST API calls — multiple targets per run. Write same extract to Parquet for analytics and FBDI for Fusion in one pass.
Library-wide crawl of LXFILES, LXMODOBJ and custom libraries discovers customer-added UDFs, shadow tables, custom files. Indexed and surfaced for configuration without manual AS/400 inventory work.
From IBM i user profile provisioning to first scheduled extract running unattended. Typical timeline: 3–5 days.
Your IBM i admin creates a dedicated *USRPRF for the connector with read-only object authority on BPCS libraries (LXFILES, LXMODOBJ, custom libraries). No QSECOFR, no *ALLOBJ. Credentials stored in your cloud KMS.
Connector container deployed to your cloud environment via Helm / Terraform / direct container run. Network reachability to IBM i LPAR confirmed. Output destination(s) configured: S3 / GCS / Azure Blob / Snowflake / Fusion FBDI drop / Kafka topic etc.
Per-file scope (which BPCS files, which fiscal years, which companies, which UDFs) configured via YAML or UI. Delta mechanism per file (journal / watermark / snapshot) chosen. Schedule defined: one-shot bulk, nightly delta, weekly snapshot or cron pattern.
Initial full-snapshot extract runs across all configured BPCS files in parallel with SQL key-range partitioning. Throttled to off-peak for multi-TB extracts. Signed manifest with counts / sums / hashes per partition produced.
Scheduled delta runs execute on cron. Run logs feed your SOC 2 audit trail. Prometheus metrics expose throughput, latency, error rates. Failures alert via email / Slack / PagerDuty / webhook. Quarterly connector updates pick up Infor LX 8.x patch-level changes automatically.
The details that matter when the connector has to run unattended for years against live IBM i production.
Respects IBM i workload management. Configurable activity-level cap. Runs in dedicated subsystem (commonly QUSRWRK or custom). Throttled to off-peak for multi-TB extracts. Never throttles live BPCS users.
Every extract is idempotent — re-running the same scope produces byte-identical output. Failed runs resume from last partition checkpoint rather than starting over. Safe for unattended cron operation.
Every run produces signed JSON manifest with record counts, sum totals, hash signatures and source LST-UPD-DATE watermarks per partition. Downstream reconciliation consumes manifest directly.
IBM i credentials and connector secrets encrypted at rest in cloud KMS (AWS KMS / GCP KMS / Azure Key Vault). Output encrypted at rest with KMS-managed keys. TLS in transit between connector and IBM i (DRDA-over-SSL) and between connector and output storage.
Single control plane orchestrates extraction across multiple IBM i LPARs (prod / QA / dev / multi-region). Each LPAR has its own *USRPRF and scope. Parallel extraction across LPARs with per-LPAR throttling.
Every IBM i connect, every SQL statement, every row count, every output write logged with user / timestamp / scope / result. Audit logs ship to SIEM via syslog / CloudTrail / Cloud Audit Logs. Pharma / defence customers pass on first attempt.
The Syntra Infor LX (BPCS) ETL connector is a production-grade, pre-built ETL component that handles the full extract-transform-load pipeline between Infor LX (BPCS) running on IBM i / DB2 for i and any modern target — Oracle Fusion Cloud ERP, Infor CloudSuite Industrial Enterprise, SAP S/4HANA, a cloud data warehouse (Snowflake, BigQuery, Redshift, Databricks), or a long-term archive. It covers every BPCS module in production use (Financials, Manufacturing, Inventory, Order Management, Procurement, Fixed Assets), every BPCS file pattern, every EBCDIC / CCSID combination, every COMP-3 packed-decimal precision rule, every CYYMMDD zoned-decimal date format and every customer UDF added through the LX customisation framework. The Infor LX (BPCS) ETL connector ships pre-built — no custom RPG export programs, no bespoke SQL, no AS/400 expert required from your team.
A generic JDBC connector can query DB2 for i, but it doesn't know what to do with what it gets back. EBCDIC characters arrive as garbled bytes if the CCSID isn't correctly negotiated. COMP-3 packed-decimal numerics arrive as raw bytes that need precision-aware unpacking. CYYMMDD zoned-decimal dates arrive as 7-digit numbers that need century-flag interpretation. BPCS file naming (GLM, GLT, IIM, ECH, MHM, ACL, CIM, PSM, RTM and 100+ others) is opaque to a generic tool. Multi-member physical files, multi-format DDS-defined files, customer UDFs, audit-trail files and the BPCS reference-table system (CCM, MCM, WHM, LOC, UOM) all need BPCS-aware handling. The Infor LX (BPCS) ETL connector ships with all of this pre-built and refined across dozens of BPCS deployments — what you save in BPCS-specific development time is multiples of the connector cost in the first month.
Cloud ERP targets: Oracle Fusion (FBDI / HDL / REST), Infor CloudSuite Industrial Enterprise (Infor's native CSI loaders), SAP S/4HANA (BAPI / OData / IDoc), Microsoft Dynamics 365 (Business Central / F&O loaders). Cloud data warehouse targets: Snowflake (Snowpipe and bulk load), BigQuery (load jobs and streaming inserts), Redshift (COPY from S3), Databricks (Delta Lake direct write), Azure Synapse (PolyBase). Lake / object storage: S3 (Parquet partitioned), GCS, Azure Blob — all with hash-signed manifests. Streaming: Kafka, Kinesis, Pub/Sub, Event Hubs — for real-time delta replay. Archive: long-term Glacier / Coldline / Archive Storage with hash-signed evidence packs and 7-year-plus retention for SOX / FDA. Custom targets configurable via REST API or webhook.
Three mechanisms supported per BPCS file. Mechanism 1 — IBM i database journal: the connector reads journal receivers via the RTVJRNE / SQL journal services, decodes inserts / updates / deletes per BPCS file in scope, and emits delta records with full before / after image. Highest fidelity, lowest source impact. Mechanism 2 — LST-UPD-DATE / LST-UPD-TIME watermark: BPCS maintains these fields on most master and transactional files; the connector queries records where LST-UPD-DATE > last-watermark and stamps the new high-watermark for next run. Simpler, requires watermark coverage on the file. Mechanism 3 — Full-snapshot diff: where neither journal nor watermark is available (rare), the connector takes full snapshots and computes the diff. Highest source impact, only used when necessary. The connector chooses the mechanism per file at configuration time.
Parquet (columnar, partitioned by fiscal year and company, ideal for downstream analytics in Athena / BigQuery / Snowflake / Spark), JSON Lines (newline-delimited JSON preserving full BPCS field shape, ideal for streaming pipelines), Fusion-native FBDI ZIPs and HDL bundles (validated against current Fusion 26x release schemas), CSV (UTF-8, configurable delimiter and quote rules, for legacy downstream consumers), Avro (for Kafka-centric pipelines), and direct REST API calls (for real-time integration to Fusion / CSI / S/4HANA endpoints). EBCDIC fields are translated to UTF-8 in every format, COMP-3 packed-decimal numerics are unpacked to standard decimal with full precision preserved, and CYYMMDD zoned-decimal dates are normalised to ISO 8601. Multiple output formats per run are supported — write the same extract to Parquet for analytics and FBDI for Fusion in one pass.
Yes. Customers running BPCS across multiple IBM i LPARs (separate prod, QA, dev, training partitions, sometimes per-region prod LPARs in multi-country deployments) configure each LPAR as a separate Infor LX (BPCS) ETL connector source. Each source has its own *USRPRF, its own library-scope, its own scheduling, its own output destination. The connector orchestrates parallel extraction across LPARs from a single control plane — useful for multi-region BPCS deployments where each region's IBM i is extracted to a regional cloud landing zone and consolidated downstream. The same control plane handles HA scenarios (extract from primary LPAR by default, fall back to MIMIX / RoboHA replica if primary is unreachable) and disaster-recovery testing scenarios.
Connector pricing is module-based and volume-tiered, with optional usage-based add-ons. Base licence covers up to two BPCS modules (typically Financials + one of Manufacturing / Inventory / Order Management) for one IBM i LPAR at a fixed annual fee. Additional modules and LPARs add to the base. Volume tiering applies if extracted record volume exceeds the tier threshold (typically 50M / 200M / 1B records per month). Optional add-ons: real-time IBM i journal reader (if real-time integration is in scope), Fusion FBDI / REST emitter (if Fusion is the target — included in migration project pricing if you're a migration customer), SOC 2 / FDA audit-logging extension, premium support SLA. Customers typically pay back the connector cost in 2–3 months versus equivalent custom RPG / SQL development plus the ongoing maintenance burden.
The Infor LX (BPCS) ETL connector is containerised and runs on Kubernetes, Amazon ECS, Google Cloud Run, Azure Container Instances or bare VM with network reachability to the IBM i LPAR. Deployment is via Helm chart, Terraform module or direct container run. Operates as a stateless extractor with state held in cloud object storage (Parquet checkpoints, hash-signed manifests) and orchestration via the Syntra control plane (or your existing Airflow / Prefect / Dagster scheduler via REST API). Observability via Prometheus metrics, Grafana dashboards, OpenTelemetry traces. SOC 2-compliant audit logging via CloudTrail / Cloud Audit Logs / syslog to your SIEM. Customers run the connector unattended for years — quarterly connector releases pick up Infor LX 8.x patch-level updates without operator intervention.
30-minute call. We'll scope your BPCS modules, IBM i landscape, target platforms and delta requirements — and have a working extract running on your AS/400 within a week. No custom RPG, no AS/400 expert required from your team.