View a markdown version of this page

Envoi et réception de messages AS2 - AWS Transfer Family

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Envoi et réception de messages AS2

Cette section décrit les processus d'envoi et de réception de messages AS2. Il fournit également des détails sur les noms de fichiers et les emplacements associés aux messages AS2.

Le tableau suivant répertorie les algorithmes de chiffrement disponibles pour les messages AS2 et indique quand vous pouvez les utiliser.

Algorithme de chiffrement HTTP HTTPS Remarques
AES128_CBC Oui Oui
AES192_CBC Oui Oui
AES256_CBC Oui Oui
DES_EDE3_CBC Oui Oui N'utilisez cet algorithme que si vous devez prendre en charge un client existant qui l'exige, car il s'agit d'un algorithme de chiffrement faible.
NONE Non Oui Si vous envoyez des messages à un serveur de la famille de transferts, vous ne pouvez effectuer cette sélection que NONE si vous utilisez un équilibreur de charge d'application (ALB).

Traitement des messages AS2

Le processus entrant est défini comme un message ou un fichier en cours de transfert vers votre AWS Transfer Family serveur. La séquence des messages entrants est la suivante :

  1. Un processus d'administration ou automatisé démarre un transfert de fichiers AS2 sur le serveur AS2 distant du partenaire.

  2. Le serveur AS2 distant du partenaire signe et chiffre le contenu du fichier, puis envoie une requête HTTP POST à un terminal entrant AS2 hébergé sur Transfer Family.

  3. À l'aide des valeurs configurées pour le serveur, les partenaires, les certificats et l'accord, Transfer Family déchiffre et vérifie la charge utile AS2. Le contenu du fichier est stocké dans le magasin de fichiers Amazon S3 configuré.

  4. La réponse MDN signée est renvoyée soit en ligne avec la réponse HTTP, soit de manière asynchrone via une requête HTTP POST distincte vers le serveur d'origine.

  5. Une piste d'audit est envoyée à Amazon CloudWatch avec des informations sur l'échange.

  6. Le fichier déchiffré est disponible dans un dossier nommé. inbox/processed

Schéma illustrant la séquence de traitement des messages entrants.

Envoi et réception de messages AS2 via HTTPS

Cette section décrit comment configurer un serveur Transfer Family qui utilise le protocole AS2 pour envoyer et recevoir des messages via HTTPS.

Envoyer des messages AS2 via HTTPS

Pour envoyer des messages AS2 via HTTPS, créez un connecteur contenant les informations suivantes :

  • Pour l'URL, spécifiez une URL HTTPS

  • Pour l'algorithme de chiffrement, sélectionnez l'un des algorithmes disponibles.

    Note

    Pour envoyer des messages à un serveur de la famille de transferts sans utiliser le chiffrement (c'est-à-dire que vous sélectionnez l'algorithme NONE de chiffrement), vous devez utiliser un équilibreur de charge d'application (ALB).

  • Fournissez les valeurs restantes pour le connecteur comme décrit dansConfiguration des connecteurs AS2.

Recevoir des messages AS2 via HTTPS

AWS Transfer Family Les serveurs AS2 ne fournissent actuellement que le transport HTTP via le port 5080. Vous pouvez toutefois mettre fin au protocole TLS sur un équilibreur de charge réseau ou d'application situé devant le point de terminaison VPC de votre serveur Transfer Family en utilisant le port et le certificat de votre choix. Avec cette approche, vous pouvez faire en sorte que les messages AS2 entrants utilisent le protocole HTTPS.

Conditions préalables

  • Le VPC doit se trouver sur le même serveur Région AWS que votre serveur Transfer Family.

  • Les sous-réseaux de votre VPC doivent se trouver dans les zones de disponibilité dans lesquelles vous souhaitez utiliser votre serveur.

    Note

    Chaque serveur de la famille Transfer peut prendre en charge jusqu'à trois zones de disponibilité.

  • Allouez jusqu'à trois adresses IP Elastic dans la même région que votre serveur. Vous pouvez également choisir d'apporter votre propre plage d'adresses IP (BYOIP).

    Note

    Le nombre d'adresses IP Elastic doit correspondre au nombre de zones de disponibilité que vous utilisez avec les points de terminaison de votre serveur.

Vous pouvez configurer un équilibrage de charge réseau (NLB) ou un équilibreur de charge d'application (ALB). Le tableau suivant répertorie les avantages et les inconvénients de chaque approche.

