Enviar y recibir AS2 mensajes - AWS Transfer Family

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Enviar y recibir AS2 mensajes

En esta sección se describen los procesos de envío y recepción de AS2 mensajes. También proporciona detalles sobre los nombres de los archivos y las ubicaciones asociadas a AS2 los mensajes.

Proceso de envío de AS2 mensajes

El proceso saliente se define como un mensaje o archivo que se envía AWS a un cliente o servicio externo. La secuencia de los mensajes salientes es la siguiente:

  1. Un administrador llama al comando start-file-transfer AWS Command Line Interface (AWS CLI) o a la StartFileTransfer API operación. Esta operación hace referencia a una configuración connector.

  2. Transfer Family detecta una nueva solicitud de archivo y localiza el archivo. El archivo está comprimido, firmado y cifrado.

  3. Un HTTP cliente de transferencia realiza una HTTP POST solicitud para transmitir la carga útil al AS2 servidor del socio.

  4. El proceso devuelve la MDN respuesta firmada, en línea con la HTTP respuesta (sincrónicaMDN).

  5. A medida que el archivo pasa de una fase a otra de la transmisión, el proceso entrega al cliente el recibo de MDN respuesta y los detalles del procesamiento.

  6. El AS2 servidor remoto pone el archivo descifrado y verificado a disposición del administrador asociado.

Diagrama que muestra la secuencia de procesamiento de los mensajes salientes.

AS2El procesamiento es compatible con muchos de los protocolos RFC 4130 y se centra en los casos de uso comunes y en la integración con las implementaciones de servidores AS2 compatibles existentes. Para más información sobre las configuraciones compatibles, consulte AS2configuraciones compatibles.

Proceso de recepción de mensajes AS2

El proceso entrante se define como un mensaje o un archivo que se transfiere a tu AWS Transfer Family servidor. La secuencia de los mensajes entrantes es la siguiente:

  1. Un proceso automatizado o de administración inicia una transferencia de AS2 archivos en el AS2 servidor remoto del socio.

  2. El AS2 servidor remoto del socio firma y cifra el contenido del archivo y, a continuación, envía una HTTP POST solicitud a un punto final AS2 entrante alojado en Transfer Family.

  3. Mediante los valores configurados para el servidor, los socios, los certificados y el acuerdo, Transfer Family descifra y verifica la AS2 carga útil. El contenido del archivo se almacena en el almacén de archivos configurado de Amazon S3.

  4. La MDN respuesta firmada se devuelve en línea con la HTTP respuesta o de forma asíncrona mediante una solicitud independiente HTTP POST al servidor de origen.

  5. Se escribe un registro de auditoría a Amazon CloudWatch con detalles sobre el intercambio.

  6. El archivo descifrado está disponible en una carpeta llamada inbox/processed.

Diagrama que muestra la secuencia de procesamiento de los mensajes entrantes.

Enviar y recibir AS2 mensajes a través de HTTPS

En esta sección se describe cómo configurar un servidor Transfer Family que utilice el AS2 protocolo para enviar y recibir mensajes a través de élHTTPS.

Envía AS2 mensajes a través de HTTPS

Para enviar AS2 mensajes medianteHTTPS, cree un conector con la siguiente información:

  • Para elURL, especifique un HTTPS URL

  • Para el algoritmo de cifrado, especifique NONE.

  • Proporcione los valores restantes para el conector tal y como se describe en Configure AS2 los conectores.

Reciba AS2 mensajes a través de HTTPS

AWS Transfer Family AS2los servidores actualmente solo proporcionan HTTP transporte a través del puerto 5080. Sin embargo, puede terminar TLS en un balanceador de carga frente al VPC punto final del servidor Transfer Family mediante el puerto y el certificado que prefiera. Con este enfoque, puede hacer que se utilicen AS2 HTTPS los mensajes entrantes.

