Hilfestellungen bei bekannten Fehlern

Diese Dokumentation dient als Hilfestellung bei der Fehlerbehandlung im AS4-System. Sie richtet sich an Kundenumgebungen, die außerdem die B2B by Practice verwenden.

Folgende Themen werden behandelt:

  • AS4 Quittungen verstehen
  • AS4 Crypto Report verstehen
  • AS4 Delivery Report verstehen
  • Nachrichtenverfolgung
  • Dead Letter Queues (DLQ)
  • AS4 Beziehungsstatus prüfen
  • Zertifikatsprozesse prüfen

Falls Sie AS4-Nachrichten vermissen, können Sie die Nachrichtenverfolgung nutzen, um gezielt nach den Nachrichten zu suchen. Ebenso können Sie die Dead-Letter-Queues prüfen.

AS4 Quittungen verstehen

Jede AS4-Nachricht muss durch eine AS4-Quittung bestätigt werden.

Wir unterscheiden folgende Status bei Quittungen:

  • positiver Quittungsstatus
  • negativer Quittungsstatus
  • Quittung ausstehend
  • fehlende Quittung

Der Quittungsstatus einer AS4-Marktnachricht wird im B2B Nachrichtenmonitor als VS/BS angezeigt. Darüber hinaus kann er über das fachliche Attribut AS4_RECEIPT_META geprüft werden.

Positive Quittungen

Die Verarbeitung der AS4-Nachricht war erfolgreich im Fall einer positiven Quittung.

Der positive Quittungsstatus wird im B2B Nachrichtenmonitor als BS “positives MDN” angezeigt. Hier ist zu beachten, dass der positive Quittungsstatus durch den nächsten Prozessschritt überschrieben werden kann. Dies ist z.B. der Fall, wenn ein Edifact-Contrl-Status eingegangen ist.

Das AS4-Receipt-Meta enthält bei einer positiven Quittung keine Fehlermeldungen.

Negative Quittungen

Die Verarbeitung der AS4-Nachricht war nicht erfolgreich im Fall einer negativen Quittung. Die Inbound-Verarbeitung wird in der B2B gestoppt, indem die Nachricht in einen Error-Channel geroutet wird.

Der negative Quittungsstatus wird im B2B Nachrichtenmonitor als BS “negatives MDN” angezeigt.

