Message Logging
Overview
The message logger enables clients to trace all messages related to a specific request, providing transparency for monitoring and audit purposes.
The VoP Responder logs the following messages:
-
Incoming RVM Request/Response [1]
-
Account Management Request/Response
Additionally, data going out via Identity Resolution to Netowl will also be captured in a Processing Archive Message
The below diagram depicts the message logs to and from the services, using FPAD as the selected RVM.
How It Works
VoP Responder captures all messages exchanged with external systems:
-
Message Capture: Messages are intercepted at key points in the processing flow and logged using the IPF Message Logger
-
Message Structure: Each logged message contains:
-
Timestamp - when the message was logged
-
Processing context - contains request ID and processing entity
-
Message type - identifies the type of message (e.g., ACCOUNT_MANAGEMENT_REQUEST)
-
Direction - whether the message was SENT or RECEIVED
-
Message body - the actual content of the message (serialized to JSON)
-
Message ID - unique identifier linking related messages. Consists of three parts delimited by
|-
MESSAGE_LOGprefix -
Request ID - The unique identifier received from each request. This identifier is included in this part of the Message ID and can be used for correlation, as described in point 3. All related messages will share the same value for this portion of the Message ID.
-
Random UUID - this part of the Message ID is unique for each message
-
-
Supporting data - additional metadata such as headers
-
-
Message Correlation: All messages associated with a single transaction are tied together using the request ID from the incoming request. This enables straightforward tracing of the request throughout the system.
| Logged messages conform to the following JSON Schema. Furthermore, the request ID is populated into the messageId field, which can be linked to the Processing Archive Message via its requestId field. |
Headers
If Kafka message logging is enabled, message log entries will also contain Kafka Headers.
Currently, VoP populates the following values into the headers:
-
requestId - The request ID as received in the request messages.
-
processingEntity - The processing entity received from the Account Management system.
| Other headers may be present as populated by the Connector Framework. |
Configuration
The type of message logger to use is configured with the message.logger.type (default: kafka) property as documented in the applicable message logger configuration pages below (e.g. Kafka/Mongo)
Error Handling
The message logging system in VoP Responder is designed to be resilient to failures, ensuring that issues with message logging do not impact the core functionality of the service.
Runtime Errors
When errors occur during message logging, the following error handling mechanisms are in place:
-
Resilient Error Handling: Errors in message logging are caught and logged but do not interrupt the main processing flow. This ensures that even if message logging fails, the primary service functionality continues to operate.
-
Error Logging: When a message logging operation fails, an error message is logged with the request ID for traceability:
-
For request logging failures:
"Error saving {type} request to message logger for request id {requestId}" -
For response logging failures:
"Error saving {type} response to message logger for request id {requestId}"
-
-
Graceful Degradation: When Kafka message logging is enabled but Kafka becomes unavailable, the service remains operational. In this case, message logging is temporarily suspended until Kafka connectivity is restored. This behavior is managed using a circuit breaker mechanism configured within the message logging connector. For more information on circuit breakers, see here.
| If Mongo is selected for message logging, and Mongo becomes unavailable after the VoP Responder has started, then the VoP Responder service will become unavailable. |