SAP Gateway: SAP Gateway deployment

options in a nutshell
Posted by Andre Fischer May 27, 2013
Updates:
added pro's and con's to the deployment options
explanation why a SAP Business Suite system using embedded deployment option must NOT be
used as a hub (28.06.2013)
added a link to the SAP Note 1942072 - SAP NetWeaver Gateway 2.0 Support Package Stack
Definition which describe which SP level on 7.40 is equivalent to which SP level of SAP NetWeaver
Gateway 2.0 running on a release prior to 7.31 (18.11.2013)
added link to YouTube video that is based on this blog
Added HCP OData provisioning (aka Gateway as a Service) as a fourth deployment option
(14.04.2016)
Added Boxes for SAP Gateway Hub and SAP Gateway Backend Framework, to make it more clear
that also the AddOns / software components are needed as well. Especially when talking about the
fourth cloud based option for the SAP Gateway Server. (20.04.2016)

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.
A YouTube video that is based on this blog can be found here:

Root cause for this discussion was that basic Gateway functionalities if running on releases prior to SAP
NetWeaver 7.40 are contained in different AddOns that have to be deployed separately.
While in releases prior to SAP NetWeaver 7.40 the SAP Gateway server or hub functionalities require that
the AddOn's GW_CORE and IW_FND are deployed on the server system, the Gateway backend enablement
functionalities required that AddOn IW_BEP had to be deployed on the backend system.
As of SAP NetWeaver 7.40 and higher you dont have to decide where to put the SAP Gateway
software components since SAP has taken the decision for you
. This is because the software
component SAP_GWFND is installed as part of the SAP NetWeaver 7.40 standard and includes the
functional scope of the AddOns IW_BEP, GW_CORE, IW_FND and in addition IW_HDB.
SAP NetWeaver Basis release

SAP Gateway Hub Framework**

SAP Gateway Backend

Framework*

7.31

GW_CORE,

IW_BEP

and earlier

IW_FND

Generated by Jive on 2016-05-15+02:00

1

SAP Gateway: SAP Gateway deployment options in a nutshell

as of 7.40

SAP_GWFND

SAP_GWFND

*,** For the sake of readability I am using in the rest of the document the following terms:
SAP Gateway Hub Framework for the Add Ons GW_CORE and IW_FND or the software component
SAP_GWFND and
SAP Gateway Backend Framework for the Add On IW_BEP and the software component 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 software 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.
With the advant of SAP Fiori Cloud edition now a fourth option is available where the SAP Gateway Server
component runs in SAP HANA Cloud Platform while the service implementation still resides on the on premise
SAP Backend System. For more details about SAP Fiori Cloud edition see the following blog Announcing
General Availability (GA) of SAP Fiori Cloud Edition!
When deploying systems that reside on SAP NetWeaver 7.40 on the on side (typically the SAP Gateway
Server) and SAP NetWeaver 7.31 and earlier on the other side (typically the SAP Business Suite Backend
System) the question will come up which SP level on SAP NetWeaver 7.40 is equivalent to which SP level for
SAP NetWeaver Gateway 2.0 running on top of 7.31 or earlier.
For this please check SAP Note 1942072 - SAP NetWeaver Gateway 2.0 Support Package Stack
Definition

Overview - All 4 deployment options

As a starting point all four deployment options are shown.
Please note that in contrast to the description in the online documentation I am differentiating between two
types of hub deployment. One where the services are deployed in the backend and one where the service is
deployed on the hub

Generated by Jive on 2016-05-15+02:00

2

SAP Gateway: SAP Gateway deployment options in a nutshell

Option 1 (hub architecture)

