Skip to Content

In my previous blog, we introduced you to the SAP Netweaver Gateway and how it leverages the Odata protocol liberates SAP Business Data for consumption on virtually any platform, environment or device.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

OData – Everything that you need to know (Part 2)

OData – Everything that you need to know (Part 3)

OData – Everything that you need to know (Part 4)

In this blog we will see the various deployment options for SAP Netweaver Gateway and their pros and cons.

Before getting into the various deployment options with SAP Netweaver Gateway, it is important to understand the different components.

SAP Netweaver Gateway prior to NW 7.4 had three add-ons namely GW_CORE, IN_FND and IW_BEP. While the first two components were required for Gateway server functionalities, IW_BEP was used for Gateway backend functionalities.

From the onset of NW 7.0 release, all the three components are bundle into a single component SAP_GWFND or Gateway Foundation.

There are three possible deployment options to pick from and we will discuss each one of them.

1. Hub Deployment: Development in the Backend system

  

In this deployment strategy, the SAP Netweaver Gateway is installed on separate SAP machine referred to as Gateway Hub. The OData services are registered and exposed from the Gateway Hub but are developed in the SAP backend system. If SAP Business Suite backend systems are running on NW release prior to 7.4 then component IW_BEP should be installed. For systems running on NW7.4 onwards the SAP_GWFND component contains both Gateway server and backend functionalities as mentioned before.

Advantages of this deployment options are  as follows:

  • There is only a single access point of access to the SAP Backed systems. No direct access from outside world provides enhanced security.
  • Gateway Hub can be a system running on newer release NW 7.31 or NW 7.4 with Backed system running on lower release is perfectly acceptable.
    • Gateway on newer release would mean support for SAP UI5.
    • Supports added authentication features.
  • Direct access to metadata (DDIC) and business data for OData Modeling by backend systems.

  

/wp-content/uploads/2016/02/1_883071.png

2. Hub Deployment: Development in the Hub

Hub Deployment with development in the Gateway Hub is an option where just like the previous option, there is a dedicated Gateway Hub as a separate system from the backend system. Since, all the development related to SAP Netweaver Gateway takes place in the Gateway Hub, backend not necessary should have any Gateway components installed. It is a feasible option if you don’t want to do any kind of developments in the backend system and leverage what is already available.

There are a few disadvantages though:

  • Access to the data source for Odata service development is only limited to existing BAPIs and RFCs.
  • There will be no direct access to the backed dictionary objects to the Gateway Hub where the Odata services are modeled. The access is limited to only to remote access.
  • Having a landscape with dedicated system as Gateway Hub involves additional costs as compared an embedded deployment option. This is true for the above deployment option as well.

  

/wp-content/uploads/2016/02/2_883072.png

3. Embedded Deployment

In the Embedded Deployment option, the SAP Netweaver gateway components are installed as add-ons on the SAP backed system itself. Both the Odata modeling and the exposing of the services is done from the backend system. This deployment strategy saves cost as there is no dedicated Gateway Hub. Also, the runtime overhead due to remote calls in the above two deployment options is reduced.

Disadvantages:

  • If there are multiple SAP Business Suite Backed systems in the landscape then, each system will have to have its own installation and configuration of Netweaver Gateway components.
  • Upgrade of backed systems will follow a different cycle than that of Netweaver Gateway.
  • Additional security measures needed as there is no single access point from the backend system to the consumers.

/wp-content/uploads/2016/02/3_883076.png

In the next blog, we will explain the case study that will be the basis of our future blogs related to end-to-end steps of producing and consuming OData services.


Next Blog: OData – Everything that you need to know (Part 6)

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply