SAP PI Vs SAP Gateway

A common question people usually ask when starting out implementing or learning SAP OData and SAP Gateway is, what is the difference between SAP PI and SAP Gateway – (SAP NetWeaver Gateway is now rebranded as SAP Gateway.. so I will continue to call it SAP Gateway)?

If you haven’t yet started to read about the Gateway and OData, then you should start now and if you don’t know what is SAP PI, then its fine fair to say its an SAP product used to integrate SAP and non-SAP systems.

SAP PI stands for Process Integration and has been in the industry for a long time. I am sure you must have heard of ALE and IDOCs which is used to transfer data between systems. PI (originally started out as XI) is a much bigger product than ALE. It is an SAP Technology Framework to solve Integration challenges specifically for data transfer between Applications(A2A) and Systems(B2B).

Since SAP Gateway is also related to transferring SAP Data to external consumers hence on initial thought it could be assumed that PI should be able to cater to all that the Gateway does and more. Hence one might wonder, is investing in an additional Gateway really necessary or can PI do the job. Since companies may have already invested in it so really do we need the Gateway?

I will try to answer this question in 2 ways: A simpler example and then some more details further down.

Scenario:

Imagine you a have headache and you walk up to your local pharmacist or chemist and ask them to recommend a headache pill. The Pharmacist suggests you take an over the counter Aspirin. You agree and tell the Pharmacist that you would want to buy one. The Pharmacists checks their inventory and finds that the stock on Asprin is running low. So she goes inside the warehouse to place a bulk order for a particular brand of Aspirin.

The order however is not dispatched right away. The pharmacy’s software system bundles up all the days orders and dispatches this order to the drug distributor which is responsible for distribution of the drug from the Pharmaceutical company that develops and markets the drug.

The above scenario is a very very simplified version of a very complex system. But lets understand the business scenario here.

In the above example there are two types of transactions that happen.

1. An end user transaction where in the customer purchased an Asprin over the counter from the Pharmacist.
2. A system transaction where in the system placed a bulk order to the Distributors system, the Pharma company’s product sales and Distribution network.

If we have to make a broad statement here and keeping all the complexities away for a moment, then for the first transaction case we would use an SAP Gateway, while for the second type of transaction we would use a SAP PI kind of Framework.

---

Another common requirement could be that you have some flat files in one system and you want to move those files from one system to another system programmatically on a daily basis after applying some programming logic to validate the file content without any manual intervention. In such a case also PI would be a better choice than Gateway.

---

Lets see why would that be the case. We will then be able to appreciate each technology as it exists.

The answer to this is based on the scenarios that the company is trying to solve.

User Requirements:

In the current era, SAP users can be typical classified into 2 types.

1. Power users : Users who are well versed with using SAP GUI, Portal etc. These are primarily users like administrators for example, purchase administrator, payroll administrator, system administrators.
2. End users : These are  “occasional user” who regularly but typically on need basis, use the SAP environment. This group often has difficulty using SAP applications, as they are used differently to what they are accustomed to with other business and consumer applications. Additionally, they want mobile access so as to carry out ad hoc work regardiless of the location or time.

When we talk about End users, since they are users who have difficulty using SAP applications, and expect consumer grade, app like features in their business applications, hence making these user interfaces easy to use is necessary. Plus with the rapid technology changes happening, it is necessary to have the capability to be able to quickly deploy the changes and adapt to newer innovations. For this reason SAP has introduced a completely new concept called as sap FIORI and SAP Gateway is one of its core components which is responsible to feed data for its Apps.

The Gateway is built in such a way as to enable the development of REST based OData services in SAP which can expose underlying SAP data thus keeping the application developer free to develop frontends that can consume the data as per the user requirements without burdening the developer from knowing the details of the underlying data structure(known as metadata). This can happen only because OData is based off of the HTTP protocol which is a REST implementation and since the internet works on HTTP hence all applications that run on the internet invariably understand HTTP.

However when we talk about System to System, Application to Application (A2A) and Business to Business(B2B) type of communication, then we cannot be certain that all business applications will ahere to HTTP. Many of the older (legacy) systems within the company cannot be easily upgraded. Also many of the company’s partners like suppliers, vendors, customers etc use system which are non-SAP or spread across multiple domains and technologies. Hence building an integration channel between them based purely on HTTP is difficult.

