Updates:
- added pro's and con's to the deployment options
In the past I have been frequently asked which deployment option I would recommend for SAP NetWeaver Gateway. The official documentation can be found here in SAP Online Help.
Root cause for this discussion was that basic Gateway functionalities if running on releases prior to 7.40 are contained in different AddOns that have to be
deployed separately.
While in releases prior to 7.40 the Gateway server or hub functionalities require that the software components GW_CORE and IW_FND are deployed on the server system, the Gateway backend enablement functionalities required that software component IW_BEP had to be deployed.
As of SAP NetWeaver 7.40 and higher you don’t have to decide where to put the Gateway core components since SAP has taken the decision for you 
.
This is because the component SAP_GWFND is installed as part of the 7.40 standard and includes the functional scope of IW_BEP, GW_CORE, IW_FND and in addition IW_HDB.
| SAP NetWeaver Gateway server functionalities | SAP NetWeaver Gateway backend enablement | |
|---|---|---|
| 7.31 and earlier | GW_CORE, IW_FND | IW_BEP |
| as of 7.40 | SAP_GWFND | SAP_GWFND |
So instead of discussing where to deploy which AddOn the discussion will be around whether you will go for a hub architecture or whether you will activate the Gateway service on the SAP Business Suite system itself (also called “Embedded Deployment”).
Since the Gateway core components will be part of each system running on top of NetWeaver 7.40 in the future you still have basically three options how to run SAP NetWeaver Gateway services in a system landscape.
In contrast to the description in the online documentation I am differentiating between two types of hub deployment. One where the service deployed in the backend and one where the service is deployed on the hub.
Option 1 (hub architecture)
In this case the Gateway server functionalities are only used on one dedicated server, the hub system. The services are deployed on the backend systems and are registered on the server. The Gateway service is thus deployed in the Gateway backend systems where either IW_BEP is deployed systems or that are running on top of 7.40 leveraging the core component SAP_GWFND.
Pro's:
+ Routing and composition of multiple systems is supported
+ Single point of access to backend systems
+ Hub System can be based on a newer release (7.31 or 7.40) that supports additional authentication options (Kerberos, SAML Browser protocol)
+ Hub System can be based on a newer release (7.31 or 7.40) that supports SAPUI5
+ Enhanced security because of no direct access to the backend system
+ Direct local access to metadata (DDIC) and business data, meaning easy reuse of data
Con's:
- Additional server needed for Gateway
Option 2 (Hub architecture with development on the server)
In this case the Gateway server functionalities are only used on one dedicated server, the hub system. In contrast to option 1 also the service deployment takes place on the hub system. This option is used if either no development must be performed on the backend system or in case of releases prior to 7.40 if it is not allowed to deploy the AddOn IW_BEP in the backend. In this case the developer is limited to the interfaces that are accessible via RFC in the backend.
Pro's: (in addition to the ones mentioned in option 1):
+ no need to install (and upgrade) Gateway AddOn’s in the backend
+ services developed by partners do not need any deployment on the backend systems
Con's (in addition to the ones mentioned in option 1):
- access is limited to remote enabled interfaces (RFC function modules, BAPI’s, BW Easy Queries, SPI Objects)
- remote enabled interfaces might not be optimal suited (e.g. they might not offer appropriate filter options)
- GENIL objects cannot be accessed remotely
- Additional server needed for Gateway
- NO direct local access to metadata (DDIC) and business data, meaning reuse of data is limited to remote access as mentioned above
Option 3 (Embedded architecture)
In this case the service is deployed on the same system where it is registered.
Pro's:
+ Less runtime overhead as one remote call is reduced
Con's:
- If multiple SAP Business Suite systems are used Gateway would have to be configured multiple times
- Routing and composition cannot be used
- Upgrade of AddOn’s in a backend system in larger companies is usually only possible once or twice a year
