Senden und Empfangen von AS2 Nachrichten

In diesem Abschnitt werden die Prozesse zum Senden und Empfangen von AS2 Nachrichten beschrieben. Es enthält auch Einzelheiten zu Dateinamen und Speicherorten, die mit AS2 Nachrichten verknüpft sind.

In der folgenden Tabelle sind die verfügbaren Verschlüsselungsalgorithmen für AS2 Nachrichten aufgeführt und es wird angegeben, wann Sie sie verwenden können.

Verschlüsselungsalgorithmus	HTTP	HTTPS	Hinweise
AES128_CBC	Ja	Ja
AES192_CBC	Ja	Ja
AES256_CBC	Ja	Ja
DES_ _CBC EDE3	Ja	Ja	Verwenden Sie diesen Algorithmus nur, wenn Sie einen Legacy-Client unterstützen müssen, der ihn benötigt, da es sich um einen schwachen Verschlüsselungsalgorithmus handelt.
NONE	Nein	Ja	Wenn Sie Nachrichten an einen Transfer Family Family-Server senden, können Sie nur auswählen, NONE ob Sie einen Application Load Balancer (ALB) verwenden.

Prozess zum Empfangen von Nachrichten AS2

Der eingehende Prozess ist definiert als eine Nachricht oder Datei, die auf Ihren AWS Transfer Family Server übertragen wird. Die Reihenfolge für eingehende Nachrichten ist wie folgt:

1. Ein Administrator- oder automatisierter Prozess startet eine AS2 Dateiübertragung auf dem AS2 Remote-Server des Partners.

2. Der AS2 Remoteserver des Partners signiert und verschlüsselt den Dateiinhalt und sendet dann eine HTTP-POST-Anforderung an einen AS2 eingehenden Endpunkt, der auf Transfer Family gehostet wird.

3. Mithilfe der konfigurierten Werte für den Server, die Partner, Zertifikate und die Vereinbarung entschlüsselt und verifiziert Transfer Family die AS2 Payload. Der Dateiinhalt wird im konfigurierten Amazon S3 S3-Dateispeicher gespeichert.

4. Die signierte MDN-Antwort wird entweder direkt mit der HTTP-Antwort oder asynchron über eine separate HTTP-POST-Anfrage an den ursprünglichen Server zurückgegeben.

5. Ein Prüfprotokoll CloudWatch mit Einzelheiten zum Austausch wird an Amazon geschrieben.

6. Die entschlüsselte Datei ist in einem Ordner mit dem Namen inbox/processed verfügbar.

Senden und Empfangen von AS2 Nachrichten über HTTPS

In diesem Abschnitt wird beschrieben, wie Sie einen Transfer Family Family-Server konfigurieren, der das AS2 Protokoll zum Senden und Empfangen von Nachrichten über HTTPS verwendet.

Themen

• Senden Sie AS2 Nachrichten über HTTPS

• Empfangen Sie AS2 Nachrichten über HTTPS

Senden Sie AS2 Nachrichten über HTTPS

Um AS2 Nachrichten über HTTPS zu senden, erstellen Sie einen Connector mit den folgenden Informationen:

• Geben Sie für die URL eine HTTPS-URL an

• Wählen Sie für den Verschlüsselungsalgorithmus einen der verfügbaren Algorithmen aus.

  Anmerkung

  Um Nachrichten an einen Transfer Family Family-Server zu senden, ohne Verschlüsselung zu verwenden (d. h. Sie wählen NONE den Verschlüsselungsalgorithmus), müssen Sie einen Application Load Balancer (ALB) verwenden.

• Geben Sie die verbleibenden Werte für den Connector ein, wie unter beschrieben. AS2 Konnektoren konfigurieren

Empfangen Sie AS2 Nachrichten über HTTPS

