Invio e ricezione di messaggi AS2

Questa sezione descrive i processi per l'invio e la ricezione di messaggi AS2. Fornisce inoltre dettagli sui nomi dei file e sulle posizioni associati ai messaggi AS2.

La tabella seguente elenca gli algoritmi di crittografia disponibili per i messaggi AS2 e quando è possibile utilizzarli.

Algoritmo di crittografia	HTTP	HTTPS	Note
AES128_CBC	Sì	Sì
AES192_CBC	Sì	Sì
AES256_CBC	Sì	Sì
DES_EDE3_CBC	Sì	Sì	Utilizzate questo algoritmo solo se dovete supportare un client legacy che lo richiede, poiché si tratta di un algoritmo di crittografia debole.
NONE	No	Sì	Se si inviano messaggi a un server Transfer Family, è possibile selezionare solo NONE se si utilizza un Application Load Balancer (ALB).

Processo di invio di messaggi AS2

Il processo in uscita è definito come un messaggio o un file inviato AWS a un client o servizio esterno. La sequenza per i messaggi in uscita è la seguente:

1. Un amministratore chiama il comando start-file-transfer AWS Command Line Interface (AWS CLI) o l'operazione StartFileTransfer API. Questa operazione fa riferimento a una connector configurazione.

2. Transfer Family rileva una nuova richiesta di file e individua il file. Il file è compresso, firmato e crittografato.

3. Un client HTTP di trasferimento esegue una richiesta HTTP POST per trasmettere il payload al server AS2 del partner.

4. Il processo restituisce la risposta MDN firmata, in linea con la risposta HTTP (MDN sincrono).

5. Man mano che il file si sposta tra le diverse fasi di trasmissione, il processo fornisce al cliente la ricevuta della risposta MDN e i dettagli di elaborazione.

6. Il server AS2 remoto mette il file decrittografato e verificato a disposizione dell'amministratore partner.

L'elaborazione AS2 supporta molti dei protocolli RFC 4130, con particolare attenzione ai casi d'uso comuni e all'integrazione con le implementazioni di server compatibili con AS2 esistenti. Per i dettagli sulle configurazioni supportate, vedere.

Processo di ricezione dei messaggi AS2

Il processo in entrata è definito come un messaggio o un file che viene trasferito sul tuo AWS Transfer Family server. La sequenza per i messaggi in entrata è la seguente:

1. Un processo amministrativo o automatizzato avvia un trasferimento di file AS2 sul server AS2 remoto del partner.

2. Il server AS2 remoto del partner firma e crittografa il contenuto del file, quindi invia una richiesta HTTP POST a un endpoint AS2 in entrata ospitato su Transfer Family.

3. Utilizzando i valori configurati per il server, i partner, i certificati e l'accordo, Transfer Family decrittografa e verifica il payload AS2. Il contenuto del file viene archiviato nell'archivio di file Amazon S3 configurato.

4. La risposta MDN firmata viene restituita in linea con la risposta HTTP o in modo asincrono tramite una richiesta HTTP POST separata al server di origine.

5. Un audit trail viene scritto su Amazon CloudWatch con i dettagli sullo scambio.

6. Il file decrittografato è disponibile in una cartella denominata. inbox/processed

Invio e ricezione di messaggi AS2 tramite HTTPS

Questa sezione descrive come configurare un server Transfer Family che utilizza il protocollo AS2 per inviare e ricevere messaggi tramite HTTPS.

Argomenti

• Invia messaggi AS2 tramite HTTPS
• Ricevi messaggi AS2 tramite HTTPS

Invia messaggi AS2 tramite HTTPS

Per inviare messaggi AS2 tramite HTTPS, crea un connettore con le seguenti informazioni:

• Per l'URL, specifica un URL HTTPS

