Če dobavljate velikemu trgovcu na drobno ali avtomobilski skupini v Evropi, uporabljate EDI. Ne zato, ker bi kdo obožaval sintakso EDIFACT, temveč zato, ker format izbere stran z večjim nabavnim oddelkom, njihov format pa je bil standardiziran leta 1988. Čakanje, da vam ponudijo REST API, ni strategija.
Kako dejansko izgleda sodobna postavitev EDI
Skrivnost je v tem, da EDI obravnavate kot transportno narečje, ne kot arhitekturo. Znotraj integracije je vse preprost, dobro tipiziran objekt naročila/odpreme/računa; EDIFACT in X12 obstajata le na skrajnem robu, v prevajalnikih, ki so dolgočasni, verzionirani in temeljito testirani s testnimi podatki.
Ta ločitev se izplača na tri načine:
- Vključitev novega poslovnega partnerja pomeni nov profil prevajalnika - različico sporočila, posebnosti segmentov, njihovo kreativno uporabo polj s prostim besedilom - ne nove poslovne logike.
- Testiranje je mogoče ponoviti. Vsaka kadarkoli prejeta partnerska datoteka je testni primer. Ko se prevajalnik spremeni, skozenj znova poženemo pet let prometa in primerjamo rezultat.
- 20 let star ERP in povsem nova spletna trgovina vidita isti objekt naročila, zato naročila EDI in naročila API tečejo skozi en sam cevovod z enim samim naborom pravil.
Nezanimivi deli, ki so pomembni
Potrditve so polovica protokola. Partner, ki v svojem časovnem oknu ne prejme sporočila CONTRL, bo predpostavil, da je naročilo izginilo, in poklical vašo prodajno ekipo. Zakasnitev potrditev nadzorujte enako, kot nadzorujete razpoložljivost - to je metrika, ki jo dejansko občuti nabavni referent vaše stranke.
EDI ni tehnični dolg. Je infrastruktura - kot tirna širina. Z modernizacijo se ga ne znebite; zgradite čiste adapterje in mu pustite, da še naprej zanesljivo počne to, kar počne že štiri desetletja.