In this case the SAP Gateway server functionalities are only used on one dedicated server, the hub system.
The service implementation takes place in the backend and the services are registered in the backend systems
and are activated (published) on the server. The Gateway service is thus deployed in a SAP Business Suite
backend systems where either the AddOn IW_BEP is installed or that is running on top of SAP NetWeaver
7.40 leveraging the software component SAP_GWFND.
Please note:
The hub system should be a SAP NetWeaver ABAP server and not a SAP Business Suite system (see last
paragraph)
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.40 or 7.50) that supports additional authentication options
(Kerberos, SAML Browser protocol, OAuth)
+ Hub System can be based on a newer release (7.40 or 7.50) that supports the deployment of SAPUI5 apps
or can act as a frontend server for SAP Fiori
+ Enhanced security because of no direct access to the backend system
+ Service implementation has direct local access to metadata (DDIC) and business data, meaning easy reuse
of data

Generated by Jive on 2016-05-15+02:00

3

SAP Gateway: SAP Gateway deployment options in a nutshell

Option 2 (Hub architecture with development on the server)

In this case the SAP Gateway server functionalities are also 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 SAP backend systems have to be supported that have a SAP basis releases prior to SAP
NetWeaver 7.0, so that the AddOn IW_BEP cannot be installed on the backend or
if it is not allowed to deploy the AddOn IW_BEP in the backend.

Generated by Jive on 2016-05-15+02:00

4

SAP Gateway: SAP Gateway deployment options in a nutshell

In this case the developer is limited to the interfaces that are accessible via RFC in the backend.
Please note:
The hub system should be a SAP NetWeaver ABAP server and not a SAP Business Suite system (see last
paragraph).
Pro's: (in addition to the ones mentioned in option 1):
+ no need to install (and upgrade) SAP Gateway AddOns 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, BAPIs, 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 in the service implementation. This means that
reuse of data is limited to remote access as mentioned above

Generated by Jive on 2016-05-15+02:00

5

SAP Gateway: SAP Gateway deployment options in a nutshell

Option 3 (Embedded architecture)

In this case the services are developed, registered as well as published in the SAP Business Suite backend
system.
Pro's:
+ Less runtime overhead as one remote call is reduced
Con's:
- If multiple SAP Business Suite systems are used SAP Gateway would have to be configured multiple times
- If SAP Fiori is used you will end up with multiple SAP Fiori Launchpads

Generated by Jive on 2016-05-15+02:00

6

SAP Gateway: SAP Gateway deployment options in a nutshell

- If embedded deployment is chosen the system must not be used as a hub for additional backend systems. As
a result Routing and composition cannot be used. An explanation can be found in the following paragraph.
- Upgrade of AddOns in a backend system in larger companies is usually only possible once or
twice a year

