MSI Debugging

As the other MSI related chapters may have shown, the MSI interface allows for many different forms of integration. In such a complex setup, it is natural that misconfiguration may occur. Therefore, debug functionalities have been included to help tracing and resolution of problems.

Message Debugging

The lowest level at which debugging of the MSI interface can take place is the message level, just after/at the Web API. Debugging on this level will show the incoming and outgoing messages to and from PAS-X.

In order to make Debugging on this level flexible, debug-hooks in the Web API endpoint have been implemented. All these debug hooks currently call functions from the "mbro-msi-hooks.lua" library.

To implement message debugging, this library must be overwritten with the dedicated debugging functionality. To do this, a Script Library named "mbro-msi-hooks.lua" should be added to an object higher in the I/O Model (for example, Core or System). In order to create a simple monitoring of incoming and outgoing messages the following code can be added as the Lua Script body for the Script Library.

-- mbro-msi-hooks.lua --debug
local JSON= require("rapidjson")
local lib={}

lib.ON_MES_TO_SF= function(arg, req, respCode, respMessage)
    syslib.log(3,"msi-hook ON_MES_TO_SF:",JSON.encode({arg,req,respCode, respMessage}))
end
lib.ON_SF_TO_MES= function( arg, req, respCode, respMessage)
    syslib.log(3,"msi-hook ON_SF_TO_MES:",JSON.encode({arg,req,respCode, respMessage}))
end
lib.ON_SF_TO_MES_DELETE= function( arg, req, respCode, respMessage)
    syslib.log(3,"msi-hook ON_SF_TO_MES_DELETE:",JSON.encode({arg,req,respCode, respMessage}))
end

return lib

Message Processing Debugging

In addition to the low-level debugging mentioned above, debugging events can also be activated on the Message Processor. In order to do so, the Debug property of the Message Broker must be activated.

Message Broker Debug Switch
Figure 1. Message Broker Debug Switch

After activation, concise messages regarding the individual processing steps for Message reception as well as message generation will be displayed in the Log of the MessageProcessor.

This provides a very detailed insight into the actual message processing, the approach to this is described below.

Incoming Message Processing

For each incoming messages, the Message Processor iterates through the configured Message Configurations and checks if the incoming message matches one of them. Each of these parameter checks is documented in the log. - If a matching Message Configuration is found, "match is true" is logged. - If non-matching Message Configuration is found, "No Matching Message Configuration Found" is logged.

Message Processor Log In
Figure 2. Message Processor Log In

After a matching Message Configuration is found, this configuration is processed further and additional log entries will be generated depending on the individual mapping type.

Outgoing Message Processing

The creation of an outgoing message is initiated either as a reaction to an incoming message, or a response to a trigger. In both cases, the relevant message configuration is used to generate the XML response. Therefore, the Taglist is read and subsequently, the parameters as well as the qualifiers are extracted and processed one by one. In addition, the different generation steps for the XML Message are logged.

Message Processor Log Out
Figure 3. Message Processor Log Out