Trex Pi
Wer einen großen Einzelhändler oder Automobilkonzern in Europa beliefert, macht EDI. Nicht weil irgendjemand die EDIFACT-Syntax liebt, sondern weil die Partei mit der größeren Einkaufsabteilung das Format bestimmt, und ihr Format wurde 1988 standardisiert. Darauf zu warten, dass sie eine REST-API anbieten, ist keine Strategie.
Wie ein moderner EDI-Aufbau tatsächlich aussieht
Der Trick besteht darin, EDI als Transportdialekt zu behandeln, nicht als Architektur. Innerhalb der Integration ist alles ein einfaches, sauber typisiertes Order-/Despatch-/Invoice-Objekt; EDIFACT und X12 existieren nur ganz am Rand, in Übersetzern, die bewusst langweilig, versioniert und durch umfangreiche Tests mit aufgezeichneten Beispieldateien abgesichert sind.
Diese Trennung zahlt sich auf drei Arten aus:
- Das Onboarding eines neuen Handelspartners bedeutet ein neues Übersetzerprofil - Nachrichtenversion, Segment-Eigenheiten, seine kreative Nutzung von Freitextfeldern - nicht neue Fachlogik.
- Tests sind wiederholbar. Jede jemals empfangene Partnerdatei dient als aufgezeichnetes Testbeispiel. Ändert sich ein Übersetzer, spielen wir fünf Jahre Verkehr erneut durch und vergleichen die Ausgabe.
- Das 20 Jahre alte ERP und der brandneue Webshop sehen dasselbe Order-Objekt, sodass EDI-Bestellungen und API-Bestellungen durch eine einzige Pipeline mit einem einzigen Regelwerk laufen.
Die unglamourösen Teile, auf die es ankommt
Bestätigungen sind die halbe Miete des Protokolls. Ein Partner, der seine CONTRL-Nachricht nicht innerhalb seines Zeitfensters erhält, geht davon aus, dass die Bestellung verschwunden ist, und ruft Ihr Vertriebsteam an. Überwachen Sie die Bestätigungslatenz genauso wie die Verfügbarkeit - es ist die Kennzahl, die der Einkaufssachbearbeiter Ihres Kunden tatsächlich zu spüren bekommt.
EDI ist keine technische Schuld. Es ist Infrastruktur - wie die Spurweite von Schienen. Man wird es nicht durch Modernisierung los; man baut saubere Adapter und lässt es weiter tun, was es seit vier Jahrzehnten zuverlässig tut.