Option 4 (HCP OData provisioning aka "Gateway as a Service)

Please note: This option is currently only available as part of SAP Fiori Cloud Edition.
For more details about SAP Fiori Cloud edition see the following blog Announcing General Availability (GA)
of SAP Fiori Cloud Edition! and more details about SAP HCI OData provisioning can be found in the follwoing
document New version of HCI OData Provisioning service available on SAP HANA Cloud Platform trial
landscape.
This option is similar to option 1 in a sense that service development takes place in the SAP Business Suite
backend system but the SAP Gateway hub components are now running in SAP HANA Cloud Platform using
the service HCI OData provisioning. The great advantage for customers is that they do not have to run their
own SAP Gateway Hub / SAP Fiori Frontend Server. The OData service as well as the SAP Fiori applications
are deployed on SAP HANA Cloud Platform and are securely connected to the SAP Business Suite backends
using the SAP Cloud Connector.

Pro's:

Generated by Jive on 2016-05-15+02:00

7

SAP Gateway: SAP Gateway deployment options in a nutshell

+ Cloud benefits (SAP handles upgrades, scaling, security,)
+ Composition of multiple systems is supported
+ Single point of access to backend systems + Hub System can be based on SAP HANA Cloud Platform that
supports additional authentication options
+ No additional server is needed for the SAP Gateway Hub system / SAP Fiori Frontend server
+ Service implementation has direct local access to metadata (DDIC) and business data, meaning easy reuse
of data
Con's:
- The following constraints as described in SAP Note 1830712 apply: http://service.sap.com/sap/support/
notes/1830712

Generated by Jive on 2016-05-15+02:00

8

SAP Gateway: SAP Gateway deployment options in a nutshell

Do NOT use a SAP Business Suite System with embedded

deployment as a hub system for additional backend systems
You should not use a SAP Business Suite System with embedded deployment as a hub system for additional
backend system.
The reason is that this might lead to a situation where the SAP NetWeaver Gateway release of the hub system
is lower than the version of the SAP NetWeaver Gateway backend components of the remote backend system.
Such a situation can occur because it might not be possible to upgrade the hub system at the same time as the
backend system. Internal policies might dictate that a SAP Business Suite system that is used as a hub must
not be upgraded.
To avoid such a situation the recommended approach is to choose one of the following options:
1. Use embedded deployment option for your SAP Business Suite systems
2. If you go for a hub based architecture you should use a dedicated SAP NetWeaver Gateway Hub system
that should run on the latest release of SAP NetWeaver Gateway.

Generated by Jive on 2016-05-15+02:00

9

SAP Gateway: SAP Gateway deployment options in a nutshell

Please have look at SAP Note 1830198 - SAP NW Gateway: Dependencies Between IW_BEP and IW_FND
that is mentioning dependencies between IW_FND and IW_BEP.
Also there the main understanding is that we do have one IW_FND hub installation and connected SAP
Business Suite systems in where IW_BEP is installed.

Additional Information in the SAP Documentation

System Landscape Recommendations for SAP NetWeaver Gateway - Additional Notes

Deployment Options
Embedded Versus Hub Deployment
SAP Note 1830198 - SAP NW Gateway: Dependencies Between IW_BEP and IW_FND
SAP Online Help - HCI OData Provisioning

29662 Views Tags: sap_netweaver_gateway

Arkajeet Dasgupta in response to Andre Fischer on page 10

May 13, 2016 1:22 PM
Hi Andre,
I have a question(on S4 Cloud and HCP deployment) based on your last reply. Is this statement based
on my understanding true?
Incase the customer is using S4 cloud and not on-premise, for an application which involves exposing Odata
built using gateway service builder and not through XS - the service needs to be registered in HCI and then
exposed through HCP to the external world.
Thanks for your inputs in advance.
Arka
Andre Fischer in response to Jerome Benjamin on page 10
May 13, 2016 11:40 AM
Hi Benj,
if the customer is using S/4 HANA in the cloud the OData services will be published by S/4 itself.
If the customer is using S/4 on premise the situation is similar to the deployment of an SAP ERP on premise.
You can either use embedded deployment (Option 3) or hub based deployment (Option 1 ).
Best Regards,
Andre
Jerome Benjamin
May 13, 2016 10:22 AM
Hello Andre,
Nice blog.

Generated by Jive on 2016-05-15+02:00

10

SAP Gateway: SAP Gateway deployment options in a nutshell

But I have a question here, Our customer will not installed HCP within 3 years, now we have deployed
gateway based on scenario 1.
What will be the best approach if customer deploy S/4 HANA in the cloud or in on-premise ? do we need to
decommission the gateway server again ?
Best Regards,
Benj.
Andre Fischer in response to Victoria Albors on page 11
May 11, 2016 5:08 PM
Hi Victoria,
I wouldn't do this.
The cloud connector is a component that is a crititcal componet for your network and access to the same shall
be restricted as much as possible. For more details see our online documentation:
SAP HANA Cloud Platform
There you will find the following statement "Following the same arguments, we recommend that you use the
machine to operate the Cloud connector only and no other systems."
Please put any other question in our forum ,rather than doing this as a comment to a blog.
Best Regards,
Andre
Victoria Albors
May 11, 2016 2:31 PM
Hi Andre,

Thanks very much for you help, another question

in the same server as the backend ?
Thanks again .

. Is it posible to install the SAP HANA Cloud Connector

Andre Fischer in response to Victoria Albors on page 11

May 9, 2016 9:03 PM
and yes, cloud connector is mandatory to connect from hcp to your on premise backend systems
BR Andre
Andre Fischer in response to Victoria Albors on page 11
May 9, 2016 9:01 PM
If you want to go for option 4 you have to have the sap gateway backend components installed (IW_BEP) if
your backend are based on sap NW 7.31 or earlier .
if they are based on 740 or later nothing has to be installed since the software component SAP_GWFND is part
of sap NW 740 or later.
Best Regards,
Andre
Victoria Albors
May 9, 2016 6:01 PM

Generated by Jive on 2016-05-15+02:00

11

SAP Gateway: SAP Gateway deployment options in a nutshell

Hello Andre,
I'm very new with this subjects, ( I do not know if it has sense ) but if we want to deploy option 4. What it is
necessary to install in the SAP Back end - what add ons ?. and another question is it strictly necessary to
deploy the SAP HANA cloud connector ?
Thanks very much for your help,
Pavan Golesar in response to Andre Fischer on page 12
Mar 31, 2016 8:31 AM
Thanks anyways
Andre Fischer in response to Pavan Golesar on page 12
Mar 1, 2016 11:55 AM
I saw that already an answer was provided that solved your issue.
Pavan Golesar
Mar 1, 2016 8:59 AM
Dear Andre Fischer,
are the service builder havin their own data elements in gateway.??
I have already raised the thread Critical Issue with Date format in Gateway and ECC.
Thanks.
Pavan G
Nguyen David in response to Andre Fischer on page 12
Feb 24, 2016 7:06 PM
Thanks for the confirmation Andre!!
Andre Fischer in response to Nguyen David on page 12
Feb 24, 2016 6:25 PM
sure. That s what a SAP gateway hub is for.
best regards
Andre
Nguyen David
Feb 24, 2016 6:09 PM
Hello Guru,
Can we connect multiple SAP backends to a single SAP NW Gateway? and I am not talking about multiple
clients, but difference ERP backends.
Thanks
David
Jerome Benjamin
Oct 30, 2015 5:52 PM
Hi Andre,

Generated by Jive on 2016-05-15+02:00

12

SAP Gateway: SAP Gateway deployment options in a nutshell

Interesting blog.
We have the gateway installed with option 1 scenario. we plan to build a ui5 application with our backend SRM
system. where shall we build these gateway services and in which system shall we deploy the ui5 application ?
Regards,
Benjamin
Pavan Golesar
Oct 27, 2015 11:23 AM
Exellent Post :-)
Thanks Andre.
Regards,
--PavanG
Fernando Figueiredo
Aug 13, 2015 1:03 AM
Hi Andre,

