How to Architect SAP NetWeaver Gateway for Dummies (and for Experts)

[Former Member]

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:

http://wiki.sdn.sap.com/wiki/display/BBA/Chapter+10.+NetWeaver+Gateway+Guidelines+for+Best-Built+App...

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.