B2B Message Service

Der B2B Message Service gehört zum B2B System. Er ist nicht Teil des AS4 Systems.

Der B2B Message Service kann asynchron per AMQP an ein AS4 System angeschlossen werden.

• AS4 Outbound: Über die weitere REST Schnittstelle (/messages) kann der Service nach korrektem B2B-Customizing die messageId und attributeId einer von der B2B ausgehenden Edifact empfangen. Diese wird über eine interne Queue weitergeleitet zu einem im selben Service liegendem Consumer, welcher die Edifact aus der Datenbank lädt und diese über den Message Broker an den Translator Service weiterleitet. Nachdem das AS4-System die Nachricht an den Marktpartner gesendet hat, empfängt die Anwendung über eine weitere AMQP Schnittstelle Informationen über AS4 Nachricht und Quittung vom AS4-System, speichert diese in der B2B- Datenbank und setzt den Verarbeitungsstatus und Bestätigungsstatus entsprechend.
• AS4 Inbound: Der Service empfängt eine Edifact Nachricht inklusive weiterer Informationen über den AS4-Versand und die Quittung per AMQP und übergibt diese an die B2B Queue (Datenbank) zur weiteren Verarbeitung durch die B2B. Basierend auf den weiteren Informationen werden Verarbeitungsstatus, Bestätigungsstatus und Channel gesetzt.
• AS4 Pathswitch Delivery: Der Service kann auch Pathswitch-Informationen vom AS4-System emfpangen und an das B2B-System weiterleiten, damit das b2B-System weiß, ob zwischen zwei Markpartnern eine Kommunikation über AS4 besteht oder nicht.

Der B2B Message Service kann asynchron per AMQP Edifact Nachrichten empfangen & verschicken (unabhängig von AS4).

• Edifact Empfang: Der Service kann eine Edifact per AMQP empfangen und dem B2B Workflow übergeben.
• Edifact Versand: Der Edifact Versand kann über die gleiche Schnittstelle wie AS4 Outbound Workflow erfolgen.

Hardware Anforderungen

Eine Service-Instanz erfordert mindestens 512 MB RAM.

Wir empfehlen 0,4 CPU-Kerne je Instanz.

Logs werden auf die Festplatte geschrieben, entsprechend muss genügend Speicherplatz vorhanden sein.

Abhängigkeiten

Der Service greift auf einen Message-Broker zu, um Nachrichten zu empfangen und zu versenden.

Der Service greift auf eine SQL Datenbank zu, um Nachrichten zu speichern. Hierbei handelt es sich um die gleiche Datenbank, die auch von der B2B genutzt wird. Der Speicherverbrauch einer B2B Datenbank ist hoch. Er skaliert mit dem Nachrichtenaufkommen und hängt von der Archivierungs-/Löschstrategie ab.

Einfache Konfiguration der b2b-message-service.properties

Datenbank Anbindung

Der Microservice benötigt Zugriff auf eine SQL Datenbank. Es ist das gleiche Datenbank-Schema zu konfigurieren, welches auch von der B2B genutzt wird. Die Tabellen müssen bereits zuvor angelegt worden sein. Für weitere Details zum Anlegen der Tabellen sei auf die B2B Dokumentation verwiesen.

#=== JDBC Settings ==='
datasource.url=jdbc:postgresql://localhost:5435/b2bbp
datasource.username=postgres
datasource.password=admin
datasource.schema=b2bbp

Message Broker Anbindung

Außerdem benötigt der Service die Konfiguration des Message-Brokers AMQP:

rabbitmq.host=localhost
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=guest

Konfiguration ausgehend an (externes) AS4 System per AMQP

Es gibt eine interne Queue, welche die messageId und attributeId an den internen Consumer weiterleitet.

b2bMessageExchangeName=b2b.message
b2bMessageGroup=default

Routing ist in diesem Fall nicht nötig. Lediglich der Gruppenname (b2bMessageGroup) kann angepasst werden. Diese Konfiguration wird ebenfalls für den internen Consumer angewendet. Nachdem der Consumer die messageId und die attributeId empfängt, wird die Edifact aus der Datenbank geladen. Danach wird diese an den Message Broker weitergeleitet:

outboundRequestExchangeName=as4.outbound.request
outboundRequestHeaderName=partner
outboundRequestHeaderValues=

Die Variable outboundRequestExchangeName definiert die ausgehende Warteschlange zum Übersetzungsdienst. Wenn Sie die Routing-Option verwenden möchten, bei der Nachrichten basierend auf spezifischen Informationen an verschiedene Warteschlangen gesendet werden, können die Eigenschaften outboundRequestHeaderName und outboundRequestHeaderValues konfiguriert werden. outboundRequestHeaderName kann als Filterkategorie betrachtet werden, während outboundRequestHeaderValues die Werte sind, nach denen die Nachrichten gefiltert werden.

