Hvis du leverer til en stor detailkæde eller automotive-koncern i Europa, bruger du EDI. Ikke fordi nogen elsker EDIFACT-syntaks, men fordi parten med den største indkøbsafdeling vælger formatet, og deres format blev standardiseret i 1988. At vente på, at de tilbyder et REST-API, er ikke en strategi.
Sådan ser en moderne EDI-opsætning faktisk ud
Tricket er at behandle EDI som en transportdialekt, ikke en arkitektur. Inde i integrationen er alt et almindeligt, veltypet order-/forsendelses-/fakturaobjekt; EDIFACT og X12 findes kun helt ude i kanten, i translatorer der er kedelige, versionerede og grundigt testet på optagne eksempelfiler.
Den adskillelse betaler sig på tre måder:
- At onboarde en ny handelspartner betyder en ny translatorprofil - beskedversion, segment-særheder, deres kreative brug af fritekstfelter - ikke ny forretningslogik.
- Test kan afspilles igen. Hver eneste partnerfil, der nogensinde er modtaget, fungerer som testeksempel. Når en translator ændres, kører vi fem års trafik igennem den igen og diff'er output.
- Det 20 år gamle ERP-system og den splinternye webshop ser det samme ordreobjekt, så EDI-ordrer og API-ordrer flyder gennem én pipeline med ét sæt regler.
De ugalante dele, der betyder noget
Kvitteringer er halvdelen af protokollen. En partner, der ikke modtager sin CONTRL-besked inden for sit tidsvindue, vil antage, at ordren er forsvundet, og ringe til dit salgsteam. Overvåg kvitteringsforsinkelse på samme måde, som du overvåger oppetid - det er den måling, din kundes indkøbsmedarbejder rent faktisk mærker.
EDI er ikke teknisk gæld. Det er infrastruktur - ligesom sporvidde. Man slipper ikke af med det gennem modernisering; man bygger rene adaptere og lader det blive ved med at gøre det, det har gjort pålideligt i fire årtier.