Invio e ricezione AS2 di messaggi

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

Processo di invio AS2 dei messaggi

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'StartFileTransferAPIoperazione. 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 HTTP client di trasferimento esegue una HTTP POST richiesta per trasmettere il payload al server del AS2 partner.

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

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

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

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

Procedura 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 HTTP POST richiesta 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 MDN risposta firmata viene restituita in linea con la HTTP risposta o in modo asincrono tramite una HTTP POST richiesta 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 AS2 di messaggi tramite HTTPS

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

Invia AS2 messaggi tramite HTTPS

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

• Per ilURL, specificare un HTTPS URL

• Per l'algoritmo di crittografia, specificareNONE.

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

Ricevi AS2 messaggi tramite HTTPS

AWS Transfer Family AS2i server attualmente forniscono solo il HTTP trasporto tramite la porta 5080. Tuttavia, puoi terminare TLS utilizzando un sistema di bilanciamento del carico davanti all'VPCendpoint del server Transfer Family utilizzando una porta e un certificato di tua scelta. Con questo approccio, puoi utilizzare i messaggi in AS2 arrivo. HTTPS

Prerequisiti

• VPCDeve trovarsi nello Regione AWS stesso server Transfer Family.

• Le sottoreti del server VPC devono trovarsi all'interno delle zone di disponibilità in cui si desidera 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 inserire 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.

Configura il tuo Network Load Balancer

Configura un Network Load Balancer NLB () con accesso a Internet nel tuo. VPC

Per creare un Network Load Balancer e definire l'VPCendpoint 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 nelle stesse VPC che utilizzi con gli endpoint del server.

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

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

   • In Protocol (Protocollo), seleziona 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 DefaultSSL/TLScertificate.

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 TLS connessione viene interrotta al. NLB Pertanto, l'indirizzo IP di origine riportato nei tuoi gruppi di AS2 CloudWatch log Transfer Family è l'indirizzo IP privato NLB del tuo partner commerciale, anziché l'indirizzo IP esterno del tuo partner commerciale.

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.

   • In Protocol (Protocollo), seleziona TCP.

   • Per Port (Porta), immettere 5080.

   • Per Tipo di indirizzo IP, scegli IPv4.

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

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

4. Scegli Next (Successivo).

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

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

   • Per IPv4l'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 creare il 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 DNS nome del Network Load Balancer.

Importante

Gestisci l'accesso al tuo server dagli indirizzi IP dei client utilizzando le liste di controllo degli accessi alla rete (reteACLs) per le sottoreti configurate sul load balancer. Le ACL autorizzazioni 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 sugli indirizzi IP anziché sulle 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

AS2i 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 "/DOC-EXAMPLE-SOURCE-BUCKET/myfile1.txt" "/DOC-EXAMPLE-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 ruoliURL, profili, Message Disposition Notices (MDNs), tag e metriche di monitoraggio.

È possibile verificare che il partner abbia ricevuto correttamente i file visualizzando i file and. JSON MDN Questi file sono denominati in base alle convenzioni descritte inNomi 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.

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 JSON file corrispondente) viene salvato nella cartella. /processed Ad esempio /DOC-EXAMPLE-BUCKET/AS2-folder/processed.

  Il JSON file 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 JSON file corrispondente) viene salvato nella /failed cartella. Ad esempio /DOC-EXAMPLE-BUCKET/AS2-folder/failed.

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

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

• Un file Message Disposition Notice (MDN) 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'StartFileTransferAPIoperazione (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'StartFileTransferAPIoperazione o nel start-file-transfer AWS CLI comando. Per esempio:

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

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

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

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

• Se è presente 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 registri per visualizzare i dettagli dei tuoi trasferimenti, compresi quelli non riusciti.

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. FAILEDGli stati COMPLETED and rappresentano la fase finale dell'elaborazione e sono visibili nei JSON file.

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

JSONFile di esempio

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

File in uscita di esempio che è stato trasferito correttamente:

{
  "requester-content-type": "application/octet-stream",
  "mesage-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 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": "/testbucket-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"
}