Jeśli dostarczacie towary dużemu detaliście lub grupie motoryzacyjnej w Europie, korzystacie z EDI. Nie dlatego, że ktokolwiek uwielbia składnię EDIFACT, ale dlatego, że format wybiera strona z większym działem zakupów, a jej format został ustandaryzowany w 1988 roku. Czekanie, aż zaoferują REST API, nie jest strategią.
Jak naprawdę wygląda nowoczesna konfiguracja EDI
Sztuczka polega na traktowaniu EDI jako dialektu transportowego, a nie architektury. Wewnątrz integracji wszystko jest prostym, dobrze otypowanym obiektem zamówienia/wysyłki/faktury; EDIFACT i X12 istnieją wyłącznie na samym brzegu, w translatorach, które są proste, wersjonowane i dokładnie testowane na nagranych plikach przykładowych.
Ten podział opłaca się na trzy sposoby:
- Wdrożenie nowego partnera handlowego oznacza nowy profil translatora - wersję komunikatu, osobliwości segmentów, ich twórcze podejście do pól tekstowych - a nie nową logikę biznesową.
- Testowanie jest powtarzalne. Każdy plik kiedykolwiek otrzymany od partnera staje się przykładem testowym. Gdy translator się zmienia, przepuszczamy przez niego pięć lat ruchu i porównujemy wynik.
- 20-letni ERP i zupełnie nowy sklep internetowy widzą ten sam obiekt zamówienia, więc zamówienia z EDI i z API przepływają przez jeden potok z jednym zestawem reguł.
Mało efektowne elementy, które mają znaczenie
Potwierdzenia to połowa protokołu. Partner, który nie otrzyma swojego komunikatu CONTRL w wyznaczonym oknie czasowym, założy, że zamówienie zniknęło, i zadzwoni do waszego działu sprzedaży. Monitorujcie opóźnienie potwierdzeń tak samo, jak monitorujecie dostępność systemu - to metryka, której faktycznie doświadcza pracownik działu zakupów waszego klienta.
EDI to nie dług techniczny. To infrastruktura - jak rozstaw szyn kolejowych. Nie da się go pozbyć przez modernizację; buduje się czyste adaptery i pozwala mu robić dalej to, co niezawodnie robi od czterech dekad.