We hosted a webinar this week about how to test SAP Cloud Integration (CPI). We showed how easily you can create test cases for your SAP CPI IFlows with a few clicks and run and maintain them. If you are interested, you can see the replay here.
We covered:
- How to automate your testing
- How to test mock services
- Testing PI to CPI migrations
I did get one interesting question that I get from time to time when talking about our testing tool.
Update: If you want to run a load test on your SAP Cloud Integration/CPI, we recommend our updated blog here. Here we show how you can easily trigger an iFlow 1000s of times.
Question: will this help test performance?
Watch on YouTube Can you measure SAP Cloud Integration (CPI) Performance
It is a really valid question because you want to see if the infrastructure or the code you have created successfully are performing differently. If you get a performance decrease of 20% there is something you should be looking into.
It could be because you have added some memory or CPU-hungry part of the process that you would like to understand.
For now, the answer is no.
And there are a few reasons.
What is performance?
First, we need to understand what the performance of an IFlow is and how you want to be testing it. There could be a number of versions:
- How long does it take to run a given iflow with the content
- How many concurrent processes can run
Both of these depend on:
- Payload
- Processing time on the server
- Latency with calling external services
- Current load on the server and the network
- What the CPI system otherwise is doing
- Database access
In an SAP PI world, it was easy to control 4+5 because you know what the server is up to. In a CPI world, you can have many nodes and my guess is the runtime nodes run on servers that are somehow shared. It means that if other clients were performing testing at the same time it would affect the free CPU utilization. It would make it much harder to know what the current performance is.
With that in mind, it could be normal that the iflow perform 50% slower because the above factors are different.
Could we implement this at Figaf?
Yes, it would be possible to include this into the Figaf server or to allow you to export the file to Apache JMeter that you can run as a part of your daily processing.
It could provide some good metrics about whether you have introduced a slowdown.
We could take the single iFlow processing time and compare it to the last time you ran that test. It would give you some idea of how the system is performing.
But how much confidence would such a value give you to make a better process?
Do let me know how you think good performance testing should be done.
Please share here.