AWS Transfer Family AS2 Server bieten derzeit nur HTTP-Transport über Port 5080 an. Sie können TLS jedoch auf einem Netzwerk oder einem Application Load Balancer vor Ihrem Transfer Family Family-Server-VPC-Endpunkt beenden, indem Sie einen Port und ein Zertifikat Ihrer Wahl verwenden. Mit diesem Ansatz können Sie festlegen, dass eingehende AS2 Nachrichten HTTPS verwenden.

Voraussetzungen

• Die VPC muss sich auf demselben Server AWS-Region wie Ihr Transfer Family Family-Server befinden.

• Die Subnetze Ihrer VPC müssen sich innerhalb der Availability Zones befinden, in denen Sie Ihren Server verwenden möchten.

  Anmerkung

  Jeder Transfer Family Family-Server kann bis zu drei Availability Zones unterstützen.

• Weisen Sie bis zu drei Elastic IP-Adressen in derselben Region wie Ihr Server zu. Sie können sich auch dafür entscheiden, Ihren eigenen IP-Adressbereich (BYOIP) mitzubringen.

  Anmerkung

  Die Anzahl der Elastic IP-Adressen muss der Anzahl der Availability Zones entsprechen, die Sie mit Ihren Serverendpunkten verwenden.

Sie können entweder einen Network Load Balance (NLB) oder einen Application Load Balancer (ALB) konfigurieren. In der folgenden Tabelle sind die Vor- und Nachteile der einzelnen Ansätze aufgeführt.

In der folgenden Tabelle sind die Unterschiede in den Funktionen aufgeführt, wenn Sie einen NLB und einen ALB zum Beenden von TLS verwenden.

Funktion	Network Load Balancer (NLB)	Application Load Balancer (ALB)
Latency	Geringere Latenz, da er auf Netzwerkebene arbeitet.	Höhere Latenz, da es auf der Anwendungsebene arbeitet.
Unterstützung für statische IPs	Kann elastische IP-Adressen anhängen, die statisch sein können.	Elastic IP-Adressen können nicht angehängt werden: Stellt eine Domain bereit, deren zugrunde liegende IP-Adressen sich ändern können.
Erweitertes Routing	Unterstützt kein erweitertes Routing.	Unterstützt erweitertes Routing. Kann den erforderlichen X-Forwarded-Proto Header AS2 ohne Verschlüsselung einfügen. Dieser Header wird in X-Forwarded-Proto auf der Website developer.mozilla.org beschrieben.
TLS/SSL-Kündigung	Unterstützt die Kündigung TLS/SSL	Unterstützt die TLS/SSL Kündigung
Gegenseitiges TLS (mTLS)	Transfer Family unterstützt derzeit nicht die Verwendung eines NLB für mTLS	Support für mTLS

Configure NLB

Dieses Verfahren beschreibt, wie Sie einen mit dem Internet verbundenen Network Load Balancer (NLB) in Ihrer VPC einrichten.

Um einen Network Load Balancer zu erstellen und den VPC-Endpunkt des Servers als Ziel des Load Balancers zu definieren

1. Öffnen Sie die Amazon Elastic Compute Cloud-Konsole unter https://console.aws.amazon.com/ec2/.

2. Wählen Sie im Navigationsbereich Load Balancers und dann Create Load Balancer aus.

3. Wählen Sie im Bereich Network Load Balancer die Option Erstellen.

4. Geben Sie im Abschnitt Grundkonfiguration die folgenden Informationen ein:

   • Geben Sie unter Name einen aussagekräftigen Namen für den Load Balancer ein.

   • Für Scheme, wählen Sie Internet-facing.

   • Wählen Sie für IP address type (Typ der IP-Adresse) die Option IPv4 aus.

5. Geben Sie im Abschnitt Netzwerkzuordnung die folgenden Informationen ein:

   • Wählen Sie für VPC die Virtual Private Cloud (VPC) aus, die Sie erstellt haben.

   • Wählen Sie unter Zuordnungen die Availability Zones aus, die den öffentlichen Subnetzen zugeordnet sind, die in derselben VPC verfügbar sind, die Sie mit Ihren Serverendpunkten verwenden.

   • Wählen Sie für die IPv4 Adresse jedes Subnetzes eine der Elastic IP-Adressen aus, die Sie zugewiesen haben.

