Get groov’in with your iFlows – groovy scripting with Eclipse for CPI

[Martin-Pankraz]

Today, I’m going to make your life as integration developer a whole lot easier. Whenever there’s a complex transformation requirement, for instance combining rows from an excel sheet into one object by a common identifier, Scripting is a great way to tackle the issue. SAP offers two flavors of scripting – JavaScript and Groovy.

The only downside is that the SAP Cloud Platform Integration WebUI does development environment. So, basically, it is like developing whilst blindfolded and then hoping for the best during deployment and runtime. As an integration developer you want a little more than syntax highlighting. You at least want to have syntax checks, code completion and the ability to test messages easily without deploying entire iFlows and executing them.

Fortunately, there are some clever people at the SAP community, who can show us how to setup a development environment for those CPI scripts.

I am going to build upon their amazing work and equip you with a custom iFlow and a Postman request that allows you to “hunt” for the Java-Libraries residing on your own Cloud Platform Integration tenant. You will need them to be able to execute your groovy script from eclipse.

Find out how my custom iFlow finds java libraries on your CPI tenant on Vadim’s amazing blog post.

Also, Eng Swee produced a fantastic write up on how to start your first functional tests with a groovy script.

Ready to groove?

So let’s say you’ve installed Eclipse Neon, the groovy plugin and added Eng Swee’s initial scripts for message processing and running the test. Then, you notice that the project produces errors due to missing dependencies. This is what we need to fix.

Have a look at my slightly adapted demo structure below, which I am going to refer to from hereon.

Message processing script “src/com/convista/groovydemo/Script1.groovy”:

package com.convista.groovydemo

import com.sap.gateway.ip.core.customdev.util.Message;

import java.util.HashMap;



def Message processData(Message message) {

    //Body 

       def body = message.getBody();

       message.setBody(body + "Body is modified");

       //Headers 

       def map = message.getHeaders();

       def value = map.get("oldHeader");

       message.setHeader("oldHeader", value + "modified");

       message.setHeader("newHeader", "newHeader");

       //Properties 

       map = message.getProperties();

       value = map.get("oldProperty");

       message.setProperty("oldProperty", value + "modified");

       message.setProperty("newProperty", "newProperty");

       return message;

}

Note: If you run into encoding problems, for example, with messages, created by the csv converter, consider adding the java.lang.String class to your get-method (e.g. message.getBody(java.lang.String)).

And the script “Tester.groovy” that executes the actual test. This piece simulates the message passed by the CPI framework so to say.

package com.equalize.groovy.testing



import com.sap.gateway.ip.core.customdev.processor.MessageImpl

import com.sap.gateway.ip.core.customdev.util.Message



// Load Groovy Script

GroovyShell shell = new GroovyShell()

def script = shell.parse(new File("src/com/convista/groovydemo/Script1.groovy"))



// Initialize message with body, header and property

Message msg = new MessageImpl()

msg.setBody(new String("Hello Groovy World"))

msg.setHeader("oldHeader", "MyGroovyHeader")

msg.setProperty("oldProperty", "MyGroovyProperty")



// Execute script

script.processData(msg)



// Display results of script in console

println("Body:\r\n" + msg.getBody())



def displayMaps = { String mapName, Map map ->

	println mapName

	map.each { key, value -> println( key + " = " + value) }

}

displayMaps("Headers:", msg.getHeaders())

displayMaps("Properties:", msg.getProperties())

The blogs, mentioned above, walk you through the dependency problem with SAP’s standard class “Message” and explains, in detail, how to solve it.

So: “What are we doing here then?”

Vadim and Eng Swee left you with a very cumbersome approach to retrieve the java libraries. I’d like to show you a much more integrated way of doing this without comprising Eng Swee’s goal of teaching a man to fish instead of simply giving him a fish to eat, so he has the skills to feed himself going forward.

What else do you get?

Vadim’s and Eng Swee’s approach involves executing your incomplete groovy project, identifying an error relating to a missing dependency in eclipse, and using that missing class name on an additional groovy script, which you need to deploy on CPI to download the corresponding java library from your tenant. Once you have the java library file you can add it to your class path and re-execute your project to find the next missing class. For this next one you need to alter the groovy script on the iFlow and re-deploy.

Ugh, that is quite a lot of work, because you currently need to download ten java library files to get a complete set and the deployment times of the iFlow can take several minutes. It can easily take 20 minutes to complete them. So that is why I decided to develop an iFlow, which can do all of this in one go. You can download it here.

To achieve what I wanted I needed the ability to pass the java class name dynamically without hard coding it on a groovy script. That way we can circumvent the re-deployment process. So, to achieve that, I use an https connector that allows the forwarding of the HTTP query string parameters. SAP is running the Apache Camel server for that reason. You can read more about this here.

A couple of weeks ago my colleague 6c74addc374841d587eccd4a68075de8 gave you an introduction on how to use Postman for testing your iFlows. You are going to need that knowledge now.

As you can see the URL for my iFlow https endpoint requires the following pattern:

/external/trigger?lib=<java class name>

The yellow part is required for the Camel server, the blue part addresses the https endpoint of the iFlow and the red part is the name of the query string variable, which can be accessed on the iFlow later on. Check it out below:

You can access the query string parameters by reading the header “CamelHttpQuery”. I decided to parse it by applying a substring to actually get the value of the parameter (lib=some.java.class.name).

I feed the result into Vadim’s script logic that utilizes the Java API to lookup the jar file, which contains the class name. The result is then base64 encoded and added as a string attachment to an iFlow message.

For the convenience of the developer I added the jar file name including its version as the title of the attachment.



Finally you need to copy the base64 encoded string and create a jar file from it. I decided to do this by running another groovy script once more. As preparation you need to copy the encoded string into a text file and put it on the libs folder of my demo project. You can also download it from my GitHub repository. The script is called Base64Decoder.groovy. Add the jar file to your project’s build path, try to run the groovy script “Tester” once again and start the process of “hunting” for more missing jar files again.



Once you are done “hunting” for all the SAP jar files and added all of them to your build path, you can finally execute tests with your groovy scripts:

That wasn’t too hard, was it?

engswee.yeoh suggests you take the testing approach even further. If you want to delve further into Test Driven Development with your groovy scripts take a look here.

Before concluding, I would like to emphasize the power of creating message logs (with attachments) with groovy scripts. In our case we used it to output the content of the jar files from the CPI tenant. But, of course, possible use cases for custom logging are only limited by your imagination and implementation needs.

Final Words

So I’ve introduced you to the setup procedure and told you where to find instructions on how to setup your groovy development environment in eclipse to get started with groovy scripting for your CPI iFlows. I also showed you how to download the required java libraries more easily and quicker than my SAP community colleagues Vadim and Eng Swee suggest.

Next time I am going to combine the topics of our blogs, which we posted so far and talk about end-to-end testing of your iFlows. So stay tuned for more.

As always feel free to leave comments and ask lots of follow up questions.

Thanks

Martin