Trex Pi
Ha egy nagy kiskereskedőt vagy autóipari csoportot szállít ki Európában, akkor EDI-t használ. Nem azért, mert bárki is rajong az EDIFACT szintaxisáért, hanem mert a nagyobb beszerzési osztállyal rendelkező fél választja meg a formátumot, és az ő formátumukat 1988-ban szabványosították. Nem stratégia arra várni, hogy egyszer majd kínáljanak egy REST API-t.
Hogyan néz ki valójában egy modern EDI-beállítás
A trükk az, hogy az EDI-t szállítási dialektusnak kezeljük, nem architektúrának. Az integráción belül minden egy egyszerű, jól típusos megrendelés/szállítási bizonylat/számla objektum; az EDIFACT és az X12 csak a legszélén létezik, egyszerű, verziózott és rögzített mintafájlokon alaposan tesztelt fordítókban.
Ez a szétválasztás három módon térül meg:
- Egy új kereskedelmi partner bevezetése egy új fordítói profilt jelent - üzenetverzió, szegmens-sajátosságok, a szabadszöveges mezők kreatív használata -, nem pedig új üzleti logikát.
- A tesztelés visszajátszható. Minden valaha kapott partnerfájl egy rögzített tesztpélda. Amikor egy fordító megváltozik, öt év forgalmát futtatjuk újra rajta, és összehasonlítjuk a kimenetet.
- A 20 éves ERP és a vadonatúj webshop ugyanazt a megrendelés-objektumot látja, így az EDI-megrendelések és az API-megrendelések egyetlen adatfolyamon áramlanak, egyetlen szabályrendszerrel.
A kevésbé látványos részek, amelyek számítanak
A visszaigazolások a protokoll felét teszik ki. Az a partner, aki nem kapja meg a CONTRL üzenetét az előírt időablakon belül, azt fogja feltételezni, hogy a megrendelés eltűnt, és felhívja az értékesítési csapatát. Figyelje a visszaigazolási késleltetést ugyanúgy, ahogy az üzemidőt figyeli - ez az a mérőszám, amelyet az ügyfele beszerzési munkatársa a valóságban megtapasztal.
Az EDI nem technikai adósság. Ez infrastruktúra - mint a vasúti nyomtáv. Modernizálással nem lehet megszabadulni tőle; tiszta adaptereket épít, és hagyja, hogy tovább csinálja azt, amit négy évtizede megbízhatóan csinál.