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 registrador de VoP registra los siguientes mensajes:

  • Solicitud/Respuesta RVM entrante nota al pie:[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 Solicitante en su lugar.]

  • Solicitud/Respuesta de Gestión de Cuentas

Además, los datos que se envían a través de la Resolución de Identidad a Netowl también se capturará en un Procesando mensaje de archivo

El diagrama a continuación representa el message logs a y desde los servicios, utilizando FPAD como el RVM seleccionado.

overview

Cómo Funciona

VoP Responder 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, ACCOUNT_MANAGEMENT_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 identificador único recibido de cada solicitud. Este identificador se incluye en esta parte del ID del mensaje y puede ser utilizado para la correlación, 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.

Los mensajes registrados se ajustan a lo siguiente Esquema JSON. Además, el ID de la solicitud se completa en el campo message Id, el cual puede estar vinculado al Mensaje del Archivo de Procesamiento a través de su campo request Id.

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 se eliminará a partir de la versión 2025. 4. 0.

Si Mongo message log Si la función de búsqueda 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 VoP Responder 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 Ejecución

Cuando ocurren errores durante message log En caso de error, se encuentran en su lugar 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 el ging, 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 {type} request to message logger for request id {requestId}"`

    • Para fallos en el registro de respuestas:`"Error saving {type} response to message logger for request id {requestId}"`

  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 de ging. Para más información sobre los interruptores automáticos, consulte aquí.

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