SAP Process Integration (SAP PI) is a functionally comprehensive SOA middleware platform aimed at A2A (Application-2-Application) and B2B (Business-2-Business) system integration scenarios.

PI scenarios are often executed independently without the direct involvement of a ‘user’ whereas Gateway Scenarios mostly are synchronous and require direct involvement of the user.

PI implementation processes are often complex, containing several aspects and several people, applications and environments. It usually takes months (of designing, constructing, testing and validating) to get a new or modified scenario up and running.

Architecture of  SAP PI:

SAP software has many core modules which cater to various necessary business functions of any organization, for example, Accounting, Finance,  Sales and Distribution, HR, MM etc. However there are some modules which are additional support modules. As stand alone they are of no significance but with them they the software usability and functionality becomes very powerful. SAP Enterprise Portal and SAP PI are two such modules.

SAP PI is built as an SOA (Service oriented architecture) in that meaning the applications that need the SAP PI are not bothered with the internal running of the PI.

A common example of an SOA application could be a payment gateway that comes into picture when you purchase a product online. Your credit card payment is validated and the payment is processed by a third party service company and after the payment goes through, the program control returns back to the original website with a success or failure response. The caller website is not bothered about what happened, all it wants to know is whether the transaction was complete or not.

PI is also an ESB (Enterprise Service Bus) model which means you can integrate different applications by setting up a communication channel between them to enable application to talk through the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus.

 

There are many adapters available in the PI system which helps to integrate SAP and non-SAP systems.

• Usually in a typical large scale SAP implementation there may be some legacy applications which cannot be migrated to SAP because of their complexity or SAP just doesn’t support them. In such cases its a usual practice to leverage SAP PI to build an interface to transfer data between the 2 systems.
• Also within an SAP system itself its typical to have a CRM, SRM, FI systems to be running on different SAP instances. In such a case a PI system acts as a central box which keeps all these systems in synch.
• There are non-SAP third party systems and partners such as Banks and vendors who’s systems have to be integrated with the client’s SAP system. Every system may be different and working on its own unique protocol. Because PI has a number of adapters inbuilt hence mapping out the transfer process between heterogeneous systems is possible.
• Another important point to keep in mind is communication between systems is usually synchronous. Particularly in the case of a gateway, a request is sent from a calling application and the application waits for a response before proceeding to the next step. However sometimes you may need the data transfer to be asynchronous. In such cases a PI system allows  us to create asynchoronous mode of data transfer.
• A Gateway provides OData feed to the calling application by using its own native BAPI and RFCs so when it comes to non-SAP system data using Gateway really doesn’t make sense (atleast for now).

There are many points to mention when explaining the difference between Gateway and PI but frankly SAP Gateway cannot be compared to SAP PI, because it only supports synchronous connectivity to a SAP environment. SAP chose this deliberately so that Gateway could be optimally positioned for all developments concerning SAP Mobile, SAPUI5 Modern Apps, etc. SAP Gateway is considered an absolute must in the SAP landscape of the average SAP organization when looking at the SAP roadmap.

Developing in SAP Gateway needs developer to know SAP BAPI, SAP OOABAP and SAP RFC’s however the application developer who is tasked with developing the consumption screens and modules need not know about the SAP Data structure However developing integration scenarios for SAP PI needs extensive knowledge of SAP architecture and the business process.

So Frankly speaking if you want to build an application is dependent on heavy user interaction then SAP Gateway is necessary, however your chief concern is System Integration between 2 or more systems requiring minimal human intervention then you should think about SAP-PI.

Hence next time you are asked this question whats the difference between SAP PI and SAP Gateway, you know better to advice them what to use when.

Thanks for reading this extensive blog. I have tried to keep the blog to the point without going into much details about the internal workings of either the Gateway or PI.

 

Click to Download the complete pdf Comparison Chart

There are many blogs that address this topic. Following are some blogs if you want to read more.

For more information and samples on PI Check the following links

• https://blogs.sap.com/2013/05/21/sap-pi-for-beginners/
• https://en.wikipedia.org/wiki/SAP_NetWeaver_Process_Integration