Technology
What we work with
Formats and transports first, because that is where the work is. Tools second, because they matter less.
Message formats
| Format | Where it turns up |
|---|---|
| EDIFACT | Order-to-invoice and carrier flows with European counterparties. ORDERS, ORDRSP, DESADV, INVOIC, IFTMIN; D96A more often than anything newer. |
| ANSI X12 | US counterparties. 850, 856 and 810 cover most of it. |
| SAP IDocs | ORDERS05, DESADV, INVOIC, and whatever the client's ERP team has extended over the years. |
| Flat files | CSV, fixed-width, Cargo-IMP-style records. Still most warehouse and plant traffic. |
| JSON and XML | REST and SOAP, on the newer end of a connection. |
UNB+UNOC:3+BUYER0047:ZZ+DISTR01:ZZ+260527:0240+0048291' UNH+48291+ORDERS:D:96A:UN' BGM+220+4067231+9' DTM+137:20260527:102' NAD+BY+K4067::92'
An ORDERS interchange as it arrives. The mapping starts after the bytes are safely on disk.
Transports
AS2 over HTTPS where the retail side asks for it. SFTP for most of everything else. OFTP2 where the automotive side insists. Plain HTTPS APIs, and message queues where both ends can hold one. We manage keys and certificates as part of support, because expiry at 03:10 on a Sunday is the classic silent failure.
Around them
On the client side we mostly meet PostgreSQL, Oracle and SQL Server. Mapping and reconciliation work is written in Python or Java, run on Linux, kept in Git, and scheduled by whatever the client already has: cron, the ERP's own job control, or a commercial scheduler somebody bought in 2011. We do not ask the client to change any of this.
Deliberately boring
We are cautious on purpose. No event-streaming platform where a cron job and a queue will do. State kept in a relational database the client's own team can query. Upgrades in the client's maintenance window, not ours. An interface that runs at night has to be understood at four in the morning by whoever got woken, and boring is what makes that possible.