Wir wollen wissen, was mit unseren Nachrichten passiert…
Was wir im privaten Bereich an Diensten wie WhatsApp schätzen, ist aus dem EDI-Bereich schon längst nicht mehr wegzudenken — die gesicherte und verlässliche Zustellung von Nachrichten. Denn während der fehlgeschlagene Versand einer SMS — die beispielsweise unsere Verabredung zum Abendessen über eine Verspätung informieren soll — noch relativ glimpflich ausgehen kann, ist die Nachvollziehbarkeit und gesicherte Zustellung von EDI-Nachrichten essentiell. Verlorengegangene INVOIC-Nachrichten oder ZUGFeRD-Rechnungen können schön äußerst ärgerlich sein. Nicht auszudenken allerdings wenn wir uns über den Verbleib von Bewegungsdaten wie z.B. ORDERS (Bestellungen) nicht sicher sein können: was am Vormittag bestellt wird, muss in manchen Branchen und Lieferketten bereits am Nachmittag ausgeliefert werden. Werden DESADV (Lieferscheine) nicht erhalten, steht womöglich niemand zum Abladen am Cross-Docking Lager bereit, wenn der LKW mit der Lieferung eintrifft.
Damit derartige Szenarien vermieden werden können und wir im Falle von Problemen bei der Zustellung von EDI-Nachrichten entsprechend gegensteuern können, wird der Erhalt (und teilweise auch die Verarbeitung) von EDI-Nachrichten üblicherweise bestätigt. Denn ohne Bestätigungen kann auch kein durchgehendes Monitoring im EDI ermöglicht werden.
Empfangsbestätigung im EDI-Bereich
Dabei können wir generell nach zwei verschiedenen Ebenen von Bestätigungen (engl.: Acknowledgments) unterscheiden: (i) Jene auf Protokollebene und (ii) jene auf Nachrichten- oder auch Prozessebene.
Monitoring auf Protokollebene
Bestätigungen auf dieser Ebene sind Bestandteil des verwendeten Standards/Protokolls zum Nachrichtenaustausch. Dabei erfolgt die Bestätigung zumeist direkt von der jeweiligen Messaging-Komponente des Empfängers, sobald die Nachricht technisch einwandfrei empfangen wurde und noch bevor sie ins Warenwirtschaftssystem importiert wurde. Im EDI-Bereich trifft man vor allem auf zwei Protokolle, die sich wegen ihrer Sicherheit und ihrer Nachvollziehbarkeit bislang etabliert haben.
AS2
AS2 (Applicability Statement 2) ist ein Protokoll zur sicheren und zuverlässigen Übertragung von Nachrichten zwischen zwei Partnern (Punkt-zu-Punkt Prinzip) auf Basis des HTTP-Protokolls. Erhaltene Nachrichten werden standardmäßig durch einen MDN (Message Disposition Notification) quittiert. Der MDN kann dabei entweder synchron oder asynchron vom Sender angefordert werden.
Im ersten Fall wird der MDN direkt nach der Übertragung der Nachricht vom Sender zum Empfänger — und zwar im Rahmen der gleichen HTTP-Verbindung — vom Empfänger der Nachricht an den Sender übermittelt.
Im zweiten Fall wird der MDN in einer separaten HTTP-Verbindung an den Sender der eigentlichen Nachricht übertragen. Synchrone MDNs sind heute oftmals beliebter, da die Antwort „schneller“ erhalten wird. Bei höheren Volumina bzw. großen Nachrichten empfiehlt sich jedenfalls die Verwendung von asynchronen MDNs. Konnte die Nachricht nicht einwandfrei empfangen werden (z.B. weil sie aufgrund fehlerhaft konfigurierter Zertifikate nicht entschlüsselt werden konnte), wird ein „negativer MDN“ retourniert.
X.400
X.400 (siehe auch unseren früheren Beitrag) ist ein auf dem Mailbox-Prinzip basierendes Protokoll, wobei die Kommunikation über dedizierte Netzwerke getrennt vom Internet erfolgt. X.400 kennt prinzipiell zwei Typen von Bestätigungen: Delivery Notifications (DN) und Receipt Notifications (RN).
Delivery Notifications werden vom Mailserver des Empfängers generiert, wenn dieser die Nachricht an die Mailbox des Empfängers zustellt. Das negative Pendant zur DN ist die sogenannte Non-delivery Notification (NDN) und wird im Fehlerfall an den Sender übermittelt.
Receipt Notifications können von der Clientsoftware des Empfängers generiert werden – in der Praxis wird die RN in der automatisierten Übertragung kaum angefordert bzw. unterstützt, sodass üblicherweise mit dem Erhalt einer DN davon ausgegangen wird, dass der Empfänger die Nachricht erhalten hat (und auch verarbeiten kann). Das negative Pendant zur RN ist die Non-receipt notification (NRN).
Interessanterweise kennt auch unser bekanntes Internet Email (d.h. das darunterliegende SMTP-Protokoll), diese beiden Typen von Bestätigungen. Der Sender eines Emails kann vom Mailserver des Empfängers eine sogenannte Delivery Status Notification (DSN) anfordern — was das Pendant zur Delivery Notification (DN) bei X.400 ist. Im Fehlerfall werden in der Praxis automatisiert negative DSNs bei Zustellungsproblemen vom Mailserver an den User zurückgemeldet (z.B. der Empfänger ist unbekannt).
Ebenso kann der Sender vom Empfänger eine Message Disposition Notification (MDN) anfordern, die vom Empfänger über das E-Mail Programm auf Nachfrage versandt werden kann. In der Praxis haben sich Lesebestätigungen bei Internet E-Mail kaum durchgesetzt bzw. werden Anforderungen für Lesebestätigungen oft ignoriert.
Monitoring auf Nachrichtenebene
Bestätigungen auf Nachrichtenebene sind „reguläre“ Geschäftsdokumente, die — aufgrund eines definierten Prozesses — bei Erhalt des eigentlichen Geschäftsdokumentes vom Empfänger retourniert werden. Ein gängiges Beispiel in der EDIFACT-Welt ist, dass eingehende ORDERS-Nachrichten mit einer CONTRL-Nachricht beantwortet werden. Die CONTRL-Nachricht bestätigt dabei, dass der EDIFACT-Interchange importiert und syntaktisch korrekt verarbeitet werden konnte. Neben der CONTRL-Nachricht, die eigentlich auf die syntaktische Verarbeitung fokussiert, kann mittels APERAK-Nachrichten der Status der fachlichen Verarbeitung einer eingehenden Nachricht rückgemeldet werden und einzelne Positionen der eingehenden Nachrichten akzeptiert bzw. abgelehnt werden.
Je nach Branche und lokaler Gegebenheit variiert die Verwendung von Bestätigungen auf Nachrichtenebene. Zumeist verlässt man sich auf die Bestätigungen auf Protokollebene — d.h. konkret auf X.400 Delivery Notifications (DN) oder AS2 MDNs. In den Niederlanden ist es jedoch beispielsweise auch üblich, dass Bestellprozesse eine ORDERS-Nachricht mittels APERAK-Nachricht bestätigen. Auch in Deutschland beginnen einige Unternehmen im Lebensmittelhandel damit, sich den Nachrichtenerhalt mittels CONTRL-Nachrichten bestätigen zu lassen. Besonders detailliert ist die Verwendung von CONTRL und APERAK-Nachrichten für die Energiebranche in Deutschland definiert. Hier sehen Austauschbeziehungen (z.B. bei Wechsel des Stromlieferanten) einen zweistufigen Bestätigungsprozess vor, indem nach erfolgter Syntaxprüfung zuerst eine CONTRL-Nachricht und nach erfolgter fachlicher Prüfung eine APERAK-Nachricht retourniert wird.
Monitoring und Nachvollziehbarkeit bei ecosio
Die Nachvollziehbarkeit der Austauschbeziehungen hat bei ecosio höchste Priorität. ecosio aggregiert die unterschiedlichen Bestätigungstypen auf Protokoll- sowie Nachrichtenebene zu einem einheitlichen Schema und ermöglicht die komplette Nachvollziehbarkeit des Statusverlaufs. Dieses „Ende-zu-Ende“-Monitoring können Benutzer entweder über den komfortablen ecosio.Monitor mittels Web-Browser einsehen oder auch über eine einheitliche und einfache API direkt in die Warenwirtschafts- bzw. Inhousesysteme einbinden.
Für einige ERP-Systeme wie z.B. Mesonic, BMD aber auch SAP existieren bereits vorgefertigte Lösungen. Wir beraten Sie gerne dazu.
SAP ERP und SAP S/4HANA sind die Marken oder eingetragenen Marken der SAP SE oder ihrer verbundenen Unternehmen in Deutschland und mehreren anderen Ländern.