Le tableau ci-dessous présente les différences de fonctionnalités entre l'utilisation d'un NLB et d'un ALB pour terminer le protocole TLS.

Fonctionnalité Équilibreur de charge réseau (NLB) Équilibreur de charge des applications (ALB)
Latence Latence plus faible car il fonctionne au niveau de la couche réseau. Latence plus élevée car il fonctionne au niveau de la couche applicative.
Prise en charge des adresses IP statiques Peut joindre des adresses IP Elastic qui peuvent être statiques. Impossible de joindre des adresses IP élastiques : fournit un domaine dont les adresses IP sous-jacentes peuvent changer.
Routage avancé Ne prend pas en charge le routage avancé.

Supporte le routage avancé. Peut injecter X-Forwarded-Proto l'en-tête requis pour AS2 sans cryptage.

Cet en-tête est décrit X-Forwarded-Proto sur le site web https://developer.mozilla.org/ developer.mozilla.org.

TLS/SSL résiliation Supporte le TLS/SSL licenciement Supporte le TLS/SSL licenciement
TLS mutuel (mTLS) Transfer Family ne prend pas actuellement en charge l'utilisation d'un NLB pour les mTLS Support pour mTLS
Configure NLB

Cette procédure décrit comment configurer un équilibreur de charge réseau (NLB) connecté à Internet dans votre VPC.

Pour créer un équilibreur de charge réseau et définir le point de terminaison VPC du serveur comme cible de l'équilibreur de charge
  1. Ouvrez la console Amazon Elastic Compute Cloud à l'adresse https://console.aws.amazon.com/ec2/.

  2. Dans le volet de navigation, choisissez Load Balancers, puis choisissez Create load balancer.

  3. Sous Network Load Balancer, choisissez Créer.

  4. Dans la section Configuration de base, entrez les informations suivantes :

    • Dans le champ Nom, entrez un nom descriptif pour l'équilibreur de charge.

    • Pour Scheme, choisissez Internet-facing.

    • Pour le type d'adresse IP, choisissez IPv4.

  5. Dans la section Cartographie du réseau, entrez les informations suivantes :

    • Pour VPC, choisissez le cloud privé virtuel (VPC) que vous avez créé.

    • Sous Mappages, choisissez les zones de disponibilité associées aux sous-réseaux publics disponibles dans le même VPC que celui que vous utilisez avec les points de terminaison de votre serveur.

    • Pour l'adresse IPv4 de chaque sous-réseau, choisissez l'une des adresses IP Elastic que vous avez allouées.

  6. Dans la section Auditeurs et routage, entrez les informations suivantes :

    • Pour Protocole, choisissez TLS.

    • Pour Port, entrez 5080.

    • Pour Action par défaut, choisissez Créer un groupe cible. Pour plus de détails sur la création d'un nouveau groupe cible, consultezPour créer un groupe cible.

    Après avoir créé un groupe cible, entrez son nom dans le champ Action par défaut.

  7. Dans la section Paramètres de l'écouteur sécurisé, choisissez votre certificat dans la zone SSL/TLS Certificat par défaut.

  8. Choisissez Créer un équilibreur de charge pour créer votre NLB.

  9. (Facultatif, mais recommandé) Activez les journaux d'accès pour que l'équilibreur de charge réseau conserve une piste d'audit complète, comme décrit dans Journaux d'accès de votre équilibreur de charge réseau.

    Nous recommandons cette étape car la connexion TLS est interrompue au niveau du NLB. Par conséquent, l'adresse IP source qui apparaît dans vos groupes de CloudWatch journaux Transfer Family AS2 est l'adresse IP privée de la NLB, au lieu de l'adresse IP externe de votre partenaire commercial.

Configure ALB

Cette procédure décrit comment configurer un équilibreur de charge d'application (ALB) dans votre VPC.

