Position of SAP NetWeaver Gateway versus SAP PI

With the advent of SAP NetWeaver Gateway 2.0 as standard SAP integration framework, the question arises what the positioning is towards SAP PI/PO, the other SAP integration approach. The question can be answerred from multiple viewpoints.

Business viewpoint

SAP introduced Gateway to address the strong and growing business demand for mobile access into the SAP business suites. SAP NetWeaver Gateway provides for mass consumption of SAP business data and functionality in your existing SAP Business Suite systems. The target audience for SAP NetWeaver Gateway applications is a group known as Occasional Platform Users (OPU). Gateway is designed to optimal facilitate people-centric applications. It is a lightweight framework, easy to develop services as well as consume them; and therefore allows short windows of [commercial] opportunities.

SAP NetWeaver Process Integration (SAP NetWeaver PI) is a comprehensive SOA middleware platform focused on A2A (Application-2-Application) and B2B (Business-2-Business) integration scenarios. PI provides SAP customers a SOA foundation to manage their SOA landscape and SOA development and deployment lifecycle. The scenarios are often executed autonomous, without direct involvement of ‘an user’.

Implementation of PI scenarios involves a lot of different aspects and complexities. As inherent consequence, it takes months before a new or modified scenario can be brought (desigend, engineered, tested and validated) into production.

Architectural viewpoint

SAP PI is foremost an ESB product. It is a separate product to enable integration of heterogenous landscapes, including but not limited to SAP only.

PI is intended as an enterprise integration broker. It enables multiple consumption and integration patterns, whether they be system-to-system interaction, business to business interaction, or simple consumption of backend systems via various interaction channels. It uses an adapter framework for connectivity into the various landscapes and technologies. Note that this is the common approach in ESB land. For instance, also Tibco and Microsoft BizTalk apply this. Through these adapters, multiple connectivity manners are possible: message based, web service calls, IDoc, JCo, JMS.

PI supports both synchronous and asynchronous invocation models. In case of the latter, reliable message-delivery is guaranteed.

SAP positions PI also as one of the parts of SAP PO (Process Orchestration), together with SAP BPM (Business Process Management) and SAP BRM (Business Rules Management). PO supports the orchestration of message exchanges and service calls via a BPMN- based process engine. PI enables herein the statefull handling of integration-centric processes, relying on standard integration patterns to support more sophisticated scenarios such as collecting and aggregating messages or bringing messages in the right order.

NetWeaver Gateway is the point of access into SAP Business Suite data and functionality. It’s single role is to service enable the SAP business applications to outside world, for stateless user-centric scenarios. This is direct/synchronous invocation, not messaging/asynchronous. Gateway uses the de-facto standard market protocol of REST and OData (ATOM + JSON) for simple and fast web service interface, relying on natural request/response mechanisms.

Gateway is aware of SAP internals, but hides them to the outside. To achieve optimal fast performance, Gateway directly invokes via SAP proprietary protocols the BAPIs and RFC of the business applications. There is no messaging layer in between, minimal extra time added in the ‘Gateway’ layer.

Gateway does not give access to non-SAP systems (at least not directly).

System viewpoint

Gateway is hosted on the NetWeaver ABAP stack. Initially it is deployed as Add-On to NetWeaver. As of NW 7.40 it will be an integral part of the NetWeaver ABAP stack.

SAP PI is a product on its own, deployed in the infra landscape of SAP customers. Prior to version 7.3, PI is hosted on a dual stack of NetWeaver Java and NetWeaver ABAP servers. Starting with PI 7.3 only the Java stack is required. From these NetWeaver servers, SAP PI is loosely coupled to the backend(s) - SAP and not-SAP. PI thus requires separate NetWeaver servers (minimal for the Java stack) in the landscape, in addition to the ABAP server(s) for the SAP business suites.

Development viewpoint

When you talk about service enabling the SAP landscape, you must be aware that you also talk about 2 different types of development. On the one side you need to provision the services within your SAP landscape, on the other side you consume these services – and this is not necessary within SAP context. Stronger, it typically will not be, in nowadays of Mobile and Web applications. Consumption is mostly done within iOS, .NET, Android, PHP, Force.com, HTML5, and also SAPUI5 context. The non-SAP developers do not want to care about the intrinsics of SAP internals, but just consume the data + functionalities in a standards-based way.

Consuming SAP PI services is very SAP specific; as developer you are made and have to be aware of the SAP intrinsics. Although SAP PI provides SOAP based Enterprise Services; reality forces to admit that they are still very much ‘SAP-aware’. You cannot feasible integrate with PI services without knowing about the SAP system behind. At minimal the data structure is SAP specific, and often also the processing model.

Gateway consumption instead also (or even more) aims at non-SAP developers; in that distinction you do not want to be aware of how SAP internally works, and its datastructures. Gateway applies a more lightweight approach to achieve this; and conforms to REST / OData as standards-based approach. It is able to do that because the focus of Gateway is much smaller as that of PI. Basically Gateway aims to expose SAP data to the outside world. And this perfectly matches with REST, the ‘ODBC protocol of the web’.

REST / OData can be consumed within any technology, and is supported in the common IDEs (Integrated Development Environments): Eclipse, Visual Studio and Xcode. To facilitate even more, SAP delivers a Productivity Accelerator to easily consume Gateway services in iOS, .NET or Java context.

To ease and accelerate development of Gateway services, SAP provides design-time tools to generate OData (or Generic / SOAP, but this is actively deprecated) services based from the existing SAP business objects in the SAP backend system. PI provides graphical mapping + transformation tools to map the data format of the integrated backend system into the external provided datamodel.

Note that to build both the ES Services as Gateway Services; you must have good knowledge of the disclosed SAP business objects.

Miscellaneous pointers

• SAP NetWeaver Gateway and SAP NetWeaver PI are complementary products
• Gateway is not a replacement for SAP Netweaver PI and eSOA services/ESB's
• Both SAP NetWeaver Gateway and SAP NetWeaver Process Integration can provision RESTful services to SAP backend applications (PI via the Advantco REST adapter)

Conclusive words

Gateway is recommended for user-centric applications. Use Gateway when there is a need for synchronous access to business objects of an SAP Business Suite system.

Use Process Integration when general purpose integration is needed, involving disparate systems and applications requiring asynchronous and synchronous services involving SAP and non-SAP applications and systems.

SAP lacks an official paper / statement regarding Gateway versus PI, but you can derive some of the positioning from their actual actions. SAP is using more and more SAPUI5 as lightweight front-end technology, with Fiori as evident latest example. In all published SAPUI5 examples, SAP applies Gateway for the integration into SAP landscape.

SAP Virtual Events hosted a one-hour session addressing the topic ‘SAP PI and Gateway – When to use what’. You can watch it here.