EDI in JTL: Make or Buy? Architektur- und Entscheidungsleitfaden

EDI ist im B2B-Umfeld kein optionales Add-on, sondern integraler Bestandteil der operativen Wertschöpfung. Sobald Unternehmen mit Marktplätzen, Großhändlern, Filialisten oder Industriepartnern arbeiten, wird strukturierter Datenaustausch zur Grundvoraussetzung. Typische Nachrichtentypen wie ORDERS, DESADV oder INVOIC bilden dabei nicht nur Belege ab, sondern sind direkt mit Logistik, Faktura, Buchhaltung und Warenverfügbarkeit verknüpft.

Fehlerhafte oder instabile EDI-Prozesse wirken sich unmittelbar auf Umsatz, Lieferfähigkeit und Kundenbeziehungen aus. Genau deshalb ist die zentrale Frage nicht rein technisch, sondern strategisch:

Standardlösung einkaufen oder Integrationsarchitektur selbst aufbauen?

In einem Kundenprojekt haben wir eine EDI-Integration für JTL auf Basis von Mendelson (AS2) und einer eigenen Java-Middleware umgesetzt. Die ERP-Anbindung erfolgt über die offizielle JTL-API. Diese Entscheidung war sowohl architektonisch als auch wirtschaftlich begründet.

Technische Ausgangslage: JTL und EDI

JTL-Wawi ist ein ERP-System mit klar definierten Geschäftsprozessen für Einkauf, Verkauf, Lager und Versand. EDI hingegen ist keine ERP-Funktion, sondern eine Integrations- und Kommunikationsschicht zwischen Organisationen.

Eine vollständige EDI-Architektur besteht nicht nur aus einem AS2-Server. Sie umfasst mehrere logisch getrennte Ebenen:

• Transportebene: Signierung, Verschlüsselung, Zertifikatsmanagement, MDN-Handling
• Syntaxebene: Parsing von EDIFACT (z. B. ORDERS, DESADV, INVOIC)
• Semantikebene: Validierung, Partner-spezifische Regeln, Pflichtfelder, Referenzprüfungen
• Transformations- und Integrationsschicht: Mapping in das interne Domänenmodell und Übergabe an das ERP

Ergänzend kommen technische Querschnittsthemen hinzu:

• Idempotente Verarbeitung (keine Doppelbuchungen)
• Fehlerklassifizierung und Retry-Strategien
• Monitoring, Logging und Alerting
• Archivierung und Revisionssicherheit

Genau hier entsteht die eigentliche Komplexität, nicht beim AS2-Handshake.

Umgesetzte Architektur

Die Architektur wurde bewusst in klar getrennte Verantwortungsbereiche aufgeteilt.

Mendelson übernimmt ausschließlich die AS2-Kommunikation. Dazu gehören Protokoll-Terminierung, Zertifikatsprüfung, Entschlüsselung eingehender Nachrichten sowie das korrekte Versenden von MDNs. Damit bleibt die Transportschicht klar isoliert und austauschbar.

Nach erfolgreichem Empfang werden die Rohdaten persistent abgelegt, beispielsweise in einem objektbasierten Storage oder Dateisystem. Diese Persistenzebene dient sowohl der Nachvollziehbarkeit als auch der Wiederholbarkeit von Verarbeitungsschritten.

Die eigentliche Business-Logik liegt in einer Java-basierten Middleware. Sie fungiert als zentraler Integrations-Hub. Dort werden EDIFACT-Nachrichten geparst, validiert, in interne Domänenmodelle transformiert und partnerindividuelle Regeln angewendet. Auch Status-Tracking, Fehlerklassifizierung und Retry-Mechanismen sind hier implementiert.

Die Anbindung an JTL erfolgt über die offizielle JTL-API. Dadurch wird sichergestellt, dass sämtliche Transaktionen über dokumentierte und update-sichere Schnittstellen laufen. Direkte Datenbankzugriffe wurden bewusst vermieden, um Upgrade-Fähigkeit und Systemstabilität nicht zu gefährden.

Outbound-Prozesse, etwa das Generieren und Versenden von DESADV oder INVOIC, sind spiegelbildlich aufgebaut. JTL erzeugt den fachlichen Datensatz, die Middleware transformiert in EDIFACT, Mendelson übernimmt Transport und Signierung.

Diese klare Schichtung sorgt für Austauschbarkeit einzelner Komponenten, saubere Verantwortlichkeiten und langfristige Wartbarkeit.

Warum Middleware statt reiner Plattformlösung?