Pour créer un équilibreur de charge d'application et définir le point de terminaison VPC du serveur comme cible de l'équilibreur de charge
  1. Ouvrez la console Amazon Elastic Compute Cloud à l'adresse https://console.aws.amazon.com/ec2/.

  2. Dans le volet de navigation, choisissez Load Balancers, puis choisissez Create load balancer.

  3. Sous Application Load Balancer, choisissez Create (Créer).

  4. Dans la console ALB, créez un nouvel écouteur HTTP sur le port 443 (HTTPS).

  5. (Facultatif) Si vous souhaitez configurer l'authentification mutuelle (mTLS), configurez les paramètres de sécurité et un magasin de confiance.

    1. Joignez votre SSL/TLS certificat à l'auditeur.

    2. Sous Gestion des certificats clients, sélectionnez Authentification mutuelle (mTLS).

    3. Choisissez Verify with Trust Store.

    4. Dans Paramètres mTLS avancés, choisissez ou créez un trust store en téléchargeant vos certificats CA.

  6. Créez un nouveau groupe cible et ajoutez les adresses IP privées des points de terminaison de vos serveurs Transfer Family AS2 en tant que cibles sur le port 5080. Pour plus de détails sur la création d'un nouveau groupe cible, consultezPour créer un groupe cible.

  7. Configurez les contrôles de santé pour que le groupe cible utilise le protocole HTTP sur le port 5080.

  8. Créez une nouvelle règle pour transférer le trafic HTTPS de l'auditeur vers le groupe cible.

  9. Configurez l'écouteur pour qu'il utilise votre SSL/TLS certificat.

Une fois que vous avez configuré l'équilibreur de charge, les clients communiquent avec celui-ci via l'écouteur de port personnalisé. L'équilibreur de charge communique ensuite avec le serveur via le port 5080.

Pour créer un groupe cible
  1. Après avoir choisi Créer un groupe cible dans la procédure précédente, vous êtes redirigé vers la page Spécifier les détails du groupe pour un nouveau groupe cible.

  2. Dans la section Configuration de base, entrez les informations suivantes.

    • Pour Choisir un type de cible, choisissez des adresses IP.

    • Pour Nom du groupe cible, saisissez un nom pour le groupe cible.

    • Pour le protocole, votre sélection dépend du fait que vous utilisez un ALB ou un NLB.

      • Pour un équilibreur de charge réseau (NLB), choisissez TCP

      • Pour un équilibreur de charge d'application (ALB), choisissez HTTP

    • Pour Port, entrez 5080.

    • Pour le type d'adresse IP, choisissez IPv4.

    • Pour VPC, choisissez le VPC que vous avez créé pour votre serveur Transfer Family AS2.

  3. Dans la section Bilans de santé, choisissez le protocole de contrôle de santé.

    • Pour un ALB, choisissez HTTP

    • Pour un NLB, choisissez TCP

  4. Choisissez Suivant.

  5. Sur la page Enregistrer les cibles, entrez les informations suivantes :

    • Pour Réseau, vérifiez que le VPC que vous avez créé pour votre serveur Transfer Family AS2 est spécifié.

    • Pour l'adresse IPv4, entrez l'adresse IPv4 privée des terminaux de votre serveur Transfer Family AS2.

      Si vous avez plusieurs terminaux pour votre serveur, choisissez Ajouter une adresse IPv4 pour ajouter une autre ligne permettant de saisir une autre adresse IPv4. Répétez cette procédure jusqu'à ce que vous ayez saisi les adresses IP privées de tous les points de terminaison de votre serveur.

    • Assurez-vous que Ports est réglé sur5080.

    • Choisissez Inclure comme en attente ci-dessous pour ajouter vos entrées à la section Objectifs de révision.

  6. Dans la section Réviser les cibles, passez en revue vos cibles IP.

  7. Choisissez Créer un groupe cible, puis revenez à la procédure précédente de création de votre NLB et saisissez le nouveau groupe cible à l'endroit indiqué.

Tester l'accès au serveur à partir d'une adresse IP Elastic

Connectez-vous au serveur via le port personnalisé à l'aide d'une adresse IP Elastic ou du nom DNS du Network Load Balancer.

Important

Gérez l'accès à votre serveur à partir des adresses IP des clients en utilisant les listes de contrôle d'accès réseau (ACL réseau) pour les sous-réseaux configurés sur l'équilibreur de charge. Les autorisations ACL réseau sont définies au niveau du sous-réseau, de sorte que les règles s'appliquent à toutes les ressources qui utilisent le sous-réseau. Vous ne pouvez pas contrôler l'accès à partir des adresses IP des clients à l'aide de groupes de sécurité, car le type de cible de l'équilibreur de charge est défini sur les adresses IP et non sur les instances. Par conséquent, l'équilibreur de charge ne conserve pas les adresses IP sources. Si les contrôles de santé du Network Load Balancer échouent, cela signifie que l'équilibreur de charge ne peut pas se connecter au point de terminaison du serveur. Pour résoudre ce problème, vérifiez les points suivants :

  • Vérifiez que le groupe de sécurité associé au point de terminaison du serveur autorise les connexions entrantes depuis les sous-réseaux configurés sur l'équilibreur de charge. L'équilibreur de charge doit pouvoir se connecter au point de terminaison du serveur via le port 5080.

  • Vérifiez que l'état du serveur est en ligne.

