A5 - Ist der AS2-Endpunkt des Partners erreichbar?

Hierfür werden zwei Tests benötigt.

• Netzwerktest
  Dazu führen Sie bitte einen Pingtest/telnet vom Integration Server aus. Ist der Verbindungsversuch auf IP und Port außerhalb des Integration Servers erfolglos → Bitte mit A10 fortfahren.
  Bei Bedarf fragen Sie bitte bei Ihrer Infrastruktur nach.

• HTTP-Test
  Der zweite Test wird benötigt, wenn netzwerktechnisch alles in Ordnung ist. Dazu muss die Verbindung über HTTP getestet werden. Für einen einfachen Test können Sie auch die AS2-Adresse des Partners per Browser aufrufen.
  Wenn ein HTTP-Fehlercode zurückkommt, dann fahren Sie bitte fort mit A11.

A6 - Wird eine gültige MDN zurück geliefert?

Was ist eine MDN?

Eine MDN (Message Disposition Notification) ist eine Empfangsbestätigung. Diese wird während eines AS2-Austauschs nach Erhalt der AS2-Nachricht vom Empfänger an den Absender verschickt.

Damit signalisiert der Empfänger, dass die Datei vollständig übertragen wurde. In der MDN wird dem Absender mitgeteilt, ob der Sendeversuch erfolgreich war oder dabei ein Fehler unterlaufen ist.

War die Sendung erfolgreich, kann der Absender mit der MDN den fristgerechten Empfang der Nachricht bestätigen. Bei erfolglosen Übertragungen, also bei einem Fehler in der MDN, kann man oft anhand des Fehlers auf das Problem der Übertragung schließen.

Eine MDN kann synchron und asynchron versendet werden. Der Unterschied ist, dass bei ersterem gewartet wird, bis die Inhalte verarbeitet wurden und bei zweiterem die MDN sofort bei Erhalt der AS2-Nachricht gesendet wird, ohne auf den Prozess zu warten.

Eine gültige MDN hat einen eindeutigen Aufbau. Es handelt sich um einen Multipart-Request. Die einzelnen Bereiche sind getrennt durch Boundaries z. B. ------=_Part_14_2121847739.1648642823595.

Wenn die Datei anders aufgebaut ist, wie z. B. eine HTML-Seite, dann ist dies keine gültige MDN und es geht weiter bei A15.

Hinweis: Die MDNs finden Sie im Comm-Log (Control Center → Logs → Comm-Log) und werden entsprechend der in der Konfigurationsdatei ./etc/as2.xml angegebenen Aufbewahrungsdauer im System gespeichert.

Hier ein Beispiel einer richtig aufgebauten MDN.

A7 - Gibt die MDN einen Fehler zurück?

Im "Beispiel - FAILED" unten in Zeile 11 bzw. 24+25 lässt sich der Fehler erkennen (authentication-failed).

MDNs können eine Vielzahl von Fehlern beinhalten. Um diese besser verständlich zu machen, muss näher auf den Aufbau einer AS2-Übertragung eingegangen werden. Siehe auch E7.

A10 - Handelt es sich um einen Netzwerkfehler?

Wie kann ein Netzwertfehler identifiziert werden?

Als Netzwerkfehler werden alle Fehler bezeichnet, bei denen eine Verbindung zur Gegenseite nicht aufgebaut werden kann.

Im Log gibt es die Zeile "try to connect to server", ab dort wird erstmal versucht die Gegenseite zu erreichen. Befindet sich gleich dahinter eine Fehlermeldung, handelt es sich um ein Netzwerkfehler.

"Connection timed out: connect" bedeutet, dass die IP-Adresse von der Gegenseite bereits nicht erreichbar ist.

Der Verbindungsversuch wird nach einer bestimmten Zeit abgebrochen, ein Abbruch erfolgt meistens durch eine Netzwerkkomponente, aber nicht vom Integration Server.

Hier bitte alle beteiligten Firewalls prüfen!

"Connection refused: connect" bedeutet, dass die Verbindung zur Gegenseite über die IP erreicht werden konnte, jedoch der Port nicht.

Die Ursachen können sein, dass der Port im Kanal nicht korrekt ist, der Port in der Firewall nicht offen ist oder dass der Port auf der Partnerseite nicht offen ist, weil z. B. die Anwendung auf der anderen Seite nicht läuft.

Folgende Fehler können darauf hinweisen, dass der Server auf der Gegenseite überlastet ist.

A11 - Handelt es sich um einen HTTP-Fehler?

Ein HTTP-Fehler kann identifiziert werden, wenn in der Fehlermeldung ein HTTP-Statuscode auftaucht.

Hier eine Liste der gängigsten HTTP-Fehler in Verbindung mit AS2:

A15 - Bitte an den Partner wenden

Mit dem Partner Kanaleinstellungen, Zertifikat, Verschlüsselung/Signatur überprüfen.

E5 - Sind die Nachrichten im request.log ersichtlich?

Das Request-Log befindet sich in der GUI unter Control Center → Logs → Server-Logs → Http server oder in der Datei ./logs/request.log.

Anhand des Zeitstempels können Sie erkennen, wann der AS2-Request empfangen wurde. Gibt es zu der Zeit keinen Eintrag, kam kein AS2-Request am Integration Server an. Achtung: Im Request-Log wird die UTC-Zeit verwendet!

Offizielle AS2-Nachrichten sind immer an der POST-Methode und der IP-Adresse des Partners erkennbar. Als Pfadangabe muss der richtige AS2-URL-Pfad angegeben werden .../partner/AS2Retrieve

