How JD Edwards' Z-file staging tables, Business Services, AIS, Orchestrator Studio, Real Time Events and F47 EDI tables map onto D365 data entities, OData, business events, Power Automate and Fabric — and the direct-database-read habits that D365's cloud architecture forecloses.
JD Edwards EnterpriseOne's integration surface reads like a timeline of enterprise integration itself. Batch and EDI-era Z-file staging tables sit at the foundation. A Java-based Business Services (BSSV) layer added SOAP, and later REST, web services on top.
The classic JD Edwards integration idiom is the Z-file: a table suffixed Z1 — an inbound sales order table, a GL journal interface table, a voucher interface table, an AR invoice interface table among them — that holds an unedited transaction exactly as it arrived from an external system, batch job, or spreadsheet upload.
Business Services (BSSV) wrap JD Edwards business functions as callable web services, hosted on a dedicated Java BSSV server tier, originally SOAP-first and later extended with REST.
Orchestrator Studio deserves its own section because it is one of the few places in this entire course where the honest comparison runs in JD Edwards' favour. An orchestration is a sequence of steps — a Form Request, a Data Request, a Business Service Request, a Connector Request, a Notification — assembled through a low-code designer.
Real Time Events (RTE) publish an XML event from a flagged point inside a business function — an order was created, a shipment was confirmed — for one or more subscribing systems to react to, historically consumed through middleware or a BSSV-fronted listener.
JD Edwards' EDI capability is built from two cooperating pieces: the familiar Z-file staging tables used to move transaction data in and out, and a dedicated range of F47 tables holding trading-partner setup, transaction-set definitions, and the translation and cross-reference rules that convert a partner's flat file or X12/EDIFACT…
Two very different integration habits sit under this heading, and only one of them survives the move to D365 unchanged.
The replacement for "point a reporting tool at the database" is a governed export of the data, not a new connection string. BYOD (Bring Your Own Database) is the older mechanism: selected entities are exported into a customer-provisioned Azure SQL database that reporting tools can connect to safely.
Building this table for a specific site is itself a useful discovery exercise, not just a reference to consult afterwards. Walk every existing JD Edwards interface — however it is currently built — and classify it by volume, latency tolerance, and whether it needs to notify on an event or serve a query, before assigning it a D365…
JD Edwards' integration surface is unusually layered, and several of its layers translate onto D365 more cleanly than most functional concepts in this course: