HCI – Payload Logging using Groovy Scripts – Part 1

Background

Logging during a message processing is always handy be it for run-time debugging during development or during during support when you want to understand what happened during the life cycle of a message.

HCI provides default logging options as described in this blog : HCI First Steps Part 6 – Identifying issues . The tracing options described in this blog are temporary options as the trace is persisted only 10 for Minutes. Try to View Trace post 10 minutes of processing your message and you will get the below error message

This is obviously not ideal. Are there better options that ensure that the logs are available for consumption post the 10 minutes duration? Those from a PI background would know the advantage of using Trace statements in their user define functions. The trace statements enabled you to understand what happened during the processing of your message. Is there something similar in HCI?

You can insert logging statements in your Groovy Script and Java Scripts. The documentation to this is described here, Defining Scripts

This blog covers a sample using Groovy Scripts but it would work similarly in the context of a Java Script as well.

Groovy Script Example

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
    def body = message.getBody(java.lang.String) as String;
    def messageLog = messageLogFactory.getMessageLog(message);
    if(messageLog != null){
        messageLog.setStringProperty("Logging#1", "Printing Payload As Attachment")
        messageLog.addAttachmentAsString("ResponsePayload:", body, "text/plain");
     }
    return message;
}

The above script has 3 critical components,

Example Script Usage in a Integration Flow

This is a simple SOAP to SOAP Scenario with the Script to log the response of the SOAP call to the Message Processing Log as an attachment. The Script listed above is used in a Integration Flow after the Request/Reply step.The expected result is that the Request-Reply step response is written to the message processing log.

Testing of the Integration Flow with the Groovy Script

Eclipse

Trigger your Integration flow, and then proceed to the message processing log in Eclipse. Below will be seen.

The Logging#1 contains the Text that was printed as a String in the Groovy Script.

As mentioned previously, while we have hard coded this in our example to a constant string, this can also be any of the Message Headers, Message Payload and Message Properties as required.

The Attachments contains a Hyper Link with the name of the Attachment as mentioned in our source code. Clicking on this hyperlink, will lead to the actual payload.

WebUI

Likewise, when monitoring your flow over the WebUI, the same info is visible. In fact the WebUI provides the Message Processing Log and Attachments separately making it easier to navigate and view the specifics as required,

Sequence of Printing of Logs

Eng Swee Yeoh had pointed to a very important concept in terms of how the Logs are printed. The documentation link pointed previously has the below info,

Note that the properties provided by the script step are displayed in alphabetical order in the resulting message processing log (MPL). That means that the sequence of properties in the MPL does not necessarily reflect the sequence applied in the script.

What this basically means is if your Groovy Script has multiple print setStringProperty, these are not printed in the logs in the same order as they get executed in the Message Processing Log. Infact, they are printed alphabetically.

For example, if your Grrovy script has the statements,

messageLog.setStringProperty("DEF", "Printing Payload As Attachment1")
messageLog.setStringProperty("ABC", "Printing Payload As Attachment2")

The message processing Log will print the output in Alphabetical order instead of the sequence in which it is executed, i.e,  for the example listed above, ABC is printed 1st, followed by DEF as per below image.

When implementing your Groovy Script to use print in the Message Processing Log, it is recommended that you ensure that the String Properties have the Key’s as Log#1, Log#2 and so on to that the Printing happens in the same order as execution.

Final Note

Like everywhere else, there are performance tradeoff’s between Logging multiple payloads and not logging the same and hence this should be used with required design considerations. It is recommended that the Groovy Logging described in this blog is used in combination with Externalized Parameters to enable / disable logging of Payloads for an Integration Flow. Your externalized parameters can be set to a Logging true/false which is then checked within your Groovy Script and then the Data Logged as required.

The steps to externalize your logging is described in the next blog of this series : HCI – Payload Logging using Groovy Scripts – Part 2 – Use Externalized Parameters