Envío y recepción de mensajes AS2

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

En la siguiente tabla se enumeran los algoritmos de cifrado disponibles para los mensajes AS2 y cuándo se pueden utilizar.

Algoritmo de cifrado	HTTP	HTTPS	Notas
AES128_CBC	Sí	Sí
AES192_CBC	Sí	Sí
AES256_CBC	Sí	Sí
DES_EDE3_CBC	Sí	Sí	Utilice este algoritmo únicamente si debe admitir un cliente antiguo que lo requiera, ya que es un algoritmo de cifrado débil.
NONE	No	Sí	Si envía mensajes a un servidor de Transfer Family, solo puede seleccionar NONE si utiliza un Application Load Balancer (ALB).

Proceso de envío de mensajes AS2

El proceso de salida 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 operación de la StartFileTransfer API. 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 cliente HTTP de transferencia realiza una solicitud HTTP POST para transmitir la carga útil al servidor AS2 del socio.

4. El proceso devuelve la respuesta MDN firmada, en línea con la respuesta HTTP (MDN síncrona).

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

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

El procesamiento AS2 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 compatibles con AS2 existentes. Para más información sobre las configuraciones compatibles, consulte .

Proceso de recepción de mensajes AS2

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

1. Un proceso automatizado o de administración inicia un AS2 file transfer en el servidor AS2 remoto del socio.

2. El servidor AS2 remoto del socio firma y cifra el contenido del archivo y, a continuación, envía una solicitud HTTP POST a un punto de conexión de entrada AS2 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 carga útil del AS2. El contenido del archivo se almacena en el almacén de archivos configurado de Amazon S3.

4. La respuesta MDN firmada se devuelve en línea con la respuesta HTTP o de forma asíncrona mediante una solicitud HTTP POST independiente 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.

Enviar y recibir mensajes de AS2 a través de HTTPS

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

Temas

• Enviar mensajes de AS2 a través de HTTPS
• Recibir mensajes de AS2 a través de HTTPS

Enviar mensajes de AS2 a través de HTTPS

Para enviar mensajes de AS2 mediante HTTPS, cree un conector con la siguiente información:

• Para la URL, especifique una URL HTTPS

• Para el algoritmo de cifrado, selecciona cualquiera de los algoritmos disponibles.

  nota

  Para enviar mensajes a un servidor Transfer Family sin utilizar el cifrado (es decir, si selecciona el algoritmo NONE de cifrado), debe utilizar un Application Load Balancer (ALB).

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

Recibir mensajes de AS2 a través de HTTPS

AWS Transfer Family Actualmente, los servidores AS2 solo proporcionan transporte HTTP a través del puerto 5080. Sin embargo, puede finalizar el TLS en un balanceador de carga de redes o aplicaciones frente al punto final de VPC del servidor Transfer Family mediante el puerto y el certificado que prefiera. Con este método, puede hacer que los mensajes de AS2 entrantes utilicen HTTPS.

Requisitos previos 

• La VPC debe estar en el mismo lugar que su Región de AWS servidor Transfer Family.

• Las subredes de la VPC deben estar dentro de las zonas de disponibilidad en las que desee utilizar el 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 puede optar por traer su propio intervalo 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.

Puede configurar un Network Load Balance (NLB) o un Application Load Balancer (ALB). En la siguiente tabla se enumeran las ventajas y desventajas de cada enfoque.

En la siguiente tabla se muestran las diferencias en las capacidades cuando se utiliza un NLB y un ALB para finalizar el TLS.

Característica	Network Load Balancer (NLB)	Application Load Balancer (ALB)
Latencia	Menor latencia, ya que funciona en la capa de red.	Mayor latencia, ya que funciona en la capa de aplicación.
Compatibilidad con direcciones IP estáticas	Puede adjuntar direcciones IP elásticas que pueden ser estáticas.	No se pueden adjuntar direcciones IP elásticas: proporciona un dominio cuyas direcciones IP subyacentes pueden cambiar.
Enrutamiento avanzado	No admite el enrutamiento avanzado.	Admite el enrutamiento avanzado. Puede inyectar el X-Forwarded-Proto encabezado necesario para el AS2 sin cifrado. Este encabezado se describe en X-Forwarded-Proto en el sitio web developer.mozilla.org.
Terminación de TLS/SSL	Soporta la terminación de TLS/SSL	Soporta la terminación de TLS/SSL
TLS mutuo (mTLS)	Transfer Family no admite actualmente el uso de un NLB para los mTLs	Support for mTLS

Configure NLB

Este procedimiento describe cómo configurar un Network Load Balancer (NLB) con acceso a Internet en la VPC.

Creación de un equilibrador de carga de red y definición del punto de conexión de VPC del servidor como destino del equilibrador 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 Tipo de dirección IP, elija ipv4.

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

   • En VPC, elija la nube privada virtual (VPC) que haya creado.

   • En Asignaciones, elija las zonas de disponibilidad asociadas a las subredes públicas que están disponibles en la misma VPC que utiliza con los puntos de conexión del servidor.

   • Para la dirección IPv4 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, 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 Configuración de oyente seguro, elija su certificado en el área de Certificados SSL/TLS predeterminados.