6. Geben Sie im Abschnitt Listener und Routing die folgenden Informationen ein:

   • Wählen Sie als Protokoll die Option TLS aus.

   • Geben Sie im Feld Port 5080 ein.

   • Wählen Sie für Standardaktion die Option Zielgruppe erstellen aus. Einzelheiten zum Erstellen einer neuen Zielgruppe finden Sie unterErstellen einer Zielgruppe.

   Nachdem Sie eine Zielgruppe erstellt haben, geben Sie ihren Namen in das Feld Standardaktion ein.

7. Wählen Sie im Bereich Secure Listener Settings Ihr Zertifikat im Bereich SSL/TLS Standardzertifikat aus.

8. Wählen Sie Create Load Balancer aus, um Ihren NLB zu erstellen.

9. (Optional, aber empfohlen) Aktivieren Sie die Zugriffsprotokolle für den Network Load Balancer, um einen vollständigen Audit-Trail zu führen, wie unter Zugriffsprotokolle für Ihren Network Load Balancer beschrieben.

   Wir empfehlen diesen Schritt, da die TLS-Verbindung im NLB beendet wird. Daher ist die Quell-IP-Adresse, die in Ihren Transfer Family AS2 CloudWatch Family-Protokollgruppen wiedergegeben wird, die private IP-Adresse der NLB und nicht die externe IP-Adresse Ihres Handelspartners.

Configure ALB

Dieses Verfahren beschreibt, wie Sie einen Application Load Balancer (ALB) in Ihrer VPC einrichten.

Um einen Application Load Balancer zu erstellen und den VPC-Endpunkt des Servers als Ziel des Load Balancers zu definieren

1. Öffnen Sie die Amazon Elastic Compute Cloud-Konsole unter https://console.aws.amazon.com/ec2/.

2. Wählen Sie im Navigationsbereich Load Balancers und dann Create Load Balancer aus.

3. Wählen Sie unter Application Load Balancer Create (Erstellen) aus.

4. Erstellen Sie in der ALB-Konsole einen neuen HTTP-Listener auf Port 443 (HTTPS).

5. (Optional). Wenn Sie die gegenseitige Authentifizierung (mTLS) einrichten möchten, konfigurieren Sie Sicherheitseinstellungen und einen Trust Store.

   1. Hängen Sie Ihr SSL/TLS Zertifikat an den Listener an.

   2. Wählen Sie unter Behandlung von Client-Zertifikaten die Option Gegenseitige Authentifizierung (mTLS) aus.

   3. Wählen Sie Mit Trust Store verifizieren aus.

   4. Wählen Sie unter Erweiterte mTLS-Einstellungen einen Vertrauensspeicher aus oder erstellen Sie ihn, indem Sie Ihre CA-Zertifikate hochladen.

6. Erstellen Sie eine neue Zielgruppe und fügen Sie die privaten IP-Adressen Ihrer Transfer Family AS2 Family-Serverendpunkte als Ziele auf Port 5080 hinzu. Einzelheiten zur Erstellung einer neuen Zielgruppe finden Sie unter. Erstellen einer Zielgruppe

7. Konfigurieren Sie Integritätsprüfungen für die Zielgruppe, um das HTTP-Protokoll auf Port 5080 zu verwenden.

8. Erstellen Sie eine neue Regel, um HTTPS-Verkehr vom Listener an die Zielgruppe weiterzuleiten.

9. Konfigurieren Sie den Listener so, dass er Ihr SSL/TLS-Zertifikat verwendet.

Nachdem Sie den Load Balancer eingerichtet haben, kommunizieren die Clients mit dem Load Balancer über den benutzerdefinierten Port-Listener. Anschließend kommuniziert der Load Balancer über Port 5080 mit dem Server.