I would like to know if there's any information about migrating from Embedded deployment to Central HUB in a
Fiori implementation.

regards,
fernando
Andre Fischer in response to WISE-ERP EMEA SAP Support on page 14
Apr 14, 2015 8:20 AM
Hi Bert,
it is not mandatory to have IW_BEP deployed in the ECC 6.0 backend in order to perform a deep insert.
You would have to have however a RFC function module in place that
a) can be called remotely from your DPC_EXT class in the hub
b) would perform the creation of your business object that you have modelled in OData as two different entities
in a parent child relationship. (For example a BAPI / RFC that creates a sales order alongside with the line
items in one request)
So if requirement b) is not fullfilled your developers are right that they would have to call some classes /
methods that are not remote enabled.
This could be done by deploying IW_BEP and writing code in your DPC_EXT class for the method
CREATE_DEEP_ENTITY or as a workaround (if you don't want to deploy IW_BEP at any cost) you can wrap

Generated by Jive on 2016-05-15+02:00

13

SAP Gateway: SAP Gateway deployment options in a nutshell

these calls in a custom RFC function module that can than be called remotely from your DPC_EXT class in the
hub.
But sooner or later you will get IW_BEP or better the software component SAP_GWFND anyway ...
Latest if you upgrade your ECC to a rEhP that runs on top of NW 7.40.
Then you could still move your code from your DPC_EXT in the hub to the backend.
Best Regards,
Andre
WISE-ERP EMEA SAP Support
Apr 13, 2015 3:49 PM
Hi Andre,
We have installed central hub SAP Netweaver 7.40 and chosed option 2 but now our developers want to create
complex Business Entities and they claim add-on IW_BEP on ECC 6.0 backend system is required.(also see
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0d92637-3d0d-2f10-ebb2-efc1f40a85e8?
QuickLink=index&overridelayout=true&53717156092624) .
But that's exactly what we wanted to avoid by using a central hub.
Is there a way to avoid the installation of the add-on on the backend system or is there only 1 way forward to
meet the request from our developers?
Thanks for your feedback
Bert
Abdul MUGHNI
Mar 29, 2015 9:41 AM
Hi Andre,
Could you also share some information on the license implications of having Option 1 and 2. Would the
existing users licence from for Business Suite still be valid or new licenses would need to be purchased by the
customer for the GW Hub Server?
Secondly, The roles and authorizations defined for the Business Suite would need to be recreated on the GW
Hub server as well or would it somehow be using the ones from the Business Suite? How would this work?
Would appreciate if could shed some light on these two topics

Thanks and Regards,

Generated by Jive on 2016-05-15+02:00

14

SAP Gateway: SAP Gateway deployment options in a nutshell

Abdul
VINCENZO TURCO
Feb 25, 2015 12:48 PM
Hi all,
great blog indeed there, thanks for sharing.
With the latest development about a Gateway Java on board of PO, possibly the above scenario can be even
extended.
For instance: let' assume that I need to develop my UIs on PO/BPM and need to consume the OData services
exposed by a GW Hub architecture.
Is it correct that the OData service from the GW Hub can be "published" onto the Java Gateway on board PO?
Any pointers in this direction would be greatly appreciated
Thanks, regards
Vincenzo
Andy Silvey
Jan 10, 2014 2:58 PM
Hi Andre,
great blog and thank you for connecting it to the other discussion.
For all, Deployment Options are also discussed in the GateWay 2.0 SP06 Master Guide which is here.
Kind regards,
Andy.
Chandan V.A in response to Sandy HAL on page 15
Jan 7, 2014 7:00 AM
Hi San,
Hub communicates with the backend systems using a trusted RFC.
If you need identity federation then create a System alias for a RFC destination with "current user" option
checked in (see SM59 documentation). If you don't need identify federation then maintain the user name and
password for the RFC destination.
I hope this answers your question.
Regards
Chandan
Sandy HAL
Jan 7, 2014 1:34 AM
Hi Andre,

Generated by Jive on 2016-05-15+02:00

15

SAP Gateway: SAP Gateway deployment options in a nutshell

I was going through this article as we are planning to implement SAP GW server for our mobility applications.
This very informative.

Keeping Option 1 (hub architecture) in view,

I need some clarification on data flow in terms of network security stand point, does GW server needs any
80/443 access to back end systems (or is it ONLY RFC connections)? If yes does SAP Gateway will re-initiate
a different http / https session when it communicates with the internal system?

I tried looking @ different documents, did not get any clear answer. Hope you can guide / through some light at
it.

San
Andre Fischer in response to Wolfgang Dr. Rckelein on page 16
Oct 26, 2013 7:10 PM
Hi Wolfgang,
you are right that Note 1830198 states "As of SAP NetWeaver Gateway 2.0 SP06, it is possible to have a
higher version of SAP NetWeaver Gateway enabling component installed."
If you however use a backend where IW_BEP does have a higher SP Level than the SAP NetWeaver Gateway
Server you will not be able to leverage new features of that newer SP.
So a newer SP would run in the backend but with regards to features you will be bound to the SP level of the
hub.
Best regards,
Andre
Wolfgang Dr. Rckelein
Oct 23, 2013 5:28 PM
Hi Andre,
regarding "embedded deployment as a hub system" and Note 1830198: According to the note "As of SAP
NetWeaver Gateway 2.0 SP06, it is possible to have a higher version of SAP NetWeaver Gateway enabling
component installed." For me it is not clear why this not also applies to your latest slide (besides the strong
recommendation in the note), as I interpreted this sentence in the way that a SP06 hub should be able to talk to
a higher backend enabled.
Regards,
Wolfgang