Folgende Parameter werden für outboundRequestHeaderName unterstützt: partner, tenant. Es ist möglich, mehrere Werte durch Kommas getrennt in outboundRequestHeaderValues anzugeben.

Für jeden Wert, der nicht in outboundRequestHeaderValues festgelegt ist, wird automatisch eine Standard-Queue mit der Gruppe default erstellt.

Konfiguration eingehender Edifact per AMQP

Der Exchange Name, sowie die Gruppe, muss konfiguriert werden. Der vollständige Name der Queue setzt sich demnach wie folgt zusammen: {inboundEdifactExchangeName}.{inboundEdifactGroup} . Nachfolgend sind die standardmäßig erforderlichen Konfigurationen aufgeführt.

inboundEdifactExchangeName=as4.inbound
inboundEdifactGroup=delivery
inboundEdifactRoutingKey=http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service
inboundEdifactExchangeType=topic
inboundEdifactChannel=INBOUND_MESSAGES
inboundEdifactErrorChannel=AS4_ERROR

Die Variable inboundEdifactChannel bezieht sich auf den B2B-Eingangskanal. B2B-Tomcat kann die Nachricht verarbeiten und der Benutzer kann die Edifact-Nachricht in der MessageMonitor-Ansicht sehen. Zusätzlich dazu werden AS4-Nachricht, AS4-Nachrichtendaten (zusätzliche Informationen zur Geschäftsnachricht), AS4-Empfangsbestätigung, AS4-Empfangsbestätigungsdaten (zusätzliche Informationen zur Empfangsbestätigung) und AS4-Custom-Daten (alle anderen Informationen, die über AMQP gesendet werden) in der Tabelle b2bbp_data_attribute mit den Attributen AS4_MESSAGE, AS4_MESSAGE_DATA, AS4_RECEIPT, AS4_RECEIPT_DATA & AS4_CUSTOM gespeichert. Bei einem Fehler wird die Nachricht an die DLQ (Dead Letter Queue) gesendet. Zusätzlich dazu wird der BS (Bestätigungsstatus) basierend auf dem Empfangsstatus in der Datenbank gespeichert. Wenn die Empfangsbestätigung nicht zugestellt wurde (Empfangsbestätigung oder zugestellte Empfangsbestätigung ist leer), wird kein BS gespeichert. Wenn der Empfangsstatus leer ist (positive Empfangsbestätigung), wird der BS ‘MSU’ gespeichert. Wenn der Empfangsstatus ausgefüllt ist (negative Empfangsbestätigung), wird der BS ‘MSE’ gespeichert. Wenn die Empfangsbestätigung nicht zugestellt oder negativ ist, wird der B2B-Kanal inboundEdifactErrorChannel verwendet, um die Nachricht in der Datenbank zu speichern. Andernfalls wird der B2B-Kanal inboundEdifactChannel verwendet.

Speicherung des gesamten Queue-Objekts und Weiterleitung über die B2B einen anderen Service

Der B2B Message Service kann das gesamte Input-Json-Objekt in der Datenbank speichern. Es ist standardmäßig deaktiviert und kann über die Eigenschaft saveInputMessage aktiviert werden. Das Objekt wird in dem Attribut “INPUT_MESSAGE” gespeichert.

saveInputMessage=true

Der B2B Message Service kann Queue-Objekte über die B2B weitergeben. Zunächst muss die Eingangsnachricht bzw. das Eingangsobjekt wie im vorherigen Abschnitt in der Datenbank gespeichert werden.

Der REST-Endpunkt /messages ist auch für den Empfang der messageId, attributeId und des Workflows (der Workflow muss json sein) verantwortlich und wird verwendet, um das gesamte eingehenden json-Objekt aus der B2B-Datenbank abzurufen (attributeId=INPUT_MESSAGE). Um dies zu erreichen, gibt es eine interne Queue, welche die messageId, attributeId und den Workflow an den internen Consumer weiterleitet.

b2bMessageExchangeName=b2b.message
b2bMessageGroup=default

Anschließend wird das json-Objekt aus der Datenbank abgerufen und zur weiteren Verarbeitung an eine andere Queue gesendet.

b2bInboundPassThroughExchangeName=b2b.json
b2bInboundPassThroughExchangeType=topic

Um die Nachricht auf der Grundlage der Informationen des json-Objekts weiterzuleiten, können der Routingkey und der Headername konfiguriert werden.

