I have repeatedly lauded SAP CPI’s flexible pipeline (based on Apache Camel) as a feature that I really enjoy using. It allows integration developers to exert their creativity when designing integration solutions. Another feature that have received less coverage from me is its OData API, yet it is another amazing part of CPI. These APIs allow you to extend CPI’s usage, again allowing developers to come up with innovative solutions outside of CPI.
Bringing together both of these, I have had the privilege in recent months to work with Andrzej Halicki to enhance int4‘s Interface Testing Tool (IFTT) to include capability to test CPI integration flows.
In the following parts of this blog post, I will provide a sneak peek at the technical bits of IFTT that support testing of CPI integration flows.
Overview of IFTT’s Testing Approach
Before looking at the technical bits in detail, I will run through IFTT’s approach to automated interface testing.
- Create a configuration to test a particular interface (PI or CPI)
- Create test case(s) with expected input and output messages
- Execute test case by triggering input message to middleware (PI or CPI)
- Extract output message and compare against expected results
- Generate report with test results
The Bits and Bobs in IFTT
In order to achieve the above mentioned approach, the following two key functionalities are implemented in IFTT.
Triggering message to CPI
In order for IFTT to be able to trigger messages to a particular integration flow in CPI, we introduce an “IFTT Dispatcher” integration flow. This relates to the first feature that I mentioned above, where we can design flexible solutions by combining multiple integration flows. The dispatcher acts as a “middle man”, whereby it receives the message from IFTT and routes it dynamically to the target integration flow.
Extracting message payload from CPI
Subsequently, once the message has been processed in CPI, the payloads need to be retrieved for comparison. In PI, this is achieved with the help of the message logging functionality. Since there is no similar functionality to persist payloads in CPI, we turn to the trace functionality in CPI. Once trace is turned on for a particular integration flow, the payloads are persisted for the next one hour.
To extract them, we use the second feature mentioned, CPI’s OData APIs. In particular, we use the Message Processing Logs API.
First of all, we locate the corresponding run steps of the Message Processing Log (MPL).
And subsequently, we extract the payload for that particular step.
Voila! Now we have the payload and we can compare it against the expected output to verify if the test was successful.
Hungry For More?
If you would like to learn more about IFTT, I strongly encourage you to enroll in the current running openSAP course Virtualize and Automate Your SAP Testing Using Int4 IFTT. This is a free online course to learn about Int4 IFTT, an automated testing software that enables end-to-end application interface testing across the full SAP landscape.
For CPI in particular, look out for Andrzej, who will cover more details about CPI testing with IFTT in Week 2 Unit 3 and Week 3 Unit 4.
Additionally, it is TechEd season again, and int4 will again be running a booth at TechEd Barcelona. We would love for you to drop by for a visit.