Invio e ricezione AS2 di messaggi

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

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

Algoritmo di crittografia	HTTP	HTTPS	Note
AES128_CBC	Sì	Sì
AES192_CBC	Sì	Sì
AES256_CBC	Sì	Sì
DES_ _CBC EDE3	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 ricezione AS2 dei messaggi

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 AS2 file sul AS2 server remoto del partner.

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

3. Utilizzando i valori configurati per il server, i partner, i certificati e il contratto, 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 AS2 messaggi tramite HTTPS

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

Argomenti

• Inviare AS2 messaggi tramite HTTPS

• Ricevi AS2 messaggi tramite HTTPS

Inviare AS2 messaggi tramite HTTPS

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

• Per l'URL, specificate 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 AS2 connettori

Ricevi AS2 messaggi tramite HTTPS

AWS Transfer Family AS2 i server attualmente forniscono solo il trasporto HTTP tramite la 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 in arrivo utilizzino HTTPS. AS2

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 senza crittografia. AS2 Questa intestazione è descritta in X-Forwarded-Proto sul sito web developer.mozilla.org.
Terminazione TLS/SSL	Supporta la TLS/SSL terminazione	Supporta la TLS/SSL terminazione
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 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'IPv4 indirizzo di ogni sottorete, scegli uno degli indirizzi IP elastici che hai allocato.

6. Nella sezione Listener and 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 SSL/TLS Certificato 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 tuoi gruppi di AS2 CloudWatch log Transfer Family è l'indirizzo IP privato di NLB, anziché l'indirizzo IP esterno del tuo partner commerciale.

Configure ALB

Questa procedura descrive come configurare un Application Load Balancer (ALB) 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 SSL/TLS certificato all'ascoltatore.

   2. In Gestione dei certificati del 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 AS2 server Transfer Family 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 di integrità per il gruppo target in modo che utilizzi il protocollo HTTP 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 Tipo di indirizzo IP, scegli IPv4.

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

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

   • Per un ALB, scegli HTTP

   • Per un NLB, scegli TCP

4. Scegli Next (Successivo).

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

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

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

     Se hai più di un endpoint per il tuo server, scegli Aggiungi IPv4 indirizzo per aggiungere un'altra riga per l'immissione di un altro IPv4 indirizzo. 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 (rete ACLs) 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

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

È possibile utilizzare Transfer Family per inviare AS2 messaggi 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 "/amzn-s3-demo-source-bucket/myfile1.txt" "/amzn-s3-demo-source-bucket/myfile2.txt"

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

aws transfer list-connectors

Il list-connectors comando restituisce il connettore IDs e Amazon Resource Names (ARNs) per i connettori. URLs

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 avvisi di disposizione dei messaggi (MDNs), 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 AS2 del connettore, vedere. Visualizza i dettagli AS2 del connettore Per ulteriori informazioni sulla creazione di AS2 connettori, vedereConfigura i AS2 connettori.

Per inviare un messaggio AS2 in uscita

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 del AS2 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 AS2 server remoto mette il file decrittografato e verificato a disposizione dell'amministratore partner.

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

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, /amzn-s3-demo-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, /amzn-s3-demo-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, /amzn-s3-demo-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 /amzn-s3-demo-bucket/AS2-folder/file-to-send.txt

  Se si esegue questo comando, i file MDN e JSON vengono salvati in /amzn-s3-demo-bucket/AS2-folder/processed (per trasferimenti riusciti) o /amzn-s3-demo-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, vedereAS2 codici di errore.	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": "/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"
}

Esempio di file in uscita trasferito senza successo:

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

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 trasferito senza successo:

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