Always use PI/PRO for exposing web services

I recently had a long walk at the park trying to get my young son to sleep in his stroller. While I walked, I was thinking about a question I had this week from a potential client, and wondering about SAP integration, and whether or not we need PI/PRO, or if we might be able to use ECC for webshops instead.

The potential clients were doing web service, or a portal, and they wanted to know if they could connect with an ECC backend. I told them that’s fine; the conventional wisdom in PI communities has been that we want to make sure everything is governed through the PI, so we’ve used SOS services. This has been the mantra since I started with PI/XI, it’s been the standard approach.

Recently, however, I see that this standard has loosened up a little, and developers are exposing things in different ways. The first thing that comes to mind is Gateway, which is almost the same thing as using the PI, but enables you to access the ECC data directly using the OData and other similar operations. So Gateway is probably one of the more capable technologies.

We’ve also got solutions like API management, which usually goes through Gateway, or in some instances through PI/PRO. This is a bit of a change, which makes me think again about what the benefits are of using a PI. Obviously, you’ve got the element of governance — you know who’s calling the server – and you’ve got a way of exposing all kinds of different services to the outside world. In this case, the developers just need to worry about web services, and not about RFCs, proxies, or whatever you are calling on the back end. Other benefits include security and scalability, which allow you ensure that that the web service/front end, would not bog down the ECC system with too many requests all at one time. The PI allows you to configure that in different ways. Those are some of the good capabilities of the PI.

On the other hand, the PI is adding some latency to the web service calls, and the development process takes a little bit longer because it is more complicated to call through different layers.

So, ultimately, I guess people need to figure out what a project’s integration strategy is, and whether they have a PI or an HCI, and especially how they all fit in together. For example, if you want an HCI and are calling the ECC back-end, things can become a little complicated! With that in mind, in a lot of instances, it may even be possible to call ECC directly, and let the web guys worry about that part. Sure, as a PI developer, I would prefer to get this extra work, but if it’s not adding a lot of value for my client and it’s just me logging hours, I don’t know if I can justify using it.

What are your thoughts? Please share your input, so I can share with my clients.

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?

Retiring the SAP PIDocumenter and Diff tools

I have retired my documentation tools.

The reason is that they used an old form for documentation and SAP PI/PO did no longer support the use of XIM files. It was therefore not as much the tool was used anymore.

I have created a short guide to how you can export your mappings to an Excel sheet with NWDS. I’m not to found of the layout of it but it does support standard and also export UDFs. So it is an easier way to make the documentation.

How to document SAP PI/PO Mappings using NWDS

Forcing the Use of SAP PI/PO

notebook against colour background with images

One of my colleagues has recently approached me with a question: what happens if the customer doesn’t want the use of the PI system for certain scenarios? We usually stick to the idea that communication needs to be done directly through the PI system – but should consultants force the use of PI for every scenario?


In a PI scenario there is a pass-through (no mapping) interface at work. One of its requirements is that all connections go through the SAP system. The main advantage of this comes from the fact that monitoring becomes easier. You are able to see what RFC (Remote Function Call) calls are made and what load processes are taking place. If you know everything that is happening, working on the architecture also becomes easier. You also have the ability to execute the reprocessing of failed messages (asynchronous messages).


The PI system also makes it easier for clients to execute a call. They can use an SOAP service to call the system and there is no need to use other protocols. Load balancing is also allowed by the PI system, limiting the number of concurrent calls to the back end. In the case of long duration calls, this can make the ERP system less loaded. If several systems are used, it is easiest to use PI and move the processes from this system to multiple other systems.


Now let’s discuss the possible drawbacks of the exclusive use of PI. Obviously, a major drawback is the single point of failure. If the PI system is down, nothing works. This can cause some organizational problems. On the flip side, there is only one system that needs to be maintained.


Extra development work is also needed – you need to find solutions for various issues and develop new scenarios (this is good news for consultants, who are kept busy). Needless to say, performance RFC threads will put some extra load on the system and costs will rise if all requests are sent through the PI system. You might also have a problem with too many threads running at the same time. If that’s the case, you will need to do some performance tuning. If you need to do some changes in the area of RFC calls, you will find that changing the endpoint is a rather easy task to complete.

When developing, you should be able to tell whether in some cases the same architecture should be used. As a professional, you have to figure out the ideal solution for every situation. You also need to allow businesses to say ‘no’ to use the PI system for some scenarios.

The post Forcing the Use of SAP PI/PO appeared first on SAP PI course.

We dont need this java on PI

I was working with a client doing Bank (BCM) integration on the SAP PI platform. Everything was going well. Then I got into a talk around if we could get rid of this Java thing.

Then I had a small issue… Since my focus was to make everything in the integration layer as simple as possible and be able to upgrade it. So it would be possible to go to the single stack.

The claim was fair enough that the bank department did not have enough skills on the Java to support a lot of java code. There was enough ABAP developers around, because they had worked with ABAP for 5+ years. They had the skills for coding and supporting ABAP, in that perspective it was much easier for him and the team to support it.

The same does I see when I do consulting with smaller clients, where they only have a basis or an ABAP developer to handle the PI as a side project. How many things can you handle and support before it is too much.

They seem to have gotten the idea that SAP was moving away form Java. So all business logic from SAP will be in ABAP. They thought of this because of the Oracle acquisition of Sun. My comments was that in my view SAP was still investing heavily in Java both for the PI/PO and for the cloud applications.

I recorded this video around the issue.

I think we got to an agreement on what should be different. The big issue was about maintain lookup values for the business. Most of the values should be maintain on the ERP system, which is not a complete goodbye to the Java stack.

And ABAP mappings was never in the scope.

I still think it is a valid point, what are you required to now inhouse before you can maintain a SAP PI system. Do you need to be PI certificed or can you just have some skills in debugging and monitor the PI system?

The post We dont need this java on PI appeared first on SAP PI course.