Scroll Top

Understanding SAP NetWeaver Gateway

IBPM Low-code RPAAnthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Herndon.  ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is an Appian, Pegasystems, and UIPath Low-code and RPA Value Added Service Partner. You can reach him at [email protected].


Through SAP’s history, SAP has provided numerous methods for accessing SAP backend data by external consumer applications. SAP NetWeaver Gateway is their OPEN  standards-based framework. SAP changed the name from SAP NetWeaver Gateway to SAP Gateway in the spring of 2014.  SAP deleted the “NetWeaver” moniker in a number of products to illustrate these technologies “support platforms and deployments beyond core SAP NetWeaver.”

The SAP Gateway, is an open-standard-based framework. This technology provides a simple solution for businesses to connect their platforms, environments and devices to the SAP software they use. With it, you access your required web services, server functionalities and tools to assist you in a seamless application, data or system integration.

Simply put, SAP Gateway is a technology that provides a simple way to connect devices and applications to SAP software based on market standards (REST and OData). The framework enables development of people-eccentric solutions by exposing SAP business software data to new experiences such as social and collaboration environments, mobile and tablet devices and rich internet applications. It simplifies connectivity to SAP applications by allowing any programming language or model to be used without the need for SAP knowledge by leveraging REST services and OData/ATOM protocols.

Understandably, you might have questions about the SAP Gateway, so lets dig in…..

What are REST and Odata?

You can connect to SAP applications via all programming models and languages using OData protocols and REST services. So let’s start by looking at some key points of these technologies as they relate to their use in this blog.

  • REST (Representational State Transfer) is a software architecture style used for distributed systems like the World Wide Web. Owing to its simple style, REST has gradually replaced other design models like WSDL {Web Services Description Language} and SOAP {Simple Object Access Protocol}.
  • OData (open data protocol) is a web protocol that allows data queries and updates. With this open protocol, you can query data sources over the HTTP protocol then get results in different formats like plain XML, JSON and Atom. It provides a uniform option for the display, structure, and query of data. Thanks to OData, there no longer is a communication barrier between non-SAP and SAP web developers. There is also no license agreement or cost required for using OData services.

Information Exchange on The SAP Gateway

The SAP Gateway {depicted as SAP NWGW in the below diagram} seamlessly connects your environments, platforms and devices to SAP Enterprise data via OData. The clients who consume the query service in the diagram are depicted as the consumers. The servers exposing OData services via their endpoints are the producers.

SAP Netweaver Gateway IX

According to SAP, developers can connect to different SAP software applications using all programming languages and models. This is possible without knowledge of SAP because developers can leverage OData and REST protocols. Before OData’s introduction, connecting non-SAP and SAP solutions required point-to-point interactions that led to duplicated efforts, time, and money.

Architecture of the sap gateway

SAP Gateway forms an essential ABAP bridge between various consumption channel (applications, browsers, devices) and SAP business suite systems (SRM, ECC). Its basic architecture comprises multiple tiers to enable the connection. These include a consumer, Business Suite system and NetWeaver Gateway tier as depicted in this image below…

SAP Gateway Architecture

The consumer tier comprises clients using an interface to access OData services created using HTTP (.NET, PHP, HTMLL5/SAPUI5) in the SAP Gateway. This is considered the front end of SAP Gateway.

The SAP NetWeaver Gateway tier comprises an OData library with runtime components processing requests and housing the functionalities that create OData services. There is also a comprehensive service building console with various alternatives for building Gateway services by reusing technical objects like BOR or from scratch.

The SAP Business Suite tier holds SAP business solutions like SRM, CRM and ECC.

SAP NetWeaver Gateway Deployment Options

You have four deployment alternatives for your SAP NetWeaver Gateway summarized in the diagram below.

Sap Gateway Deployment

Let’s look at each of these in turn….

Hub deployment on the Gateway hub while using the SAP Business Suite backend for service deployment (central hub deployment). Here, you can only access Gateway functionalities on a dedicated hub system. The Business Suite backend system is your platform for developing services before exposing them on the hub server. This deployment alternative supports the composition and routing of multiple systems while allowing access only via the Gateway hub, thus boosting security.

Hub and service deployment on the Gateway hub (embedded deployment). Here, you access SAP gateway functionality on a dedicated hub system on which the development of services also takes place. The hub system used in this option is the SAP NetWeaver ABAP server rather than the SAP Business Suite System. With this option, you do not have to install a backend SAP Gateway component. Even so, it limits access to remote-enabled interfaces like BAPIs, and you have no direct metadata local access. The embedded deployment option is used when no development is allowed on the backend system.