Erstellen einer Zielgruppe

1. Nachdem Sie im vorherigen Verfahren „Zielgruppe erstellen“ ausgewählt haben, werden Sie zur Seite „Gruppendetails angeben“ für eine neue Zielgruppe weitergeleitet.

2. Geben Sie im Abschnitt Grundkonfiguration die folgenden Informationen ein.

   • Wählen Sie für Wählen Sie einen Zieltyp die Option IP-Adressen aus.

   • Geben Sie unter Zielgruppenname einen Namen für die Zielgruppe ein.

   • Ihre Auswahl für Protokoll hängt davon ab, ob Sie eine ALB oder eine NLB verwenden.

     • Wählen Sie für einen Network Load Balancer (NLB) TCP

     • Wählen Sie für einen Application Load Balancer (ALB) HTTP

   • Geben Sie im Feld Port 5080 ein.

   • Wählen Sie für IP address type (Typ der IP-Adresse) die Option IPv4 aus.

   • Wählen Sie für VPC die VPC aus, die Sie für Ihren Transfer Family AS2 Family-Server erstellt haben.

3. Wählen Sie im Abschnitt Health Checks das Health Check-Protokoll aus.

   • Wählen Sie für ein ALB HTTP

   • Wählen Sie für einen NLB TCP

4. Wählen Sie Weiter aus.

5. Geben Sie auf der Seite Ziele registrieren die folgenden Informationen ein:

   • Vergewissern Sie sich, dass für Network die VPC angegeben ist, die Sie für Ihren Transfer Family AS2 Family-Server erstellt haben.

   • Geben Sie als IPv4 Adresse die private IPv4 Adresse der Endpunkte Ihres Transfer Family AS2 Family-Servers ein.

     Wenn Sie mehr als einen Endpunkt für Ihren Server haben, wählen Sie IPv4 Adresse hinzufügen, um eine weitere Zeile für die Eingabe einer anderen IPv4 Adresse hinzuzufügen. Wiederholen Sie diesen Vorgang, bis Sie die privaten IP-Adressen für alle Endpunkte Ihres Servers eingegeben haben.

   • Stellen Sie sicher, dass Ports auf 5080 eingestellt ist.

   • Wählen Sie unten „Als ausstehend einbeziehen“ aus, um Ihre Einträge zum Abschnitt „Ziele überprüfen“ hinzuzufügen.

6. Überprüfen Sie im Abschnitt Ziele überprüfen Ihre IP-Ziele.

7. Wählen Sie Zielgruppe erstellen aus, kehren Sie dann zum vorherigen Verfahren zur Erstellung Ihrer NLB zurück und geben Sie die neue Zielgruppe an der angegebenen Stelle ein.

Testen Sie den Zugriff auf den Server von einer Elastic IP-Adresse

Stellen Sie über den benutzerdefinierten Port eine Connect zum Server her, indem Sie eine Elastic IP-Adresse oder den DNS-Namen des Network Load Balancer verwenden.

Wichtig

Verwalten Sie den Zugriff auf Ihren Server von Client-IP-Adressen aus, indem Sie die Netzwerk-Zugriffskontrolllisten (Netzwerk ACLs) für die auf dem Load Balancer konfigurierten Subnetze verwenden. Netzwerk-ACL-Berechtigungen werden auf Subnetzebene festgelegt, sodass die Regeln für alle Ressourcen gelten, die das Subnetz verwenden. Sie können den Zugriff von Client-IP-Adressen aus nicht mithilfe von Sicherheitsgruppen steuern, da der Zieltyp des Load Balancers auf IP-Adressen statt auf Instances festgelegt ist. Daher speichert der Load Balancer keine Quell-IP-Adressen. Wenn die Integritätsprüfungen des Network Load Balancers fehlschlagen, bedeutet dies, dass der Load Balancer keine Verbindung zum Serverendpunkt herstellen kann. Überprüfen Sie Folgendes, um dieses Problem zu beheben:

