Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
DG
Active Contributor

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.



 



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.


 



So what is new 


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.


 



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.



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. 



What is next?


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.


 
Labels in this area