Trex Pi
Pokud dodáváte velkému maloobchodníkovi nebo automobilové skupině v Evropě, používáte EDI. Ne proto, že by někdo miloval syntaxi EDIFACT, ale protože formát si vybírá strana s větším nákupním oddělením, a jejich formát byl standardizován v roce 1988. Čekat, až vám nabídnou REST API, není strategie.
Jak vypadá moderní nastavení EDI ve skutečnosti
Trik spočívá v tom, brát EDI jako přepravní dialekt, ne jako architekturu. Uvnitř integrace je vše obyčejný, dobře typovaný objekt objednávky/dodávky/faktury; EDIFACT a X12 existují jen na samém okraji, v překladačích, které jsou jednoduché, verzované a důkladně testované na nahraných vzorových souborech.
Toto oddělení se vyplácí třemi způsoby:
- Onboarding nového obchodního partnera znamená nový profil překladače - verze zprávy, zvláštnosti segmentů, jejich kreativní využití textových polí - ne novou obchodní logiku.
- Testování lze přehrát znovu. Každý soubor, který jsme kdy od partnera přijali, slouží jako testovací vzorek. Když se překladač změní, znovu jím prožene pět let provozu a porovná výstup.
- Dvacet let starý ERP a zbrusu nový e-shop vidí stejný objekt objednávky, takže objednávky z EDI i z API procházejí jednou pipeline s jednou sadou pravidel.
Nevzhledné části, na kterých záleží
Potvrzení tvoří polovinu protokolu. Partner, který neobdrží zprávu CONTRL ve svém časovém okně, bude předpokládat, že objednávka zmizela, a zavolá vašemu obchodnímu týmu. Monitorujte latenci potvrzení stejně jako monitorujete dostupnost - je to metrika, kterou skutečně pociťuje nákupčí vašeho zákazníka.
EDI není technický dluh. Je to infrastruktura - jako rozchod kolejí. Modernizací se ho nezbavíte; postavíte čisté adaptéry a necháte ho dál dělat to, co spolehlivě dělá už čtyři desetiletí.