• Vergewissern Sie sich, dass die dem Serverendpunkt zugeordnete Sicherheitsgruppe eingehende Verbindungen aus den Subnetzen zulässt, die auf dem Load Balancer konfiguriert sind. Der Load Balancer muss in der Lage sein, über Port 5080 eine Verbindung zum Serverendpunkt herzustellen.

• Vergewissern Sie sich, dass der Serverstatus Online ist.

Dateien mithilfe eines AS2 Connectors übertragen

AS2 Konnektoren stellen eine Beziehung zwischen Handelspartnern für die Übertragung von AS2 Nachrichten von einem Transfer Family Family-Server an ein externes, partnereigenes Ziel her.

Sie können Transfer Family verwenden, um AS2 Nachrichten zu senden, indem Sie auf die Connector-ID und die Pfade zu den Dateien verweisen, wie im folgenden Befehl start-file-transfer AWS Command Line Interface (AWS CLI) dargestellt:

aws transfer start-file-transfer --connector-id c-1234567890abcdef0 \
--send-file-paths "/amzn-s3-demo-source-bucket/myfile1.txt" "/amzn-s3-demo-source-bucket/myfile2.txt"

Führen Sie den folgenden Befehl aus, um die Details für Ihre Konnektoren abzurufen:

aws transfer list-connectors

Der list-connectors Befehl gibt den Connector IDs URLs, und Amazon Resource Names (ARNs) für Ihre Konnektoren zurück.

Um die Eigenschaften eines bestimmten Connectors zurückzugeben, führen Sie den folgenden Befehl mit der ID aus, die Sie verwenden möchten:

aws transfer describe-connector --connector-id your-connector-id

Der describe-connector Befehl gibt alle Eigenschaften für den Konnektor zurück, einschließlich seiner URL, Rollen, Profile, Hinweise zur Nachrichtendisposition (MDNs), Tags und Überwachungsmetriken.

Sie können überprüfen, ob der Partner die Dateien erfolgreich erhalten hat, indem Sie sich die JSON- und MDN-Dateien ansehen. Diese Dateien werden gemäß den unter beschriebenen Konventionen benannt. Dateinamen und Speicherorte Wenn Sie bei der Erstellung des Connectors eine Logging-Rolle konfiguriert haben, können Sie Ihre CloudWatch Logs auch auf den Status von AS2 Nachrichten überprüfen.

Informationen zum AS2 Connector finden Sie unter AS2 Konnektordetails anzeigen. Weitere Informationen zum Erstellen von AS2 Konnektoren finden Sie unter AS2 Konnektoren konfigurieren.

Um eine AS2 ausgehende Nachricht zu senden

Der ausgehende Prozess ist definiert als eine Nachricht oder Datei, die von AWS einem externen Client oder Service gesendet wird. Die Reihenfolge für ausgehende Nachrichten ist wie folgt:

1. Ein Administrator ruft den Befehl start-file-transfer AWS Command Line Interface (AWS CLI) oder die StartFileTransfer API-Operation auf. Diese Operation verweist auf eine connector Konfiguration.

2. Transfer Family erkennt eine neue Dateianfrage und lokalisiert die Datei. Die Datei ist komprimiert, signiert und verschlüsselt.

3. Ein Transfer-HTTP-Client führt eine HTTP-POST-Anfrage durch, um die Nutzdaten an den AS2 Server des Partners zu übertragen.

4. Der Prozess gibt die signierte MDN-Antwort entsprechend der HTTP-Antwort zurück (synchrones MDN).

5. Während sich die Datei zwischen den verschiedenen Übertragungsphasen bewegt, übermittelt der Prozess dem Kunden die MDN-Antwort, den Empfang und die Verarbeitungsdetails.

