Last weekend, at the SAP Inside Track Walldorf event, I had the pleasure of showing a live demo of CPILint, an upcoming open source tool for SAP Cloud Integration. In this blog post, I’ll give you an overview of CPILint and what it can do.

What is CPILint?

Let’s start by breaking down the name. CPI is short for SAP Cloud Integration, SAP’s integration platform for the cloud (or Integration Platform as a Service/iPaaS in Gartner terms). Lint (also known as a linter) is a tool that flags, quoting the Wikipedia article, “programming errors, bugs, stylistic errors, and suspicious constructs”. You may already know linters such as ESLint for JavaScript, and abaplint for ABAP by Lars Hvam.

So, CPILint is a linter for SAP Cloud Integration. More specifically, it’s a tool that automatically checks your integration flows against a number of different rules. The rules cover best practices, connectivity, security and more. From the built-in rules, you choose the ones you want to enforce, and CPILint does the work of checking for integration flows that don’t follow those rules.

You might think of the CPILint rules as executable development guidelines. A development guidelines document might state that at company X, we only transform messages with message mapping. That’s all well and good, but up until now, there’s been no way of knowing whether that guideline is actually being followed, short of manually checking every integration flow. With CPILint, however, you can set up a rule specifying allowed mapping types, and completely automate the process.

CPILint is open source

What does it mean to you, that CPILint is released as open source? First, it ensures that you always have access to the full source code. The code and all required files will be available on GitHub, and also included in every release of the tool.

Second, the open source license allows you to modify the code. CPILint is released under the MIT License, which is one of the most permissive and most straightforward open source licenses out there. This means that if there’s something you want to add or change, you can go right ahead and do so.

How does it work?

The CPILint rules inspect integration flow artifacts. An integration flow artifact is what gets created behind the scenes, when you build a new integration flow. The artifact contains metadata, resources (e.g. scripts, XML Schema files and so on) and an XML document containing the complete configuration of your integration flow. Some rules only inspect resources, but most of them examine the integration flow XML document.

The majority of the rules work by inspecting a single integration flow artifact to determine whether it breaks that rule. One example is the rule that checks for allowed mapping types. Others, however, need to see every integration flow artifact to do their work. An example of this is the rule that makes sure, that for every receiver ProcessDirect channel, there is a matching sender ProcessDirect channel with the same address. This rule cannot know for sure whether a sender channel is missing, until it has inspected every integration flow artifact.

When an integration flow artifact breaks a rule, that rule creates an issue. The issue contains the information required to locate the problem, such as which integration flow artifact, which mapping step or channel etc. CPILint is a command line tool, and for the moment, all issues are echoed to the command line. However, issue handling is pluggable, and there are many ways they could be handled, like adding them to an incident tracking system, or posting them to a Slack channel.

CPILint can inspect integration flow artifacts, that have been downloaded to the local machine, or directly in the Cloud Integration tenant using the OData API.

What does it look like?

Here’s a simple example of a rules file, which is the XML document containing the rules, you want to check:

And here’s an example of the tool’s output on the command line:

In this example, CPILint has discovered an integration flow with a ProcessDirect receiver channel, that does not have a matching ProcessDirect sender channel.

The ASCII art can be disabled, by the way, but why would you want to? 😀

What’s next?

The tool is still under development, and so is not available yet. However, a beta test is planned for Q1 of 2019. I’ll post the details of signing up here on the SAP Community site, so watch this space, if you’re interested in joining. For the 1.0 release, I’m aiming for sometime in the first half of 2019.

Shoutouts

Before wrapping up, I’d like to send a special shoutout to Vadim Klimov and my fellow SAP Mentor Eng Swee Yeoh, for the really excellent feedback they’ve given me, and continue to give. Thanks guys, you rock.