Als u een grote retailer of automotive-groep in Europa beleveren, doet u aan EDI. Niet omdat iemand dol is op EDIFACT-syntax, maar omdat de partij met de grotere inkoopafdeling het formaat kiest, en hun formaat werd in 1988 gestandaardiseerd. Wachten tot zij een REST API aanbieden is geen strategie.
Hoe een moderne EDI-opzet er in de praktijk uitziet
De truc is om EDI te behandelen als een transportdialect, niet als een architectuur. Binnen de integratie is alles een eenvoudig, sterk getypeerd order-/verzend-/factuurobject; EDIFACT en X12 bestaan alleen helemaal aan de rand, in vertalers die saai, geversioneerd en uitvoerig getest zijn met opgenomen voorbeeldbestanden.
Die scheiding betaalt zich op drie manieren uit:
- Het aan boord nemen van een nieuwe handelspartner betekent een nieuw vertalerprofiel - berichtversie, segmenteigenaardigheden, hun creatieve gebruik van vrije-tekstvelden - niet nieuwe bedrijfslogica.
- Testen is herhaalbaar. Elk ooit ontvangen partnerbestand dient als opgenomen testvoorbeeld. Wanneer een vertaler wijzigt, spelen we er vijf jaar aan verkeer opnieuw doorheen en vergelijken we de output.
- Het 20 jaar oude ERP en de gloednieuwe webshop zien hetzelfde orderobject, zodat EDI-orders en API-orders via één pijplijn stromen met één set regels.
De onopvallende onderdelen die er wél toe doen
Bevestigingen zijn de helft van het protocol. Een partner die zijn CONTRL-bericht niet binnen het venster ontvangt, gaat ervan uit dat de order is verdwenen en belt uw salesteam. Monitor de latentie van bevestigingen zoals u uptime monitort - het is de metric die de inkoopmedewerker van uw klant daadwerkelijk ervaart.
EDI is geen technische schuld. Het is infrastructuur - zoals spoorwijdte. U raakt het niet kwijt door te moderniseren; u bouwt schone adapters en laat het doen wat het al veertig jaar betrouwbaar doet.