6. Der AS2 Remoteserver stellt die entschlüsselte und verifizierte Datei dem Partneradministrator zur Verfügung.

AS2 Die Verarbeitung unterstützt viele der RFC 4130-Protokolle, wobei der Schwerpunkt auf allgemeinen Anwendungsfällen und der Integration mit bestehenden Serverimplementierungen mit AS2 aktivierter Funktionalität liegt. Einzelheiten zu den unterstützten Konfigurationen finden Sie unter. AS2 Konfigurationen

Dateinamen und Speicherorte

In diesem Abschnitt werden die Konventionen zur Benennung von Dateien für AS2 Übertragungen erörtert.

Beachten Sie bei eingehenden Dateiübertragungen Folgendes:

• Sie geben das Basisverzeichnis in einer Vereinbarung an. Das Basisverzeichnis ist der Amazon S3 S3-Bucket-Name in Kombination mit einem Präfix, falls vorhanden. Beispiel, /amzn-s3-demo-bucket/AS2-folder.

• Wenn eine eingehende Datei erfolgreich verarbeitet wurde, wird die Datei (und die entsprechende JSON-Datei) in dem /processed Ordner gespeichert. Beispiel, /amzn-s3-demo-bucket/AS2-folder/processed.

  Die JSON-Datei enthält die folgenden Felder:

  • agreement-id

  • as2-from

  • as2-to

  • as2-message-id

  • transfer-id

  • client-ip

  • connector-id

  • failure-message

  • file-path

  • message-subject

  • mdn-message-id

  • mdn-subject

  • requester-file-name

  • requester-content-type

  • server-id

  • status-code

  • failure-code

  • transfer-size

• Wenn eine eingehende Datei nicht erfolgreich verarbeitet werden kann, wird die Datei (und die entsprechende JSON-Datei) in dem /failed Ordner gespeichert. Beispiel, /amzn-s3-demo-bucket/AS2-folder/failed.

• Die übertragene Datei wird im processed Ordner als gespeichertoriginal_filename.messageId.original_extension. Das heißt, die Nachrichten-ID für die Übertragung wird vor der ursprünglichen Erweiterung an den Namen der Datei angehängt.

• Eine JSON-Datei wird erstellt und gespeichert alsoriginal_filename.messageId.original_extension.json. Zusätzlich zur hinzugefügten Nachrichten-ID wird die Zeichenfolge .json an den Namen der übertragenen Datei angehängt.

• Eine MDN-Datei (Message Disposition Notice) wird erstellt und gespeichert als. original_filename.messageId.original_extension.mdn Zusätzlich zur hinzugefügten Nachrichten-ID wird die Zeichenfolge .mdn an den Namen der übertragenen Datei angehängt.

• Wenn es eine eingehende Datei mit dem Namen gibtExampleFileInS3Payload.dat, werden die folgenden Dateien erstellt:

  • Datei — [e-mail]

  • JSON — [e-mail]

  • MDN — [e-mail]

Bei ausgehenden Übertragungen ist die Benennung ähnlich, mit dem Unterschied, dass es keine Datei für eingehende Nachrichten gibt und außerdem die Übertragungs-ID für die übertragene Nachricht zum Dateinamen hinzugefügt wird. Die Übertragungs-ID wird durch den StartFileTransfer API-Vorgang zurückgegeben (oder wenn ein anderer Prozess oder ein anderes Skript diesen Vorgang aufruft).

• Das transfer-id ist eine Kennung, die mit einer Dateiübertragung verknüpft ist. Alle Anfragen, die Teil eines StartFileTransfer Anrufs sind, teilen sich einetransfer-id.