Generated by Jive on 2016-05-15+02:00

16

SAP Gateway: SAP Gateway deployment options in a nutshell

Arun Kumar
Sep 28, 2013 6:22 PM
Hello Andre,
This is really useful info
We are deploying a netweaver hub as part of our SAP implementation program
We have a couple of SAPUI5 ( on NW portal) applications and a few sap mobile applications planned .
I am trying to pick the correct Hub option - option 1 or 2, since we are on NW 7.4 ( all backend systems also on
NW 7.4) , all the BEP features are already available as part of SAP_GWFND component
Will option 1 be the best for our scenario?

Regards
Arun
Sheetal Deshmukh
Jul 9, 2013 8:40 AM
Hi Andre ,
This is really a good post ! Very informative !
Thanks ,
Sheetal
DJ Adams
Jun 17, 2013 9:46 AM
Nice post, Andre, and the addition of the Pro's & Con's are welcome.
cheers
dj
Andre Fischer in response to Marco Ferrari on page 18
Jun 13, 2013 8:00 AM
Hi Marco,
thanks for raising this point. I should have been a little bit more clear about this.
Standard applications from SAP require that IW_BEP together with the AddOn that contains the service itself
are deployed on the backend. As a result these applications and any application that leverages interfaces
that are only available locally in a SAP Business Suite System can be used only when you choose either the
deployment option 1 or 3 as described above.

