
SAP CPI is becoming a much more used integration engine for running your SAP Integration. It is the place where you want to be creating your future integration.
We have for 18 months been able to easily set up SAP CPI Test cases in the Figaf DevOps Tool, and the functionality has been improved over time as we got more exposure with the tool. I wanted to take this blog and write about some of the new features that we have added to make it easier to perform SAP CPI tests. It should be as easy as possible otherwise nobody gets around to performing them.
We have wanted to make a non-intrusive process as possible for our test to be created. We used the record and replay functionality. Where we could take a payload set of messages from production and send them to your development to test the system to get a request. This is the fastest way to create test cases because you did not need to write any logic yourself.
We have been using the trace functionality where you can test all integration really simply without having to modify any of the existing flows. Moreover, the tool can keep an iflow in trace mode for an extended period. The Figaf Tool is then able to fetch all messages from the flow and be able to process tests for it.
You can see a video of this in action here.
We have a feature that allowed you to mock endpoints that you could not all multiply times or where master data was not accessible. It could be to call Create Employee where it would block the next time you called because the employee already existed.
The way we have achieved it was to make a copy of the iFlow and then change the endpoints to point to the Figaf Tool. Then Figaf could serve the requests with the data to be expected after the call. You would thereby be able to test the remainder of the flow without any problems.
We had some customers that wanted to use our test functionality to create specific test cases they needed to make sure they had tested. So it could be each time they found a defect they needed to set up something on how to solve the problem.
We have added a few new features to be able to support these cases. I think it makes a lot of sense if you want better control over the tests you are performing.
Sometimes it is okay that a message fails because of an error when you are creating specific test cases. It could be your iflow fails if you send invalid data. Then you should be able to run the same test and expect a failed message. This makes it easier to create real test cases.
Our test cases before required the user to download all messages in an iflow. It was not necessary in some cases. The less messages that you process the easier it becomes for you to handle the processing.
If you once you record the message select this option only the first message (used to trigger the test flow) and the last messages(s) will be recorded.
It is now possible to include or exclude the specific steps that you want to check out. There may be a lot of steps included in your process that does not really work for being recorded. Then it makes sense to have a list of the steps you want to process
It is also possible to perform tests with specific payloads. So you can take any message in the flow and start processing it from there.
User often uses MPL attachments or persisted messages. Once you process your recording you can select to include attachments also. Then they will be seen as separate messages. They can be compared to our normal types of messages.
We have created the Shared Configuration and modified it so it matches with our SAP CPI test cases. This gives some extra options of controlling individual test cases. So you can create:
One test case that includes parts of your iflow with include steps
One test case with end to end with mocking data because those data does not exist in the development system
One test that test end to end to see the full flow exists.
Some clients have iflows that are using multiply ProcessDirect calls inside one iflow. We have support this option also so you can run all the messages as one test case to simplify the processing.
The SAP CPI testing option in the Figaf DevOps or Testing Tool have been improving over time.
We currently support the following adapters
HTTP
SOAP
ProcessDirect (The Figaf tool need a HTTP to Process Direct Adapter)
We will probably be adding more like JMS, XI Proxy or IDOC.
If the adapter is not listed then it will be possible to perform test. The Tool will instead just create a copy of the iFlow with a HTTP endpoint that can be used for testing. That way you can still perform the tests even if they use an unknown adapter type.
The system supports comparison of the following formats
XML
JSON
Text
EDIFACT
X12
Tradacom
Many customers are considering or already moving to SAP CPI. I think it is cubical that you perform many tests if you migrate any interface between the two platforms. It is possible to take a SAP PI test case created with the tool and migrate it to SAP CPI test with a few clicks.
This will simplify the testing part of the migration. You can see a video of this test case migration from SAP PI to SAP CPI.
Once you have created some simple way for you to leverage the test cases you already created to create runtime for your Groovy environment. You can see how to create Unit test for your groovy scripts and be able to debug them easily.
There is a number of areas that we can improve our testing functionality in.
Support more adapters directly by Figaf without creating copies of the iflows.
Find a way to leverage the SAP CPI simulation mode for testing. It seems like this functionality is improving. We may be able to tap into this functionality also and create smaller test sets.
And then as always if the customers see something where we can help them, then we will look into it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 |