E6 - Sind die AS2-Nachrichten im Comm-Log ersichtlich?

Das Comm-Log befindet sich in der GUI unter Control Center → Logs → Comm-Log.

Dort ist erkennbar, ob es sich um eingehende oder ausgehende Nachrichten handelt.

Eine AS2-Nachricht besteht dabei immer aus einer Übertragung (Daten) und der MDN Bestätigung/Zurückgewiesen.

Eine automatisierte Benachrichtigung mittels Comm-Log-Event wird weiter unten beschrieben.

E7 - Welcher Status ist im Comm-Log ersichtlich?

Zurückgewiesen → Die MDN wurde an den Partner gesendet, allerdings mit einer Fehlermeldung. Diese können Sie in der MDN einsehen. Im Comm-Log sollte in der Spalte Datei ein Dokument zum Download zur Verfügung stehen.

Bestätigt → Die MDN wurde an den Partner gesendet und darin wurde eine erfolgreiche Übertragung gemeldet.

Siehe Punkt E6 (Screenshot unterer Teil).

E15 - Bitte an den Partner wenden

Kommen die Nachrichten nicht an Ihrer Firewall an, könnte es sein, dass der Partner die Nachrichten an eine falsche Adresse sendet oder seine Firewall die Nachricht blockiert. Oftmals wird auch Test- und Produktiv-System verwechselt!

E16 - An Ihre Infrastruktur wenden

Kommen die Nachrichten an der Firewall an, sind aber in der Datei ./logs/request.log nicht ersichtlich, liegt es zumeist an Firewall-Einstellungen, welche die Nachrichten nicht an den Integration Server weiterleitet.

E17 - AS2-Kanal ist nicht richtig konfiguriert oder nicht angelegt

Bitte überprüfen Sie zuerst, ob der Kanal angelegt und aktiv ist. Anschließend gleichen Sie (idealerweise mit dem Partner) die Kanaleinstellungen ab.

Die häufigsten Fehlerursachen sind vertauschte IDs oder eine falsche Adresse/Zertifikat/Verschlüsselungsalgorithmen.

E18 - Fehlermeldungen überprüfen/abgleichen

Siehe Punkt A7.

Logs

Logs können bei der Fehlerfindung (und für unseren Support) sehr hilfreich sein! Hierzu können Sie auch einen Log-Extract über die GUI (Control Center → Logs → Server Logs) durchführen.

• ./logs/request.log
  Ist ein POST-Request der Gegenstelle im Log zu sehen?
  Hinweis: Wurde die AS2-Adresse per Browser aufgerufen, sollte es ein GET sein.
  

• ./logs/as2/error.log & message.log
  Für AS2-spezifische Fehler.
  

• ./logs/services/error.log & message.log
  Für Fehler im Message-Protokoll oder falls ein DMZ-Server im Einsatz ist.

Wann erscheint eine Nachricht unter "Unresolved" (nur für AS2)?

Eine Nachricht erscheint unter Unresolved, wenn

• kein Profil für die Verarbeitung gefunden wurde,

• eine Signaturprüfung erfolgreich war,

• die Nachricht entschlüsselt werden konnte.

Eine Nachricht erscheint nicht unter Unresolved, wenn

• die Signaturprüfung nicht erfolgreich war,

• die Nachricht nicht entschlüsselt werden konnte.

Error Handling mittels Comm-Log-Event

Anbei ein Standardprofil, mit dem die Comm-Log-Einträge mit dem Comm-Log-Eingangsagenten ausgelesen werden können. Die Abfrage-Logik in Phase 3 muss hierbei noch ergänzt werden! H inweis: Profil funktioniert nur mit Version > 4.5!

Profile-ComLogCheck.pak

Empfehlung für Zertifikate

Wir empfehlen ganz allgemein auf AS2-Ebene möglichst selbst signierte Zertifikate zu verwenden, aus folgenden Gründen:

• Sie sind verbreitet und werden auch von den "Großen", wie z. B. Amazon, akzeptiert.

• Da sie selbst signiert sind, kann man deren Gültigkeitsdauer ohne Probleme auf 10+ Jahre legen, wodurch man sich den jährlichen Zertifikatswechsel erspart.

• Wenn man aus Versehen einen privaten Schlüssel exportiert (AS2-Zertifikate werden häufig auf drittem Weg ausgetauscht), ist nicht viel Geld verloren.

Anderes

• Andere Fehler könnten auch mit dem Umstieg auf eine neue Lobster/Java-Version zu tun haben. Hierfür bitte die java.security bzw. die hub.xml bezüglich Ciphers überprüfen!

• Auf das Thema AS2 mit DMZ-Server wird hier noch nicht eingegangen. Bei AS2-Problemen in Verbindung mit einem DMZ-Server bitte den Lobster Support kontaktieren!

• Bei eingehenden Nachrichten wird keine MDN an den Partner zurückgesendet.

  • Die Partneradresse ist nicht erreichbar.
    Da die Nachrichten aber teilweise erfolgreich durchgehen, würde man das hier nicht sehen, bzw. wenn, nur zeitweise Ausfälle auftreten.

  • Ihre DNS-Auflösung hat zeitweise Probleme.
    Prüfen Sie bitte mit Ihrer Infrastruktur, ob zu diesen Timestamps Probleme mit Ihrer DNS-Auflösung vorliegen. Dann könnte die Adresse nicht mehr aufgelöst und in weiterer Folge auch nicht erreicht werden.

Haben Sie Änderungsvorschläge oder Ideen zu dieser Seite, lassen Sie es uns wissen, indem Sie ein Ticket aufmachen!