Introducing CPITracker

[MortenWittrock]

Updated December 9th, 2017: HCITracker has been renamed CPITracker, since the HANA Cloud Integration product name no longer exists.

In some of my SAP Community blog posts, I’ve highlighted ways we can look under the metaphorical hood of SAP Cloud Platform Integration. In this post, for instance, I showed how to find the version of the underlying Apache Camel framework. In this one, I showed how to discover some interesting properties of the XSLT processor.

In the shower (where else?) the other day, I had an idea: Tracking how these values change over time, would offer some interesting insights into how SAP Cloud Platform Integration is continously updated behind the scenes.

As a weekend project, I set out to develop an Integration Flow that does exactly that. The result is the @CPITracker Twitter feed. The tracker hasn’t been running for very long, but has so far reported these two updates:

Why is this interesting?

In my book, taking a peek behind the scenes of SAP Cloud Platform Integration is interesting in and of itself. But there is more actionable knowledge to be gained as well. The tweets shown above tell us that Apache Camel is now at version 2.17.4. A quick test shows that the messageHistory Simple expression language variable, which was introduced in version 2.17, is now available in SAP Cloud Platform Integration. See? We’ve learned something useful already 🙂

What is being tracked?

At the moment, the following properties are tracked:

• Supported XSLT version


• XSLT processor vendor


• XSLT processor product name


• XSLT processor product version


• Java Runtime Environment version


• Java Runtime Environment vendor


• The JVM version


• The JVM vendor


• Apache Camel version


• Groovy version


• CPI build number

As I add more, I will keep this blog post updated.

How does it work?

The tweets are posted by an Integration Flow running in my tenant. A Timer Start Event executes the Integration Flow at regular intervals. A couple of Groovy functions and an XSLT stylesheet extract the values I need, and Data Store operations are used to save and retrieve the values. Another Groovy function compares the previous set of values with the current set and extracts any differences found. A General Splitter then iterates over those differences, and each one is turned into the text of a tweet by yet another Groovy function, and posted to Twitter using the Twitter adapter.