Kui te tarnite suurele jaemüüjale või autotööstuse kontsernile Euroopas, siis te kasutate EDI-t. Mitte sellepärast, et keegi armastaks EDIFACT-i süntaksit, vaid sellepärast, et suurema hankeosakonnaga osapool valib formaadi ning nende formaat standardiseeriti 1988. aastal. Ootamine, et nad pakuksid REST API-t, ei ole strateegia.
Milline näeb tänapäevane EDI-lahendus tegelikult välja
Trikk on käsitleda EDI-t kui transpordidialekti, mitte arhitektuuri. Integratsiooni sees on kõik lihtne, korralikult tüübitud tellimuse/saatelehe/arve objekt; EDIFACT ja X12 eksisteerivad ainult päris servas, tõlkijates, mis on lihtsad, versioonihaldusega ja põhjalikult salvestatud näidisfailidega testitud.
See eraldamine tasub end ära kolmel viisil:
- Uue kauplemispartneri liitumine tähendab uut tõlkijaprofiili - sõnumi versioon, segmentide iseärasused, nende loominguline vaba teksti väljade kasutus - mitte uut äriloogikat.
- Testimine on korratav. Iga kunagi vastu võetud partnerifail on salvestatud testinäidis. Kui tõlkija muutub, käivitame selle kaudu uuesti viie aasta liikluse ja võrdleme väljundit.
- 20 aastat vana ERP ja täiesti uus e-pood näevad sama tellimuse objekti, nii et EDI tellimused ja API tellimused liiguvad läbi ühe andmevoo ühtede reeglite järgi.
Ilma sära, kuid olulised osad
Kinnitused on pool protokollist. Partner, kes ei saa oma CONTRL sõnumit ettenähtud aja jooksul, eeldab, et tellimus kadus, ja helistab teie müügimeeskonnale. Jälgige kinnituste viivitust samamoodi, nagu jälgite töökindlust - see on mõõdik, mida teie kliendi hankespetsialist tegelikult kogeb.
EDI ei ole tehniline võlg. See on infrastruktuur - nagu rööpmelaius. Sellest ei saa moderniseerimise teel lahti; te ehitate puhtad adapterid ja lasete sel jätkata tegemist, mida see on usaldusväärselt teinud juba nelikümmend aastat.