Requisitos previos 

  • VPCDebe estar en el Región de AWS mismo servidor de Transfer Family.

  • Sus subredes VPC deben estar dentro de las zonas de disponibilidad en las que quiere usar su servidor.

    nota

    Cada servidor Transfer Family admite hasta tres zonas de disponibilidad.

  • Asigne hasta tres direcciones IP elásticas en la misma región que su servidor. O bien, puede optar por utilizar su propio rango de direcciones IP (BYOIP).

    nota

    La cantidad de direcciones IP elásticas debe coincidir con la cantidad de zonas de disponibilidad que utilice con los puntos de conexión del servidor.

Configuración de un equilibrador de carga de red

Configure un Network Load Balancer NLB () con acceso a Internet en su. VPC

Para crear un Network Load Balancer y definir el VPC punto final del servidor como destino del balanceador de carga
  1. Abra la consola de Amazon Elastic Compute Cloud en https://console.aws.amazon.com/ec2/.

  2. En el panel de navegación, elija Equilibradores de carga y, a continuación, elija Crear equilibrador de carga.

  3. En equilibrador de carga de red, seleccione Crear.

  4. En la sección Configuración básica, introduzca la siguiente información:

    • En Nombre, escriba el nombre del equilibrador de carga.

    • En Scheme, elija Internet-facing.

    • En IP address type ((Tipo de dirección IP), elija IPv4.

  5. En la sección Asignaciones de red, escriba la siguiente información:

    • Para VPC, elija la nube privada virtual (VPC) que creó.

    • En Mapeos, elija las zonas de disponibilidad asociadas a las subredes públicas que están disponibles en las mismas VPC que utiliza con los puntos finales de sus servidores.

    • Para la IPv4dirección de cada subred, elija una de las direcciones IP elásticas que haya asignado.

  6. En la sección Oyentes y rutas, escriba la siguiente información:

    • En Protocol (Protocolo), elija TLS.

    • En Puerto, escriba 5080.

    • En Acción predeterminada, elija Crear grupo objetivo. Para obtener información detallada sobre la creación de un nuevo grupo objetivo, consulte Creación de un grupo de destino.

    Tras crear un grupo objetivo, introduzca su nombre en el campo Acción predeterminada.

  7. En la sección de configuración de Secure Listener, elija su certificado en el área PredeterminadoSSL/TLScertificado.

  8. Selecciona Crear balanceador de cargas para crear el tuyo. NLB

  9. (Opcional, pero recomendado) Active los registros de acceso del equilibrador de carga de red para mantener un registro de auditoría completo, tal y como se describe en los registros de acceso del equilibrador de carga de red.

    Recomendamos este paso porque la TLS conexión finaliza en elNLB. Por lo tanto, la dirección IP de origen que se refleja en sus grupos de AS2 CloudWatch registro de Transfer Family NLB es la dirección IP privada, en lugar de la dirección IP externa de su socio comercial.

Tras configurar el equilibrador de carga, los clientes se comunican con el equilibrador de carga a través del receptor de puertos personalizado. A continuación, el equilibrador de carga se comunica con el servidor a través del puerto 5080.

Creación de un grupo de destino
  1. Tras seleccionar Crear grupo de destino en el procedimiento anterior, accederá a la página Especificar los detalles del grupo para un nuevo grupo objetivo.

  2. En la sección Configuración básica, introduzca la siguiente información:

    • En Elegir un tipo de destino, elija Direcciones IP.

    • En Nombre del grupo de destino, escriba el nombre del grupo de destino.

    • En Protocol (Protocolo), elija TCP.

    • En Puerto, escriba 5080.

    • En IP address type ((Tipo de dirección IP), elija IPv4.

    • Para VPC, elija el VPC que creó para su AS2 servidor Transfer Family.

  3. En la sección Health checks, elige TCPel protocolo Health Check.

  4. Elija Next (Siguiente).

  5. En la página Registrar objetivos, escriba la siguiente información:

    • Para Network, confirme que esté especificado el VPC que creó para su AS2 servidor Transfer Family.

    • Como IPv4dirección, introduce la IPv4 dirección privada de los puntos finales de tu AS2 servidor Transfer Family.

      Si tiene más de un punto final para su servidor, elija Agregar IPv4 dirección para agregar otra fila para ingresar otra IPv4 dirección. Repita este proceso hasta que haya introducido las direcciones IP privadas de todos los puntos de conexión del servidor.

    • Asegúrese de que Puertos esté configurado en 5080.

    • Seleccione Incluir como pendiente a continuación para añadir sus entradas a la sección Revisar objetivos.

  6. En la sección Revisar objetivos, revise sus objetivos de IP.

  7. Seleccione Crear grupo objetivo y, a continuación, vuelva al procedimiento anterior para crear el suyo NLB e introduzca el nuevo grupo objetivo donde se indica.

Prueba del acceso al servidor desde una dirección IP elástica

Conéctese al servidor a través del puerto personalizado mediante una dirección IP elástica o el DNS nombre del Network Load Balancer.

importante

Gestione el acceso al servidor desde las direcciones IP de los clientes mediante las listas de control de acceso a la red (redACLs) de las subredes configuradas en el balanceador de cargas. Los ACL permisos de red se establecen a nivel de subred, por lo que las reglas se aplican a todos los recursos que utilizan la subred. No puede controlar el acceso desde las direcciones IP de los clientes mediante grupos de seguridad, ya que el tipo de destino del equilibrador de carga se establece en Direcciones IP en lugar de en instancias. Por tanto, el equilibrador de carga no conserva las direcciones IP de origen. Si las comprobaciones de estado del equilibrador de carga de red fallan, significa que el equilibrador de carga no puede conectarse al punto de conexión del servidor. Para solucionar este problema, compruebe lo siguiente:

  • Confirme que el grupo de seguridad asociado al punto de conexión del servidor permita las conexiones entrantes desde las subredes que están configuradas en el equilibrador de carga. El equilibrador de carga debe poder conectarse al punto de conexión del servidor a través del puerto 5080.

  • Confirme que el Estado esté en línea.

Transferencia de archivos mediante un conector AS2

AS2los conectores establecen una relación entre los socios comerciales para la transferencia de AS2 mensajes desde un servidor Transfer Family a un destino externo propiedad del socio.

Puedes usar Transfer Family para enviar AS2 mensajes haciendo referencia al ID del conector y a las rutas de acceso a los archivos, como se muestra en el siguiente 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"

Para obtener los detalles de los conectores, ejecute el siguiente comando:

aws transfer list-connectors

El list-connectors comando devuelve el conector IDs y los nombres de recursos de Amazon (ARNs) de los conectores. URLs

Para devolver las propiedades de un conector concreto, ejecute el siguiente comando con el ID que desee usar:

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

El describe-connector comando devuelve todas las propiedades del conector, incluidas sus funcionesURL, perfiles, avisos de disposición de mensajes (MDNs), etiquetas y métricas de monitoreo.

Para confirmar que el socio ha recibido correctamente los archivos, consulte los MDN archivos JSON y. Estos archivos se nombran de acuerdo con las convenciones descritas en Nombres y ubicaciones de los archivos. Si configuró una función de registro al crear el conector, también puede comprobar el estado de los AS2 mensajes en sus CloudWatch registros.

Para ver los detalles AS2 del conector, consulteVea los detalles AS2 del conector. Para obtener más información sobre la creación de AS2 conectores, consulteConfigure AS2 los conectores.

Nombres y ubicaciones de los archivos

En esta sección se describen las convenciones de nomenclatura de archivos para AS2 las transferencias.

En cuanto a las transferencias de archivos entrantes, tenga en cuenta lo siguiente:

  • El directorio base se especifica en un acuerdo. El directorio base es el nombre del bucket de Amazon S3 combinado con un prefijo, si lo hubiera. Por ejemplo, /DOC-EXAMPLE-BUCKET/AS2-folder.

  • Si un archivo entrante se procesa correctamente, el archivo (y el JSON archivo correspondiente) se guardan en la /processed carpeta. Por ejemplo, /DOC-EXAMPLE-BUCKET/AS2-folder/processed.

    El JSON archivo contiene los siguientes campos:

    • 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 archivo entrante no se puede procesar correctamente, el archivo (y el JSON archivo correspondiente) se guardan en la /failed carpeta. Por ejemplo, /DOC-EXAMPLE-BUCKET/AS2-folder/failed.

  • El archivo transferido se guarda en la carpeta processed como original_filename.messageId.original_extension. Es decir, el identificador del mensaje de la transferencia se añade al nombre del archivo, antes de su extensión original.

  • Se crea un JSON archivo y se guarda comooriginal_filename.messageId.original_extension.json. Además de añadir el identificador del mensaje, la cadena .json se añade al nombre del archivo transferido.

  • Se crea un archivo de aviso de disposición de mensajes (MDN) y se guarda comooriginal_filename.messageId.original_extension.mdn. Además de añadir el identificador del mensaje, la cadena .mdn se añade al nombre del archivo transferido.

  • Si hay un archivo entrante con el nombre ExampleFileInS3Payload.dat, se crean los siguientes archivos:

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

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

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

En el caso de las transferencias salientes, el nombre es similar, con la diferencia de que no hay ningún archivo de mensajes entrantes y, además, el identificador de transferencia del mensaje transferido se añade al nombre del archivo. La StartFileTransfer API operación devuelve el identificador de transferencia (o cuando otro proceso o script llama a esta operación).

  • El transfer-id es un identificador que está asociado a una transferencia de archivos. Todas las solicitudes que forman parte de una llamada StartFileTransfer comparten un transfer-id.

  • El directorio base es el mismo que la ruta que se utiliza para el archivo fuente. Es decir, el directorio base es la ruta que se especifica en la StartFileTransfer API operación o el start-file-transfer AWS CLI comando. Por ejemplo:

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

    Si ejecuta este comando MDN y JSON los archivos se guardan en /DOC-EXAMPLE-BUCKET/AS2-folder/processed (si las transferencias se realizan correctamente) o /DOC-EXAMPLE-BUCKET/AS2-folder/failed (si las transferencias no se realizan correctamente).

  • Se crea un JSON archivo y se guarda comooriginal_filename.transferId.messageId.original_extension.json.

  • Se crea un MDN archivo y se guarda comooriginal_filename.transferId.messageId.original_extension.mdn.

  • Si hay un archivo de salida con nombre ExampleFileOutTestOutboundSyncMdn.dat, se crean los siguientes archivos:

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

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

También puedes consultar los CloudWatch registros para ver los detalles de tus transferencias, incluidas las que hayan fallado.

Códigos de estado

En la siguiente tabla se enumeran todos los códigos de estado que se pueden registrar en los CloudWatch registros cuando tú o tu pareja enviáis un AS2 mensaje. Los diferentes pasos de procesamiento de mensajes se aplican a diferentes tipos de mensajes y están destinados únicamente a la supervisión. Los FAILED estados COMPLETED y representan el paso final del procesamiento y están visibles en JSON los archivos.

Código Descripción ¿Se ha completado el procesamiento?
PROCESSING El mensaje está en proceso de convertirse a su formato final. Por ejemplo, los pasos de descompresión y descifrado tienen este estado. No
MDN_TRANSMIT El procesamiento del mensaje envía una MDN respuesta. No
MDN_RECEIVE El procesamiento de mensajes está recibiendo una MDN respuesta. No
COMPLETED El procesamiento del mensaje se ha completado correctamente. Este estado incluye cuando MDN se envía una para un mensaje entrante o para la MDN verificación de los mensajes salientes.
FAILED Se ha producido un error en el procesamiento del mensaje. Para obtener una lista de códigos de error, consulteCódigos de error de AS2.

JSONArchivos de ejemplo

En esta sección se enumeran JSON los archivos de ejemplo para las transferencias entrantes y salientes, incluidos los archivos de muestra para las transferencias correctas y las transferencias que no se realizan correctamente.

Ejemplo de archivo saliente que se transfirió correctamente:

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

Ejemplo de archivo saliente que se transfirió sin éxito:

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

Ejemplo de archivo entrante que se ha transferido correctamente:

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

Ejemplo de archivo entrante que se transfirió sin éxito:

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