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?
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? 😀
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.
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.
Command line and ASCII-art, what's not to like!? 🙂
It looks like a great tool for CPI audits, especially if your CPI tenant starting to grow rapidly and governance of Integration Flow starts to be a challenge. Looking forward to put my hands on it 🙂
Looking forward to try out your tool.
Sriprasad Shivaram Bhat
That sounds like a great tool! I'd be happy to test and contribute?
Looks good. Haven't tried it out (due to lack of CPI usage in our organization 😉 ), but just have an idea in case it's not implemented yet: Some kind of naming conventions for artifacts could be desirable (pattern validation, for example with a list of allowed system names which have to be included in the name of iflows).
I was actually pretty far with naming rules, but then the pandemic happened. There is a lot of code in place, though - I just need to finish it 😀 Hopefully it won't be too long.
Thanks Morten, that would be great and would give us probably the biggest added value!
CPILint 1.0.4 is out now with support for checking naming conventions. More detail in this blog post.
Thank you Morten! I will check it out. After a first glance, I especially like the Regex feature for more complex naming rules (like containing IDs)!
Hello Morten Wittrock ,
I would like to start using cpilint in our SAP CPI landscape. I want to use cpilint in combination with jenkins. I was wondering if you have ever tried setting up this combination within a SAP Cloud Platform Neo enviroment? I’m aware that there are several blog posts regarding the deployment of jenkins to the SCP enviroment available. My question is how I can let jenkins access / use cplint? AFAIK there is not direct plugin available. Do you have any thought / help regarding this matter?
Eng Swee Yeoh
I haven't done so myself, but the command line tool returns a status code which reflects whether there are issues or not, so you should be able to run the command in Jenkins and react on its outcome.
If you get this set up, it would be a great topic for a blog post 😀
The only issue I see here is that this setup would require a dedicated system i.e. vm in SCP / Azure / AWS or am I misstaken? Accoding to your comment I do understand I can't simply deploy Jenkins as Java application within the SCP as it requires commandline access?
Hi frederick dimmer Did you try it? I am also trying to include as part of a task in an azure pipeline.
Dear Alexander Clen Riva ,
I've not yet had the time to do so. However I still have this on my everlong list of TODOs ;).
Hello Morten, great post, thank you. Best Regards