Message Log ging

Descripción general

El registrador de mensajes permite a los clientes rastrear todos los mensajes relacionados con una solicitud específica, proporcionando transparencia para fines de monitoreo y auditoría.

El solicitante de VoP registra los siguientes mensajes:

  • Solicitud/Respuesta Entrante

  • CSM Reachability Descomponer Solicitud/Respuesta IBAN

  • Nota al pie de página de la solicitud/respuesta RVM: [Cuando la comunicación es directa entre Proveedores de Servicios de Pago (PSPs) y no se utiliza un RVM, se registra la Solicitud/Respuesta del Respondedor en su lugar.]

El diagrama a continuación representa los registros de mensajes hacia y desde los servicios, utilizando FPAD como el RVM seleccionado.

overview

Cómo Funciona

El solicitante de VoP captura todos los mensajes intercambiados con sistemas externos:

  1. Captura de Mensajes: Los mensajes son interceptados en puntos clave del flujo de procesamiento y registrados utilizando el IPF Message Logger

  2. Estructura del Mensaje: Cada mensaje registrado contiene:

    • Marca de tiempo-cuando se registró el mensaje

    • Contexto de procesamiento-contiene el ID de solicitud y la entidad de procesamiento

    • Tipo de mensaje-identifica el tipo de mensaje (por ejemplo, PROCESSING_ENTITY_VOP_REQUEST)

    • Dirección-si el mensaje fue ENVIADO o RECIBIDO

    • Cuerpo del mensaje-el contenido real del mensaje (serializado a JSON)

    • ID de mensaje-identificador único que vincula mensajes relacionados. Consiste en tres partes delimitadas por |

      • MESSAGE_LOG prefijo

      • ID de solicitud - El servicio genera un identificador único para cada solicitud recibida de una entidad de procesamiento. Este identificador se incluye en esta parte del ID del Mensaje y puede ser utilizado para correlacionar, como se describe en el punto 3. Todos los mensajes relacionados compartirán el mismo valor para esta porción del ID del Mensaje.

      • UUID aleatorio-esta parte del ID de mensaje es única para cada mensaje

    • Datos de soporte-metadatos adicionales como encabezados

  3. Correlación de Mensajes: Todos los mensajes asociados con una única transacción están vinculados utilizando el ID de solicitud de la solicitud entrante. Esto permite un seguimiento sencillo de la solicitud a lo largo del sistema. El mismo ID de solicitud también se incluirá en la respuesta.

Los mensajes registrados se ajustan a lo siguiente Esquema JSON

Recuperación de Mensajes

Si Kafka el registro de mensajes está habilitado, las entradas del registro de mensajes también contendrán Kafka Encabezados.

Actualmente, VoP completa los siguientes valores en los encabezados:

  • ipf_processing_context_client_request_id - El ID de solicitud generado por el servicio VoP Requester.

  • ipf_processing_context_processing_entity - La entidad de procesamiento recibió del mensaje de solicitud.

Pueden estar presentes otros encabezados según lo poblado por el Marco de Conectores.
requestId y processingEntity Los encabezados ahora están obsoletos y el soporte para estos campos se eliminará a partir de la versión 2025.4.0.

Si el registro de mensajes de Mongo está habilitado, los campos equivalentes para consultar son:

  • processingContext.clientRequestId

  • processingContext.processingEntity

Configuración

El tipo de registrador de mensajes a utilizar se configura con el message.logger.type(predeterminado:`kafka`) propiedad según lo documentado en las páginas de configuración del registrador de mensajes aplicables a continuación (por ejemplo,Kafka/Mongo)

  • Detalles de las opciones de configuración para el Kafka Message Logger están disponibles aquí

  • Detalles de las opciones de configuración para el Mongo Message Logger están disponibles aquí

Manejo de Errores

El sistema de registro de mensajes en VoP Requester está diseñado para ser resistente a fallos, asegurando que los problemas con el registro de mensajes no afecten la funcionalidad principal del servicio.

Errores de Ejecución

Cuando ocurren errores durante el registro de mensajes, se encuentran en su lugar los siguientes mecanismos de manejo de errores:

  1. Gestión de Errores Resiliente: Los errores en el registro de mensajes son capturados y registrados, pero no interrumpen el flujo principal de procesamiento. Esto asegura que, incluso si el registro de mensajes falla, la funcionalidad principal del servicio continúa operando.

  2. Registro de Errores: Cuando una operación de registro de mensajes falla, se registra un mensaje de error con el ID de la solicitud para su trazabilidad:

    • Para fallos en el registro de solicitudes:`"Error saving request to message logger"`

    • Para fallos en el registro de respuestas:`"Error saving response to message logger"`

  3. Degradación Elegante: Cuando Kafka el registro de mensajes está habilitado pero Kafka se vuelve indisponible, el servicio permanece operativo. En este caso, el registro de mensajes se suspende temporalmente hasta que Kafka la conectividad se ha restaurado. Este comportamiento se gestiona utilizando un mecanismo de disyuntor configurado dentro del conector de registro de mensajes. Para más información sobre disyuntores, consulte aquí.

Si se selecciona Mongo para el registro de mensajes, y Mongo se vuelve indisponible después de que el Solicitante de VoP ha comenzado, entonces el servicio del Solicitante de VoP se volverá indisponible.