Message Log ging

Descripción general

El message logger 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

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

El diagrama a continuación representa el message logs a 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

    • Message type-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 del 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 message log ging está habilitado,message log las entradas 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 será eliminado a partir de la versión 2025. 4. 0.

Si Mongo message log Cuando la función de ging está habilitada, los campos equivalentes para consultar son:

  • processingContext.clientRequestId

  • processingContext.processingEntity

Configuración

El tipo de message logger para usar está configurado con el message.logger.type(predeterminado:`kafka`) propiedad según lo documentado en el aplicable message logger páginas de configuración 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 message log El sistema de gestión en el Solicitante de VoP está diseñado para ser resistente a fallos, asegurando que los problemas con message log la modificación no afecta la funcionalidad principal del servicio.

Errores de tiempo de ejecución

Cuando ocurren errores durante message log En caso de error, se han implementado los siguientes mecanismos de manejo de errores:

  1. Gestión de Errores Resiliente: Los errores en message log Se registran y se registran, pero no interrumpen el flujo principal de procesamiento. Esto asegura que incluso si message log si falla, la funcionalidad principal del servicio continúa operando.

  2. Registro de Errores: Cuando un message log Si la operación de ging 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 message log ging está habilitado pero Kafka se vuelve indisponible, el servicio permanece operativo. En este caso,message log ging está temporalmente suspendido hasta Kafka la conectividad es restored. Este comportamiento se gestiona utilizando un mecanismo de disyuntor configurado dentro del message log conector ging. Para más información sobre interruptores automáticos, consulte aquí.

Si se selecciona Mongo para message log Si Mongo se vuelve no disponible después de que el Solicitante de VoP ha comenzado, entonces el servicio del Solicitante de VoP se volverá no disponible.