Blogs
|
How to Architect SAP NetWeaver Gateway for Dummies (and for Experts)
|
|
This week, I got a request through for us to urgently architect SAP NetWeaver Gateway into our internal systems at Bluefin. It immediately started a argument - I mean discussion - because a number of us fundamentally disagreed about the approach to architecting this solution. So, I stuck the question out on Twitter, which immediately caused a disagreement between some of the most respected members of the SAP Community. Here's a few tweets (note John and Sascha are colleagues!):
This week, I got a request through for us to urgently architect SAP NetWeaver Gateway into our internal systems at Bluefin. It immediately started a argument - I mean discussion - because a number of us fundamentally disagreed about the approach to architecting this solution. So, I stuck the question out on Twitter, which immediately caused a disagreement between some of the most respected members of the SAP Community. Here's a few tweets (note John and Sascha are colleagues!):
Thomas Jung: @applebyj The developer in me likes it standalone so it can be upgraded independent of the NetWeaver layer under your ERP #shinyobjects
Vijay Vijaysankar: @applebyj my guess is probably 80% peeps can use it on business suite server itself..choosing a stand alone for complex landscapes
DJ Adams: @thomas_jung @applebyj yes, all the usual advantages of standalone 'gateway' apply, nicely enough. Independent, positionable as app-firewall
John Moy: @applebyj SAP says "For a prod env, we recommend that you install the SAP NW Gateway system separately from the application back-end sys."
Sascha Wenninger: @applebyj Integrated IMHO. I see GW as being analogous to the SOAP runtime rather than Yet Another Middleware, plus REST is abt efficiency.
So with this in mind, I spend some time on research and found that none of the documents I could find gave a straight answer. The main articles I found were the NetWeaver Gateway Deployment Guide:
http://help.sap.com/saphelp_gateway20/helpdata/en/62/91ad98b19b4a91bca737fbe442273f/content.htm
And the NetWeaver Gateway Guidelines for Best-Built Applications:
For my money, they are confusing and don't give clear architectural guidelines. So here's my analysis. Feel free to argue in the comments section below:
Overview of SAP NetWeaver Gateway
SAP NetWeaver Gateway is a mechanism by which developers can connect stuff to SAP using standards-based RESTful Web Services. The first application that used it was Duet Enterprise, which connects share point to the SAP Business Suite, but you can now use it generically to get information in - and out - of SAP. It is now in version 2.0 and quite a lot of content is supported and SAP are releasing more and more content with each service release.
Gateway is great because is allows easy access to the core of SAP using standards-based REST interfaces. It's great for non-SAP people because they can access SAP easily. It's great for SAP people because the Sybase Unwired Platform uses REST/OData to connect online mobile apps back to the SAP Business Suite.
It is an Add-In to the SAP Business Suite - an ABAP Add-In - and can be installed on any SAP system based on NetWeaver 7.02 or above. That means SAP NetWeaver BW 7.02, SAP ERP 6.0 EhP5 and SAP CRM 7.0 EhP1, to mention just a few. If you don't have one of these versions then you can install Gateway on its own NetWeaver 7.02 instance, and connect it back to almost any version of SAP software - back to R/3 4.6c.
For clarity, SAP talk about a local and remote deployment model. And a standalone and embedded model. When you install Gateway on your ERP system (as an ABAP Add-In), it is a local or embedded model. When you install a separate system away from your ERP system, it is a remote or standalone model. There you go.
The question is, in what circumstances should you use which architectural model, and why. Here's my thoughts - which should take you through a thought process to allow you to decide the right way to architect Gateway.
Scenario 1: Security is paramount
If you are deploying applications that allow access from the outside world, like mobile apps, into your SAP network, and security is paramount, then you should deploy a separate instance of NetWeaver Gateway into a demilitarised zone or DMZ. This provides separation between your core SAP network and your edge. You can get the network team to lock down the NetWeaver Gateway system which will make it very difficult for unwanted visitors to penetrate your network.
Scenario 2: Old versions need to be supported
If you need NetWeaver Gateway to provide access to older versions of SAP R/3 or ERP, then you must put Gateway on a separate system. If you need to reduce cost then you could put this on the same physical system as some other SAP environment like ERP or TREX. In any case, you can't install Gateway as an add-in to your ERP environment so you need a separate system.
Scenario 3: Agility is most important
If your core Business Suite / ERP moves slowly or you are unable to update to a recent version, then it is smart to install Gateway as a separate system. This is especially true if you have very strong change management policies around your ERP environment, as you may not be able to update Gateway as often as you would like, because it will be tied to your ERP update process. This is particularly true if you operate a consolidated or global ERP environment for a large number of users or regions. If this is the case, then installing Gateway separately will afford you much needed agility.
Scenario 4: Duet Enterprise
Apparently Duet Enterprise requires a standalone version of NetWeaver Gateway. So there.
Scenario 5: Capital cost to be minimised
If capital cost should be minimised and you want access to predominately one application - and you are on ERP 6.0 EhP5 or any other NetWeaver 7.02 based platform, then you should install NetWeaver Gateway as an Add-In. I know that this is the last scenario - and all the other scenarios mean a standalone Gateway - but it works best this way.
Note that Gateway when installed as an Add-In doesn't have any technical limitations over the standalone version. In contrast to SAP's documentation, you can do everything you can do on the standalone, with the Add-In version. The SAP Help guide suggests that routing and composition of multiple systems aren't possible in the local deployment model, but there is no supporting evidence.
You probably won't upgrade to ERP 6.0 EhP5 just so you can have support for Gateway, but it is a nice benefit for customers who have just upgraded and are already there, or who are on a regular Enhancement Pack cycle. Enjoy.
Conclusions
My main view is that it's not obvious - even for the technically gifted, like some of the SAP Mentors mentioned above - what the right way to architect Gateway is. And what's more, it's not clear what the right integration strategy for SAP is. Take some of the following tweets as evidence:
Tobias Hoffman: @sufw @jhmoy @applebyj I'm always honest. SAP should make 1 product that combines all alternatives of accessing and exchanging data with SAP
Jan Penninkhof: @BoobBoo @applebyj which gateway: ABAP, Mobile or project Gateway << It's time for SAP to consolidate its middleware into one bundle.
John Moy: @applebyj Funny, @sufw sits next to me and we just gave you differing opinions. Just keeping you on your toes ;-)
Tammy Powlas: @jhmoy @applebyj I am glad you are talking about #SAP Gateway, as we just had this discussion at work today
Jon Wilson: @tobiashofmann Umm, isn't that what Process Integration is supposed to be? Gateway should just be another adapter cc @sufw @jhmoy @applebyj
Martijn Linssen: @tobiashofmann @applebyj @integrationer @sufw one single product that can handle and transform any message syntax and any transport protocol
Yes - if you get the point, people are confused. They are confused about SAP's integration strategy with Process Integration and Gateway. I think this is exacerbated by the rekindled relationship with TIBCO, which might spark rumours of an acquisition (if TIBCO weren't too expensive). Some clarity and better architectural guidelines would be of benefit for all.
John Appleby
is the Business Analytics & Technology Capability Lead at www.bluefinsolutions.com
Please, let me know if you don't agree or if I've missed a scenario. I hope you enjoy.
Comment on this weblog
| Showing messages 1 through 11 of 11. | ||
|
|
||
| Titles Only | Main Topics | Oldest First |
- Duet Enterprise standalone?
2012-02-16 00:53:43 Rudolf Dums Business Card [Reply]
Hi Guys,
Scenario 4: Duet Enterprise
you are wrong if you state Duet Enterprise requires a standalone version of Gateway.
We did it as an Add-In on BW. It works whenever we agree with SAP not to recommend it. Configuration complexity already high and increases to configure Backend connections as loop-backs.
- DUET and GW
2012-01-10 08:13:49 Patrick Brandicourt Business Card [Reply]
I am a dummy guy on the subject.
I can recall only picture and not the wording.
For you scenario 4 :
At glance it would not make sense from an architecture stand-point (UI is converging).
I have done a quick google search and I found an entry in the SDN forum which seems to tell me taht with FP1 this statement is not valid anymore.
- Security Considerations
2012-01-10 07:34:07 Frank Koehntopp
Business Card
[Reply]
I'd like to add the recommendation of putting a reverse proxy into the DMZ instead of a Gateway instance.
Gateway has all the mobile users plus (most likely) a few (trusted?) RFC connections to your ERP landscape, so I wouldn't necessarily feel ok exposing all that in the DMZ.
- Good perspective
2012-01-10 03:30:31 Sascha Wenninger Business Card [Reply]
Hi John,
many thanks for sharing your perspective on the discussion as well, especially since you started it all! :-)
Those are some good decision criteria. I guess everyone would give their own personal weightings to each of them when trying to decide on a course of action, and it of course very much depends on the customer's environment (and culture). So yes, I don't think there is a clear-cut answer (yet).
Regards,
Sascha
- Gateway and an Integration suite
2012-01-10 02:35:53 Shabarish Vijayakumar Business Card [Reply]
Jan Penninkhof: @BoobBoo @applebyj which gateway: ABAP, Mobile or project Gateway << It's time for SAP to consolidate its middleware into one bundle.
Jon Wilson: @tobiashofmann Umm, isn't that what Process Integration is supposed to be? Gateway should just be another adapter cc @sufw @jhmoy @applebyj
>>>>>
Echoes my thoughts!
I have always been confused on why SAP has two different directions and not a single combined suite for its integration requirements. Instead of investing in a completely different product, ideally I would have thought that the capabilities of Process Integration would be enhanced to handle this or at least as a plugin to PI.
Someone care to clarify?
Regards,
Shabz
- Gateway and an Integration suite
2012-01-10 13:50:38 Martin English Business Card [Reply]
The interesting thing about both the twitter conversation AND the comments here is how the answers are coloured by the respondents background. For example, the PI people see Gateway as a poor mans PI, the developers see it as question of REST v SOAP, and the architects want to know, specifically, which gateway you're talking about.
And, by the way, no one mentioned whether there's any point in having an ODATA only interface....
I would start by looking beyond the SAP environment... For example, if SAP is not the predominant software in your shop, you may need to consider integrating SAP into an existing SOAP service bus or REST gateway.
How many interfaces are expected? Maybe one or two ICF routines may be more cost effective, or depending on the inhouse skillsets, maybe even 'just' RFC.
Remember that having the toys on our resume is one thing, but providing value for our customers comes 2nd (#1, of course, is being....amazing).
Hth
- Not a good idea...
2012-01-10 03:47:39 Sascha Wenninger Business Card [Reply]
Hi Shabz,
Sorry, but I'll have to disagree with this notion that an ideal, or even a good outcome, would be to have Gateway merge with PI.
PI has been designed from the ground up as a message oriented middleware product with some ESB features, which have grown over time. PI as a product is thus based around a fundamentally different architectural style to REST. Apples and Oranges (or Pears in the Netherlands, apparently)...
Although both of these styles can successfully be used to architect solutions for systems and application integration, shoehorning one of these into a product designed to support the other is either not going to work, or will produce a less-than-optimum outcome.
REST is not a protocol for which an adapter can be developed and plugged into the PI Adapter Framework - it's a fundamentally different way of thinking about approaching integration problems.
Sure, PI should be able to consume RESTful APIs and I think that would be a good feature to have. Maybe I want PI to expose one SOAP service which drives some orchestration across other APIs, including RESTful ones. But I see that as a nice to have rather than some kind of fault with SAP's product architecture.
But making PI the One Integration Hub To Rule Them All is not a good idea.
SOA works by breaking down a problem domain along functional lines, and constructing services to which can be invoked to change state on the service provider.
REST works by breaking down a problem domain by resources, and constructing a number of representations which can be modified by the client to cause state changes on the server.
These two approaches are very different, and this difference should be recognised to avoid ending up with a solution that makes too many compromises to be truly useful to anybody. I don't see why having two products is really an issue.
Someone much smarter than me (forget who, there's too many!) once said:
"Half of the evil in IT is caused by trying to make one thing do two jobs"
And I agree with that. Do one thing, and do it well. It's a philosophy which has served UNIX very well for the last few decades.
Regards,
Sascha- Not a good idea...
2012-01-11 03:17:35 Keshav Desai Business Card [Reply]
Thanks Sascha, this clears up a lot of questions in my mind.
Regards
Keshav
- Not a good idea...
2012-01-10 15:31:25 Nigel James Business Card [Reply]
+1, Like and 3 cheers for a well argued position Sascha,
If they are separate you know what each piece of the puzzle is going to solve.
Also for that reason it is useful to have GW on a separate server for all the reasons John A mentioned in his post.
For smaller scenarios an add-on is the way to go.
Cheers,
Nigel
- Not a good idea...
2012-01-10 04:26:53 Shabarish Vijayakumar Business Card [Reply]
thanks for sharing your thoughts Sascha
- #HTML5 #MobileDevices
2012-01-10 01:16:46 Acos Rodriguez Business Card [Reply]
Hi John,
I agree with you, its a little confusing how to implement best-practices with SAP NW GW.
I was working on a prototype on mobile devices, such as iPhone's and BB's. We tried to use the OData protocol with the JavaScript library datajs. Unfortunately, this library only works for IE and is not supported for mobile devices browser. I am a little disappointed with this, we try to get standars along landscapes but there is always a little thing that does not fix 100%.
I hope that SAP can supply a working JavaScript library to ensure the communication with SAP NW GW.
Cheers!
| Showing messages 1 through 11 of 11. |