Das AS4-Receipt-Meta enthält bei einer negativen Quittung einen ebMS Error Code. Eine Auflistung möglicher Codes finden Sie im Dokument [OASIS ebXML Messaging Services Core Features](https://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html#6.7.Standard%20ebMS%20Errors outline), Abschnitt 6.7 “Standard ebMS Errors”.

Weitere Details zum jeweiligen Fehlercode können in der Quittung selbst nachgelesen werden. Die Quittung kann über das fachliche Attribut AS4_RECEIPT eingesehen werden.

Quittung ausstehend

Die Verarbeitung der AS4-Nachricht erfolgt asynchron von der B2B. Die B2B übergibt die Nachricht an das AS4-System und wartet auf das AS4-Receipt-Meta. Solange das Objekt nicht eingetroffen ist, verbleibt der Status aus Sicht der B2B auf “Quittung ausstehend”.

Während die B2B auf die Quittung wartet, wird der VS “Wartend” im B2B Nachrichtenmonitor angezeigt.

Falls das AS4-Receipt-Meta zu lange auf sich warten lässt, kann die Nachrichtenverfolgung genutzt werden, um den Verarbeitungsstatus der Nachricht zu prüfen.

Fehlende Quittungen

Die Verarbeitung der AS4-Nachricht war nicht erfolgreich im Fall einer fehlenden Quittung. Die Inbound-Verarbeitung wird in der B2B gestoppt, indem die Nachricht in einen Error-Channel geroutet wird.

Der fehlende Quittungsstatus wird im B2B Nachrichtenmonitor als ein Eintrag ohne BS angezeigt, der Verarbeitungsstatus ist jedoch nicht mehr “Wartend”, sondern “Fehler”.

Auch bei einer fehlenden Quittung wird ein AS4-Receipt-Meta an die B2B übermittelt. Das Objekt enthält bei einer fehlenden Quittung einen entsprechenden Hinweis inklusive einer Fehlermeldung mit Hinweisen zur Ursache. Je nach Ursache können weitere Fehlerdetails auch im professionellen Attribut AS4-Message-Meta gefunden werden.

AS4 Crypto Report verstehen

Das AS4-System signiert AS4-Nachrichten und verifiziert Signaturen. Ebenso ver- & entschlüsselt es Anhänge von AS4-Geschäftsnachrichten. Fehler während dieser Operationen können dazu führen, dass eine AS4-Nachricht nicht weiter verarbeitet wird.

Die Ergebnisse dieser Crypto-Operationen werden im fachlichen Attribut AS4-Message-Meta bzw. AS4-Receipt-Meta hinterlegt. Folgende Informationen werden angegeben:

  • signatureStatusCodes (Business Message & Receipt)
  • signatureReport (Business Message & Receipt)
  • cryptStatusCodes (nur Business Message)
  • cryptReport (nur Business Message)

Die Status-Codes enthalten maschinenlesbare Codes, der Report enthält eine detailierte Beschreibung. Der Status-Code 200 steht für eine erfolgreiche Verarbeitung. Alle anderen Codes stehen für Fehler. Den Reports können die genutzten Zertifikate, Algorithmen sowie Fehlerdetails entnommen werden.

Es folgt eine Auflistung möglicher Crypto Fehlerszenarien und ihrer Lösungen:

  • die Signatur-Verifikation schlug fehl, da ein gültiges Aussteller-Zertifikat fehlt (Code 2510). Lösung: Einspielen des Zertifikats in den FSS und Neustart der Nachricht.
  • die Operation schlug fehl, da die Sperrliste eines Zertifikats nicht aktuell ist (Code 2620). Lösung: sicherstellen, dass der CRL-Downloader erfolgreich ausgeführt wird. Danach Neustart der Nachricht.
  • die Signatur fehlt (Code 2400). Lösung: der Marktpartner wurde durch eine negative Quittung über den Fehler informiert. Er muss bei sich den Fehler korrigieren und erneut eine Nachricht verschicken.

AS4 Delivery Report verstehen

Falls die vollständige Übertragung der AS4-Nachricht auf Grund von Verbindungsproblemen scheitert, wird ein detailierter Fehlerbericht im AS4 Delivery Report hinterlegt. Der AS4-Delivery-Report wird in den fachlichen Attributen AS4-Message-Meta bzw. AS4-Receipt-Meta hinterlegt. Die Übertragung einer AS4-Geschäftsnachricht ist fehlgeschlagen, wenn die zugehörige Quittung nicht übermittelt worden ist.

Es folgt eine Auflistung möglicher Delivery Fehlerszenarien und ihrer Lösungen:

  • (Outbound) der Versand einer AS4-Nachricht schlug fehl, da die Partneradresse nicht erreichbar ist oder keine Quittung vor dem Timeout übermittelt worden ist. Lösung: der Partner muss sein System verfügbar machen. Danach ist der Versand neu zu starten.
  • (Outbound) der Versand einer AS4-Nachricht schlug fehl, da die TLS Verbindung gescheitert ist, z.B. auf Grund eines fehlenden Zertifikats. Stellen Sie sicher, dass im FSS die fehlenden Zertifikate hinterlegt werden und starten Sie den Versand neu.

Nachrichtenverfolgung

Bei der Verarbeitung von AS4-Nachrichten durchlaufen die Nachrichten mehrere unterschiedliche Microservices. Falls es nötig ist, die Verarbeitung einer Nachricht zu verfolgen, wird hiermit eine Hilfestellung gegeben. Voraussetzung ist die leichte Durchsuchbarkeit der Logs aller Microservices.

Falls eine Nachricht genau bis zur Übergabe zweier Microservices verfolgt wird, lohnt ein Blick in die Message-Broker Queue, die zwischen den beiden Services liegt. Möglicherweise kann die Nachricht hier gefunden werden.

Im Folgenden werden diese Prozesse unterschieden:

  • Nachrichtenverfolgung Outbound
  • Nachrichtenverfolgung Inbound
  • Nachrichtenverfolgung Outbound Pathswitch

Nachrichtenverfolgung Outbound

Die Verfolgung wird erleichtert, wenn Sie die Reihenfolge verstehen, in der die Nachrichten die Microservices durchlaufen. Eine Beschreibung des Outbound-Prozesses finden Sie hier.

Beginnen Sie die Verfolgung im Log des B2B-Message-Service. Suchen Sie nach der B2B-MessageId.

Setzen Sie die Verfolgung im Log des AS4-Outbound-Market-Message-Service fort. Hier suchen Sie nach der Kombination von Sender & Empfänger MPID. Sie können z.B. nach folgendem String suchen: tenant 9900000000001 and partner 9900000000002. Die Log-Zeilen enthalten die AS4-ID, die Sie für die weitere Verfolgung benötigen.

Mithilfe der AS4-ID können Sie die Verarbeitung der Nachricht im Log der weiteren Services verfolgen. Folgende Services sind beteiligt:

  • AS4-Crypto-Operations (2 Workflows: sign/encrypt & verify-receipt)
  • AS4-Outbound-Sender
  • AS4-Receipt-Service
  • AS4-Message-Service

Im AS4-Outbound-Sender wird außerdem das Receipt-Meta-Objekt erstellt. Sie finden hier die zugehörige AS4-ID des AS4-Receipt-Metas. Das Meta Objekt durchläuft einige Microservices unabhängig von der AS4-Nachricht, weshalb es separat verfolgt werden muss.

Nachrichtenverfolgung Inbound

Die Verfolgung wird erleichtert, wenn Sie die Reihenfolge verstehen, in der die Nachrichten die Microservices durchlaufen. Eine Beschreibung des Inbound-Prozesses finden Sie hier.

Beginnen Sie die Verfolgung im Log des AS4-Inbound-Endpoint. Suchen Sie nach der Kombination von Empfänger & Sender MPID. Sie können z.B. nach folgenden String suchen: tenant 9900000000001 and partner 9900000000002. Die Log-Zeilen enthalten die AS4-ID, die Sie für die weitere Verfolgung benötigen.

Mithilfe der AS4-ID können Sie die Verarbeitung der Nachricht im Log der weiteren Services verfolgen. Folgende Services sind beteiligt:

  • AS4-Crypto-Operations (2 Workflows: verify/decrypt & sign-receipt)
  • AS4-Receipt-Service
  • AS4-Message-Service
  • B2B-Message-Service

Im AS4-Receipt-Service wird außerdem das Receipt-Meta-Objekt erstellt. Sie finden hier die zugehörige AS4-ID des AS4-Receipt-Metas. Das Meta Objekt durchläuft einige Microservices unabhängig von der AS4-Nachricht, weshalb es separat verfolgt werden muss.

Nachrichtenverfolgung Outbound Pathswitch

Die Outbound-Pathswitch Verfolgung ist ähnlich zur Standard-Outbound-Verfolgung. Die Verfolgung beginnt jedoch nicht im B2B-Message-Service, sondern im AS4-Address-Service. Suchen Sie nach der Kombination von Sender & Empfänger MPID. Sie können z.B. nach folgenden String suchen: tenant 9900000000001 and partner 9900000000002.

Dead Letter Queues (DLQ)

Manche Fehler des AS4-Systems erzeugen zusätzlich Einträge in Dead-Letter-Queues. Diese Einträge werden nicht automatisch weiter verarbeitet. Manche Dead-Letter-Queue Einträge bieten die Möglichkeit eines Neustarts des Vorgangs. Hierfür ist der Eintrag von der DLQ in die Standard-Queue zu verschieben.

DLQ-Einträge können im Vergleich zu Fehler-Logs ein einfacheres Mittel sein, um Fehler zu erkennen.

DLQs müssen regelmäßig bereinigt werden. Sind sie überfüllt, wird es ohne zusätzliche Werkzeuge nahezu unmöglich, gezielt nach fehlerhaften Nachrichten zu suchen. Außerdem benötigen die Einträge zusätzlichen Speicherplatz.

AS4 Beziehungsstatus prüfen

Der AS4-Beziehungsstatus kann über die B2B-Marktpartnerverwaltung geprüft werden.

Nutzen Sie unsere Filter:

  • Protokoll: AS4
  • Partner: MPID des Partners
  • System: MPID des Mandanten
  • nicht abgelaufen

(Diese Filter stehen nur zur Verfügung, falls Sie die Marktpartnerverwaltung mit dem AS4-System verbunden haben. Dies ist aktuell nicht möglich, falls Sie die B2B on Premise betreiben, während das AS4-System on Crisp läuft.)

Wenn Sie die Beziehung gefunden haben, achten Sie darauf, dass der Status “Bereit” ist, und dass die AS4-Adresse korrekt eingetragen ist.

Falls der Status nicht “Bereit” ist, obwohl ein Pathswitch verschickt worden ist, kann die Nachrichtenverfolgung des Adresswechsels genutzt werden.

Zertifikatsprozesse prüfen

Dieser Abschnitt behandelt folgende Themen:

  • Zertifikate
  • Aktualisierung der Sperrlisten
  • Download von Partner Zertifikaten
  • Erneuerung von Mandanten Zertifikaten
  • Aktualisierung von Aussteller Zertifikaten

Zertifikate

Vor der AS4-Nachrichtenverarbeitung müssen alle Zertifikate korrekt hinterlegt sein. Nutzen Sie die FSS-UI, um den Status zu prüfen.

Folgende Zertifikate sind notwendig:

  • Zertifikat-Trio und zugehörige Ausstellerzertifikate für jeden Mandanten im Mandanten-Client
  • Zertifikat-Trio und zugehörige Ausstellerzertifikate für jeden Partner im shared-Client

Beachten Sie, dass jeder Mandant üblicherweise auch immer gleichzeitig ein Partner ist. Somit müssen die zugehörigen Zertifikate sowohl im Mandanten-Client als auch im shared-client hinterlegt sein.

Ein Zertifikat-Trio besteht aus Zertifikaten mit folgenden Verwendungszwecken: Signatur, Verschlüsselung und TLS.

Ein Aussteller-Zertifikat ist ein Zertifikat mit dem Verwendungszweck Root-CA oder Sub-CA.

Mandanten- & Partnerzertifikate müssen immer mit dem Alias als MPID hinterlegt sein.

Mandanten-Clients sollten als Client-Namen die MPID haben.

Der Sperrlistenstatus muss “verfügbar” sein (bzw. “selbst-signiert” bei Root-Zertifikaten).

Die Gültigkeit und der Verwendungszeitraum müssen eingehalten werden.

Das Zertifikat muss Aktiv sein.

Die folgenden Eigenschaften können (noch) nicht über die FSS-UI geprüft werden:

  • Achten Sie auch darauf, dass jeder Mandanten-Client mit genau einem zugehörigen HSM-Slot verbunden ist (prüfbar über die Datenbank)
  • An jedem Mandanten-Zertifikat muss der korrekte HSM-Key-Alias hinterlegt sein (prüfbar über die Datenbank)
  • Die Zertifikate müssen die Vorgaben erfüllen. Dazu gehört insbesondere die Angabe der AS4-Adresse und der zugehörigen Domäne (prüfbar über den Download der Zertifikate)

Eine Zertifikatskette kann über die Kombination von SKI/AKI geprüft werden. Der AKI (Authority Key Identifier) des ausgestellten Zertifikats muss dem SKI (Subject Key Identifier) des ausstellenden Zertifikats entsprechen.

Aktualisierung der Sperrlisten

Die Sperrlisten müssen regelmäßig aktualisiert werden.

Falls es Probleme beim Sperrlistenabruf gibt, möchten Sie dies korrigieren, bevor die Sperrlisten ablaufen. Deshalb empfiehlt es sich, den korrekten Ablauf der Sperrlistenabfrage kontinuierlich prüfen. Dies kann z.B. über die Logs des Sperrlistenjobs erfolgen.

Download von Partner Zertifikaten

Partner-Zertifikate laufen regelmäßig ab und müssen somit regelmäßig aktualisiert werden. Nutzen Sie zur Automatisierung dieses Vorgangs den Certificate-Manager. Die Erneuerung erfolgt noch vor Ablauf, Zertifikate müssen zeitlich überlappen.

Falls es Probleme bei der Aktualisierung von Partnerzertifikaten gibt, möchten Sie dies korrigieren, bevor die Partnerzertifikate ablaufen. Deshalb empfiehlt es sich, den korrekten Durchlauf der Aktualisierung von Partnerzertifikaten kontinuierlich prüfen. Dies kann z.B. über die Logs des Certificate-Managers erfolgen.

Erneuerung von Mandanten Zertifikaten

Mandanten-Zertifikate laufen regelmäßig ab und müssen somit regelmäßig aktualisiert werden. Nutzen Sie hierfür den CSR-Service. Die Erneuerung erfolgt noch vor Ablauf, Zertifikate müssen zeitlich überlappen.

Falls es Probleme bei der Aktualisierung von Mandanten-Zertifikaten gibt, möchten Sie dies korrigieren, bevor die Zertifikate ablaufen. Deshalb empfiehlt es sich, den korrekten Durchlauf der Aktualisierung von Mandanten-Zertifikaten kontinuierlich prüfen. Dies kann z.B. über die Logs des CSR-Service erfolgen.

Aktualisierung von Aussteller Zertifikaten

Aussteller-Zertifikate laufen regelmäßig ab und müssen somit regelmäßig aktualisiert werden. Hierfür gibt es (noch) keinen automatisierten Prozess.

Nutzen Sie regelmäßig die FSS-UI, um den Status der Aussteller-Zertifikate zu prüfen. Das Frontend zeigt an, wann Zertifikate ablaufen, und ob bereits ein Folgezertifikat hinterlegt ist.

Die Erneuerung erfolgt noch vor Ablauf, Zertifikate müssen zeitlich überlappen.

View Me   Edit Me