skip to Main Content

Digitale Post über vertraglich abgesicherte Verbindungswege

x400-telekom-screenshot

BusinessMail X.400 – das Geschäftsdatennetzwerk der Telekom Deutschland

Das X.400-Protokoll – erste Wahl bei hochsensiblen Anforderungen im elektronischen Datenaustausch

Das X.400-Protokoll ist neben der FTP-Kommunikation eng mit dem Beginn professioneller EDI-Belegaustausche verbunden. Im Hinblick auf Sicherheitsaspekte steht bei den X.400-basierten Belegflüssen neben dem reinen Datentransport v.a. der Austausch sensibler geschäftsprozessrelevanter, maschinenlesbarer EDI-Daten im Fokus. Zur Gewährleistung der Systemintegrität bildet das X.400-Protokoll ein geschlossenes Netzwerk mit kontrollierten Zugangspunkten. Jeder Nutzer ist quasi namentlich bekannt (eindeutige X.400-Adresse) und interagiert nur mit Hilfe personalisierter X.400-Accounts (X.400-Postfächer) innerhalb der X.400-Netzwerke der jeweiligen Betreiber.

Die hohen technischen Anforderungen für Einrichtung und Betrieb eines X.400-Netzwerks führen in der Praxis dazu, dass weltweit nur wenige X.400-Anbieter existieren. Man unterscheidet dabei i.d.R. zwischen nationalen (z.B. X.400-Netzwerk der Deutschen Telekom, Editel in Österreich etc.) und internationalen (OpenText, früher GXS usw.) X.400-Providern. Zwischen den X.400-Netzwerken der Provider existieren X.400-Schnittstellen, die den EDI-Datentransport auch zwischen den unterschiedlichen X.400-Netzwerken und Providern ermöglichen. Eine systemspezifische Besonderheit der X.400-Architektur prädestiniert dabei das X.400-Protokoll für den Einsatz bei hochsensiblen EDI-Anbindungen.

grafik-x400

EDI-Übertragung mit X.400 und proprietärem FileWork-Client

X.400-Austausch mit proprietärem Filework-Client

Jeder X.400 Teilnehmer kann mit einem Zugriff auf sein persönliches X.400-Zugangskonto EDI-Daten für den Versand in dieses X.400-Postfach einstellen, sowie empfangene Nachrichten abrufen. Die Synchronisation zwischen den einzelnen X.400-Zugangskonten geschieht immer über das X.400-Netzwerk des jeweiligen X.400-Betreibers und kann dabei manuell oder automatisiert initiiert werden. Somit existiert keine Möglichkeit für einen direkten Zugriff auf die X.400-Postfächer Dritter. Wegen des zusätzlichen Nutzens (Value) wird in Zusammenhang mit X.400-Netzwerken auch von einem X.400-VAN (Value Added Network) gesprochen. Dies ist einer der wesentlichen Gründe, aus denen eine EDI-Anbindung via X.400 für einen langen Zeitraum das probate Mittel der Wahl für den Transport von Geschäftsprozess-orientierten Datenaustauschen zwischen einzelnen EDI-Systemen war.

Nachteil: hohe Kosten – kein zuverlässiges Monitoring

Nachteil eines solchen X.400-Transportszenarios sind die zusätzlichen Kosten, die für die Nutzung des X.400-Netzwerks an den jeweiligen X.400-Anbieter/-Provider zu entrichten sind. Provider, Abrechnungsmodell sowie diverse andere Faktoren bestimmen die Kostenstruktur X.400-basierter Interaktion zwischen EDI-Teilnehmern beim elektronischen Belegaustausch (z.B. die Häufigkeit des Zugriffs auf das persönliche X.400-Zugangskonto, die Frequenz der Synchronisation mit den Postfächern der EDI-Partner, Dateigröße, Anzahl der Positionen oder Bytes der einzelnen EDI-Nachrichten).

Das X.400-Netzwerk der Deutschen Telekom, bzw. TCom, ist innerhalb Deutschlands mit Abstand der am häufigsten genutzte X.400-Provider (BusinessMail X.400). Der Zugriff auf das persönliche X.400-Postfach innerhalb des Telekom-Netzwerks war lange Zeit lediglich durch den proprietären X.400-Client FileWork möglich. Für den EDI-Datenaustausch werden dabei EDI-Nachrichten an diesen Client übergeben, bzw. aus diesem entnommen. Der eigentliche Synchronisationsprozess mit den zentralen Servern der Telekom wird dabei auf technischer Ebene durch den i.d.R. vor Ort installierten X.400-Client übernommen.

Diese Vorgehensweise hat erhebliche Nachteile hinsichtlich eines holistischen EDI-Monitorings. Aufgrund technischer Restriktionen kann jeweils nur die Übergabe bzw. Übernahme von EDI-Nachrichten mit dem X.400-Client nachverfolgt werden. FileWork verfügt lediglich über ein rudimentäres Script Interface, das sich als fehleranfällig gezeigt hat und daher wenig brauchbar ist, um zu erfassen, ob die EDI-Daten korrekt an die X.400-Server der Telekom übergeben wurden.

