SAP Gateway Deployment Options

[former_member563154]

SAP is offering three main deployment options for SAP Gateway:

The Hub Deployment

The Embedded Deployment and

The Deployment in Cloud.

 

Hub Deployment can be subsequently split into two different deployment scenarios: development in the backend system and development on the hub.

The Hub deployment scenario uses a dedicated server - the hub system - for the SAP Gateway functionalities.

Development on the Backend System:

The first option of hub Deployment is used in situations where the services are deployed on the backend systems and only registered on the server. The SAP Gateway server functionalities are only used on the dedicated server(hub). On the backend system, IW_BEP is deployed (or SAP _GWFND for SAP NetWeaver 7.40 or later).

The benefit of this hub deployment is that the system works as a single point of access to the backend systems. On this system, routing and composition of multiple systems is supported. Using this  kind of hub system allows the system to be on a newer release, which enables the use of up-to-date functionality (e.g, the latest authentication options or SAP UI5). In this scenario, security is improved because there is no direct access to the backend system. At the same time, the deployment allows direct access to local metadata (DDIC) and business data, which reduces run-time overhead.

The hub system shouldn't be an SAP backend system; instead, it should be an SAP Netweaver AS for ABAP. This is tru for both hub deployment options.

 

Development on the Hub:

The second option of hub deployment should be used in situations where either access to the backend system is restricted or development on the backend isn't possible. It should also be used on releases prior to SAP Netweaver 7.40 when an installation of IW_BEP on the backend isn't allowed. In this form of hub deployment, server functionalities are only used on the SAP Gateway hub system, and, in contrast to the first options, service deployment take place on the hub.

The benefit of this hub deployment are that the backend systems don't have to be touched - that is, there's no need to install or upgrade SAP Gateways add-ons on the backend. In addition, services developed by the third-party developers don't need a deployment on the backend system.

There are also some drawbacks:

• An additional server is needed for SAP Gateway.


• Access to the backend is limited to remote-enabled interfaces - for example, RFC's, BAPIs and SAP Business Warehouse (BW) Easy Queries. These interfaces might not be optimal for usage on the hub.

Embedded Deployment:

In this deployment approach, services are registered and published in the SAP backend system. Components IW_FND and GW_CORE for older versions and SAP_GWFND for SAP Netweaver 7.40 or later.

The main benefit of embedded deployment is that the run-time overhead is reduced by one remote call and that the SAP Gateway run-time has been optimized for such co-deployed setups as of SAP Netweaver 7.50 SP 04. The main drawback is that if you user several SAP Business Suite systems, you'll have to configure SAP Gateway for every system. In addition, routing and composition can't be used.

SAP don't recommend using an SAP backend system with an embedded deployment of SAP Gateway as a hub system for and additional backend system.

Cloud Deployment:

Odata Provisioning is offered as part of SAP Cloud Platform deployment. This allows access of the data from within the cloud. It's basically like the development on the hub option, with the difference that it's managed by the SAP Cloud Platform.

The benefit of SAP Cloud Platform OData provisioning is that it runs in the cloud. That being said, it comes with all the benefits of the cloud (i.e., you don't have to take care of the system landscape, installation, of upgrades). You can basically just activate it and use it on the fly. In short, you don't have to maintain a dedicated server. Furthermore, SAP Cloud platform OData Provisioning allows you to connect to several SAP backends. However, some constraints apply:

• $link and custom query options are not supported.


• The total size of a single HTTP request must not exceed 5 MB.


• Push notification scenarios are not supported.


• Soft-state and rule- based routing are not supported either.

You can refer to SAP Note: 1830712 to see the complete list.