SAP Cloud Platform Integration (CPI) || Part 7 || Maintaining logs by using “Groovy Scripts”, even if the IFlow is not on trace mode.

Dear Reader,

This blog post is a part of a series of blog posts related to SAP Cloud Platform Integration. The blogs so far are:

• My adventure in learning CPI || Part 1 || All about SAP Cloud
• My adventure in learning CPI || Part 2 || Deployment Models
• My adventure in learning CPI || Part 3 || Cloud Security
• SAP Cloud Platform Integration (CPI) || Part 4 || Know your tool
• SAP Cloud Platform Integration (CPI) || Part 5 || Content Modifier
• SAP Cloud Platform Integration (CPI) || Part 6 || Configuring Mail Adapter

Up next:

• SAP Cloud Platform Integration (CPI) || Part 8 || Working with Request Reply

——————————————————-

Sometimes, because of some unfortunate reasons, your IFlow would fail, and you would definetly have an urge to see the payload so as to know which was the customer which failed to replicate, or which is the Sales Order whose data you couldn’t [GET].

We all know, that putting the IFlow into a TRACE mode who definitely serve your purpose, but some of the cons of the TRACE mode are:

1.  After switching the TRACE mode, you have to replicate the steps again, to as to reproduce the issue in CPI.
2.  TRACE mode lasts for only 10 mins.
3.  The data in TRACE mode lasts for only an hour.
4.  And, you always might not have the option to put the IFlow on trace. For instance, if the data request is from your Hybris’s storefront, where an end-user of yours is trying to run a report which in terms of a Techanical Consultant is, when the end-user tries to access some data in ECC via CPI, and it fails. Now, in this scenario, how will you know who was the end-user? And the end-user might be your client’s customer who will accessing, got a dump. In such a scenario, TRACE won’t be of much help to you.

In these cases, come the only survivor a set of groovy script codes, which shall attach the payload in the Monitor Message Processing.

All you need to do, is enter the codes mentioned below after a “Message Mapping”, or a “Content Modifier”, or a “Filter”, or any place in the IFlow after which you wish to see the payload.

GROOVY SCRIPT FOR MAINTAINING LOGS:

In the script below, note that, the “log1” would be the name of the logfill which shall get generated. Hence, if you planning on maintaing multiple logfiles as such, then please maintain a different name everytime, like, log1, log2, log3, and so on.

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("log1","Printing Payload As Attachment")
        messageLog.addAttachmentAsString("log1",body,"text/plain");
    }
    return message;
}

In my instance, I have used the Groovy Scripts, 2 times after 2 Content Modifiers:

Now, what does the output look like? Check out the screenshot below:

If you click on the log files, below is what the log file collects for you:

Few points to note:

•  Maintaining a log file is always not necessary. You may maintain this groovy script, only when it is highly required. Because maintaing these logs will uncessarily make your Cloud Platform portal heavy.
• One of the best solutions in a situation like this is to trigger an email from your IFlow whenever there is an exception or an error i.e. your IFlow fails. (We have already seen how to trigger an email from your IFlow. In another session, we shall see, how to handle the exceptions)

Hope you had a good read.

If you wish to know more, or have any queries on this blog, then please feel free to drop a comment.

Thanks & Regards,

Sookriti Mishra