• Per l'algoritmo di crittografia, selezionare uno degli algoritmi disponibili.

  Nota

  Per inviare messaggi a un server Transfer Family senza utilizzare la crittografia (ovvero, selezionando l'algoritmo NONE di crittografia), è necessario utilizzare un Application Load Balancer (ALB).

• Fornire i valori rimanenti per il connettore come descritto in. Configura i connettori AS2

Ricevi messaggi AS2 tramite HTTPS

AWS Transfer Family I server AS2 attualmente forniscono solo il trasporto HTTP sulla porta 5080. Tuttavia, puoi terminare TLS su un sistema di bilanciamento del carico di rete o delle applicazioni davanti all'endpoint VPC del server Transfer Family utilizzando una porta e un certificato di tua scelta. Con questo approccio, puoi fare in modo che i messaggi AS2 in arrivo utilizzino HTTPS.

Prerequisiti

• Il VPC deve trovarsi nello stesso Regione AWS server Transfer Family.

• Le sottoreti del tuo VPC devono trovarsi all'interno delle zone di disponibilità in cui desideri utilizzare il server.

  Nota

  Ogni server Transfer Family può supportare fino a tre zone di disponibilità.

• Alloca fino a tre indirizzi IP elastici nella stessa regione del server. In alternativa, puoi scegliere di utilizzare il tuo intervallo di indirizzi IP (BYOIP).

  Nota

  Il numero di indirizzi IP elastici deve corrispondere al numero di zone di disponibilità utilizzate con gli endpoint del server.

È possibile configurare un Network Load Balance (NLB) o un Application Load Balancer (ALB). La tabella seguente elenca i pro e i contro di ogni approccio.

La tabella seguente fornisce le differenze nelle funzionalità quando si utilizza un NLB rispetto a un ALB per terminare TLS.

Funzionalità	Network Load Balancer (NLB)	Application Load Balancer (ALB)
Latenza	Latenza inferiore in quanto opera a livello di rete.	Latenza più elevata in quanto opera a livello di applicazione.
Supporto per indirizzi IP statici	Può allegare indirizzi IP elastici che possono essere statici.	Impossibile collegare indirizzi IP elastici: fornisce un dominio i cui indirizzi IP sottostanti possono cambiare.
Routing avanzato	Non supporta il routing avanzato.	Supporta il routing avanzato. Può iniettare l'X-Forwarded-Protointestazione richiesta per AS2 senza crittografia. Questa intestazione è descritta in X-Forwarded-Proto sul sito web developer.mozilla.org.
Terminazione TLS/SSL	Supporta la terminazione TLS/SSL	Supporta la terminazione TLS/SSL
TLS reciproco (mTLS)	Transfer Family attualmente non supporta l'utilizzo di un NLB per MTL	Support per MTL

Configure NLB

Questa procedura descrive come configurare un Network Load Balancer (NLB) con accesso a Internet nel tuo VPC.

Per creare un Network Load Balancer e definire l'endpoint VPC del server come destinazione del load balancer

1. Apri la console Amazon Elastic Compute Cloud all'indirizzo https://console.aws.amazon.com/ec2/.

2. Dal pannello di navigazione, scegli Load Balancers, quindi scegli Create load balancer.

3. In Network Load Balancer (Sistema di bilanciamento del carico della rete), scegli Crea.

4. Nella sezione Configurazione di base, inserisci le seguenti informazioni:

   • Per Nome, inserisci un nome descrittivo per il sistema di bilanciamento del carico.

   • Per Scheme (Schema), scegliere Internet-facing.

   • Per il tipo di indirizzo IP, scegli IPv4.

5. Nella sezione Mappatura della rete, inserisci le seguenti informazioni:

   • Per VPC, scegli il cloud privato virtuale (VPC) che hai creato.

   • In Mappature, scegli le zone di disponibilità associate alle sottoreti pubbliche disponibili nello stesso VPC che usi con gli endpoint del server.

   • Per l'indirizzo IPv4 di ogni sottorete, scegli uno degli indirizzi IP elastici che hai allocato.

6. Nella sezione Listener e routing, inserite le seguenti informazioni:

   • Per Protocollo, scegli TLS.

   • Per Port (Porta), immettere 5080.

   • Per Azione predefinita, scegli Crea gruppo target. Per i dettagli sulla creazione di un nuovo gruppo target, consultaPer creare un gruppo di destinazione.

   Dopo aver creato un gruppo target, inserisci il suo nome nel campo di azione predefinito.

7. Nella sezione Impostazioni Secure listener, scegli il tuo certificato nell'area Certificato SSL/TLS predefinito.

8. Scegli Crea sistema di bilanciamento del carico per creare il tuo NLB.

9. (Facoltativo, ma consigliato) Attiva i log di accesso per Network Load Balancer per mantenere un audit trail completo, come descritto in Registri di accesso per il tuo Network Load Balancer.

   Consigliamo questo passaggio perché la connessione TLS viene interrotta all'NLB. Pertanto, l'indirizzo IP di origine riportato nei gruppi di CloudWatch log di Transfer Family AS2 è l'indirizzo IP privato dell'NLB, anziché l'indirizzo IP esterno del partner commerciale.

Configure ALB

Questa procedura descrive come configurare un Application Load Balancer (NLB) nel tuo VPC.

Per creare un Application Load Balancer e definire l'endpoint VPC del server come destinazione del load balancer

1. Apri la console Amazon Elastic Compute Cloud all'indirizzo https://console.aws.amazon.com/ec2/.

2. Dal pannello di navigazione, scegli Load Balancers, quindi scegli Create load balancer.

3. In Application Load Balancer, scegli Crea.

4. Nella console ALB, crea un nuovo listener HTTP sulla porta 443 (HTTPS).

5. (Facoltativo). Se desideri configurare l'autenticazione reciproca (MTL), configura le impostazioni di sicurezza e un trust store.

   1. Allega il tuo certificato SSL/TLS al listener.

   2. In Gestione dei certificati client, seleziona Autenticazione reciproca (mTLS).

   3. Scegli Verifica con trust store.

   4. In Impostazioni MTLS avanzate, scegli o crea un trust store caricando i tuoi certificati CA.

6. Crea un nuovo gruppo target e aggiungi gli indirizzi IP privati degli endpoint del server Transfer Family AS2 come destinazioni sulla porta 5080. Per i dettagli sulla creazione di un nuovo gruppo target, consulta. Per creare un gruppo di destinazione

7. Configura i controlli sanitari per il gruppo target in modo che utilizzi il protocollo TCP sulla porta 5080.

8. Crea una nuova regola per inoltrare il traffico HTTPS dal listener al gruppo di destinazione.

9. Configura il listener per utilizzare il tuo certificato SSL/TLS.

Dopo aver configurato il sistema di bilanciamento del carico, i client comunicano con il sistema di bilanciamento del carico tramite il listener di porta personalizzato. Quindi, il load balancer comunica con il server tramite la porta 5080.

Per creare un gruppo di destinazione

1. Dopo aver scelto Crea gruppo target nella procedura precedente, viene visualizzata la pagina Specificare i dettagli del gruppo per un nuovo gruppo target.

2. Nella sezione Configurazione di base, inserisci le seguenti informazioni.

   • Per Scegli un tipo di destinazione, scegli gli indirizzi IP.

   • In Nome gruppo di destinazione, immetti un nome per il gruppo di destinazione.

   • Per Protocol, la selezione dipende dal fatto che si stia utilizzando un ALB o un NLB.

     • Per un Network Load Balancer (NLB), scegli TCP

     • Per un Application Load Balancer (ALB), scegli HTTP

   • Per Port (Porta), immettere 5080.

   • Per il tipo di indirizzo IP, scegliete IPv4.

   • Per VPC, scegli il VPC che hai creato per il tuo server Transfer Family AS2.

3. Nella sezione Controlli sanitari, scegli TCP per il protocollo Health check.

4. Seleziona Successivo.

5. Nella pagina Registra obiettivi, inserisci le seguenti informazioni:

   • Per Network, verifica che sia specificato il VPC che hai creato per il tuo server Transfer Family AS2.

   • Per l'indirizzo IPv4, inserisci l'indirizzo IPv4 privato degli endpoint del tuo server Transfer Family AS2.

     Se hai più di un endpoint per il tuo server, scegli Aggiungi indirizzo IPv4 per aggiungere un'altra riga per l'immissione di un altro indirizzo IPv4. Ripeti questa procedura finché non avrai inserito gli indirizzi IP privati per tutti gli endpoint del server.

   • Assicurati che Ports sia impostato su. 5080

   • Scegli Includi come in sospeso di seguito per aggiungere i tuoi dati alla sezione Review targets.

6. Nella sezione Rivedi gli obiettivi, esamina i tuoi obiettivi IP.

7. Scegli Crea gruppo target, quindi torna alla procedura precedente per la creazione del tuo NLB e inserisci il nuovo gruppo target dove indicato.

Verifica l'accesso al server da un indirizzo IP elastico

Connettiti al server tramite la porta personalizzata utilizzando un indirizzo IP elastico o il nome DNS del Network Load Balancer.

Importante

Gestisci l'accesso al tuo server dagli indirizzi IP dei client utilizzando gli elenchi di controllo degli accessi alla rete (ACL di rete) per le sottoreti configurate sul load balancer. Le autorizzazioni ACL di rete sono impostate a livello di sottorete, quindi le regole si applicano a tutte le risorse che utilizzano la sottorete. Non è possibile controllare l'accesso dagli indirizzi IP dei client utilizzando i gruppi di sicurezza, poiché il tipo di destinazione del sistema di bilanciamento del carico è impostato su indirizzi IP anziché su istanze. Pertanto, il load balancer non conserva gli indirizzi IP di origine. Se i controlli di integrità del Network Load Balancer falliscono, significa che il load balancer non può connettersi all'endpoint del server. Per risolvere questo problema, controlla quanto segue:

• Verifica che il gruppo di sicurezza associato all'endpoint del server consenta le connessioni in entrata dalle sottoreti configurate sul load balancer. Il load balancer deve essere in grado di connettersi all'endpoint del server tramite la porta 5080.

• Verifica che lo stato del server sia Online.

Trasferimento di file tramite un connettore AS2

I connettori AS2 stabiliscono una relazione tra i partner commerciali per il trasferimento di messaggi AS2 da un server Transfer Family a una destinazione esterna di proprietà del partner.

È possibile utilizzare Transfer Family per inviare messaggi AS2 facendo riferimento all'ID del connettore e ai percorsi dei file, come illustrato nel seguente comando start-file-transfer AWS Command Line Interface ()AWS CLI:

aws transfer start-file-transfer --connector-id c-1234567890abcdef0 \
--send-file-paths "/DOC-EXAMPLE-SOURCE-BUCKET/myfile1.txt" "/DOC-EXAMPLE-SOURCE-BUCKET/myfile2.txt"

Per ottenere i dettagli dei connettori, esegui il seguente comando:

aws transfer list-connectors

Il list-connectors comando restituisce gli ID dei connettori, gli URL e gli Amazon Resource Names (ARN) per i connettori.

Per restituire le proprietà di un particolare connettore, esegui il comando seguente con l'ID che desideri utilizzare:

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

Il describe-connector comando restituisce tutte le proprietà del connettore, inclusi l'URL, i ruoli, i profili, gli mDNS (Message Disposition Notices), i tag e le metriche di monitoraggio.

È possibile confermare che il partner ha ricevuto correttamente i file visualizzando i file JSON e MDN. Questi file sono denominati in base alle convenzioni descritte in. Nomi e posizioni dei file Se hai configurato un ruolo di registrazione quando hai creato il connettore, puoi anche controllare CloudWatch nei log lo stato dei messaggi AS2.

Per visualizzare i dettagli del connettore AS2, vedere. Visualizza i dettagli del connettore AS2 Per ulteriori informazioni sulla creazione di connettori AS2, vedere. Configura i connettori AS2

Nomi e posizioni dei file

Questa sezione illustra le convenzioni di denominazione dei file per i trasferimenti AS2.

Per i trasferimenti di file in entrata, tenete presente quanto segue:

• Si specifica la directory di base in un accordo. La directory di base è il nome del bucket Amazon S3 combinato con un prefisso, se presente. Ad esempio, /DOC-EXAMPLE-BUCKET/AS2-folder.

• Se un file in entrata viene elaborato correttamente, il file (e il file JSON corrispondente) viene salvato nella cartella. /processed Ad esempio, /DOC-EXAMPLE-BUCKET/AS2-folder/processed.

  Il file JSON contiene i seguenti campi:

  • 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

• Se un file in entrata non può essere elaborato correttamente, il file (e il file JSON corrispondente) viene salvato nella cartella. /failed Ad esempio, /DOC-EXAMPLE-BUCKET/AS2-folder/failed.

• Il file trasferito viene archiviato nella processed cartella come. original_filename.messageId.original_extension Cioè, l'ID del messaggio per il trasferimento viene aggiunto al nome del file, prima dell'estensione originale.

• Un file JSON viene creato e salvato come. original_filename.messageId.original_extension.json Oltre all'ID del messaggio aggiunto, la stringa .json viene aggiunta al nome del file trasferito.

• Un file MDN (Message Disposition Notice) viene creato e salvato come. original_filename.messageId.original_extension.mdn Oltre all'ID del messaggio aggiunto, la stringa .mdn viene aggiunta al nome del file trasferito.

• Se è presente un file in entrata denominatoExampleFileInS3Payload.dat, vengono creati i seguenti file:

  • File — [e-mail]

  • JSON — [e-mail]

  • MDN — [e-mail]

Per i trasferimenti in uscita, la denominazione è simile, con la differenza che non esiste un file di messaggi in entrata e inoltre, l'ID di trasferimento per il messaggio trasferito viene aggiunto al nome del file. L'ID di trasferimento viene restituito dall'operazione StartFileTransfer API (o quando un altro processo o script richiama questa operazione).

• transfer-idè un identificatore associato a un trasferimento di file. Tutte le richieste che fanno parte di una StartFileTransfer chiamata condividono untransfer-id.

• La directory di base è la stessa del percorso utilizzato per il file sorgente. In altre parole, la directory di base è il percorso specificato nell'operazione o nel start-file-transfer AWS CLI comando StartFileTransfer API. Per esempio:

  aws transfer start-file-transfer --send-file-paths /DOC-EXAMPLE-BUCKET/AS2-folder/file-to-send.txt

  Se si esegue questo comando, i file MDN e JSON vengono salvati in /DOC-EXAMPLE-BUCKET/AS2-folder/processed (per trasferimenti riusciti) o /DOC-EXAMPLE-BUCKET/AS2-folder/failed (per trasferimenti non riusciti).

• Un file JSON viene creato e salvato come. original_filename.transferId.messageId.original_extension.json

• Un file MDN viene creato e salvato come. original_filename.transferId.messageId.original_extension.mdn

• Se esiste un file in uscita denominatoExampleFileOutTestOutboundSyncMdn.dat, vengono creati i seguenti file:

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

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

Puoi anche controllare CloudWatch i log per visualizzare i dettagli dei tuoi trasferimenti, compresi quelli che non sono andati a buon fine.

Codici di stato

La tabella seguente elenca tutti i codici di stato che possono essere registrati nei CloudWatch log quando tu o il tuo partner inviate un messaggio AS2. Le diverse fasi di elaborazione dei messaggi si applicano a diversi tipi di messaggi e sono destinate esclusivamente al monitoraggio. Gli stati COMPLETED e FAILED rappresentano la fase finale dell'elaborazione e sono visibili nei file JSON.

Codice	Descrizione	Elaborazione completata?
IN ELABORAZIONE	Il messaggio è in fase di conversione nel formato finale. Ad esempio, le fasi di decompressione e decrittografia hanno entrambe questo stato.	No
MDN_TRANSMITX	L'elaborazione dei messaggi consiste nell'invio di una risposta MDN.	No
MDN_RECEIVE	L'elaborazione dei messaggi sta ricevendo una risposta MDN.	No
COMPLETED	L'elaborazione dei messaggi è stata completata correttamente. Questo stato include l'invio di un MDN per un messaggio in entrata o per la verifica MDN dei messaggi in uscita.	Sì
Non riuscito	L'elaborazione dei messaggi non è riuscita. Per un elenco dei codici di errore, vedereCodici di errore AS2.	Sì

File JSON di esempio

Questa sezione elenca file JSON di esempio per i trasferimenti in entrata e in uscita, inclusi file di esempio per trasferimenti riusciti e trasferimenti non riusciti.

File in uscita di esempio che è stato trasferito correttamente:

{
  "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": "/DOC-EXAMPLE-BUCKET/as2testcell0000/openAs2/TestOutboundSyncMdn-9lmCr79hV.dat",
  "as2-message-id": "fbe18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa",
  "timestamp": "2022-07-11T06:30:10.791274Z"
}

Esempio di file in uscita che non è stato trasferito correttamente:

{
  "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": "/DOC-EXAMPLE-BUCKET-4c1tq6ohjt9y/as2IntegCell0002/openAs2/openAs2TestOutboundWrongAs2Ids-necco-3VYn5n8wE.dat",
  "timestamp": "2022-07-11T21:17:24.802378Z"
}

Esempio di file in entrata trasferito correttamente:

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

Esempio di file in entrata che non è stato trasferito correttamente:

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