• Das Basisverzeichnis entspricht dem Pfad, den Sie für die Quelldatei verwenden. Das heißt, das Basisverzeichnis ist der Pfad, den Sie in der StartFileTransfer API-Operation oder im start-file-transfer AWS CLI API-Befehl angeben. Zum Beispiel:

  aws transfer start-file-transfer --send-file-paths /amzn-s3-demo-bucket/AS2-folder/file-to-send.txt

  Wenn Sie diesen Befehl ausführen, werden MDN- und JSON-Dateien in /amzn-s3-demo-bucket/AS2-folder/processed (für erfolgreiche Übertragungen) oder /amzn-s3-demo-bucket/AS2-folder/failed (für erfolglose Übertragungen) gespeichert.

• Eine JSON-Datei wird erstellt und gespeichert alsoriginal_filename.transferId.messageId.original_extension.json.

• Eine MDN-Datei wird erstellt und gespeichert alsoriginal_filename.transferId.messageId.original_extension.mdn.

• Wenn es eine ausgehende Datei mit dem Namen gibtExampleFileOutTestOutboundSyncMdn.dat, werden die folgenden Dateien erstellt:

  • JSON — ExampleFileOutTestOutboundSyncMdn.dedf4601-[e-mail]

  • MDN — ExampleFileOutTestOutboundSyncMdn.dedf4601-[e-mail]

Sie können auch die CloudWatch Protokolle überprüfen, um die Details Ihrer Übertragungen einzusehen, einschließlich fehlgeschlagener Übertragungen.

Statuscodes

In der folgenden Tabelle sind alle Statuscodes aufgeführt, die in den CloudWatch Protokollen protokolliert werden können, wenn Sie oder Ihr Partner eine AS2 Nachricht senden. Verschiedene Schritte zur Nachrichtenverarbeitung gelten für verschiedene Nachrichtentypen und dienen nur der Überwachung. Die Status COMPLETED und FAILED stellen den letzten Verarbeitungsschritt dar und sind in JSON-Dateien sichtbar.

Code	Beschreibung	Verarbeitung abgeschlossen?
VERARBEITUNG	Die Nachricht wird gerade in ihr endgültiges Format konvertiert. Beispielsweise haben sowohl die Dekomprimierungs- als auch die Entschlüsselungsschritte diesen Status.	Nein
MDN_TRANSMIT	Die Nachrichtenverarbeitung sendet eine MDN-Antwort.	Nein
MDN_RECEIVE	Die Nachrichtenverarbeitung empfängt eine MDN-Antwort.	Nein
COMPLETED	Die Nachrichtenverarbeitung wurde erfolgreich abgeschlossen. Dieser Status gilt auch, wenn ein MDN für eine eingehende Nachricht oder für die MDN-Überprüfung ausgehender Nachrichten gesendet wird.	Ja
FEHLGESCHLAGEN	Die Nachrichtenverarbeitung ist fehlgeschlagen. Eine Liste der Fehlercodes finden Sie unterAS2 Fehlercodes.	Ja

JSON-Beispieldateien

In diesem Abschnitt werden JSON-Beispieldateien für eingehende und ausgehende Übertragungen aufgeführt, einschließlich Beispieldateien für erfolgreiche Übertragungen und fehlgeschlagene Übertragungen.

Beispiel für eine ausgehende Datei, die erfolgreich übertragen wurde:

{
  "requester-content-type": "application/octet-stream",
  "message-subject": "File xyzTest from MyCompany_OID to partner YourCompany",
  "requester-file-name": "TestOutboundSyncMdn-9lmCr79hV.dat",
  "as2-from": "MyCompany_OID",
  "connector-id": "c-c21c63ceaaf34d99b",
  "status-code": "COMPLETED",
  "disposition": "automatic-action/MDN-sent-automatically; processed",
  "transfer-size": 3198,
  "mdn-message-id": "OPENAS2-11072022063009+0000-df865189-1450-435b-9b8d-d8bc0cee97fd@PartnerA_OID_MyCompany_OID",
  "mdn-subject": "Message be18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa has been accepted",
  "as2-to": "PartnerA_OID",
  "transfer-id": "dedf4601-4e90-4043-b16b-579af35e0d83",
  "file-path": "/amzn-s3-demo-bucket/as2testcell0000/openAs2/TestOutboundSyncMdn-9lmCr79hV.dat",
  "as2-message-id": "fbe18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa",
  "timestamp": "2022-07-11T06:30:10.791274Z"
}

