Concepts

In order for sent/received messages to be logged in an IPF implementation, developers must implement a suitable message logger. There is no default logger (though out-of-the-box implementations are available that log to Mongo and Kafka) as every client has different requirements ; some may wish to use a corporate central log, some may wish to use ODS or maybe even a mix depending on the message in question. This section of the documentation contains technical information for developers that allows them to implement message logging for an IPF solution.

A Message Logger in IPF is any class that implements this simple functional interface:

public interface MessageLogger {
    void logMessage(MessageLogEntry var1);
}

A common requirement is to log every message sent to or from a flow and an implementation of the MessageLogger can be provided for that purpose. We provide a logging implementation to a Connector for example.

Connectors are a very common place where a logger is used, and the Connector framework offers the additional option to enrich message data by providing an implementation of the MessageLogEntryEnrichment functional interface:

public interface MessageLogEntryEnricher<T> {
    void enrich(ConnectorMessage<T> connectorMessage, MessageLogEntry messageLogEntry);
}

(see the Connector Message Logging docs)

Before deciding to use a specific logger it’s worth considering where the message and other data logging fits into your overall strategy, especially if implementing ODS. See the Using ODS page for more on this.

MessageLogEntry Schema

Messages logged using either the Kafka or Mongo implementation of MessageLogger adhere to the following schema:

{
  "$schema" : "http://json-schema.org/draft-04/schema#",
  "title" : "Message Log Entry",
  "type" : "object",
  "additionalProperties" : false,
  "properties" : {
    "messageTime" : { },
    "processingContext" : {
      "$ref" : "#/definitions/ProcessingContext"
    },
    "messageType" : {
      "type" : "string"
    },
    "direction" : {
      "type" : "string",
      "enum" : [ "SENT", "RECEIVED" ]
    },
    "supportingData" : {
      "type" : "object",
      "additionalProperties" : {
        "$ref" : "#/definitions/Object"
      }
    },
    "message" : {
      "type" : "string"
    },
    "messageID" : {
      "type" : "string"
    },
    "reference" : {
      "type" : "string"
    }
  },
  "definitions" : {
    "ProcessingContext" : {
      "type" : "object",
      "additionalProperties" : false,
      "properties" : {
        "associationId" : {
          "type" : "string"
        },
        "checkpoint" : {
          "type" : "string"
        },
        "unitOfWorkId" : {
          "type" : "string"
        },
        "clientRequestId" : {
          "type" : "string"
        },
        "processingEntity" : {
          "type" : "string"
        }
      }
    },
    "Object" : {
      "additionalProperties" : true,
      "properties" : { }
    }
  }
}

CheckpointAwareMessageLogger

The CheckpointAwareMessageLogger extends the message logger interface hierarchy.

public interface CheckpointAwareMessageLogger extends MessageLogger {
}

You should implement a CheckpointAwareMessageLogger if you want messages logged by an IPF connector, and overall IPF strategy, to maintain the causal relationship between "pseudo-events". This is done by utilising the IPF Connector "Checkpoint" functionality. Supplying an implementation of this interface lets the connector know that it should maintain this causal relationship when sending and logging messages.

For example, the IPF Processing Data message logger implements this interface.