b2bInboundPassThroughHeaderNames=tenant
b2bInboundPassThroughRoutingKeyExpression=headers.tenant
b2bInboundPassThroughExchangeType=topic

In diesem Beispiel wird die Nachricht auf der Grundlage des Tenant-Wertes des json-Objekts weitergeleitet. Es ist auch möglich, die Weiterleitung auf der Grundlage verschiedener Routingkeys vorzunehmen, indem mehrere durch Komma getrennte headerNames konfiguriert werden.

b2bInboundPassThroughHeaderNames=tenant,partner
b2bInboundPassThroughRoutingKeyExpression=headers.tenant + '.' + headers.partner
b2bInboundPassThroughExchangeType=topic

Konfiguration Pathswitch per AMQP

Der Service empfängt per AMQP einen Pathswitch vom AS4-System und speicher ihn in der Extension ‘AS4_RELATIONS’ in der B2B-Datenbank. Der Name des Exchanges muss konfiguriert werden. Die Gruppe kann ebenfalls konfiguriert werden, so dass der Name der Queue wie folgt aussieht: ..

pathswitchExchangeName=as4.pathswitch.delivery
pathswitchGroup=default
pathswitchExchangeType=topic

Die Struktur der Extension sieht wie folgt aus:

<tenant-ILN>.<partner-ILN>.AS4=true/false
<tenant-ILN>.<partner-ILN>.AS4ID=<as4id>
<tenant-ILN>.<partner-ILN>.delivered=<delivered-timestamp>

Mit ‘.AS4’ wird angegeben ob die zwei Marktpartner per AS4 miteinander kommunizieren oder nicht. In der Locktabelle ist anhand eines Locks zu erkennen, ob ein B2B Message Service gerade in diese Extension schreibt.

Konfiguration Edifact über AMQP empfangen

Der B2B-Message-Service kann Edifact Nachrichten per AMQP empfangen und verarbeiten. Hierfür muss eine entsprechende Queue konfiguriert werden. Darüber hinaus kann der BASE_CHANNEL angegeben werden.

b2bEdifactExchangeName=b2b.edifact
b2bEdifactGroup=default
b2bEdifactChannel=OUT_B2B_MSG_SERVICE

Der Queue Eintrag enthält neben der Nachricht auch die Richtung inbound/outbound. Beispiel Nachricht für die Queue:

{
    "message": "base64 encoded edifact",
    "direction": "inbound/outbound"
}

Konfiguration B2B Inbound Pass through

Der B2B-Nachrichtendienst kann Edifact-Ereignisse für das Backend-System erzeugen (eingehender Passthrough). Hierzu muss eine entsprechende Warteschlange konfiguriert werden, die per Flag aktiviert oder deaktiviert werden kann. Zusätzlich muss der Passthrough-Kanal konfiguriert werden.

b2bInboundPassThroughExchangeName=b2b.json
b2bInboundPassThroughHeaderName=tenant
b2bInboundPassThroughHeaderValues=
saveInputMessage=false

Wichtig ist, dass der Exchange, die Queues und die entsprechenden Bindings für den Passtrough Workflow vor dem Start des B2B Message Service erstellt werden müssen, da es sonst sein kann, dass Nachrichten verloren gehen. Eine entsprechende Dokumentation zum Anlegen der Queues ist hier dokumentiert.

Zeitzone

Die Server-Zeitzone ist auf die gleiche Zeitzone wie die des B2B-Servers zu stellen. Die Server-Zeitzone darf nachträglich nicht mehr geändert werden.

REST API Dokumentation

Der Service bietet verschiedene REST Schnittstellen an, Details lassen sich der Swagger Dokumentation entnehmen.

Darüber hinaus bietet die API Server-Health Informationen an.

Der Port lässt sich über folgende Property konfigurieren: server.port=8080

Swagger

Die Beschreibung der REST API lässt sich, im Fall einer Docker Installation, unter

http://host.docker.internal:8090/aep-b2b-message-service/swagger-ui/index.html

oder unter

http://localhost:8080/aep-b2b-message-service/swagger-ui/index.html

finden.

Anhang: Gesamtkonfiguration

Folgende Konfiguration reicht in einem Standard-System aus: application.properties:

#=== JDBC Settings ==='
datasource.url=jdbc:postgresql://b2b-database:5432/b2bbp
datasource.username=postgres
datasource.password=${DB_PASSWORD}
datasource.schema=b2bbp

#=== Rabbitmq Configuration ===#
rabbitmq.host=rabbitmq3
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=${RABBITMQ_PASSWORD}

Allgemeine Hinweise zur Konfiguration finden Sie hier.