Posts

Figaf IRT 2.10 Making SAP CPI development faster Git

It has been a long time since our last release. We did have a summer vacation and had a big new function to release. 

I have been teasing that we have Git integration for SAP CPI and also added it for SAP API mgt

Why Git:

The thing that I like with our Git integration is that it allows users to access all sources from your project in just one simple repository. It will speed up the development because you will get easier access to all groovy script and XSLT, so you can reuse it. We have tried using Github, SAP Git from Cloud Platform and also Bitbucket, other will probably also work. Just be sure it is a private repository.

It gives you an opportunity to work in your favorite IDE like Eclipse or IntelliJ to edit the code. They have a much better code completion that allows you to write the code faster. 

It is our first Git release, so we are looking for feedback about how the workflow should be and if there are any ways we can improve it. 

Gradle Plugins:

From an SAP developer perspective, we are not really used to be able to use plugins in our IDE. SAP has released the Netweaver Developer Studio for PI that and the old Eclipse Plugin for CPI development. Here you had some function you could use, but it would only work in that IDE. The better way to deliver integration tools is to deliver Gradle plugins. Normal Java developers have a lot of Gradle plugins they can use to bundle application or run them in a specific way. So it would make sense to add some code to Gradle plugins that allow you to upload, deploy and test your iflows directly from your IDE. That way you don’t need to do leave your IDE to validate if your code is running correctly. We have created 3 plugins are all open source. One to CPI, one to API Mgt and one to handle testing with Figaf IRT. The plugins can be found in the Gradle plugins directory or on our Github page.

Simple workflow

One of the big challenges with starting your own infrastructure is that you need to configure all your plugin. That is the pain we are removing. You don’t need to be a Git expert or know a lot of Java configuration all configurations are delivered templates that you can just reuse. It makes your developers much more productive. 

Other improvements:

We have made some more improvements in the application and fixed some bugs. Among them are once you use the Figaf IRT to transport individual iflows that it use the unofficial Update metadata API. This allows you to keep the version history of your changes and do rollbacks. It is not ideal but we will use it until SAP support the option to update an iflow with the official API. 

What is next:

The next big challenge that we would like to tackle makes it easier for the user to create test data and assertations for CPI development. Half a year ago we created an option to create a Groovy script to set up a message with test data. The approach did make it easier but you had to make some manual changes. That is what we are trying to change. We want to make it possible to generate scripts both input and expected output, so you can run the test case a lot easier. This will speed up your development even more. 

Try it out now and see how it works

There is a free version of Figaf IRT that you can use. It will enable you to expose your CPI system using Git. You can run Figaf IRT on your Laptop and it takes 10 minutes to get started.

We hope to find a way to license the feature while making it easy to try. But for now, there is only a restriction on the number of agents/CPI systems you can connect with.

SAP CPI and GIT integration

If you want to leverage the SAP CPI capabilities and improve the speed of delivery you need a better way than use the Web front end of SAP CPI. Many users will create a GIT repository to add files to so users will get access to all files for the project and can use their favorite IDE for it. It does require a lot of effort to keep everything synchronized.

We have started to improve the functionality for users to be able to use SAP CPI from their own IDE. For this, we have created a few new features.

  • From Figaf IRT we have added an option to synchronize all your integration flows to a Git repository. You can use Github or SAP’s Git service, so all your team can get access to the same source.
  • We have created a Gradle plugin that allows you do download, upload and deploy integration flows from your IDE. This is a free plugin you can use even if you are not using Figaf IRT.
  • We have created a Gradle plugin that enables you to run a test case for one or more iflows as a part of a change.

Our design principle has been to make it as easy for developers to get to use Git and deliver as much preconfigured. You can add more plugins if you want to.

This is an initial version of the Git integration, and we will probably see some changes and ways to improve it over time. We have some more things that we could add like test scripts to run local testing and we need some improvements with commits. It will depend on customers inputs.

You can signup to try out the Figaf IRT tool now on your own CPI system and then once the new feature is added you will be able to run it.

Virtual SAP CPI landscapes

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.

Try it out the Figaf IRT tool as an onpremish or use our cloud for it.

Testing SAP CPI with Mock data service

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.

  1. Switch the integration flow into trace mode.
  2. Let the user send some messages
  3. 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.

  1. Switch the integration flow into trace mode.
  2. Figaf would send the input data
  3. Figaf IRT could then pick up all the trace data
  4. 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.

Sharing SAP CPI resources

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

  1. From an iFlow Resource, you select create a resource
  2. Enter a name for the resource. Shared_ will be added as a prefix to make it easier to see what is shared
  3. IRT will then add the new resource to your Iflow
    1. Make manual changes to start using it
  4. On other iFlows you can add the shared resource
  5. If a user changes a resource in an iflow the shared resource will have a new version
  6. Use can then apply the shared version to iFlows where it is used
  7. 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.