Die folgende Übersicht beinhaltet aktuell noch nicht den Kryptografie-Workflow.
Standardworkflow
Die folgende Darstellung skizziert die Ein- und Ausgänge der Nachrichtenkommunikation. Zu unterscheiden sind die REST, SOAP und AMQP-Schnittstellen. Die mit den AMQP gekennzeichneten Pfeile stellen die Messages Queues dar, jeweils ihrem Namen und der Pfeilrichtung vom Producer zum Consumer.
Im Outbound Workflow empfängt der AS4 Outbound Market Message Service über seine REST-Schnittstelle eine Edifact-Nachricht, welche über die as4.outbound.default Queue zum AS4 Outbound Sender gelangt. Dort wird sie in eine AS4-Message transformiert und über SOAP verschickt. Zusätzlich wird diese AS4-Nachricht über die as4.messages.default als Business-Message an den AS4 Message Service zur Speicherung weitergeleitet. Nach dem Versenden der AS4-Nachricht schickt der Empfänger eine Bestätigung. Diese wird vom AS4 Inbound Endpoint entgegengenommen und über die Queue as4.receipt.parse.default an den AS4 Receipt Service weitergeleitet, um alle notwendigen Informationen (z.B. im Falle eines negativen Receipts den ErrorCode) auszulesen. Die Bestätigung des Empfängers wird abschließend über die as4.receipt.default Queue an den AS4 Message Service zu Speicherung übergeben.
Im Inbound Workflow empfängt der AS4 Inbound Endpoint über seine SOAP-Schnittstelle eine AS4-Nachricht. Diese AS4-Nachricht wird im Falle einer positiven Überprüfung einmal als Business-Message über die as4.messages.default Queue an den AS4 Message Service und als Edifact-Nachricht über die as4.inbound.default Queue an den AS4 Inbound Market Message Service versendet. Gleichzeitig fragt der AS4 Inbound Endpoint beim AS4 Receipt Service über REST die Erstellung einer Bestätigung für den Marktpartner an. Die Bestätigung wird vom AS4 Receipt Service erstellt und dem AS4 Inbound Endpoint zum Versenden an den Marktpartner zurückgegeben. Zusätzlich wird die Bestätigung über die Queue as4.receipt.default an den AS4 Message Service gesendet.
Der Name einer Queue z.B. as4.outbound.default wird im AS4 Kontext über den Exchange as4.outbound und der Gruppenbezeichnung default gebildet.
Etwas außerhalb des AS4 Systems befindet sich die optionale Anbindung an die B2B. Beginnend am Outbound Workflow versendet die B2B die Edifact Message an den AS4 Outbound Market Message Service, endet die Verbindung mit dem Inbound Workflow mit der Edifact Message aus dem AS4 Inbound Market Message Service zu dem B2B Message Service. Der B2B Message Service ist eine spezielle Entwicklung um die Edifact Messages zu persistieren und auf der B2B suchbar zu machen.
Routingflow
Routing ermöglicht das Filtern von Eingängen in den Queues. Es kann ergänzend angewendet werden, wenn die Nachrichten zur besseren Übersichtlichkeit oder zur Performanceerhöhung auf mehrere Queues verteilt werden sollen.
Im unteren Beispielbild erhält der AS4 Outbound Market Message Service vier Edifact-Nachrichten, die für verschiedene Empfänger vorgesehen sind. Für das Routing wurde für die Eigenschaft des Empfängers (Feld ToPartyId) ein Filter konfiguriert, der die Werte 9900051000004, 9900051000005 und 9900051000006 (Exchanges) enthält. Der Wert des vierten Empfängers (9900051000007) ist nicht enthalten. Die Nachrichten für die ersten drei Empfänger werden entsprechend der Konfiguration auf die Queues as4.outbound.990005100000x verteilt, während die Edifact-Nachricht an den Empfänger 9900051000007 auf die Default Queue geroutet wird. Die Nachrichten an die 3 definierten Empfänger werden auch von jeweils einem dezidierten AS4 Outbound Sender empfangen.
Nachfolgend filtern bzw. routen die einzelnen Instanzen des AS4 Outbound Sender zur Weitergabe an den AS4 Message Service nach dem Status, erkennbar wiederum am Namen der Queues as4.messages.finished_succesful bzw. as4.messages.no_receipt.
Da sich der Name der Queue aus der Exchange Bezeichnung und der Gruppe
Bei der Konfiguration des Routing (Routingwerte und HeaderValues) muss zwingend die Groß- und Kleinschreibung beachtet werden, bsp. headerValues=GAS; GAS → as4.outbound.GAS; gas → as4.outbound.default.
Fehlerbehandlung
Jede Queue besitzt eine Dead-Letter-Queue, z.B. as4.outbound.default.dlq, in der die fehlgeschlagenen Nachrichten gesammelt werden. Diese Nachrichten müssen manuell überwacht und können bei Bedarf neu gestartet werden. Dies geschieht über die Weboberfläche des Message Brokers.
Eine weitere Differenzierung ist die Queue as4.outbound.neg.receipt, diese enthält versendete Nachrichten, die eine negative Bestätigung erhalten haben und daher nicht erneut versendet werden können und sollen.
Auch diese Queue as4.inbound.error.default bildet besondere Fälle ab. In dieser Queue sind Nachrichten enthalten, die nicht verifiziert werden konnten, oder für die keine Bestätigung erstellt oder verschickt werden konnte. Die Nachrichten dieser Queue können nicht neu gestartet werden.
Die Nachrichten in der DLQ (Dead Letter Queue), in nebenstehenden Beispiel in der Queue as4.outbound.default.dlq, lassen sich erneut versenden. Im hiesigen Beispiel handelt es sich um den Message Broker RabbitMQ. Dieser ermöglicht leider keine Elementauswahl, sondern erlaubt nur das erneute Starten aller enthaltenen Nachrichten.
Zum Versenden muss das Ziel angegeben werden. Dieses ist im Beispiel die as4.outbound.default Queue.
