How do you Document your SAP CPI Iflows

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.

SAP Best practive

I did find an example of a SAP CPI template in the best practice guide. I did not like if for a few assumptions:

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

Run Figaf IRT in your own Cloud

We have added the Figaf Cloud. as a way to allow users to run our tool to manage the SAP CPI and API management. It is a great way to scale and deploy your application.

We have it hosted in Google Cloud Platform in a Kubernetes cluster. It i pretty easy to do in GCP and it allow scaling of the application pretty easy. It did take some time to understand how to build the app and secure the application.

For customers, it is a really good way to get started using Figaf IRT because they don’t even need to install anything. And all their partners can get access to the network and run applications. So a customer can run all the application to perform DevOps on the SAP CPI and API management systems. The DevOps include

  • Monitoring and alerting
  • Change Tracking or Versioning, so you can link business requirement with a change
  • Documentation
  • Testing
  • Transport of CPI/API flows

With all the focus on data protection, it may prove to be difficult to control all your data that exists in the Figaf IRT solution. You want to have control of where it is located.

We have an ompremish installation of the Figaf IRT tool and it contains the same features as the cloud, though there can be a bit of delay with it because of the release cycles of the applications. One problem that we often hear is so where should we install the IRT application. It can sometime be deficult to find a database and a Virtual server where the Java application can run.

Cloud

For some customers it is much easier to go buy/start a server in the cloud from GCP, AWS or Azure. You can have a direct connection from the cloud enviorment to your on-premish system and thereby get access. The integration department can then get the server self and run it there.

Our installation is pretty simple you can basicly just start the application with the click of a button. It does require a bit more effort if you want to run it with specific databases and setup SSL. It take 30 minutes to install IRT if you have installed the database. The good thing about the cloud enviorments is they all have the PostgreSQL server that we use as a managed. It will then eliminate some of the Normal DB operations that you are doing and just handle it with a few click in the web configuration.

It will also be possible to provide upgrades fairly simple. We have made a docker image that you can use.

We have added a Docker image to DockerHub, so you can run IRT pretty simple to get started with using it. You will need to make a few configurations to get it running. We have a guide on running it on Azure with the hosted database.

The container for running IRT on a Docker image in one of the places starts at 200 USD a month, depending on how you want to scale and have it to perform.

Try it

You can also try Figaf IRT out on your own laptop fast.

Lessons learned while implementing SAP CPI and API management: Webinar

I held a webinar, where I talked about my experiences with SAP CPI and API management projects. And what you should remember when implementing it.

I cover some of the lessons that I had to have on the project. Like the flexibility of the platform allow you to be more agile with creating development. You can always add new paths to the processing to send results to other areas. We also touch on the use of the ProcessDirect adapter that allows you to refactor your integration for reuse. I cover my latest blog where I have talked about Calculating Fibonacci number in CPI, by the way not recommend by gives some lessons.

I have a SAP CPI course that you can take to get you started with CPI learn more

There are also some lessons for API management. It is really great for exposing Odata from your SAP Gateway and securing it pretty easy. There is some challenge with calling other scripts in javascript, so it is somewhat limited what you can do in it. API Management also has some problems with regards to transportation and documentation of changes.

With the Figaf tool you can:

  • Get a better understanding of what is developed and changed
  • Transport and documenting individual iflows
  • Monitor your CPI and set up integration with Slack, Jira
  • I will speed up your development because you will have the option to run
  • Manage your SAP PI/PO, CPI and API Management

Try the Figaf IRT tool here.

Here you can watch the replay:

As you can see, Figaf IRT can help you to optimize your workflow. If you have any questions, please contact me.

You can view the presentation here.


Monitor SAP CPI system performance

Many of the customers I talk with start to see the SAP Cloud Platform Integration(CPI) as a critical tool for their integration needs. In that perspective, it makes sense to be proactive and monitor how it performances.

There are two pages that you can use to check the status reported by SAP as I write about on my blog it is the pages Cloud Status and Status page. They may be relevant to monitor both to warn about what is happening in your landscape.

But what about how to monitor you own tenant and how it is performing. That is the question that most people want to answer because it is what matters for them and then sooner they know about an issue they can setup manual processing or figure out how to do something else. It also provides a way to to messuare if SAP is living up to the SLA of CPI.

How you can messure your CPI tennant

You can setup logging in a number of different tool that will give you some indication of how the system is responding. You can also use the Figaf IRT tool that now will allow you to monitor your CPI system. It is pretty simple and does not require any coding form your side.

You will have a dashboard that looks like the following to see the performance of your system. You can see on the diagram that the system is down for maintenance for a period of time over the weekend. It is possible to see we cannot access the management and runtime engine for a period of time. This is a partner tenant so there may be a different performance and number of nodes as a real system. The system also calls an integration flow every 5 minutes to measure how the runtime is perfroming. This is then returning a response, but from time to time it takes almost 2 second to perform. Also, notice that during the maintenance period we still get a response in the range 400 ms. If it is possible to call process messages even when there is a maintenance window it is pretty cool.

Current view of the SAP CPI monitoring

We are now collecting all the metrics for this. Next is that we will be setting up alerts on this with our alert engine. Then you can get a notification if you are getting latencies above, i.e. 2 seconds or the CPU load is above 80%. Or create a Jira ticket with the simple webhook. We will also be adding status of your JMS queue and other relevant metrics asked for by users.

We have monitoring packages starting at only 150 EUR/Month and then you can also monitor other iflows.

Try it out at IRTCloud or you can also try it on your own deployment of the IRT server you can run on your own cloud. It also has quite a lot of other options to monitor SAP CPI both trigger alerts for failed messages, restart CPI messages and give users access to monitor data them self.

Figaf IRT now supports API management

Over the last couple of weeks, we have been making transports easier for SAP CPI. Now the turn has come to SAP API management. As I understand from APIGEE the normal way is to have a build server that allows you to transport and test scripts. It does require some time and skill in setting up such a server. From the last roadmap session SAP was planing to relase some CTS+ integration in Q3 if I recall correct.

We are using the same approach to document changes of APIProxies. So you can see which Proxy part has been updated, or which script was changed. This makes it a lot easier to document what is going on and why something was changed. You will therefore know what is changed in each release.

We also allows users to make transports based on the business requirements. It is therefore easier to document changes made to the proxy, and link all changes to a business reason.

You can try it out your self at Figaf IRTCloud and see how it performs in your landscape.

With Figaf IRT you have one enviorment that allow you to document all your SAP Integrations in just one application.

We are going to add other functions to monitor your API management, so you can get some more detailed alerts about what is going on in your landscape.