SAP business suite embedded service development and deployment (embedded architecture). Here, services are published and developed in the Business Suite backend system. Your needed Gateway components will also be directly deployed to the Business Suite system. This deployment option has minimal runtime overheads and reduced remote calls. However, you have to configure the Gateway system severally, and you will end up with several SAP Fiori Launchpads if you use SAP Fiori on embedded architecture.

Gateway as a service, also called HCI OData provisioning. Please note that this deployment alternative is now only available on the SAP Fiori Cloud Edition. OData provisioning is a technology that exposes your business logic and data on the SAP Cloud as OData services. The biggest advantage of this deployment option is that clients need not run their SAP Fiori Front-end Server/SAP Gateway Hub since the OData services and SAP Fiori apps are deployed on the S/HANA Cloud Platform

SAP NetWeaver Gateway Development Overview

The SAP Gateway software comes with several service provisioning tools that generate the required source code for jump starting the development of external business applications. You can use the tools in combination with Integrated Development Environments (IDEs) like Visual Studio 2010, XCode and Eclipse. There also exist plugins for these IDEs, so a developer need not have SAP knowledge for the Gateway development process.

The SAP Gateway will create new objects from your existing BAPI, and ABAP Dynpro screens. There are tools like BOR generators, RFC generators and screen generators that can be used in this process. You can also use the OData channel to create custom Gateway objects. The channel is a set of ABAP interfaces and classes that allow the development of objects within the backend system.

After development, your objects will be registered with your SAP Gateway system so that people can access them as RESTful services.

SAP Netweaver Gateway Development Overview

What the SAP Gateway is NOT

Before we summarize I wanted to be sure to cover SAP’s PI/PO product and clear up any questions as to whether the SAP Gateway could replace these products for large volume (tens of thousands of users) integration scenarios… Here is what SAP says….

In a word—No. SAP NetWeaver Gateway is not designed to be a channel for transactional applications, nor is it designed to replace existing middleware like SAP NetWeaver PI/PO. In addition, applications built on SAP NetWeaver Gateway are not designed to target integration scenarios.  Instead, 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). These are people who need ad hoc access to SAP data and functionality in an easy-to-consume manner. They may be employees in a company or consumers of its products.

The SAP 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 (like BAPI/RFCs or transactions) via light-weight REST services. Access using mobile devices is especially easier due to the available developer tool plug-ins which can target those specific devices.

Use SAP PI/PO when integration is needed, involving disparate systems and applications requiring asynchronous and synchronous services involving SAP and non-SAP applications and systems. Process Integration is especially useful for service enabling of SAP and non-SAP applications in establishing standards based on SOA.


SAP NetWeaver Gateway is a technology that provides a simple way to connect devices and applications to SAP software based on market standards (REST and OData). The framework enables development of people-centric solutions by exposing SAP business software data to new experiences such as social and collaboration environments, mobile and tablet devices and rich internet applications. It simplifies connectivity to SAP applications by allowing any programming language or model to be used without the need for SAP knowledge by leveraging REST services and OData/ATOM protocols.

Here are some of the benefits of using this technology….

  • The platform liberates your SAP data so that you can quickly create apps to boost your company’s productivity while allowing better connection with your clients.
  • With the solution, you can build sustainable apps that will allow the extension of the lifespan and increased flexibility of your SAP infrastructure. The sustainable apps also ensure proper provisioning and governance of your infrastructure.
  • With SAP Gateway, you have quick access to actionable information that will help you make decisions. Quick access to information also allows a strong engagement with your employees and other stakeholders to actualize your objectives.
  • SAP Gateway helps your IT developers to easily adapt your IT system because of its flexible nature that allows the integration of new capabilities with your current infrastructure.
  • The platform allows connectivity to the SAP backend system through which you can use different user interfaces to access SAP data.
  • It gives users plug-ins for renowned IDEs (Integrated Development Environments) like Visual Studio 2010, XCode and Eclipse.
  • SAP Gateway works on all devices and platforms. It is also optimized for different user interaction scenarios.
  • The installation of SAP Gateway is non-disruptive and quick, meaning your company will suffer no downtime.
ITP logo

If you enjoyed this blog, Understanding SAP NetWeaver Gateway, please fill out the form below to sign up for our newsletter. We deliver SAP Technical tips & tricks, SAP news, and the current month’s BLOG right to your inbox!

Related Posts

Related Posts

Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!