grafik-x400-gateway

Elektronischer Datenaustausch über BusinessMail X.400 mit X.400 MessageGateway

X.400 Gateway der Telekom – BusinessMail X.400

Seit einiger Zeit bietet die Telekom eine neue Technologie namens X.400 MessageGateway an, die die bestehenden Nachteile hinsichtlich eines aussagekräftigen EDI-Monitorings kompensiert.

Auf technischer Ebene wird dabei für den Datenabgleich zum Austausch von EDI-Belegen eine sFTP-Client-Server-Kopplung mit den zentralen X.400-Servern der Telekom eingerichtet. Der Softzoll X.400-MessageGateClient bildet in diesem Szenario die technische Kernkomponente der X.400-Konnektivität: oberhalb der bekannten sFTP-Protokollfunktionalität wurde ein Überbau realisiert, mit dessen Hilfe der Client die verschiedenen X.400-Status verarbeiten und protokollieren kann. Auf dieser Basis kann nun erstmalig auch der gesicherte Übergabeprozess von EDI-Daten mit den Servern der Telekom professionell geloggt und nachverfolgt werden, was ein wichtiger Baustein des globalen Monitorings über alle Varianten des EDI-Datentransports ist. Das eingangs erwähnte X.400-Zugangsprogramm FileWork kennt zwar verschiedene Statusmeldungen für die einzelnen Abschnitte des X.400-Austauschprozesses, das Auslesen ist jedoch nur über ein proprietäres Script Interface möglich, das wegen häufiger Störungen in der Praxis als wenig integrationsfreundlich gilt (siehe oben). Mit der neuen Technologie des X.400-MessageGateways ist durch die Verwendung der robusten und global häufig eingesetzten sFTP-Technologie die Auswertung der relevanten sFTP-Übertragungsstatus einfacher, weniger fehleranfällig und erheblich performanter.

Store-and-Forward-Netzwerk X.400

In allen technischen X.400-Szenarien entnimmt der X.400-Provider also immer lediglich die im X.400-Postfach für den Versand gespeicherten EDI-Nachrichten und leitet diese an das Empfänger-Postfach weiter. Aus diesem Grund werden X.400-Mailsysteme oft auch als Store-and-Forward-Netzwerke bezeichnet. Dieses Charakteristikum macht X.400 u.a. für den Einsatz in EDI-Szenarien geeignet, in denen eine große Anzahl an Zulieferern auf mehrere EDI-Prozessebenen integriert werden muss. Solche Konstellationen finden sich häufig im Einzelhandelssegment, wo eine 4-stellige Anzahl von Zulieferern keine Seltenheit darstellt. Unter den zu implementierenden Teilprozessen stehen oftmals DESADV (Liefermeldung) und INVOIC (Rechnung) im Fokus der Aufmerksamkeit, da diese ein erhöhtes Anforderungspotenzial (Datenqualität und –umfang) haben.

Aus Sicht eines Handelskonzerns spielt der ob seiner reduzierten semantischen Komplexität unterschätzte ORDERS (Bestellausgang) -Prozess eine tragende Rolle und stellt aus technischer Sicht eine Herausforderung dar. Das zugrunde liegende Geschäftsmodell des Warenumschlages (just-in-time) ist auf die stetige Nachlieferung von Handelsprodukten angewiesen; der ausgehende Bestelldatenstrom ist essenziell für den Erfolg des Geschäftsmodells. Diese Anforderungen sind mit dem Einsatz der X.400-Technologie wesentlich zu vereinfachen.

Wer trägt die Verantwortung?

Durch die Besonderheiten des X.400-Szenarios ist der Bestellprozess mit dem Einstellen der ORDERS EDI-Nachrichten in das X.400-Postfach des Absenders beendet und erfolgreich abgeschlossen. Die Verantwortung für den Transport der EDI-Nachrichten sowie das Einstellen in das X.400-Zugangskonto des Empfängers trägt ab diesem Zeitpunkt der X.400-Provider. Mit Empfang der EDI-Bestelldaten im X.400-Postfach des Empfängers wechselt die Verantwortung für den Bestellprozess in den Aufgabenbereich des Lieferanten, der die weitere ordnungsgemäße Verarbeitung der eingegangenen EDI-Bestelldaten sicherstellen muss.

Für den Versender endet die Fürsorgepflicht mit der Übergabe der EDI-Bestelldaten an den eigenen X.400 Account – eine wichtige Erleichterung! Zudem dient der X.400-Account des Lieferanten als Zwischenspeicher für die EDI-ORDERS, bis diese vom Zulieferer abgerufen werden. Diese Funktionalität bieten Punkt-zu-Punkt-Verbindungen auf Basis von Protokollen wie z.B. AS2 nicht; bei einer Störung der Internetverbindung auf Lieferantenseite ist eine Übergabe der EDI-Bestelldaten nicht realisierbar, die Zuständigkeit aber verbleibt beim Absender und führt zu Verzögerungen und damit zu zusätzlichen Aufwänden im Beschaffungsprozess.

Back To Top