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 Tool, 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.

Mocking of endpoints

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.

Test non successful 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 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.

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 

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.

Settings pr 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 multiply ProcessDirect calls

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.

Other features 

The SAP CPI testing option in the Figaf DevOps or Testing Tool have 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)

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.

 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 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.

Unit tests for your Groovy Code 

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. 

Try it your self.

You can signup for a free trial of the Figaf DevOps Tool and then try to see the tool can help you.