Dacă furnizați un mare retailer sau un grup din industria auto din Europa, folosiți EDI. Nu pentru că cineva ar iubi sintaxa EDIFACT, ci pentru că partea cu departamentul de achiziții mai mare alege formatul, iar formatul lor a fost standardizat în 1988. A aștepta ca ei să ofere un API REST nu este o strategie.
Cum arată, de fapt, o configurație EDI modernă
Trucul este să tratați EDI ca pe un dialect de transport, nu ca pe o arhitectură. În interiorul integrării, totul este un obiect simplu și bine tipizat de comandă/expediere/factură; EDIFACT și X12 există doar la marginea extremă, în traducători simpli, versionați și testați intens pe fișiere de exemplu înregistrate.
Această separare dă roade în trei moduri:
- Integrarea unui nou partener comercial înseamnă un nou profil de traducător - versiunea mesajului, particularitățile segmentelor, folosirea lor creativă a câmpurilor de text liber - nu o nouă logică de business.
- Testarea poate fi reluată. Fiecare fișier primit vreodată de la un partener devine un caz de test înregistrat. Când un traducător se modifică, rulăm din nou prin el cinci ani de trafic și comparăm rezultatul.
- ERP-ul vechi de 20 de ani și magazinul online complet nou văd același obiect de comandă, astfel încât comenzile EDI și comenzile prin API trec printr-un singur pipeline, cu un singur set de reguli.
Părțile lipsite de glamour care contează
Confirmările reprezintă jumătate din protocol. Un partener care nu primește mesajul CONTRL în intervalul său va presupune că respectiva comandă a dispărut și va suna echipa dvs. de vânzări. Monitorizați latența confirmărilor la fel cum monitorizați uptime-ul - este metrica pe care referentul de achiziții al clientului dvs. chiar o resimte.
EDI nu este datorie tehnică. Este infrastructură - precum ecartamentul căii ferate. Nu scăpați de el prin modernizare; construiți adaptoare curate și îl lăsați să continue să facă ceea ce a făcut de încredere timp de patru decenii.