Some SAP CPI customers do not have a full 3 tier system landscape for their SAP CPI. But you may want to experience having all the systems connected and be able to test the flow. You can do it manually, with using the copy functionality, but it requires a lot of governance to keep the QA updated.
We did originally create the virtual landscape just to test, how our transport system worked because we did only have one CPI system. Now we have improved the functionality because it enables customers to take advance of our transport and leverage using one CPI system. We did earlier change Sender system to match with having a prefix with the system name.
We have now improved the functionality so the system is added to the Process Direct adapter. Here we are adding the prefix in the URL to both sender and receiver channels. You will thereby have the option to run it in a “QA environment”.
You can see a demonstration of how this works in the video.
Updated: If you import a package it will be auto deployed.
The transportation system also provide option to create Iflow documentation, and you can test the impact of a change. You can also make modification of Externalize Parameters across the landscape, so you can specify that the target URL on QA is this. Then IRT will handle the configuration once it deploys.
If you start making any changes to your SAP CPI system you will end up with problems where you need to be able to test your integration flows, if you make modifications to your scripts. In most cases, it will require that you have access to the same backed system and create the same requests.
Figaf have been supporting testing of SAP CPI for about 1 year. We was able to do it in the following way.
Switch the integration flow into trace mode.
Let the user send some messages
Figaf IRT could then pick up all the trace data and use it as a baseline.
To test an integration flow it did the following.
Switch the integration flow into trace mode.
Figaf would send the input data
Figaf IRT could then pick up all the trace data
Compare the data with the original data.
It did provide an easy way to test your iflows with and enabled users to compare the data. To see if anything had changed.
Why we needed a new way of testing
The old way is good if the flows you don’t have many backed services you are connecting with and they are able to reply the same data. If you have SuccessFactors it may be difficult to create or fire the same employ multiply times. Or if your interface is expecting a delta of data, then you will not without making modification be able to fetch the correct data.
And then we want to be able to run the test more often, so we can be sure nothing is impacted. It could be our new approach about adding shared resources to SAP CPI, so if you make a modification in a script it will update all the other iflows.
Or if possible be able to run it on the next release of SAP CPI to see that nothing is affected.
How testing SAP CPI with mock data work
The testing work a little different than if you have any receiver adapters. Figaf will create a copy of the iFlow, and replace all Receiver channels with a HTTP call to the Figaf IRT server. It will send information about the current test case and what part of the process it is in. The API exposed at the Figaf server will then return the HTTP headers that have been changed in the process and also the body.
As a user the only thing you need to change is how to select that the test should be performed with mock data.
If there is a change in the iflow then Figaf would automatically synchronize the testing copy, and deploy it.
You can see the demo of how the service works.
As you can see it works pretty simple to get to work. Just one tick mark on the Testing Template. The solution does work with Cloud Connector if you have CPI on your local installation of IRT, you will just need some settings to specify URL and cloud connector information when configuring the iflows.
What are the limits of mock data
With the mock data there is some limits. Some we can probably find a way to solve with more development and feedback from customers.
You will not be able to test your adapter.
You be able to test any binary objects in the headers, it is not possible to recover them.
It does not support Enrich scenarios at the moment.
Try it your self
You can download Figaf tool and run it in your own landscape or you can try it out in our cloud deployment.
https://figaf.com/wp-content/uploads/2019/06/SAP-CPI-Mock-data.png6281200dgraversenhttp://figaf.com/wp-content/uploads/2016/05/160510_FigafLogo_final_35cm_KW.pngdgraversen2019-06-24 16:58:502019-06-24 16:58:51Testing SAP CPI with Mock data service
A common use case when using SAP CPI is that you want to share scripts with multiply CPI iflows. Currently, now you have to manage this your self by copy or upload scripts in all the places it is used. It makes it pretty difficult to have a good shared repository of resources.
With shared resources, you will get a repository of all the different scripts that you have and can easily check the status of them. If the resource version, you can update all iFlows where that resource is used. If you make a modification of an object it should be possible to test to validate that nothing has happened with your processing.
You can watch a presentation of the flow here.
The flow is as the following
From an iFlow Resource, you select create a resource
Enter a name for the resource. Shared_ will be added as a prefix to make it easier to see what is shared
IRT will then add the new resource to your Iflow
Make manual changes to start using it
On other iFlows you can add the shared resource
If a user changes a resource in an iflow the shared resource will have a new version
Use can then apply the shared version to iFlows where it is used
Test that the modification does not affect processing
Limitations
There is some challenge with the current setup. You cannot share message mappings primarily because they rely on the source and target schema and possible groovy scripts, that they also need to be shared. We can probably find some way to get around it. If it becomes a requirement, we can find a solution that allows you to share message mappings also.
A standard solution from SAP
It is a common request and it may be possible that SAP will implement something similar to a standard part of the development. One thing that is required for this to work is the ability to test that the change does not affect other iFlows. It should be possible to adopt our solution, so it will enable version and support testing of the shared resources.
Want to try it out
The feature will be released in the next version of Figaf IRT probably in the week of 17 June. But you can already now signup and try all the other great functions we have to make your SAP CPI life easier.
We have an integrated approach for handling Change Management for SAP CPI (Cloud Platform Integration aka HCI). In this video (25 minutes) I show how the full application is connected. It is a way to have a central place to manage all your SAP Integration development.
In the video I show how you can get a good change management process for SAP CPI with
Full traceability for all modifications made for the development, and linking with business request
Ability to view differences between objects and understand how they have been changed because of a business request
Test the process have been developed correctly
Configuration of Iflows across the landscape, so there are no manual steps for the transport
Transport of individual iflows in the landscape
Document all changes in the process
There is also part of the monitoring that makes monitoring of the CPI easier and enables you to setup alerting if a message is in a specific state.
https://figaf.com/wp-content/uploads/2019/06/Figaf-CPI-CTS-transports.png6281200dgraversenhttp://figaf.com/wp-content/uploads/2016/05/160510_FigafLogo_final_35cm_KW.pngdgraversen2019-06-03 14:55:162019-06-03 14:55:17Watch the full flow of Figaf to handle SAP CPI Change Management
Documentation of integration has always been a strange thing. It has been pretty difficult to make sure we documented the details correctly and had enough information with. Normally you will just get some document designed to document some other thing and then try to adapt it to your integration. That will never give a good result. You may be compliant but just a waste of time if the documentation is not useful.
For SAP PI/PO we have for ages been using a Word template for the documentation of each interface. We support that with the Figaf IRT tool, so you can generate it fast. You can see an example of the SAP PI documentation here. The inspiration was to avoid having the documentation that was never updated and always had the initial version.
It was focusing on the wrong things that were a bit to detailed and too generic. Like a file conversion, or mapping it just has empty tabs that users need to fill in.
It could not be automated every well, which ment it did require a lot of user governance to host the information
It was juggling 3 different adapters and not showing the required details
I wanted to improve the process and make it even easier to capture the most important part of a CPI Iflow. It ended up with the following information:
Overview of the iFlow header information like name and description
History of changes logged with business requirements
Connection sender and receiver together with information
Test cases you have created for the tool
Flow description which is a table representation of the iflow. It will give some overview of how the different steps are connected
Configuration parameters configured in the full landscape, so you got some information on what is being used and the relavant resources.
Resources and the lat change data for them.
You can download an example of the document here for the SF to AD iflow.
There are ways to improve the document with more information. If you have anything that you think will provide value and make it easier to understand the documentation. Do let us know.
Automated documentation does have some limits like being able to update it different places, and add the extra information that makes sense.
You can try it own on your own iflows and see how it performs in your landscape.
https://figaf.com/wp-content/uploads/2019/05/SAP-CPI-Iflow-Documentation.png400700dgraversenhttp://figaf.com/wp-content/uploads/2016/05/160510_FigafLogo_final_35cm_KW.pngdgraversen2019-05-23 13:30:192019-05-23 13:30:20How do you Document your SAP CPI Iflows