Transférer des fichiers à l'aide d'un connecteur AS2

Les connecteurs AS2 établissent une relation entre les partenaires commerciaux pour les transferts de messages AS2 depuis un serveur de la famille de transferts vers une destination externe appartenant au partenaire.

Vous pouvez utiliser Transfer Family pour envoyer des messages AS2 en faisant référence à l'ID du connecteur et aux chemins d'accès aux fichiers, comme illustré dans la commande start-file-transfer AWS Command Line Interface (AWS CLI) suivante :

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"

Pour obtenir les informations relatives à vos connecteurs, exécutez la commande suivante :

aws transfer list-connectors

La list-connectors commande renvoie les ID de connecteur, les URL et les noms de ressources Amazon (ARN) pour vos connecteurs.

Pour renvoyer les propriétés d'un connecteur particulier, exécutez la commande suivante avec l'ID que vous souhaitez utiliser :

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

La describe-connector commande renvoie toutes les propriétés du connecteur, notamment son URL, ses rôles, ses profils, ses notifications de disposition des messages (mDNS), ses balises et ses mesures de surveillance.

Vous pouvez vérifier que le partenaire a bien reçu les fichiers en consultant les fichiers JSON et MDN. Ces fichiers sont nommés conformément aux conventions décrites dansNoms et emplacements des fichiers. Si vous avez configuré un rôle de journalisation lors de la création du connecteur, vous pouvez également consulter vos CloudWatch journaux pour connaître l'état des messages AS2.

Pour afficher les détails du connecteur AS2, reportez-vous Afficher les détails du connecteur AS2 à. Pour plus d'informations sur la création de connecteurs AS2, consultezConfiguration des connecteurs AS2.

Pour envoyer un message sortant AS2

Le processus sortant est défini comme un message ou un fichier envoyé depuis AWS un client ou un service externe. La séquence des messages sortants est la suivante :

  1. Un administrateur appelle la commande start-file-transfer AWS Command Line Interface (AWS CLI) ou l'opération StartFileTransfer d'API. Cette opération fait référence à une connector configuration.

  2. Transfer Family détecte une nouvelle demande de fichier et localise le fichier. Le fichier est compressé, signé et chiffré.

  3. Un client HTTP de transfert exécute une requête HTTP POST pour transmettre la charge utile au serveur AS2 du partenaire.

  4. Le processus renvoie la réponse MDN signée, soit en ligne avec la réponse HTTP (MDN synchrone ou asynchrone).

  5. Au fur et à mesure que le fichier passe d'une étape à l'autre de la transmission, le processus transmet le reçu de réponse MDN et les détails de traitement au client.

  6. Le serveur AS2 distant met le fichier déchiffré et vérifié à la disposition de l'administrateur partenaire.

Schéma illustrant la séquence de traitement des messages sortants.

Le traitement AS2 prend en charge de nombreux protocoles RFC 4130, en mettant l'accent sur les cas d'utilisation courants et l'intégration avec les implémentations de serveurs existantes AS2-enabled . Pour plus de détails sur les configurations prises en charge, consultezConfigurations AS2.

Noms et emplacements des fichiers

Cette section décrit les conventions de dénomination des fichiers pour les transferts AS2.

Pour les transferts de fichiers entrants, notez les points suivants :

  • Vous spécifiez le répertoire de base dans un accord. Le répertoire de base est le nom du compartiment Amazon S3 associé à un préfixe, le cas échéant. Par exemple, /amzn-s3-demo-bucket/AS2-folder.

  • Si un fichier entrant est traité correctement, le fichier (et le fichier JSON correspondant) est enregistré /processed dans le dossier. Par exemple, /amzn-s3-demo-bucket/AS2-folder/processed.

    Le fichier JSON contient les champs suivants :

    • 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

  • Si un fichier entrant ne peut pas être traité correctement, le fichier (et le fichier JSON correspondant) est enregistré /failed dans le dossier. Par exemple, /amzn-s3-demo-bucket/AS2-folder/failed.

  • Le fichier transféré est stocké dans le processed dossier en tant queoriginal_filename.messageId.original_extension. En d'autres termes, l'identifiant du message pour le transfert est ajouté au nom du fichier, avant son extension d'origine.

  • Un fichier JSON est créé et enregistré sousoriginal_filename.messageId.original_extension.json. Outre l'identifiant du message ajouté, la chaîne .json est ajoutée au nom du fichier transféré.

  • Un fichier d'avis de disposition des messages (MDN) est créé et enregistré sousoriginal_filename.messageId.original_extension.mdn. Outre l'identifiant du message ajouté, la chaîne .mdn est ajoutée au nom du fichier transféré.

  • S'il existe un fichier entrant nomméExampleFileInS3Payload.dat, les fichiers suivants sont créés :

    • Dossier ExampleFileInS3Payload.c4d6b6c7-23ea-4b8c-9ada-0cb811dc8b35@44313c54b0a46a36.dat

    • JSON ExampleFileInS3Payload.c4d6b6c7-23ea-4b8c-9ada-0cb811dc8b35@44313c54b0a46a36.dat.json

    • MDN — ExampleFileInS3Payload.c4d6b6c7-23ea-4b8c-9ada-0cb811dc8b35@44313c54b0a46a36.dat.mdn

