SAP Cloud Integration (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. To build a good practice you need to be able to easily create and run test cases. When the iflows changes you can easily update the test.
We can quickly set up SAP Cloud Integration test cases in the Figaf DevOps Suite, and the functionality has improved over time as we got more exposure to 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.
Watch on YouTube How to test SAP Cloud Integration in 3 minutes
Mocking of endpoints
We have a feature that allowed you to mock endpoints that you could not call multiple 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.
Test unsuccessful messages
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.
First and last message
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 select this option when you record, only the first message (used to trigger the test flow) and the last message(s) will be recorded.
Exclude/Include specific steps
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.
Changing content in the test cases
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. This enables you to always have current test cases.
Record with payloads
Users often use 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.
Settings per test case
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.
iFlows with multiple ProcessDirect calls
Some clients have iflows that are using multiple ProcessDirect calls inside one iflow. We support this option also so you can run all the messages as one test case to simplify the processing.
Other features
The SAP CPI testing option in the Figaf DevOps Suite has been improving over time.
Supported adapters
We currently support the following adapters
- HTTP
- SOAP
- ProcessDirect (The Figaf tool need a HTTP to Process Direct Adapter)
If the adapter is not listed, it is still possible to perform tests. 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.
Comparison types
The system supports comparison of the following formats
- XML
- JSON
- Text
- EDIFACT
- X12
- Tradacom
Migrate SAP PI/PO test cases to your SAP CPI
Many customers are considering or already moving to SAP CPI. I think it is crucial 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.
Unit tests for your Groovy Code
You can also leverage the test cases you already created to create a runtime for your Groovy scripts. You can see how to create Unit test for your groovy scripts and be able to debug them easily.
Try it yourself
You can start a free trial of the Figaf DevOps Suite and see how the tool can help you.
