Trex Pi
If you supply a large retailer or automotive group in Europe, you do EDI. Not because anyone loves EDIFACT syntax, but because the party with the bigger purchasing department picks the format, and their format was standardized in 1988. Waiting for them to offer a REST API is not a strategy.
What a modern EDI setup actually looks like
The trick is to treat EDI as a transport dialect, not an architecture. Inside the integration, everything is a plain, well-typed order/despatch/invoice object; EDIFACT and X12 exist only at the very edge, in translators that are boring, versioned and heavily fixture-tested.
That separation pays off three ways:
- Onboarding a new trading partner means a new translator profile - message version, segment quirks, their creative use of free-text fields - not new business logic.
- Testing is replayable. Every partner file ever received is a fixture. When a translator changes, we re-run five years of traffic through it and diff the output.
- The 20-year-old ERP and the brand-new webshop see the same order object, so EDI orders and API orders flow through one pipeline with one set of rules.
The unglamorous parts that matter
Acknowledgements are half the protocol. A partner that doesn't receive its CONTRL message within its window will assume the order vanished and phone your sales team. Monitor acknowledgement latency the way you monitor uptime - it is the metric your customer's purchasing clerk actually experiences.
EDI is not technical debt. It is infrastructure - like rail gauge. You do not modernize it away; you build clean adapters and let it keep doing what it has done reliably for four decades.