Generated by Jive on 2016-05-15+02:00

17

SAP Gateway: SAP Gateway deployment options in a nutshell

Applications that have been developed for a scenario using the deployment option 2 can instead also be used
when the deployment option 1 or 3 is used because they retrieve their data via remote enabled interfaces. In
case an embedded deployment is used the RFC calls would be thus local.
Best Regards,
Andre
Marco Ferrari
Jun 11, 2013 12:49 PM
Hello Andre,
thank you very much for your interesting blog: but what will be of existing applications (even standard ones
like HR mobile approvals) using a "Hub with development on the server"? Will they have to be ported to a
"Embedded or Central Hub" architecture?
Saumil Jyotishi in response to Andre Fischer on page 18
May 28, 2013 5:48 PM
Cool!
Andre Fischer in response to Saumil Jyotishi on page 20
May 28, 2013 4:30 PM
Hi Saumil,
I started to add Pro's and Con's to my blog.
Best Regards,
Andre
Andre Fischer in response to Paul Aschmann on page 20
May 28, 2013 4:29 PM
Hi Paul,
I started to add Pro's and Con's to the three options I mentioned in my blog.
Best Regards,
Andre
Saumil Jyotishi in response to Andre Fischer on page 18
May 28, 2013 3:34 PM
Hi Andre,
Thanks and Yes,realized I wrote incorrectly about passing certificates from gateway to backend. Of course
its ABAP Trust with assertion tickets. Updated info in my comment. I have read your article. It only outlines
what are available options but my point is, if you guys can provide 1 more guide explaining how to think when
modeling gateway by taking 1 very complex SSO scenario. This would really help in actual customer cases.
Andre Fischer in response to Saumil Jyotishi on page 19
May 28, 2013 3:03 PM
Hi Saumil,

Generated by Jive on 2016-05-15+02:00

18

SAP Gateway: SAP Gateway deployment options in a nutshell

