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.

Links to your SAP Cloud Landscape

As a developer one of the things that I often struggle with is to understand what system I need to login to to develop. With PI your learn to remember that PIT is the test system. But with CPI you just have some seemingly random numbers and it can be difficult to remember. I have received my fair share of emails with links in that I often go search for. I need to create a long series of bookmarks. And all new developers need to do that. Now we have made it easier for you to access the different pages.

I also normally added new tab names for each system so I can remember which system I’m currently have open in my tab.

With the new release of Figaf IRT 2.8 we are adding a function to allow you to configure your full landscape so you from the Figaf home page can go to all the relevant systems. Since we support transport and monitoring in your landscape you will anyway need to configure all your systems in Figaf IRT. You can also register all instances to a landscape so you will get links to all the entries in your environment.

The new homepace of Figaf IRT now look like this.

New Figaf IRT homepage with links to all your SAP Integration tenants or systems.

From each landscape you can then go to the relavant tennant and links. You can have multiply landscapes of each.

  • For API management it is both the developer portal and the API portal.
  • For PI it is /dir, Netweaver Administrator, PI monitor and B2B Add-on homepage
  • For CPI it is design, monitoring and IRT monitoring page.

If you have ideas to more then let me know.

We may add links to SAP sites like status pages or Cloud Platfrom links.

This feature will be rolled out to Figaf IRT Cloud and Figaf IRT around 14 May. You can get free access on either link. We also have some other cool features making your development process a lot easier.

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.

SAP Integration Landscape and Emerging Complexity

The field of process integration is changing quickly, setting new challenges for Integration professionals, and I think a good understanding of the available tools is key.

When we talk about paradigms in process integration, there have been 3 major phases:

  • Mainframes: Back in the day, most companies had one mainframe or two. The good thing about the mainframe was that it was fairly simple to integrate what were essentially internal programs – even if you had to work across mainframe platforms.
  • Client-server: With the emergence of client-servers and SAP R/3, the number of application servers was growing quickly. Suddenly, as an Integration Department, you had to figure out how to integrate the applications in your landscape so that you could create a new interface. In SAP terms, it may have been a Business Connector or eXchange Infrastructure (XI). You only had one tool to use.
  • The Cloud: Today, cloud integration is the norm, and the goal is to be able to quickly and easily leverage new cloud capabilities from existing development. A couple of examples of existing cloud capabilities are Hybris Cloud for Customer (e-commerce solutions) and SuccessFactor (human capital management).  There are also a number of non-SAP cloud applications. In fact, you most likely have some of them in your landscape already. As the integration expert, your job requires you to make them all play together seamlessly. Some come with prebuild content others you have to create for yourself.

As I said earlier, it used to be that you had integration consolidation that mostly worked in XI/PI. Now, Integration departments are faced with a very different landscape, driven by the need for new integration capabilities, and need to be looking outside of their space at the tools that are already available in other areas of process development. If we understand what’s out there, we can choose the right tool for the job.

I’m talking about tools like the HANA Cloud Platform – integration services (HCP-IS)/HCI, Process Orchestration (PRO), API Management, and Data Services to do bigger data ETL. We’ve also got the Application Integration Framework Overview (AIF), for when you want to do any integration with backend services. There are also SAP Gateway solutions available for exposing OData. Those are the SAP integration technologies that I can think of off the top of my head, other vendors have similar offerings that may be relevant.

I did this exercise with a customer and we spend 6 hours on the different topics and when it did fit into their architecture.

The big problem for the integration manager/architect is that you need to know the tools, and know when it makes sense to use one and how to select one over another. You also need to be able to train your team to use them. As you learn more, you’ll find a lot of overlap between the capabilities of the various tools, and knowing what each one can do will allow you to streamline your process when you have complex situations.

The challenge with all these tools is that it is both labor-intensive and potentially expensive to try them out. Say you have a situation where you want to expose some data to the user. First, you will have to figure out the logic and the capabilities of the various tools to find the best one to combine the elements so your API management will call  PRO or Gateway — to get or expose some data. Then you’ll need to acquire the tools and start using them, in order to really understand where they fit and what you can do with them. Once you get that down, you will need to work out how to leverage the technology internally. So, a lot of work is involved whenever you introduce new technology like this. You also have to keep in mind that you will be paying for licensing to use the tool, even if you don’t end up implementing it.

So as integration experts and enterprise architects, working in a rapidly changing field, we want to do our homework and really understand any tool and how we can leverage it before we place it in our systems.

What is your strategy for landscape integration? How do you cope with training problems?