Skip to Content

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+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.

To report this post you need to login first.

22 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member
    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!

    (0) 
  2. Shabarish Vijayakumar
    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

    (0) 
    1. Sascha Wenninger
      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

      (0) 
      1. Nigel James
        +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

        (0) 
      2. Former Member
        Hi Sascha,

        Excellent post. Thanks for sharing your thoughts.
        Just wondering what you think about the REST Adapter described in the following post.

        REST adapter for Netweaver SAP PI

        Also, the current use case of Gateway assumes that SAP ABAP stack (ERP,SRM,CRM and etc) is running as the backend, whereas PI can be connected to literary anything.

        Regards,

        Ryosuke Mouri

        (0) 
      3. Former Member
        Hi Sascha,

        Excellent post. Thanks for sharing your thoughts.
        Just wondering what you think about the REST Adapter described in the following post.

        REST adapter for Netweaver SAP PI

        Also, the current use case of Gateway assumes that SAP ABAP stack (ERP,SRM,CRM and etc) is running as the backend, whereas PI can be connected to literary anything.

        Regards,

        Ryosuke

        (0) 
      4. Former Member

        I agree Sascha…whenever someone asks about why is there Gateway when there is PI, I have to assume they don’t know Gateway that well. I don’t really know much about PI but I know enough (about as much as in your excellent summary) to know that they are indeed Apples and Oranges. 

        (0) 
    2. Martin English
      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

      (0) 
  3. Sascha Wenninger
    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

    (0) 
  4. Frank Koehntopp
    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.

    (0) 
  5. Former Member
    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.

    (0) 
  6. Andy Silvey

    talk about timing Adi, I am looking at the same question.

    John Appleby excellent blog (as usual)

    we’re a year down the line now, if you have time, would be kind enough to update this blog with what’s been learned in the last 12 months on this subject.

    Is there now a more concrete answer/guidance standalone or add-in on a backend by backend basis ?

    Without talking about $$ surely the standalone gives the most flexibility for upgrades/maintenance etc, and scalability ? On the other side, there is the question of agility of the landscape, we all know if a customer is not doing yearly landscape upgrades and they have one centralised Portal they can run into challenges for example when the Portal has all the business packages for HR/MDM/SRM etc, and they want to upgrade only SRM and the latest Portal Business Packages for SRM require a higher version of the Portal than they currently run, so using this as an example, one centralised system can also have challenges for agility in the landscape.

    Or should we look at GateWay like the Integrated ITS, it’s there (as an Add-in) on all ABAP stacks (providing they are the right version of course) and keep it that way, 1 GateWay for each backend instead of centralised ?

    I’ve also awoken Sascha’s  excellent blog with the similar question.

    To avoid confusion let’s keep the answers/responses either in this blog or that one – who responds first can decide which.

    All the best,

    Andy.

    (0) 
    1. Former Member Post author

      I’d love to listen to the answer to this from DJ Adams or someone similar, but I don’t think anything has changed here.

      This article was written this 2 years ago, not 12 months ago ๐Ÿ™‚

      Like many app servers or middleware systems, it will be appropriate in some cases to install it locally, and in others it will be appropriate to have a central system.

      (0) 
      1. Andy Silvey

        Hi John,

        thanks for coming back and the reminder that we’re now in 2014.

        There is no right answer, isn’t that the beauty of SAP Architecture , there

        is no one size fits all answer to anything, decisions depend on a variety

        of factors which all have different weightings from company to company.

        I am leaning towards the agility in the landscape of having the Add-in GateWay

        locally for each vertical backend where there is a requirement.

        @DJ Adams your feedback is welcome.

        Best regards,

        Andy.

        (0) 
          1. Andy Silvey

            Hi Andre,

            thank you for connecting your blog to this one.

            For all, Deployment Options are also discussed in the NW GateWay 2.0 SP06 Master Guide which is here.

            Kind regards,

            Andy.

            (0) 
  7. Former Member

    Hi John, Andy,

    Now as Gateway in my understanding is included in NW 7.4 without a separate installation, it seems quite practical to have the embedded deployment in each system (in the future, when your systems are running on 7.4)

    However, if you have an existing landscape including also PI and you have good reasons for deploying the Gateway as a central hub, does it make any sense to install it as an add-on to the same system where you have the PI running? It would sound logical to me to have all your integration components in the same platform, but are there some reasons for not doing so? Especially if you have your PI on an earlier version (prior to 7.4) as a dual-stack installation, Gateway would fit nicely into the existing PI ABAP-system.

    Best regards,

    Pekka

    (0) 
    1. Andy Silvey

      Hi Pekka,

      I am no expert of GateWay, so take what I philosophise with a pinch of salt.

      My take on this is:

      GateWay as a hub

      If we install GateWay as a hub system, one of the benefits is, this GateWay system is its own system with no dependency on other systems with regard to maintenance, operation, software lifecycle etc.

      Keeping this in mind, if we create the GateHub system as an add-on to the PI, then the GateWay, is for ever married to the PI system from the perspective of maintenance, operations, software lifecycle etc, and therefore, loses the motivations for a centralised GateWay which is independent of all other systems.

      Personally, I am leaning towards looking at GateWay as an Integrated ITS and having a GateWay Add-on for each vertical backend system.

      This means the SAP landscape retains its agility and maintainability and flexibility.

      The latest GateWay documentation available on SMP which I linked to above, the Master Guide etc, gives very nice pro’s and con’s of the architectural alternatives.

      Best regards,

      Andy.

      (0) 

Leave a Reply