a while a ago together with my colleague Genady I published the follwoing article in SAPinsider: "Take
Advantage of Cross-Platform, Cross-Device Access While Keeping Your Data Secure with SAP NetWeaver
Gateway". There we discussed the different options to achieve SSO for SAP NetWeaver Gateway.
As you pointed out correctly SAP NetWeaver Gateway supports basically three options to achieve SSO,
namely X.509 certificates, SAML 2.0 browser protocol and SAP Logon Tickets.
With the advent of latest version of SAP NetWeaver SSO also Kerberos is supported.
It is up to the consumer to provide appropriate credentials to authenticate against SAP NetWeaver Gateway.
Gateway does not pass certificates to a portal nor to a backend. SSO between Gateway and backend systems
is achieved via a trusted trusting system relationship that in the end uses SAP assertion tickets for SSO
between the hub and the backend system.
Since several SSO options are supported in parallel I see complex scenarios but not real problems.
Best Regards,
Andre
Saumil Jyotishi
May 28, 2013 12:03 PM
Well, I thought about it more and sorry but I would like to extend Paul's request to detail the pros and cons to
cover one more area.
Authentication and Authorization; especially how would you think when you architect Gateway with more
than one channel.
For Example: Lets say in your landscape you choose Hub Deployment with SharePoint as one consumption
channel, Fiori Apps as the 2nd and then lets assume you have a server side third party application. How would
you architect this landscape?
For, SharePoint, its easy; use Duet Enterprise & use SAML 2.0 for SSO with SharePoint 2010 on an SSL
encrypted HTTP line. Unfortunately I guess OData doesn't support SAML (or doest it?), so for Sharepoint 2013
you must Use Duet Enterprise with fallback option X.509. In all these cases IDP lies on SharePoint.
Now, if you want to add another channel to same landscape, you might have to think about another approach.
May be X.509 via another IDP or if you are using SAP Mobile platform, Afaria will generate the certificates for
you & SUP must pass these X.509 certificate to Gateway. Gateway then can authenticate users utilizing trust
relationship with backend.
Then, for third channel, how about using SAML 2.0? (for this you must have an IDP).

Generated by Jive on 2016-05-15+02:00

19

SAP Gateway: SAP Gateway deployment options in a nutshell

How would you map different User IDs from different channels in above scenarios (Other than SharePoint, for
SP Duet Enterprise takes care of it)? I think by defining consumer types in Gateway and using mapping view
VUSREXTID?
How about bringing Server Proxies/Relay Servers in this equation?

Sorry for my ignorance

, but I feel more clarity would be needed from SAP on Authentication/Authorization
perspective in complex productive gateway environments. Also, If anyone has experience in using same
gateway hub via multiple consumption channels, please share you experiences
Saumil Jyotishi
May 28, 2013 11:14 AM
Hi Andre/Paul,
Nice Blog. Deploying Gateway with multiple ERPs or other Business Suite Stack is indeed difficult sometimes.
Recently, like Paul said, we too have seen a few big customers who liked the idea of Hub Deployment only,
as they had different ERPs/Centralized MDMs/other Systems on various versions and these systems had
many projects going on. Also the systems had hugely different upgrade cycles (Of course there were few very
interesting discussions after we laid out Pros and Cons of deployment options). Even for Hub, putting IW_BEP
in the backend sometime ain't possible because of NetWeaver release restrictions
I am here talking about the customer who already are thinking about more than one channels for Gateway
consumption (SharePoint now & HTML5 in near Future).
These discussions become more interesting after addition of all Gateway Components with NW 7.4. I also
did a blog last month, related to this topic, on how you can use these deployment options for SharePoint
consumption via Duet Enterprise:
http://scn.sap.com/community/duet-enterprise/blog/2013/04/22/deployment-options-of-duet-enterprise-withnetweaver-gateway-20
but as Paul said, more discussions on Pros and Cons are always very welcome and interesting.
Paul Aschmann
May 27, 2013 8:11 PM
Hi Andre,
Thanks for sharing. I am very happy to hear that GW is included in 7.40 release as it will make adoption
simpler and I believe it will reach a wider target audience = great!
There has been multiple discussions around which deployment option to use and generally we had adopted
a Hub type architecture (Option 2) to keep all GW development centralized and a "common" hub to point
our mobile apps to. I was wondering if you could possibly give us another blog post or share what each
approaches pro's and con's are? I believe this may make developers/architects choices easier when designing
for the current and to-be landscapes while taking into account scalability.

Generated by Jive on 2016-05-15+02:00

20

SAP Gateway: SAP Gateway deployment options in a nutshell

Also, I would assume that due to the new Parallelism feature of SP06 it would still function the same way but
each NW Instance could source data from various backend systems as it could today?
Cheers, Paul

Generated by Jive on 2016-05-15+02:00

21