Trex Pi
Hvis du leverer til en stor forhandlerkjede eller et bilkonsern i Europa, bruker du EDI. Ikke fordi noen elsker EDIFACT-syntaks, men fordi parten med den største innkjøpsavdelingen velger formatet, og deres format ble standardisert i 1988. Å vente på at de skal tilby et REST-API er ikke en strategi.
Hvordan et moderne EDI-oppsett faktisk ser ut
Trikset er å behandle EDI som en transportdialekt, ikke en arkitektur. Inne i integrasjonen er alt et enkelt, veldefinert ordre-/forsendelses-/fakturaobjekt; EDIFACT og X12 finnes bare helt i ytterkanten, i oversettere som er kjedelige, versjonerte og grundig testet mot innspilte eksempelfiler.
Det skillet lønner seg på tre måter:
- Onboarding av en ny handelspartner betyr en ny oversetterprofil - meldingsversjon, segmentrariteter, deres kreative bruk av fritekstfelt - ikke ny forretningslogikk.
- Testing kan spilles av på nytt. Hver eneste partnerfil som noen gang er mottatt, fungerer som testeksempel. Når en oversetter endres, kjører vi fem års trafikk gjennom den på nytt og sammenligner resultatet.
- Den 20 år gamle ERP-en og den splitter nye nettbutikken ser det samme ordreobjektet, så EDI-ordre og API-ordre flyter gjennom én pipeline med ett sett regler.
De lite glamorøse delene som betyr noe
Kvitteringer er halve protokollen. En partner som ikke mottar sin CONTRL-melding innen tidsvinduet, vil anta at ordren forsvant og ringe salgsteamet ditt. Overvåk ventetiden på kvitteringer på samme måte som du overvåker oppetid - det er målingen kundens innkjøpsmedarbeider faktisk merker.
EDI er ikke teknisk gjeld. Det er infrastruktur - som sporvidde på jernbane. Du blir ikke kvitt det gjennom modernisering; du bygger rene adaptere og lar det fortsette å gjøre det det pålitelig har gjort i fire tiår.