Viele EDI-Plattformen bündeln Transport, Mapping und Partnerlogik innerhalb eines proprietären Systems. Das kann für einfache Szenarien effizient sein, führt jedoch bei steigender Komplexität häufig zu Abhängigkeiten und eingeschränkter Testbarkeit.

Durch eine dedizierte Middleware wird die Integrationslogik Teil der eigentlichen Systemarchitektur. Der Code ist versionierbar, testbar und CI/CD-fähig. Mapping-Regeln können in automatisierten Tests abgesichert werden. Partnerindividuelle Sonderfälle lassen sich strukturiert modellieren, statt in grafischen Mapping-Editoren schwer nachvollziehbar konfiguriert zu werden.

Ein weiterer Vorteil liegt in der technologischen Freiheit. Business-Logik wird nicht an ein bestimmtes Tool gebunden. Der AS2-Server könnte ausgetauscht werden, ohne dass Mapping und Orchestrierung neu implementiert werden müssen. Ebenso kann die Middleware perspektivisch weitere Schnittstellen bedienen, etwa REST, SFTP oder API-basierte Partner.

Die Integrationsschicht wird damit strategisches Asset statt Tool-Konfiguration.

Integration über die JTL-API

Die offizielle JTL-API bietet stabile, dokumentierte Endpunkte mit klarer Transaktionslogik und Validierungsmechanismen. Gerade im B2B-Umfeld, in dem Datenkonsistenz entscheidend ist, sind saubere Fehlercodes und nachvollziehbare Validierungsregeln essenziell.

Durch die ausschließliche Nutzung der API bleibt die Lösung kompatibel zu zukünftigen JTL-Versionen. Direkte Datenbankmanipulationen oder inoffizielle Hooks wurden bewusst ausgeschlossen, da sie langfristig Wartungsrisiken erzeugen.

Für Skalierungsszenarien ist diese API-Konformität entscheidend. Neue Partner oder zusätzliche Nachrichtentypen können integriert werden, ohne die Kernprozesse von JTL zu destabilisieren.

Wirtschaftliche Betrachtung: Fixkosten vs. Plattformmodell

EDI-Plattformen arbeiten typischerweise mit einem Mix aus monatlichen Lizenzkosten, transaktionsabhängigen Gebühren und partnerbezogenen Zusatzkosten. Bei wachsender Partnerzahl oder steigendem Nachrichtenvolumen steigen diese Kosten proportional.

Eine eigene Middleware verschiebt das Kostenmodell in Richtung Investition statt laufender Gebühren. Es entstehen initiale Implementierungskosten sowie laufende Infrastruktur- und Wartungskosten. Transaktionsabhängige Plattformgebühren entfallen jedoch vollständig.

Ab einer gewissen Anzahl an Partnern oder bei hohem Nachrichtenvolumen kann diese Struktur signifikante Kostenvorteile bieten. Gleichzeitig entsteht Know-how im eigenen Unternehmen, das nicht an einen Anbieter gebunden ist.

Natürlich trägt man im Gegenzug mehr technische Verantwortung. Monitoring, Zertifikatsmanagement und Betrieb müssen professionell organisiert sein. Für Unternehmen mit strategischer B2B-Ausrichtung ist das jedoch oft sinnvoller als langfristige Plattformabhängigkeit.

Make oder Buy: Entscheidungskriterien

Eine Standardlösung ist typischerweise sinnvoll, wenn:

• nur wenige Partner angebunden werden müssen
• das Transaktionsvolumen gering ist
• ausschließlich standardisierte EDIFACT-Profile genutzt werden
• eine schnelle Implementierung wichtiger ist als langfristige Kontrolle

Eine eigene Architektur wird interessant, wenn:

• mehrere Partner mit individuellen Anforderungen integriert werden müssen
• das Nachrichtenvolumen signifikant ist
• EDI strategischer Bestandteil der Geschäftsprozesse ist
• technologische Kontrolle und Testbarkeit gewünscht sind
• langfristige Kostenoptimierung Priorität hat

Die Entscheidung sollte nicht isoliert auf Basis der Implementierungskosten getroffen werden, sondern unter Berücksichtigung von Skalierung, Abhängigkeiten und strategischer Ausrichtung.

Fazit

AS2 ist heute Standard und kein strategisches Differenzierungsmerkmal mehr.

Die eigentliche Entscheidung betrifft die Architektur der Integrationsschicht, die Kontrolle über Mapping und Partnerlogik, die Skalierbarkeit der Lösung und die langfristige Kostenstruktur.

EDI in JTL ist keine Plugin-Frage, sondern eine bewusste Architektur- und Wirtschaftlichkeitsentscheidung mit direktem Einfluss auf Stabilität, Skalierung und Marge.