8. Elija Crear un equilibrador de carga para crear el equilibrador de carga de red.

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 conexión TLS finaliza en el NLB. Por lo tanto, la dirección IP de origen que se refleja en sus grupos de CloudWatch registros AS2 de Transfer Family es la dirección IP privada del NLB, en lugar de la dirección IP externa de su socio comercial.

Configure ALB

Este procedimiento describe cómo configurar un Application Load Balancer (NLB) en la VPC.

Para crear un Application Load Balancer y definir el punto final de VPC 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 aplicación, elija Create (Crear).

4. En la consola ALB, crea un nuevo agente de escucha HTTP en el puerto 443 (HTTPS).

5. (Opcional). Si desea configurar la autenticación mutua (mTLS), configure los ajustes de seguridad y un almacén de confianza.

   1. Adjunte su certificado SSL/TLS al listener.

   2. En Gestión de certificados de cliente, selecciona Autenticación mutua (mTLS).

   3. Elige Verificar con un almacén de confianza.

   4. En Configuración avanzada de mTLS, elija o cree un almacén de confianza cargando sus certificados de CA.

6. Cree un nuevo grupo de destino y añada las direcciones IP privadas de los puntos finales del servidor AS2 de Transfer Family como destinos en el puerto 5080. Para obtener información detallada sobre la creación de un nuevo grupo objetivo, consulte Creación de un grupo de destino.

7. Configure las comprobaciones de estado para que el grupo de destino utilice el protocolo TCP en el puerto 5080.

8. Cree una nueva regla para reenviar el tráfico HTTPS del agente de escucha al grupo de destino.

9. Configure el agente de escucha para que utilice su certificado SSL/TLS.

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 cuanto al protocolo, su selección depende de si utiliza un ALB o un NLB.

     • Para un Network Load Balancer (NLB), elija TCP

     • Para un Application Load Balancer (ALB), elija HTTP

   • En Puerto, escriba 5080.

   • En Tipo de dirección IP, elija ipv4.

   • En VPC, elija la VPC que ha creado para el servidor AS2 de Transfer Family.

3. En la sección Comprobación de estado, elija TCP para el protocolo de comprobación de estado.

4. Elija Siguiente.

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

   • Para Red, confirme que esté especificada la VPC que creó para el servidor AS2 de Transfer Family.

   • Para Dirección IPv4, introduzca la dirección IPv4 privada de los puntos de conexión de su servidor Transfer Family AS2.

     Si tiene más de un punto de conexión para su servidor, elija Agregar dirección IPv4 para agregar otra fila e introducir otra dirección IPv4. 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 de destino y, a continuación, vuelva al procedimiento anterior para crear su 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 nombre DNS del equilibrador de carga de red.

importante

Administre el acceso al servidor desde las direcciones IP de los clientes mediante las listas de control de acceso de la red (ACL de la red) de las subredes configuradas en el equilibrador de carga. Los permisos de las ACL 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

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

Puedes usar Transfer Family para enviar mensajes AS2 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 comando list-connectors devuelve los ID de los conectores, las URL y los nombres de recursos de Amazon (ARN) de los conectores.

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 comando describe-connector devuelve todas las propiedades del conector, incluidas la URL, los roles, los perfiles, los avisos de disposición de mensajes (MDNs), las etiquetas y las métricas de supervisión.

Para confirmar que el socio recibió correctamente los archivos, consulte los archivos JSON y MDN. 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 en sus CloudWatch registros el estado de los mensajes AS2.

Para ver los detalles del conector AS2, consulte Visualización de los detalles del conector AS2. Para obtener más información acerca de cómo crear un conector AS2, consulte Configure los conectores AS2.

Nombres y ubicaciones de los archivos

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

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 archivo JSON correspondiente) se guardan en la carpeta /processed. Por ejemplo, /DOC-EXAMPLE-BUCKET/AS2-folder/processed.

  El archivo JSON 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 archivo JSON correspondiente) se guardan en la carpeta /failed. 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 archivo JSON y se guarda como original_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 como original_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: [e-mail]

  • JSON: [e-mail]

  • MDN: [e-mail]

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 operación de la StartFileTransfer API 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 operación o el start-file-transfer AWS CLI comando de la StartFileTransfer API. Por ejemplo:

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

  Si ejecutas este comando, los archivos MDN y JSON 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 archivo JSON y se guarda como original_filename.transferId.messageId.original_extension.json.

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

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

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

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

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 mensaje AS2. Los diferentes pasos de procesamiento de mensajes se aplican a diferentes tipos de mensajes y están destinados únicamente a la supervisión. Los estados COMPLETADO y FALLIDO representan el paso final del procesamiento y están visibles en los archivos JSON.

Código	Descripción	¿Se ha completado el procesamiento?
PROCESAMIENTO	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 de mensajes envía una respuesta de MDN.	No
MDN_RECEIVE	El procesamiento de mensajes recibe una respuesta de MDN.	No
COMPLETED	El procesamiento del mensaje se ha completado correctamente. Este estado incluye cuando se envía un MDN para un mensaje entrante o para la verificación por MDN de los mensajes salientes.	Sí
ERROR	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.	Sí

Ejemplos de archivos de JSON

En esta sección, se enumeran los archivos JSON de muestra 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",
  "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"
}

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": "/DOC-EXAMPLE-BUCKET-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"
}