Skip to Content
Technical Articles

Clean up your CPI code with script collections and CPILint

Scripting is a powerful feature of SAP Cloud Integration (CPI for short in the rest of this blog post). It lets you implement advanced logic in JavaScript and Groovy, that would be much more complicated or even impossible to accomplish using the built-in flow steps.

Up until very recently, you couldn’t share scripts across integration flows (iflows for short in the rest of this blog post). That meant that you sometimes had no choice but to copy the same script into multiple iflows, resulting in duplicated code. Generally, that is a bad thing, since it makes maintaining and updating your code harder and more error-prone. Avoiding duplicated code is a sound DRY (Don’t Repeat Yourself) principle.

Fortunately, the latest version of CPI introduces a nice solution to this problem: Script collections. They are a new type of artifact that holds scripts and JAR archives. A script collection can be referenced from an iflow, thereby making its contents available in that iflow. In other words: Script collections let you reuse scripts and JAR archives across iflows without duplicating code. For a much more in-depth introduction to script collections, please see this new blog post by Kamlesh Zanje.

With script collections we can avoid duplicated code going forward. If you already have duplicate scripts in your tenant, they should be moved to script collections and shared. But how to find those duplicate scripts? CPILint can help you with that.

CPILint is an open source, rule-based governance tool for SAP Cloud Integration. With CPILint you set up rules, that you want your iflows to comply with, and the tool then does the work of checking the iflows in your tenant for compliance. CPILint ships with rules covering areas such as scripting, mapping, connectivity and security. To learn more about CPILInt, please see this blog post.

In the following I will show you how to find duplicate scripts using CPILint and replace them with script collections.

Step 1: Identify the duplicate scripts

With CPILint you can check your iflows for duplicate resources using the DuplicateResourcesNotAllowed rule. The rule supports all the CPI resource types, but in this particular context we’re only interested in scripts and JAR archives. Here’s a complete CPILint rules file that checks for the relevant duplicates:

<?xml version="1.0" encoding="UTF-8"?>
<cpilint>
    <rules>
        <duplicate-resources-not-allowed>
            <resource-type>groovy-script</resource-type>
            <resource-type>javascript-script</resource-type>
            <resource-type>java-archive</resource-type>
        </duplicate-resources-not-allowed>
    </rules>
</cpilint>

To check your entire CPI tenant for duplicates, save the XML to a local file and execute CPILint from the command line as follows:

cpilint -rules <the file you just saved> -tmn-host <the hostname of your Tenant Management Node> -username <your tenant username>

(For more information about installing and running CPILint, please see this wiki page. For details on the various command-line options, run cpilint -help.)

For the purpose of this blog post I created two iflows and added the same Groovy script to both of them. Here’s the output from CPILint, when I check those two iflows:

As expected, CPILint reports that a duplicate Groovy script has been found. Notice how the duplicate scripts have different filenames, by the way. CPILint checks for duplicates using a checksum of the contents, so duplicates will be found even if their filenames differ. If you feel like delving into the details of how that’s done, the source code is available right here 🙂

Now that we’ve found two duplicate scripts, let’s go ahead and replace them with a single script inside a script collection.

Step 2: Create a script collection

The first order of business is to create an empty script collection (to learn how to do so, please see Kamlesh’s blog post). Please note that at this point, the script collection must be created in the same package as the iflows that reference it (consuming script collections across packages is on the roadmap).

Instead of creating a new, blank script inside the freshly created script collection, I use the upload feature:

This lets me add the duplicated scripts directly from one of the iflows identified by CPILint:

The script collection now contains a single Groovy script:

Save the script collection and we’re ready to proceed to the final step.

Step 3: Replace the duplicate scripts

Now that we have a script collection in place, all we need to do is replace the two local scripts in the iflows with the shared script. To do that, we must first create a reference to the script collection from both iflows. How to do that is described in Kamlesh’s post. Next, assign the shared script to the script step by first clicking the “Assign” button:

On the “Reference Resources” tab, choose the relevant script collection and script and click “OK”:

Finally, go to the “Resources” tab of your iflow and delete the local script; we no longer need it!

Here’s the output when I run CPILint again:

Mission accomplished: The duplicate script issue has been resolved!

Conclusion

The new script collections feature is a great addition to the Cloud Integration toolbox. Using script collections you can avoid duplicating code, which is something you should strive for as a developer. And using script collections in combination with CPILint lets you clean up any duplicate scripts that have managed to find their way onto your tenant.

4 Comments
You must be Logged on to comment or reply to a post.
    • Thanks, Daniel. The check for duplicates accesses the resources of the iflow directly; it doesn't need to see the script collections. Also, I only use the designtime artifacts, and the designtime OData APIs don't return script collections (yet, anyway).

        • CPILint doesn't know that the duplicates have been replaced by scripts inside script collections; it only knows that there are no more duplicates. Which, for this purpose, is good enough.