Pour les transferts sortants, la dénomination est similaire, à la différence qu'il n'y a pas de fichier de messages entrants et que l'ID de transfert du message transféré est ajouté au nom du fichier. L'ID de transfert est renvoyé par l'opération d'StartFileTransferAPI (ou lorsqu'un autre processus ou script appelle cette opération).

  • transfer-idIl s'agit d'un identifiant associé à un transfert de fichier. Toutes les demandes faisant partie d'un StartFileTransfer appel partagent untransfer-id.

  • Le répertoire de base est le même que le chemin que vous utilisez pour le fichier source. En d'autres termes, le répertoire de base est le chemin que vous spécifiez dans l'opération ou la start-file-transfer AWS CLI commande de l'StartFileTransferAPI. Par exemple :

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

    Si vous exécutez cette commande, les fichiers MDN et JSON sont enregistrés dans /amzn-s3-demo-bucket/AS2-folder/processed (pour les transferts réussis) ou /amzn-s3-demo-bucket/AS2-folder/failed (pour les transferts échoués).

  • Un fichier JSON est créé et enregistré sousoriginal_filename.transferId.messageId.original_extension.json.

  • Un fichier MDN est créé et enregistré sousoriginal_filename.transferId.messageId.original_extension.mdn.

  • Si un fichier sortant est nomméExampleFileOutTestOutboundSyncMdn.dat, les fichiers suivants sont créés :

    • JSON ExampleFileOutTestOutboundSyncMdn.dedf4601-4e90-4043-b16b-579af35e0d83.fbe18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa.dat.json

    • MDN — ExampleFileOutTestOutboundSyncMdn.dedf4601-4e90-4043-b16b-579af35e0d83.fbe18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa.dat.mdn

Vous pouvez également consulter les CloudWatch journaux pour consulter les détails de vos transferts, y compris ceux qui ont échoué.

Codes d’état

Le tableau suivant répertorie tous les codes d'état qui peuvent être enregistrés dans les CloudWatch journaux lorsque vous ou votre partenaire envoyez un message AS2. Les différentes étapes de traitement des messages s'appliquent à différents types de messages et sont destinées à la surveillance uniquement. Les états COMPLETED et FAILED représentent l'étape finale du traitement et sont visibles dans les fichiers JSON.

Code Description Traitement terminé ?
TRAITEMENT Le message est en cours de conversion dans son format final. Par exemple, les étapes de décompression et de déchiffrement ont toutes deux ce statut. Non
MDN_TRANSMETTRE Le traitement des messages envoie une réponse MDN. Non
MDN_RECEIVE Le traitement des messages reçoit une réponse MDN. Non
TERMINÉ Le traitement des messages s'est terminé avec succès. Cet état inclut le moment où un MDN est envoyé pour un message entrant ou pour la vérification MDN des messages sortants. Oui
ÉCHEC Le traitement du message a échoué. Pour obtenir la liste des codes d'erreur, consultezCodes d'erreur AS2. Oui

Exemples de fichiers JSON

Cette section répertorie des exemples de fichiers JSON pour les transferts entrants et sortants, y compris des exemples de fichiers pour les transferts réussis et les transferts échoués.

Exemple de fichier sortant transféré avec succès :

{ "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" }

Exemple de fichier sortant transféré sans succès :

{ "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" }

Exemple de fichier entrant transféré avec succès :

{ "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" }

Exemple de fichier entrant transféré sans succès :

{ "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" }