Blogs
|
Opinions on deploying NetWeaver Gateway
|
|
It all started with a tweet by SAP Mentor John Appleby (@applebyj)...
Quite a few people responded in short order via twitter with their thoughts on the topic. Aside from John being well known (and followed on twitter), this is surely indicative of the level of interest in the technology. Kudos to SAP for getting the community excited with their products! On a complete tangent, I just love how twitter has this ability to stimulate such exchanges in 140 characters or less!
So far so uncontroversial. Many of the conceptual architecture diagrams I have seen at TechEd and elsewhere follow this approach - like this one from MOB130 at TechEd 2011:
However, my position on the matter was a little different:
Go for Integrated deployment
My response runs counter to the recommendation made in the admin guide quoted by John Moy, so let me try to explain why I feel an integrated (i.e. remote) installation of NetWeaver Gateway is usually most appropriate architectural choice.
NetWeaver Gateway is not that different
Like others, I generally see Gateway in much the same way as the SOAP Runtime or the Proxy framework which already exist in ABAP systems – an add-on to an existing system which provides interfaces by facading internal APIs like RFCs and BAPIs. Gateway provides another set of doors alongside the existing SOAP-based openings through which other systems can gain access to the data and functionality of the Business Suite. Those consuming systems need not worry about the proprietary protocols required for RFC communication but can choose to interact using open standards. Gateway simply provides another, different open standard in the form of OData to complement existing SOAP-based interfaces.
From what I saw during our hands-on work on the NW Gateway 1.0 “beta” program, and from keeping abreast of the evolution of this into v2.0, the product isn’t complex enough to warrant a separate installation in my opinion.
NetWeaver Gateway is not middleware
Gateway’s raison d’etre is to expose representations of internal resources (in the REST sense) from Business Suite systems. However, it doesn’t provide any tools for building OData representations by composing or re-composing existing data from multiple systems, or even from multiple different BOR objects, into a new aggregate representation. Essentially, anything which isn’t a subset of a single BAPI return requires custom ABAP code to be written.
In a central, stand-alone installation as shown on conceptual architecture diagrams like the one above, this ABAP code would have to get data from the various underlying sources from which the single exposed OData resource is composed from. How would this work? Gateway doesn’t (yet) provide any mechanisms for consuming SOAP enterprise services and only relies on RFC calls. Not nice. In order to call SOAP web services, I would have to write custom code to aggregate the returns of multiple calls to ABAP consumer proxies into something the Gateway runtime can then transform into OData. So lots of "glue code". Of course, anything is possible using custom code, but I would expect some actual tooling here if the vision of a central, stand-alone Gateway deployment is to be realised. Middleware systems like PI do provide such tooling and don't require developers to write lots of mundane glue code...
This leads me to conclude that a single, detached layer of Gateway composing OData resources from a variety of backends is essentially wishful future-state thinking rather than something which customers can adopt right now using Gateway 2.0 and without much fuss and coding. I do have some ideas on what I’d love to see in Gateway 3.0, but that’s the subject of a future blog...
Efficiency wins!
One of the appeals of designing APIs in accordance with REST principles is their greater simplicity compared to SOAP and the associated WS-* mess. To me, any kind of “application gateway”-style translation or bridging – such as building up a RESTful representation by making 3 SOAP/RFC calls to the same backend – negates a lot of the efficiency benefits of REST. One could even argue that it makes things worse by adding another layer of complexity/failure.
When all else fails...
Security, rate-limiting and auditing benefits of a stand-alone instance are pretty weak arguments here as well. Maybe I’m being cynical here, but I only ever see these come up once all other arguments have been exhausted.
I struggle to see customers exposing any ABAP stack to the Internet without some kind of application gateway or reverse proxy in front of it. Once you have that layer, the security arguments espoused in the admin guide become moot. Those specialised tools are much better at security, auditing and rate limiting than Gateway or any other general-purpose system is ever going to be. It’s their bread and butter after all! Specialist vendors like apigee, Layer7 or Mashery offer API gateway products with very impressive features around load balancing, throttling, DoS protection, SLA enforcement and versioning of Internet-facing APIs. Companies are likely to want only one such API gateway because there are economies of scale here. And since they will likely want to provide APIs from non-SAP systems as well, using Gateway for this role does not seem attractive.
Go for the simple option!
So in my mind, installing Gateway on each Business Suite system is preferable as it is the simplest option and provides some advantages over a stand-alone deployment.
Companies with multiple systems such as CRM, ECC and SRM may end up with multiple Gateway installs. But because Gateway is pretty painless to install and configure and essentially runs itself, this should not cause any discomfort.
If there ever is a requirement for a stand-alone instance, and the product has some decent tooling which makes such a thing worthwhile, then this can always be retrofitted to result in a hybrid landscape. Nothing wrong with that. In my mind, that is no different to modern SOA deployment architectures, whereby most systems have SOAP stacks which may (or may not, depending on your beliefs) be supplemented with a central SOAP stack in the form of an ESB.
...but it depends...
One big hurdle right now is the fairly demanding version requirements. Unless you’re running NetWeaver 7.02 SP7 or later in your Business Suite system, an integrated install is a non-starter. However I am sure this will change for the better; it was mentioned in passing at TechEd that Gateway is planned to be on its own release track in the future and this could improve the situation, or (fingers crossed!) even result in it becoming available for older releases?
If you must have NetWeaver Gateway right now and your Business Suite does not meet the version requirements, then a stand-alone install on a small ABAP stack is always an option, and it’s great that SAP have provided a choice here. However, I would only ever regard this as a tactical solution.
The above does not apply to the Sybase Unwired Platform in my mind. SUP is a much more complex (read fully-featured) product with its own architecture, persistence, management mechanisms, etc. and is not closely coupled to any backend implementation in the same way NetWeaver Gateway is. In my opinion, SUP is well deserving of its own installation, and I can see a single instance serving all connected mobile devices and backends.
Thanks are also due to my colleagues John Moy (@jhmoy) and Jacek Klatt (@yatzeck) for being passionate and knowledgeable discussion partners in an email exchange of views on John Appleby’s tweet which ultimately led to this blog.
Sascha Wenninger
is @sufw on twitter and an Architect for Australia Post, focusing on integration matters
Congratulations to making it to the end! What do you think? Please feel free to weigh in to the debate in the comments!
Comment on this weblog
| Showing messages 1 through 25 of 25. | ||
|
|
||
| Titles Only | Main Topics | Oldest First |
- Gateway & Composition
2012-02-09 01:53:56 Hendrik Lock
Business Card
[Reply]
I just clarified that composition has not been released with GW 2.0 SP03.
- SAP NW Gateway - JavaScript
2012-01-20 00:40:43 Acos Rodriguez Business Card [Reply]
Hi Sascha,
nice blog entry!!!
I am currently working on a prototype based on SAP NW Gateway for mobile devices using datajs library.
Unfortunately, this library only works with IE, as soon as I try to access data through Firefox/Chrome/Safari browsers, it does not work. Did you know about that? Maybe you can give any clue to get this work.
Thanks for your help.
Regards,
Acos Rodriguez- SAP NW Gateway - JavaScript
2012-01-20 03:41:37 Sascha Wenninger Business Card [Reply]
Hi Acos,
Do you know what specific error you are getting in non-IE browsers? I would be surprised if the library does not work at all in those browsers, but cannot confirm myself.
Have you seen Chris Whealy's excellent HowTo guide on SDN on exactly this topic - maybe this might help?
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/505619a7-73bf-2e10-fe96-da9a86b23120
Regards,
Sascha
- How about installation on PI
2012-01-11 13:32:13 Fons van Nuland Business Card [Reply]
Great blog Sacha,
I agree with you that for landscapes that are not that complex or for the use of little services the best way to implement Gateway is install it on your relevant SAP component as an add-on.
However when there is a complex landscape or there are security regulations to be met than you might have to choose for a separate installation. This choice brings an additional component in your landscape with all costs and troubles of the additional component.
How about installing Gateway as an additional component on your PI system instead of adding an extra compenent. All security issues shall already be covered by your PI system and your PI system will already be connected to all the relevant SAP systems.
What do you think about that?
Best regards,
Fons van Nuland- How about installation on PI
2012-01-11 14:19:46 Sascha Wenninger Business Card [Reply]
Hi Fons,
Installing Gateway on PI is also something we considered. However, there are wo obstacles to this as we saw them.
First of all, Gateway requires NetWeaver ABAP 7.02 but there is no corresponding PI release as PI (along with CE, BPM, etc) is on a different branch of NetWeaver compared to the Business Suite. I don't know whether it is possible to install Gateway on the ABAP stack of PI 7.31 for example. I have seen nothing from SAP which suggests this would work, but we also never tried.
PI 7.3 was the first release of PI which can be installed without an ABAP stack, so SAP have effectively deprecated it for PI. I'm sure a lot of customers won't immediately get rid of their ABAP stacks (especially if using lots of ccBPMs), but it means hosting Gateway on PI would only be a tactical choice even if it was possible.
Regards,
Sascha
- Rest runtime
2012-01-10 03:52:08 Olivier CHRETIEN Business Card [Reply]
Hi,
I am with Sasha on this subject. We already have dozens of servers for SAP landscapes. A standalone Netweaver Gateway is just an economical aberration (even if it would be nice technically) : One more landscape to install, to run, to backup, to supervise, to patch, etc...
In my opinion, the Netweaver gateway should even not exist as an add-on but just as the REST runtime like there is the SOAP runtime.
- Great points, but I'd still recommend Standalone
2012-01-09 05:41:37 Jonathan Wilson Business Card [Reply]
Hi Sascha,
Great blog, and I agree with all the points you make, particularly the one about the similarity between NetWeaver Gateway and the SOAP Runtime.
However I believe that there is one very strong argument for Standalone deployment. It is found in Note 1569624 (Installation/Delta Upgrade of SAP NW Gateway 2.0), which contains the following point:
- It is not possible to uninstall GATEWAY 2.0. Before you install the GATEWAY 2.0, keep in mind that you cannot uninstall ABAP add-ons.
So unless you are absolutely certain that you want the NetWeaver Gateway components in your Business Suite system forever, then a Standalone deployment is probably the safest option, as it gives you the ability to remove Gateway from your landscape in the future, should you wish to do so.
I believe that this recommendation is especially relevant for anyone who is evaluating Gateway, as you will most likely want to avoid making irreversible changes to your Business Suite systems until you are certain that you will want to keep them.
Cheers,
Jon- Great points, but I'd still recommend Standalone
2012-01-09 20:55:33 Sascha Wenninger Business Card [Reply]
Hi Jon,
Thanks for the detailed response!
I hear your point on the "permanence" of the Gateway addon in a system. However, this isn't really different to any of the stuff controlled by the switch framework today. I know our ABAP stacks are littered with unused features which can't be removed even if we don't use them. We just disable the ICF nodes so they can't be used, and leave it at that. If something isn't used, then it's unlikely to cause extra work during upgrades. It has a separate area in SPRO, all of its ABAP objects and tables are in their own namespace and it has clearly delineated ICF nodes so I think it would actually be quite feasible to "deprecate" it *if* a customer decides they no longer want it...
Regards,
Sascha
- Great thoughts
2012-01-09 05:01:09 DJ Adams Business Card [Reply]
Great thoughts Sascha, you make some compelling arguments.
Although I don't think there's a one size fits all approach anyway (and I'm sure that opinion is shared).
One other aspect which may (though perhaps shouldn't!) influence the decision is simplifying the Same Origin policy stuff with XHR calls. Simple deployments with app+data served from same domain.
The idea of a standalone gateway is appealing at least conceptually, in the same spirit as the early days of initiatives similar to Gateway.
cheers
dj- Cross-domain not tha big a deal?
2012-01-10 13:40:11 Sascha Wenninger Business Card [Reply]
Hi DJ,
I've had a bit of a think about your XHR comment. Please correct me if I'm missing something as I am not very experienced with this stuff...
Cross-domain restrictions really only come into play when consuming APIs from a browser. If we were to consume a Gateway API directly from, say a native mobile app, then this wouldn't be an obstacle.
Now, if we had a web app (mobile or not) which was hosted on one of the SAP systems, and which would cause the browser to make calls to gateway, then we could run into cross-domain restrictions. However, if we host the web app, then we should also have control over the document.domain property of the pages. This could be loosened (e.g. set to myco.com rather than host.myco.com) to resolve this. Even if the app was hosted externally, we're likely to have some control over it as we need to point it at our Gateway system in the first place.
So are cross-domain concerns really only applicable to "mash-up" kinds of use cases in the context of Gateway?
Sascha
- Cross-domain not tha big a deal?
2012-01-17 06:44:19 DJ Adams Business Card [Reply]
Hi Sascha
(It's odd typing that name, I'm used to @sufw :-)
You're right, XHR/Same Origin Policy restrictions are not applicable to calls outside the browser context, i.e. API-style usage from an App is fine. Also, as you say, if you're in control of the back end, there are lots of options, from reverse proxy all the way through to CORS.
Loving how your post has generated such a surge of interest - kudos!
dj- Cross-domain not tha big a deal?
2012-01-18 05:53:09 John Patterson Business Card [Reply]
Hi dj
I agree there are lots of options.
After watching your slightly blurry winning Demojam entry at SITNL, I am interested knowing
- how you got round SOP using the Google Secure Data Connector?
- and could did you use a GData API to read the Gateway OData?
A blog would be nice.
Cheers
JSP- #sitNL demojam writeup
2012-01-18 06:25:45 DJ Adams Business Card [Reply]
Hi John
Indeed, that is on my list, but it's further down that I thought at the moment. I'll see what I can do.
Cheers!
dj
- Great thoughts
2012-01-09 20:46:13 Sascha Wenninger Business Card [Reply]
Hi DJ,
Thank you for your comments!
"initiatives similar to Gateway" sounds interestingly mysterious :-)
I do agree that there is no single approach which will work for every one and in every situation, especially seeing as it's relatively early days with Gateway; its demanding version requirements alone do present a solid argument for stand-alone.
However, given the commitment to OData that SAP has recently shown (for better or worse given that even its inventors describe it as "ODBC for the Web"), I do believe that wrinkles such as the version requirements will go away in due time. SAP has already talked about ByDesign and HANA supporting OData natively, and I'm sure (hope?) it's only a matter of time until Gateway is shipped with every NetWeaver system much like software components like ST-PI are today.
To me, this makes a stand-alone deployment a largely tactical choice to work around some of these 'wrinkles'. If you are running the correct versions of the backend, then the argument for a stand-alone deployment becomes less convincing in my opinion... But others will have different viewpoints, as this isn't a binary problem.
Sascha
- Good blog and discussion...
2012-01-09 04:46:10 Jason Scott Business Card [Reply]
Great blog and I agree with your position on the integrated deployment. Simpler and gateway is definitely not "middleware". The last thing we need is another middleware product from SAP.
Regards, Jason Scott.- Good blog and discussion...
2012-01-09 20:38:53 Sascha Wenninger Business Card [Reply]
Hi Jason,
thank you for your comments. Despite having spent the past few years working almost exclusively on PI projects, I have really swallowed the REST Kool-Aid over the past ~12 months and do believe that more, or even all-pervasive, middleware is not always A Good Thing. Sometimes there is nothing wrong with "point to point" integration... :-)
Sascha
- You convinced me
2012-01-09 04:38:53 John Moy Business Card [Reply]
Hi Sascha,
I should mention to readers of this blog that my original response to John Appleby's question was to quote some text from an SAP app admin guide which reads as follows ...
"For a productive environment, we recommend that you install the SAP NetWeaver
Gateway system separately from the application back-end system. Doing so offers
the advantage that you can use the protocols between the servers for monitoring
purposes and protect the system against attacks."
That said, after seeing your compelling arguments as detailed in this blog, I must say that you have altered my opinion to align with your thinking. Well done!
Regards
John
- My vision
2012-01-09 04:38:19 Ivan Femia Business Card [Reply]
Hi Sascha,
Thanks for this interesting blog, btw I'm considering the stand alone installation still the first option for several reasons:
* GW Server should be in the DMZ
* One GW Server could be the front end for several back-ends
* Having GW installed on each back-ends requires more effort in maintaining and upgrading either NetWeaver or GW Server itself (You should also consider licence charges with several installations)
* GW Server has some NetWeaver requirements that can not be fulfilled by all your systems
Regards,
Ivan
- My vision
2012-01-09 20:36:13 Sascha Wenninger Business Card [Reply]
Hi Ivan,
as I said the real answer is "it depends" on your requirements and particular situation. For me, my "going in position" is a local/integrated deployment but that just reflects my own position, environment and personal biases. This is likely to be different for everyone.
However, I would caution against the belief that Gateway in a DMZ can somehow protect your backend from external attacks.
I for one don't have enough trust in the fairly complex ABAP stack to expose it to the internet directly. To the open-source side of my brain, it smells too much like 'security by obscurity' to be trusted with direct internet exposure. And if someone manages to compromise the Gateway system in your DMZ, then they access the no-longer protected backend... I would strongly prefer a good reverse proxy or even an API management layer in front of it to provide mature tools to protect against DoS attacks for example.
Your Mileage May Vary of course but thank you for your thoughts.
Sascha- My vision
2012-01-10 05:01:55 Ivan Femia Business Card [Reply]
Sascha,
you're right "depends", but if I have to choice a solution now I will prefer stand alone or consider this as the first choice. Happy you raised this interesting discussion.
Ivan
- Just a random thought...
2012-01-09 04:09:59 Alisdair Templeton Business Card [Reply]
Hey Sascha.
Nice work - have to say that I agree with your assessment, though I fear that GW will collect more and more "responsibilities" with future releases. IMHO, a standalone GW deployment seems to be taking on the responsibilities of a "SOA Gateway" - I'm not sure this is where we hoped this would go...
Although GW as a standalone install seems excessive on its own, it appears that any Customer that will also be doing mobility with SUP will also need NW Mobile, which will have GW installed, so this may impact the deployment decision.
AT- Just a random thought...
2012-01-09 20:28:26 Sascha Wenninger Business Card [Reply]
Hi Al,
yes, I don't think a fat middleware layer is where I would like to see Gateway going either. I think we agree on this - after all, the SOAP runtime in the ABAP stack isn't a big stand-alone layer either...
John will be able to correct me, but I believe the new SAP mobile apps don't require NW Mobile anymore and make do with just SUP 2.1 and Gateway.
Sascha- Just a random thought...
2012-01-09 21:45:03 Alisdair Templeton Business Card [Reply]
Hey Sascha.
Like you said in your blog - "It Depends".
Apps like Leave Request, Sales Order Notification etc. don't store any data locally on the device (apart from credentials and some WF context info depending on the app). In this case, you are correct SUP 2.1 talks to ERP via GW.
Currently, the apps that are supporting offline operation - Field Service, CRM Sales etc use both SUP 2.1 and Netweaver Mobile (for the DOE) - and the "other GW" as John pointed out earlier ;)
That said, I guess it's possible that the DOE functionality could find its way into SUP in future releases - maybe someone can point to information on this?. Of course, this would be a major issue for anyone that has already implemented these solutions, as its a massive architectural change - so most likely NW Mobile will be around for a while...
AT
- Just a random thought...
2012-01-09 04:30:37 John Moy Business Card [Reply]
Hi Al,
I think the GW that is installed in NW Mobile is a different thing altogether? Or perhaps I am misreading things.
Sascha - well done getting your blog published!
Rgds
John- Just a random thought...
2012-01-09 13:56:54 Alisdair Templeton Business Card [Reply]
Hi John.
Serves me right for just skimming the installation guides! You are correct, it is the "Gateway for SAP Netweaver Mobile" which is not the same thing as Gateway...But hey, what's another "Gateway" between friends ;)
I wonder if they will converge at some stage???
AT
| Showing messages 1 through 25 of 25. |