Skip to Content
Technical Articles

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

7 Comments
You must be Logged on to comment or reply to a post.
  • Hi sookriti,

    I have a problem can you please guide.

    1. When i deploy an Iflow why there are so many messages that gets triggered every few minutes.
  • Hi Sookriti Mishra ,

    Thanks for the great series. Re. second bullet point under ‘Few Points to Note’ section which points to “trigger an email from your IFlow whenever there is an exception or an error “

    Can you please advise, How we we know that there is an exception or error ? Is there a parameter in header or a property using which we can know that there is an exception ?

    Ideally, we would like to send an email to admin whenever an iflow fails/encounters error – as people are not monitoring the CPI regularly and we get to know of issues only when somebody pro-actively checks the CPI monitor. Therefore, we would like to trigger email when iflow fails. Where to put the mail adapter in this case such that email is sent only when iflow fails ?

    Thanks,

    suchita phulkar

     

  • Hi Sookriti,

    Groovy scripts are not only good for logging. The real strength of Groovy is:

    • Handling of JSON. The creation of JSON and the extraction of data out of JSON files is very simple in Groovy. (except for the conversion from and to XML, there are no adapters for JSON)
    • Mapping of XML (see also https://blogs.sap.com/2019/06/07/i-heart-groovy-mapping/ ). The Groovy scripts can be developed and tested in a decent IDE (e.g. IntelliJ) so you are much faster and have more tool support)
    • You can define classes in Groovy and instantiate Groovy objects within Groovy scripts

    Regards

    Thomas

  • Hi Sookriti,

    Nice article. This way of logging is extremely useful, but as you said, it can get computationally/storage heavy if you overuse it in your iFlows.

    That is why I like to use a boolean variable as a “switch” at the beginning of my code, and then wrap the logging logic inside an if statement, checking if the variable is set to true.

    With your example, it would look like this:

    import com.sap.gateway.ip.core.customdev.util.Message;
    import java.util.HashMap;
    
    def Message processData(Message message) 
    {
        def loggingEnabled = false;
        if(loggingEnabled)
        {
            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;
    }

    It enables you to relatively quickly enable/disable groovy script logging. I still didn’t have a more complex scenario for this, but I guess a step further would be to somehow externalize this “switch” for even easier management (eg. using a Content Modifier before the Script).

    Best,
    Aleksa

    • Hello,

      You seem to be on the correct track.  Turning on and off the Groovy Script logger externally with external parameter makes perfect sense, provided you are able to reproduce the issue.

      I would suggest calling the Groovy Script in Exception Subprocess to capture the payload and error details.  This can be extended further to email payload and error details within subprocess.

       

      Thanks!

      Lokesh