Trex Pi
Om ni levererar till en stor detaljhandelskedja eller fordonskoncern i Europa, använder ni EDI. Inte för att någon älskar EDIFACT-syntax, utan för att parten med den större inköpsavdelningen väljer formatet, och deras format standardiserades 1988. Att vänta på att de ska erbjuda ett REST-API är ingen strategi.
Hur en modern EDI-uppsättning faktiskt ser ut
Tricket är att behandla EDI som en transportdialekt, inte en arkitektur. Inuti integrationen är allt ett enkelt, väldefinierat order-/avisering-/fakturaobjekt; EDIFACT och X12 existerar bara ytterst i kanten, i översättare som är trista, versionshanterade och grundligt testade mot inspelade exempelfiler.
Den separationen lönar sig på tre sätt:
- Att onboarda en ny handelspartner innebär en ny översättarprofil - meddelandeversion, segmentegenheter, deras kreativa användning av fritextfält - inte ny affärslogik.
- Testning kan spelas upp igen. Varje partnerfil som någonsin tagits emot sparas som ett testexempel. När en översättare ändras kör vi fem års trafik genom den igen och jämför utdatan.
- Det 20 år gamla ERP-systemet och den splitternya webbutiken ser samma orderobjekt, så EDI-order och API-order flödar genom en och samma pipeline med samma regelverk.
De oglamorösa delarna som spelar roll
Kvitteringar är hälften av protokollet. En partner som inte tar emot sitt CONTRL-meddelande inom sitt tidsfönster kommer att anta att ordern försvann och ringa er säljavdelning. Övervaka kvitteringslatens på samma sätt som ni övervakar drifttid - det är måttet som er kunds inköpshandläggare faktiskt upplever.
EDI är inte teknisk skuld. Det är infrastruktur - som spårvidd. Det är inget man blir av med genom modernisering; man bygger rena adaptrar och låter det fortsätta göra det det gjort tillförlitligt i fyra decennier.