SAP Gateway deployment options in a nutshell
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)
- Added information about the performance improvements when the hub and the backend or in the case of embedded deployment the systems are based on SAP NetWeaver 750 SP4 or later (18.10.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 don’t 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 and earlier |
GW_CORE, IW_FND |
IW_BEP |
| 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
.
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
If the hub system and your backend system are both based on 750 SP4 or later you can leverage the performance improvements for embedded deloyment also when using hub deployment. For more details see my blog How to take advantage of the performance improvements in SAP Gateway in SAP NetWeaver 7.50 SP04
+ 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
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.
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 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 in the service implementation. This means that reuse of data is limited to remote access as mentioned above
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. This is especially true for SAP NetWeaver 750 SP04 or later as I described in my blog How to take advantage of the performance improvements in SAP Gateway in SAP NetWeaver 7.50 SP04
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
– 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 AddOn’s 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:
+ 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
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:
- Use embedded deployment option for your SAP Business Suite systems
- 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.
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.
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.
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
Hi Paul,
I started to add Pro's and Con's to the three options I mentioned in my blog.
Best Regards,
Andre
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:
https://blogs.sap.com/2013/04/22/deployment-options-of-duet-enterprise-with-netweaver-gateway-20/
but as Paul said, more discussions on Pros and Cons are always very welcome and interesting.
Hi Saumil,
I started to add Pro's and Con's to my blog.
Best Regards,
Andre
Cool!
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).
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 🙂
Hi Saumil,
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
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.
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?
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.
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
Nice post, Andre, and the addition of the Pro's & Con's are welcome.
cheers
dj
Hi Andre ,
This is really a good post ! Very informative !
Thanks ,
Sheetal
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
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
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
Hi Andre,
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
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
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.
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
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,
Abdul
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
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 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
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
Exellent Post 🙂
Thanks Andre.
Regards,
--PavanG
Hi Andre,
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
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
sure. That s what a SAP gateway hub is for.
best regards
Andre
Thanks for the confirmation Andre!!
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
I saw that already an answer was provided that solved your issue. 🙂
Thanks anyways 🙂
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,
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
and yes, cloud connector is mandatory to connect from hcp to your on premise backend systems
BR Andre
Hi Andre,
Thanks very much for you help, another question 😳 . Is it posible to install the SAP HANA Cloud Connector in the same server as the backend ?
Thanks again .
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
Hello Andre,
Nice blog.
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.
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
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
Thanks for sharing
For hub deployment, which system should I use to design/construct the Entity Data Model?
Thank you
you do this in the backend using transaction SEGW.
best regards
Andre
Thank you
Hi Andre,
One question after going through the blog -
I have read somewhere/heard (maybe incorrectly, hence the question) that another reason option 1 is preferred over option 2 due to the fact that in option 2, one would end up making more round trips and more number of RFC calls between Gateway hub and backend thereby impacting performance. Is there truth in this? I ask because the disadvantages mentioned for option 2 in the blog do not mention performance.
If this is true, any thoughts on why there would be more round trips in option 2 as opposed to option 1?
Thanks.
Regards,
Aniket
I have described performance optimizations here: https://blogs.sap.com/2016/10/10/take-advantage-performance-improvements-sap-gateway-sap-netweaver-7.50-sp04/
They work for embedded deployment as well as for hub based deployment.
The little overhead for the hub based deployment is needed if you want to leverage the hub capabilities.
Best Regards,
Andre
Hi Andre,
Thanks for this post. I am a little fuzzy on the packaging and deployment and have a few questions.
My apologies if these are overly basic and I am completely clueless.
We have developed an embedded odata service using sap gateway.
So we have the backend views, table types, rfcs etc. in one package. We call this the "Business suite" package.
Then we have the entity sets, service implementation etc. in another package. We call this the "Gateway" package.
This is all working fine.
We have created transports of both of these packages.
I think we are leaning towards "Hub Deployment with Development on the SAP Business Suite System".
I guess I am a little fuzzy on the configuration tasks, and how to describe them to the customer.
Here is my current thinking:
In this case, both of these packages should get installed in the backend system.
We have to create an ABAP RFC destination - the customer does this in the backend system?
We also have to create a System alias - the customer does this in the backend system?
The customer then registers the service from segw in the backend system, connecting it to the hub system.
So I don't think they actually import any of our transported files into the hub system?
Thanks,
Derek
Very nice blog.
I would include in Option 1 (HUB with development in the backend) also the Pro's as follow:
Thanks
Danilo
Hello Andre,
i also have a question maybe you can give us a hint.
we use embedded deployment (we are on ERP EHP7 7.40 with SAP_UI 751).
So we are thinking of switching to option 1 Central Deployment but developing in backend.
Is it true that we are on 740 erp backend and 751 on Gateway Hub? So we can always use a newer version on Hub.
Thinking of Fiori, erp backend and Gateway hub need to have the same UI_Version then?
When creating a service or building a fiori app they get deployed "kind of automatic" to the Gateway Hub?
Do we also have (we have 3 stages on ERP [dev,test,production]) to install the same number of stages for dev,test,production?
how can we migrate vom embedded szenario to hub scenario?
sorry for that many questions 😉
best regards
oliver
We are live SAP Gateway and ECC as our deployment in HUB model. One question - what is best practice to connect Gateway to backend? Do we connect it to central instance or to application server?
I would recommend to use the central instance and then to use load balancing and logon groups.
This way you can leverage load balancing and you as well have the option to limit the communication to certain application servers.
Best Regards,
Andre
Hello Experts,
We are planning to setup NW Gateway servers to deploy FIORI Apps as well as MCF services to procure customer facing applications on web/mobile.
Definitely, we are going for Central Hub Architecture. Question is: Is it good idea to keep everything on single NW GW, or it is better to have them on separate GW servers with FRIORI Apps on one and MCF services on another.
Any help or suggestion is highly appreciated.
Regards,
~Mark
Dear Experts - any help on this will greatly appreciated. thankyou!
All,
What are the benefits if we would have the Central Hub deployed on HANA system while the backend Odata is still on a non-HANA system. Could someone shed some light on this ?
Thanks & Best Regards,
Babu Kilari
Not sure.
But if you happen to convert your backend systems to S/4HANA there is a hard requirement to run the front end Server (the SAP Gateway Hub) on top of a SAP database.
https://blogs.sap.com/2017/11/09/sap-fiori-for-sap-s4hana-1709-architecture/
One of the three options is SAP HANA.
And if all your systems run on the same database product this makes it easier for you to manage the same.
Regards,
Andre
Andre Fischer I have a question on option 4. Imagine we have two similar backend systems and we have the OData deployed in both the systems ( So, technically the data model is same and the code / entity sets are same ). With the help of cloud connector we mapped these systems to SAP Cloud platform. However, the users who look at the "business data" different from backend system 1 to backend system 2. In this case, how does the Fiori launchpad ( via Portal service ) recognize the user and route the call to the correct backend system and show the correct data. I understand there is something called "System Aliasing" via /IWFND/MAINT_SERVICE. However, that would be part of the Gateway system which is in the backend and if my understanding is correct, the portal service doesn't allow any aliasing. Is my understanding correct ? or am I missing something. I ask this question because in the above blog we said, it is similar to option 1 except that the front end UI5 layer is in SCP. So, we might call this as a Central Hub. However, w.r.t the aliasing - I am afraid and not sure if this is possible. Could you comment a bit on this ? Thanks a lot in advance for your explanation !
Cheers,
Babu Kilari
Andre Fischer
I have a question on option 4. Imagine we have two similar backend systems and we have the OData deployed in both the systems ( So, technically the data model is same and the code / entity sets are same ). With the help of cloud connector we mapped these systems to SAP Cloud platform. However, the users who look at the "business data" different from backend system 1 to backend system 2. In this case, how does the Fiori launchpad ( via Portal service ) recognize the user and route the call to the correct backend system and show the correct data. I understand there is something called "System Aliasing" via /IWFND/MAINT_SERVICE. However, that would be part of the Gateway system which is in the backend and if my understanding is correct, the portal service doesn't allow any aliasing. Is my understanding correct ? or am I missing something. I ask this question because in the above blog we said, it is similar to option 1 except that the front end UI5 layer is in SCP. So, we might call this as a Central Hub. However, w.r.t the aliasing - I am afraid and not sure if this is possible. Could you comment a bit on this ? Thanks a lot in advance for your explanation !
Cheers,
Babu Kilari
I will check this.
Regards,
Andre
Andre Fischer Thank you for the reply. I will wait for your answer on this one. Cheers, Babu Kilari
Andre Fischer I understand you're totally busy. But, I would like to check with you once again if this is possible if we deploy the UI5 layer in SAP Cloud Platform while the OData layer is still implemented in the backend layer.
Thanks & Best Regards,
Babu Kilari