Beispiel für eine ausgehende Datei, die nicht erfolgreich übertragen wurde:

{
  "failure-code": "HTTP_ERROR_RESPONSE_FROM_PARTNER",
  "status-code": "FAILED",
  "requester-content-type": "application/octet-stream",
  "subject": "Test run from Id da86e74d6e57464aae1a55b8596bad0a to partner 9f8474d7714e476e8a46ce8c93a48c6c",
  "transfer-size": 3198,
  "requester-file-name": "openAs2TestOutboundWrongAs2Ids-necco-3VYn5n8wE.dat",
  "as2-message-id": "9a9cc9ab-7893-4cb6-992a-5ed8b90775ff@718de4cec1374598",
  "failure-message": "http://Test123456789.us-east-1.elb.amazonaws.com:10080 returned status 500 for message with ID 9a9cc9ab-7893-4cb6-992a-5ed8b90775ff@718de4cec1374598",
  "transfer-id": "07bd3e07-a652-4cc6-9412-73ffdb97ab92",
  "connector-id": "c-056e15cc851f4b2e9",
  "file-path": "/amzn-s3-demo-bucket-4c1tq6ohjt9y/as2IntegCell0002/openAs2/openAs2TestOutboundWrongAs2Ids-necco-3VYn5n8wE.dat",
  "timestamp": "2022-07-11T21:17:24.802378Z"
}

Beispiel für eine eingehende Datei, die erfolgreich übertragen wurde:

{
  "requester-content-type": "application/EDI-X12",
  "subject": "File openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.dat sent from MyCompany to PartnerA",
  "client-ip": "10.0.109.105",
  "requester-file-name": "openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.dat",
  "as2-from": "MyCompany_OID",
  "status-code": "COMPLETED",
  "disposition": "automatic-action/MDN-sent-automatically; processed",
  "transfer-size": 1050,
  "mdn-subject": "Message Disposition Notification",
  "as2-message-id": "OPENAS2-11072022233606+0000-5dab0452-0ca1-4f9b-b622-fba84effff3c@MyCompany_OID_PartnerA_OID",
  "as2-to": "PartnerA_OID",
  "agreement-id": "a-f5c5cbea5f7741988",
  "file-path": "processed/openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.OPENAS2-11072022233606+0000-5dab0452-0ca1-4f9b-b622-fba84effff3c@MyCompany_OID_PartnerA_OID.dat",
  "server-id": "s-5f7422b04c2447ef9",
  "timestamp": "2022-07-11T23:36:36.105030Z"
}

Beispiel für eine eingehende Datei, die nicht erfolgreich übertragen wurde:

{
  "failure-code": "INVALID_REQUEST",
  "status-code": "FAILED",
  "subject": "Sending a request from InboundHttpClientTests",
  "client-ip": "10.0.117.27",
  "as2-message-id": "testFailedLogs-TestRunConfig-Default-inbound-direct-integ-0c97ee55-af56-4988-b7b4-a3e0576f8f9c@necco",
  "as2-to": "0beff6af56c548f28b0e78841dce44f9",
  "failure-message": "Unsupported date format: 2022/123/456T",
  "agreement-id": "a-0ceec8ca0a3348d6a",
  "as2-from": "ab91a398aed0422d9dd1362710213880",
  "file-path": "failed/01187f15-523c-43ac-9fd6-51b5ad2b08f3.testFailedLogs-TestRunConfig-Default-inbound-direct-integ-0c97ee55-af56-4988-b7b4-a3e0576f8f9c@necco",
  "server-id": "s-0582af12e44540b9b",
  "timestamp": "2022-07-11T06:30:03.662939Z"
}