Skip to Content

Opinions on Deploying NetWeaver Gateway

It all started with a tweet by SAP Mentor John Appleby (@applebyj)…
@applebyj: Question SAPpers, should you install NW Gateway as standalone or integrated? What are the decision criteria?

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!

@vijayasankarv: @applebyj my guess is probably 80% peeps can use it on business suite server itself..choosing a stand alone for complex landscapes

@thomas_jung: @applebyj The developer in me likes it standalone so it can be upgraded independent of the NetWeaver layer under your ERP #shinyobjects

@qmacro: @applebyj @thomas_jung yes need to balance those factors also. Middleware is always good (dislike the term, but I have nothing better).

@jhmoy: @applebyj SAP says: For a prod env, we recommend that you install the SAP NW Gateway system separately from the application back-end sys.

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:

Vison: People-Centric Content from Multiple Sources

However, my position on the matter was a little different:

@sufw: @applebyj Integrated IMHO. I see GW as being analogous to the SOAP runtime rather than Yet Another Middleware, plus REST is abt efficiency.

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.

You must be Logged on to comment or reply to a post.
  • 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.


    • 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!



      • 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???


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


      • 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…


  • 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


    • 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,

        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.


  • 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!



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

    • 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… 🙂


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


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


    • 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 rather than 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?


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


    • 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…



    • Hi Jonathan

      It is not quite true that you cannot uninstall Gateway.

      We’d prefer that you don’t uninstall it, but if you really need to (and you speak nicely to us 🙂 ), we can arrange for you to receive a delete transport for Gateway.

      You should understand however that provision of the delete transport is by special arrangement only and is not a generally available option.


      Chris W

      • Hi Chris,

        Thanks for sharing this, it is certainly good to know that there is a way (even if it is not generally available) to remove Gateway.  Obviously this is not the preferred path, but I can see situations where removing the add-on might be beneficial (e.g. following migration to a central hub installation).



  • 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 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

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



  • Hi Sascha

    I’m a concerned by some of your comments and the conclusions reached in this blog.  I’ll list them in the order they occur.

    Get your umbrella – the parade’s about to be rained on…

    1) You equate “product complexity” with the need for a separate installation.  Why do you see a correlation here?

    The need for a separate Gateway installation is based on defining a single (or low number) of client communication end points and has no correlation with the internal complexity of the software.

    2) There is both a conceptual and factual error in your statement “Gateway doesn’t (yet) provide any mechanisms for consuming SOAP enterprise services and only relies on RFC calls“.

    The conceptual error is between the interrelationship between SOAP and OData.  It is analogous to saying “My diesel engine car doesn’t work very well if I put petrol in it”.

    SOAP and OData are like diesel and petrol.  Both work very well in their own context, in that they are the fuel that drives a particular type of engine.  But they are not designed to be used outside their design context.  Petrol will kill a diesel engine!

    The factual error is in the statement that Gateway relies on RFC calls.  Depending on how Gateway has been installed, an RFC call might be made from the Gateway Hub server to the backend in order to invoke the required business functionality, or the entire Gateway service might execute directly in the backend system.

    Compatibility with SOAP was never part of Gateway’s design remit; therefore, it is not appropriate to find fault with Gateway because it offers no facilities to invoke SOAP services.  These are two different interfaces designed at different times for different reasons.

    If you wish to aggregate data from multiple backend systems into a single Gateway service, then this is it not “wishful future-state thinking“.  Instead its perfectly possible using RFC calls as the interface rather than SOAP calls.  The easiest way to do this is to create a custom Gateway service that executes in the Gateway Hub server and makes RFC calls in various backend systems.

    3) In the “Efficiency Wins” section, you state “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.

    Sorry, but this is not an accurate conclusion.

    The principles of REST make no mention of how a backend system should implement its functionality.  Instead, REST simply defines principles for how the communication between participants is to be regulated.  If, within the implementation of its functionality, the participant acting as the server wishes to make multiple calls to some other system, then it is perfectly at liberty to do so.

    According to the principle of REST, as longs as a single OData service is provided to the client, it matters not how that service is implemented internally.

    REST is not primarily concerned about efficiency, it is concerned about providing a uniform interface that makes service consumption as easy as possible.

    4) In the section “Go for the simple option” you directly contradict the SAP recommendation by stating that it is simpler to install Gateway entirely on each backend system.  This is not recommended by SAP simply because its not simpler!

    If you have say, half a dozen systems in your system landscape, then you could argue (with some justification) that the administrative overhead of maintaining multiple installations of Gateway is negligible.

    However, we (SAP) must make a recommendation that fits the widest number of customer situations – and then handle all the other use cases as variants.

    We specifically recommend installing a central Gateway server because there is now only one communication endpoint for client traffic.  This recommendation applies irrespective of whatever third party reverse proxy you may or may not have installed.

    The only remaining consideration in the scalability of admin effort is the need to upgrade the IW_BEP component in each backend.  This add-on needs to be present in the backend system if you wish to develop custom Gateway services directly in the backend system.

    For some customers that have huge system landscapes (i.e. > 100 productive SAP systems), then the maintenance of IW_BEP in each backend becomes a significant overhead.  Consequently, such customers opt for a small number Gateway Hub server installations.  The custom developed Gateway services then run in the hub server and make RFC calls into the appropriate backend servers.

    5) In the section “…But it depends…“, you do not seem to distinguish between installing all the Gateway components directly into your backend system, and installing only the IW_BEP add-on in the backend system (with the remaining add-ons install in a Gateway Hub server).

    The SAP preferred installation option for Gateway is to have a separate Gateway server containing all the add-ons except for IW_BEP.

    The remaining IW-BEP add-on is installed directly into the backend system(s) and the system requirement  is NW 7.00 SP18 or higher.

    This recommendation is of course based on the assumption that your system architecture diagram does not look like a photo from the Hubble Space Telescope (I jest not, some of our large customers really are in that situation).

    6) In the same “…But it depends…” section, you also attempt to equate Sybase’s Unwired Platform with Gateway.  Again, this is not an appropriate comparison.  Gateway is nothing more than the OData API into an SAP system (or systems); it never was or will be, intended to offer direct client application capability.

    SUP or the other hand, is a complete toolset for developing, deploying and managing client applications.  As such, it provides functionality Gateway was never designed to provide.

    Sorry to rain on the parade here, but there seems to be a strong underlying assumption that because Gateway doesn’t behave in a manner similar to existing technology (e.g. SOAP based services), then somehow, it is legitimate to find fault with Gateway.

    Please resist the temptation to equate that which is familiar with that which is good.

    I have just finished writing the new Gateway training course GW100, and many of the points discussed here are covered in the very first chapter of the training course.

    I would strongly recommend that anyone interested in Gateway should attend this course.


    Chris W

    • Hi Chris, Great to see an SAP employee entering this discussion. I can see valid points on both sides of the argument… However the comment above by Olivier rings true for me… If as you say “Gateway is nothing more than the OData API into an SAP system” then surely this should just be provided free as an abap add-on to be used just as Web Services, BAPI’s, RFC’s and even file upload/download already are. What’s the difference?

      We already have a powerful tool in SAP with the ICF. Why would I use GW instead of using the ICF to provide RESTful services (and also use the more widely accepted JSON).?

      If you need to call a couple of BAPI’s via a REST API, then this is very easily accomplished with pretty basic coding in the ICF. Why have GW with its extra servers and administration?

      Regards… Jason.

      • Hi Jason

        Well, I can’t answer the question of why SAP has decided to make Gateway an item on the price list and then charge (relatively speaking) peanuts for its use…  I know Jon Reed and Dennis Howlett have had a good old gripe about this situation, but grumbling aside, we are where we are and I don’t think grumbling about it is going to change anything.

        As for “why should I use Gateway instead of the native ICF?” question; there’s nothing to stop you doing whatever you like – its your SAP system, code up whatever solution makes best sense for you.

        Gateway is provided for those customers “who just want it to work” without having to go into the  technical details of creating an interface at the lower level of raw OData and the ICF.

        One of the main reasons for providing Gateway is to offer an API into SAP that is as easy to consume as possible.  This means that we stop using proprietary protocols such as RFC or any other software layer that requires the developer of the consumption app to have any knowledge of the internal workings of an SAP system.

        For experienced ABAP developers, its true that a REST API can be implemented using basic coding in the ICF – but you have assumed that all customers are able to code ABAP and will therefore take the same approach as you.  This assumption is not valid however.  Strange as it sounds, SAP has plenty of customers where none of the employees can write a single line of ABAP.

        We can go round and round in circles arguing about the morality (or otherwise) of why Gateway exists and why SAP is charging for it.  None of this changes the fact that Gateway is here, that it offers a RESTful API into SAP systems, and that a consumption app developer can consume that API without needing to have any knowledge of the internal workings of an SAP system.

        This situation reminds me of an advert on British TV for Ronseal Wood Preservative.  The strap line say “It does exactly what it says on the tin”.  (That fact that you have to pay for the tin and its contents is a different matter).

        Gateway is much like this.  Assuming you’re happy to pay the nominal amount for its use, Gateway does exactly what it says in the tin.


        Chris W

        • Hi Chris,

          Like Jason mentioned, its great to see SAP engaging here.  I know the licensing is not your domain, but I don’t quite agree with the licensing being ‘peanuts’.  The experience I have seen from a customer is that the customer was asked to ESTIMATE their future number of invocations through Gateway over a one year period.  The customer couldn’t do this because they didn’t know the use cases for which it would be used.  In which case the Sales Exec estimated for them and the figure was non trivial.  When asked what happens if the actual usage turns out to be lower than the estimate, the response was it doesn’t matter – they pay based on the original estimate.  When asked what happens if their actual usage turns out to be higher than their estimate – then they get hit in an audit.  To me asking customers to estimate number of invocations in advance is like trying to throw darts blind folded.  Even SAP didn’t accurately estimate load on the new SCN during the recent upgrade.  I have experience with a third party mobile platform vendor that charges based on throughput as well, and their pricing is not dissimilar to SAP’s on a per usage basis.  However, the advantage they have is their mobile platform is in the cloud, so their meter is in the cloud, and consequently they can charge customers based on usage accurately, and in arrears.  From a customers perspective this is much more palatable – if their solutions are not used much, they pay less.  Anyway as I said I don’t expect you to comment because it isn’t actually your domain to talk about licensing.

          I do agree that Gateway provides a mechanism for consumption developers to consistently connect to SAP systems.  Developing REST APIs custom in SICF doesn’t scale if you want to sell your client app on an app store.  Although one concern I have is that those customers where ‘none of the employees can write a single line of ABAP’ also tend to be (in my opinion) the same customers who are reluctant to install another ABAP server.

          I dearly hope that Gateway does proliferate through the ecosystem, given such reliance upon it for SAP’s mobility ambitions.

          Thanks for your contribution.



          • Hi John.

            I totally agree that there needs to be a better process to manage usage costs – maybe a reconciliation each year where one party pays the difference to the other. Probably this means that the GW server would need the meter built in – which may be difficult, but the pieces are there – as Robbo put it, it’s kinda like the utility metering approach. The electricity retailers have been doing this forever – think hedge contracts etc – can’t be too hard to apply to this.

            I do need to ask though – who puts in GW without a use case? Sure, in a sandpit environment it’s a “what can we use this for” scenario – but surely this is covered by Dev licensing and not Production licensing, where the usage estimates must be made. Hopefully, by the time you need to estimate productive usage and finalise licensing, there is an actual business problem being solved! Also, how does someone throw up their hands and say usage estimates are too hard? Without this, how do you do any capacity planning at all? Any web based application – store fronts for example – must do this, or risk crashing on day 1.

            I’m not saying its easy, but its definitely possible 🙂 . And it’s a really important part of the development process. How do you do stress testing otherwise??? Also, i’d recommend taking a look at “Release It” by Michael Nygard, who discusses much of this. He’s also speaking at YOW this year.

            Hope the new job is going well.


          • “who puts in GW without a use case” … I probably should have been more prescriptive.  Yes there was a use case … in fact it was a mobile app (one of SAP’s). But the customer was expecting to adopt more during the year.  I guess the due diligence could have been performed to calculate the potential usage based on predicted adoption rates during the year.  One of the interesting things with SAP’s mobile apps is how do customers figure out how many invocations occur when performing (say) a leave request process from SAP’s mobile app. I guess customers could trace it, but then you would need to actually have the solution in place to do that (as well as all the SUP infrastructure etc.).  SAP (I am told) don’t provide the source code for these apps – so for instance if you want to add your logo to the app you need SAP consulting to fly in and do that for you – at least that was the case based on the app versions available a few months ago.  But I’m off topic, we aren’t discussing SUP here!

            Interesting though, if you establish a price based on an initial use case, I guess you would need to re-price every time you decide to add a new use case?  Or implement the pricing model you describe in your first paragraph.



          • Hey John.

            You’re absolutely right. We’ll IMHO anyway, you’d be looking at changing your license agreement every time you released new features that were delivered via gateway. Otherwise, and possibly this is the point you were making earlier, you’d have to estimate invocations based on every possible use case you *may* ever implement with gateway, in which case, yes, it’s pretty much impossible.

            Which takes us back to the utilities model. Pay a license fee, and then pay for consumption as/when it happens – maybe even offer some sort of tiered billing for high consumption customers. But, apart from putting $ in someones pocket at the time of sale, there is no need for this number to be disclosed to SAP at the time of sale – SAP should just read the meter every so often and send a bill based on the agreed $/invocation figure. That said, I still strongly believe that the customer needs to attempt to work this number out for the reasons I discussed earlier – capacity planning, and of course estimating running costs for the app.

            On your other comment regarding SUP apps – SAP probably should disclose exactly how chatty these apps are to allow you to do some sort of estimate. Otherwise you’re at the mercy of the unknown, which nobody really wants 🙁


          • Hey Al,

            which brings on my favourite bit about the whole licensing model – it’s based on number of transactions/invocations, not volume – so just wait to see people building apps that have huge “fetch everything” calls to limit the number of transactions/invocations at the cost of user experience. Whilst the excellent user experience apps with AJAX style data fetching/updating will cost you $$$ in Gateway transactions/invocations. The architecture of app design shouldn’t be driven by such concerns – but you can bet it will be.

            But if we grumble enough – perhaps it will change?

            If not, I’ll just build everything in Neo and use the cloud solutions which don’t have such licensing nightmares (or OData) … yet 😉

          • …And that’s exactly why there should be no usage based licensing.

            And realistically, usage based licensing is no good for either party

            1) From a SAP PoV, the effort to measure/monitor compliance must outweigh the benefit

            2) Customers build ****** apps trying to keep the costs down as you point out.

            On another note, I’m curious about what you thought I meant by volume? I meant exactly what you said – volume => no of transactions/invocations


          • Off topic, but what is the licensing for NWCloud (neo)? I didn’t know it was announced. It might be per transaction/invocation as well… Worst case there are other PaaS solutions as well.   😉
          • Hi Alisdair

            Its certainly true that no one puts in Gateway for the sake of Gateway.  The vast majority of customer’s install Gateway because they need it in order to achieve some other end result.

            Its like the fact that no one buys a car because it has great spark plugs – but without spark plugs, your car is nothing more than an ornament on the driveway.

            Its also true that most customers install Gateway because they want to jump on the Mobile bandwagon.  However, as I replied to John Moy, Gateway can act as an interface for type of any client app – mobile or otherwise.

            If you are ever in a position of describing examples of Gateway use cases to customer, please paint the widest picture possible and don’t restrict Gateway to the “mobile only” set of use cases.


            Chris W

          • …Gateway can act as an interface for type of any client app – mobile or otherwise. […] don’t restrict Gateway to the “mobile only” set of use cases.


            Thank you for pointing this out! For a very long time, SAP’s marketing channels focused almost exclusively on the mobile use cases (and the obligatory Twitter/Facebook ones) and completely neglected to position Gateway as a useful tool for some A2A integration scenarios. It’s of course not a silver bullet with universal applicability, but as you pointed out it’s also a lot broader than just mobile. I think DJ Adams built some Ariba/SAP ERP/<something else> integration many years ago using REST principles, so there’s at least one example in the wild of this…


          • No S**t 😉 Otherwise you’d probably be spouting the Gateway =  “people centric” slogan that we’ve all come to adore so much 🙁

            I think many of us can see the value in a A2A model for REST – it’s just the message/marketing seems to be going the other way. I refer to just a few of the SAP and SCN links that have texts describing Gateway as “people centric” – not A2A.





            SAP NetWeaver Gateway

            Enables people-centric applications to consume SAP Business Suite data through popular devices and platforms in an easy and standards-based fashion.

          • Hi Chris.

            Sure. In fact, the first couple of use cases I imagined for Gateway were of the A2A type, distributing product catalogs to local store servers in a retail context (Atom Pub is actually really good for this). The beauty of HATEOS being that a machine can work it’s way through an application protocol (state machine) guided by hypermedia and link relations just as well as a human can.

            Not to push the car analogy too far, but I think the general perception of the consumption licensing model is that SAP are happy to sell us the car, but they also own all the Petrol Stations…


          • Hi Alisdair

            The product catalogue distribution idea is a perfect use case for Gateway.  In fact Netflix has been exposing their entire film catalog this way for quite a while.


            Chris W

          • Hi Jon

            I am under no illusions that if you ask a salesperson to make an estimate that links volume usage to their commission, then they will err on the side that benefits their commission.

            As you say, having a cloud based system would be far more beneficial to the customers because the monitoring can be done on the basis of actual usage, rather than some what-can-I-get-away-with estimate conjured up by a salesperson.

            One of the next major developments for Gateway is to be able to offer this product as a cloud-based solution.  I can’t spill too many beans about how this will work, but there will be several variations of this theme depending on how much of the rest of the customer’s SAP system(s) is(are) cloud-based. 

            I don’t know specifically about how the usage of cloud-based Gateway will affect a customer’s license or how they will be charged, but there will certainly be the technical capability to provide retrospective, usage based billing.

            I think its pretty safe to say that Gateway will definitely proliferate throughout the SAP ecosystem.  Judging by the internal demand for places on the GW100 training course, I’d say you will see standard application areas of SAP  start to offer Gateway/OData based interfaces to their functionality within the next 6 to 12 months.

            CAVEAT!  This is only my opinion based on keeping my ear to the ground – not a hard commitment from each and every development manager.

            Please also spread the message  that whilst SAP Mobility solutions need Gateway, Gateway is not limited to providing only Mobility solutions.  A consumption app running on any type of device capable of speaking HTTP(S) and parsing an XML or JSON message can act as a client for Gateway.


            Chris W

          • Hi Chris, thanks for your response  In relation to “Please also spread the message  that whilst SAP Mobility solutions need Gateway, Gateway is not limited to providing only Mobility solutions”, I’m completely with you on that.  In fact I think I’ve volunteered to give a presentation to our Australian user group on precisely this topic later in the year.



          • Hi John, Just wondering what you mean by “Developing REST APIs custom in SICF doesn’t scale”? Why is that? Doesn’t GW use ICF as well…

          • Hi Jason, when I meant ‘scale’, I wasn’t referring to it in a technical ICF sense.  I was more rather referring to the fact that, whatever approach the vendor provides I assume will proliferate more throughout the ecosystem and will be what consumption developers will ultimately choose to develop for.  So yes, you could build a custom REST API at your customer side, and build a cool front-end which consumes it.  But your opportunity there is limited to one customer.  How do you then package this up and distribute to the entire SAP ecosystem and get consumption developers globally to build UIs that consume using your custom API?  Note sure if that makes sense, but it is what I mean’t by saying the custom approach doesn’t scale (unless code exchange approaches proliferate … such as ADL, but that is another discussion).



          • Cool. You could package the abap component as an abap add-on as some vendors already do… But I know what you’re saying. 

          • …the other thing is that building from scratch is actually not a trivial exercise in design, build, refactoring, etc. with several iterations and a decent learning curve. Sure, there are quite a few developers in the ecosystem who are more than capable (and willing) to do this, but most probably not enough for all ~150,000+ SAP customers, or even for the few thousand who have a need for this sort of thing and don’t just run SAP for FI/CO 😉

            So I guess relying exclusively on developer skill won’t scale to SAP’s massive customer base. Enter Gateway, a framework which has already made many decisions for developers.

    • Hi Chris,

      First, like the others I’d like to thank you for adding to the conversation. It’s good to have a real supporter of Gateway in amongst so many sceptics.

      I’d beg to differ with you on a couple of the points that you raise.

      Just because something has been designed not to do something is not an excuse for it not doing it if this will add benefit to the users of the solution. Would it be nice if Gateway could consume SOAP natively? I think yes – and it might allow it to take advantage of work that had previously be done with SOA and ESBs and expose that using OData. I understand that the solution wasn’t designed to do this – but it would be nice. Especially when considering the standalone solution, this make some real sense to me. I find “fault” with my landline phone because it doesn’t allow me to see a picture of the person I am talking to – it was never designed to do this – yet I now use Skype to do this. Hopefully we will not have to change over to the SAP integration version of Skype just because the standard product won’t let me do the things I want it to do in the future. I hope that people will continually find fault with the solution and therefore continually strive to improve it.

      Secondly, I think grumbling actually does make a difference. Perhaps you’d be surprised at how many people at SAP listen to that grumbling and are committed to working with it. Take for example the recent HANA dev licences – if you think that grumbling had nothing to do with it, we’d have something else to disagree on 😉

      And finally and I’m addressing a particular bugbear of my own that many don’t agree with – so feel free to join them! I think the use of the term REST when associated with Gateway/OData has been abused. There are very few BAPIs that could be cobbled into a REST API, to claim that one could produce a RESTful API without writing a line of code is perhaps stretching the definition of REST more than I would like. I often feel that REST has been taken to mean HTTP based API rather than the definition given to it by its creator ( If you are actually going to design a resource based, stateless API, then you will struggle with BAPIs – as most of these have been built with the SOAP SOA model in mind rather than the ROA model. Taking it further, some of the constructs in OData would seem to defy the whole resource based model – specifically the use of POST to batch up multiple resource operations either seems to be not very resource centric or not very stateless, depending on how I look at it.

      Thanks for motivating me to write something – and in turn question/justify how I feel about these things.



      • Hi Chris

        I think the reason that SAP has not offered a SOAP -> OData interface is because there is only a partial functional overlap between them.  It is certainly not possible to have a neat, bijective mapping between a SOAP message and an OData message.  Consequently, in order to accurately map a SOAP message to an OData message would require alot of manual intervention; which, in my opinion, would significantly detract from the benefit of having the interface in the first place.

        Nonetheless, if you feel motivated to write such a translation layer, go for it!  🙂

        I’m sure there would be many interested parties willing to help you if such a project were placed on Code Exchange.  (Just be prepared to solve some hard problems).

        Just for your information. about 7 years ago, an internal project was started to try and find a tool that could automatically translate standard ABAP Dynpros into Web Dynpro ABAP components and views.  Some very smart guys worked on this project, but it was eventually abandoned as there were too many discrepancies between the two interface architectures.  I venture to say that a SOAP -> OData conversion layer would be heading down a similar path.

        I dare say that grumbling about a high visibility product like HANA will be taken seriously and that adjustments will be made in response to these complaints.  However, since Gateway is not so much of a “flagship product” as HANA, alot more grumbling might be required before fundamental changes are made concerning the licensing/charging model.  That said, please feel free to grumble!  I’m certainly not saying that charging for Gateway usage makes sense – I’m just saying we are where we are, and that the current state of affairs is beyond my ability to explain…

        I completely agree that BAPIs are rarely going to make good candidates for being offered as RESTful services.  But please remember that a BAPI is by no means the only unit of functionality that can be exposed as a Gateway service.  During the GW100 training course, I am at pains to repeat the statement that a Gateway service is only designed for Business 2 Consumer or Business 2 Employee interfaces (ask Fred Verheul for confirmation of this – he’s on my GW100 course this week in Holland).  This immediately makes 98% of BAPIs unsuitable for direct exposure through the Gateway interface, simply because they are designed to provide a Business 2 Business interface.

        A BAPI should only be wrapped as a Gateway service if you can successfully expose only those fields that are:

        a) Meaning and relevant to the end user

        b) Sufficient to drive the data input requirements of the BAPI

        c) Do not require subsequent client requests to complete the business process

        In fact, the more the students on GW100 see the flexibility that can be achieved through a custom developed Gateway service, the less likely they are to want to the generator tool.  This is not to say that the generator tool is bad – its just that its restricted in the range of functionality it can generate compared to a custom written service.

        If you use the custom built approach, it is not difficult to build a fully RESTful interface – just make sure that you’re not making a dumb wrapper around a BAPI.


        Chris W

        • Chris Whealy wrote:

          In fact, the more the students on GW100 see the flexibility that can be achieved through a custom developed Gateway service, the less likely they are to want to the generator tool.  This is not to say that the generator tool is bad – its just that its restricted in the range of functionality it can generate compared to a custom written service.

          If you use the custom built approach, it is not difficult to build a fully RESTful interface – just make sure that you’re not making a dumb wrapper around a BAPI.


          Hooray! 🙂 I am very glad that the messaging shifted away from the BDC and (to a lesser? extent) BAPI driven Gateway services after the release of SP2, or was it 3? I totally agree with you that the vast majority of BAPIs don’t really fit into the style of interactions which people might call RESTful. And that’s also Chris Paine‘s bugbear.

          I personally see the generation tools in a similar light as the “expose BAPI as web services” features which have been around for a long time. Nice and convenient to quickly hack together something a bit ugly for a PoC, but for real production-ready code you’d want to use the outside-in design approach which the ABAP Proxy framework provides. Good move by SAP to push people towards the model-driven Pure ODC approach.

    • Well might as well join all the other Australians (or based in Australia) commenters (chatty bunch we are).  Here’s my rant (the good, the bad, the ugly)

      Firstly, IW_BEP on back-end and central hub is way to go IMO for most companies that have at least more than a single ERP (especially when considering a network zone model and the ability to consider a Gateway central hub as something existing in a different zone). And yes, with my EA hat on – the product for RESTFul services from SAP is Gateway, and although we can easily develop RESTFul services directly via an ICF node (trivially for some of us I know) – buy over build; is preferred if it fits the requirements fairly well (which it didn’t originally for Sascha). Plus the Gateway folk seem to be releasing new features such as developer tools pretty quickly which we can’t say will hold true for custom solutions for when the experts walk out the door.

      But as much as I would not like to care about licensing (it is very cheap for simple scenarios open to external customers who don’t use it much) – My problem is that it is licensed in a way that will effect the design of the RESTFul services and that needs to be addressed.  If it was licensed by average unique users interacting through Gateway per day/month; then that would be slightly better (or free).  But basing it on number of back-end calls (or similar) means that:

      1. A highly successful app will cost more (maybe that’s good since the bad app costs less);

      2. A disgruntled customer could write a program to hit your Gateway system almost like a Denial of Service just to make you pay because they know how SAP works (remembering this will cost in license and infrastructure costs if not detected);

      3. But fundamentally, my biggest problem is as a developer; license influenced design of complex resources will result in a cheaper license rather than a well structured set of resources. If I have a customer cart and a customer; but wrap that into a single resource – hey my license costs have just been halved!

      BTW – I’m not wanting to get into a philosophical argument over RESTFul either as Gateway is what it is, and provided the sales guys stop selling the BDC/RFC/generation model approach; at least it’s a reasonable solution when you use the oData model approach (disclosure – I am highly experienced in Gateway from a PowerPoint perspective, but have not played directly with SP4 yet – and only with SP3 a little bit – but love the VMWare version).

      Guess I better stop ranting.

      Actually what would be good is for some major players to start advertising what they’ve gone live with in terms of Gateway (with full disclosure around licensing for a change) so that we know it really does what the sticker says it does (which in the old days – included the price).

      Okay – Now I’ll stop.

      • Hi Matt

        And the Aussies call the Poms a bunch of whingers!  🙂

        As you said, the Gateway devs are producing new tools to support Gateway development at a rapid rate.  We are currently on SP4 of Gateway 2.0.  In this version of the GW you can start to use the new Gateway Service Builder (txn SEGW).  This tool replaces the use of SE80 as the dev environment for custom built Gateway services.  In SP4 it only has basic development features, but by the time SP5 is released (end of August 2012 – if all goes according to plan), it will be a fully useful tool for all aspects of Gateway Service development.

        I am not trying to justify the current licensing model for Gateway, I’m just say that it is what it is – be it right or wrong (or some shade in between).  You non-SAP folks should take up a collective gripe if you want this to change.  This not a discussion in which I can get involved.


        Chris W

        • Hi Chris,

          I was really replying to the group and SAP in general, and definitely wouldn’t expect you to tackle the licensing model problem.  That said, as everyone else said, great to see someone from SAP at least tackling these questions to a degree rather than ignoring them.

          Looking forward to working with SP5 but hopefully they don’t try to sell this as a non-developer tool as good design is still really important to utilise Gateway effectively, and not as if it was some kind of .NET Connector or jCo connector 😉

          And my prediction is the license model will change; and it will just take time hence for now; let’s get some real live production scenarios happening (with some help from SAP)!



    • Hi Chris,

      First of all thank you for taking the time to write a very detailed and reasoned response. Even if we don’t agree on everything, I really do value the discussion, and I believe others do as well. It’s great to see someone who is as close to the product and its thinking behind it, go through the effort of penning a response.

      I’ll try to explain my thinking a little more behind each of the points you have called out; I hope it helps, even if that is by making my ignorances clearly visible 😉 The order of the points is a little topsy-turvy, but here goes:

      Regarding your Point #3

      I know the REST architectural style is not concerned with efficient communication, and that efficiency is in fact readily sacrificed at the altar of compliance with the universal interface presented by HTTP.

      Despite this, increased efficiency is often a happy coincidence of building an API along REST principles. Not always or even most of the time, but I’d venture that this usually holds for simple “get me some data” type interactions which are the most common ones in terms of volume in my opinion. Most end user-facing apps I can think of fetch more information from a server than they push to it, so the innate cacheability of GET requests is a big bonus. I couldn’t find any stats on this to be back me up, but did come across this break-down of HTTP requests to a large CouchDB system (A RESTful JSON API is its native DB interface), which showed that GET outnumbered PUT + POST by a factor of 35:1.

      Having a super-lean, cacheable and bandwidth-efficient REST API is of little value in my books if its backend implementation is crazily slow – e.g. by making serial roundtrips to various (non-cacheable!) SOAP endpoints, discarding 95% of the bytes in the responses and fitting what remains into a lean JSON format. Sure, it’ll be lean on the wire between the consumer at the REST API host, but efficient this is not.

      This comes back to your Point #2: I’m not a big fan of “lipstick on the SOAP” patterns like these, and agree Gateway was neither designed for this, nor does it particularly well (the MOC stuff Jeff pointed out excepted). This section was partly in response to several members of the community expressing their desire for exactly this functionality – and I wanted to point out that this might not be the best idea. Didn’t make that really clear though, did I?…

      However, let’s say that I wanted this anyway because I’m more concerned with network performance between my API server and a mobile user in central Africa, than I am about wasting a bunch of CPU cycles in my data centre. Since Gateway wasn’t designed for orchestrating multiple SOAP services into a single OData one, I’ll use Apigee/Vordel/Layer7/Mashery instead as this stuff is (part of) their bread and butter. Those products are also far more capable reverse proxies for APIs, with SLA reporting, quota enforcement, payload inspection for nasty stuff, etc. etc.

      Since I’m in Enterprise IT land, I always strive for the “1 system to rule them [use cases] all”, so this would become my single API gateway through which all API requests must flow. Since many organisations are falling over themselves provisioning APIs, and many APIs will need data from non-SAP systems, this is bound to happen.

      However, now I’ve neatly cut out any security benefits which I may have obtained by having a separate “hub” Gateway system. Again, this further reduced in my mind the value of the “hub by default” deployment model.

      Regarding Point #4

      I am directly contradicting SAP’s recommendation for a central “hub” Gateway system by default, because I simply cannot see how the cost  of another dev/test/volume test/prod ABAP landscape “only” for Gateway could justify the potential benefits of such an architecture for any but the very largest of SAP customers. Sure, no argument if you have 40 ECC systems scattered around the globe, but very few customers have that.

      I work for one of the biggest SAP shops in Australia; we run ERP, CRM, SCM, SRM, BW, PI, EP, and a whole bunch of ‘peripheral’ stuff, and in my opinion even such a landscape wouldn’t justify a separate Gateway landscape for cost reasons. This kind of comes back to your Point #1 – in my books Gateway simply isn’t complex or resource hungry enough that it couldn’t easily be run on the backend systems without impacting their performance.

      This also introduces a single point of failure which could take down all your APIs. Since Gateway is largely stateless, that can fortunately be mitigated against using standard HA procedures, but this adds yet more cost and complexity…

      And lastly, taking the 40,000ft perspective, I don’t expose all SOAP web services out of PI and have it make RFC calls into the various backends… Why would I apply that pattern to Gateway?

      Regarding Points #5 and #6

      You are correct that I don’t make that distinction, and to be honest it’s largely because I am (currently) largely ignorant of the impact of this distinction. It’s something I need to read up on more.

      Since this whole comment thread is already long enough, I won’t go into SUP very much other than stating my belief that access to backend data and functionality is a significant part of SUP’s value proposition for most mobile use cases (i.e. ones which don’t involve local persistence of transactional data other than caches). And since Gateway does that a lot better than SUP, it reduces the value proposition of SUP for a lot of mobile use cases. Don’t get me wrong, I’m not saying all, but maybe ~50%? – does SUP really add value to a mobile timesheet approval app whose simple UI and lack of local data storage means it could more easily be deployed as a mobile web app talking to a Gateway API, than via SUP?


      Some things really are easier in XML than JSON 😛


      • Hi Sascha

        Although I don’t have any hard an fast stats to back up my hunch, I’d venture to say that the ratio of GET:POST/PUT requests you’ve seen for CouchDB will be similar for Gateway based solutions.

        Of course the backend implementation must be as efficient as possible.  I regularly point out to the GW100 students that if they want to write a custom Gateway service that executes in a hub server, then they should be very careful when making RFC calls (particularly BAPI calls) into the backend server.

        BAPIs tend to have large and complex interfaces that send far more information than is actually needed by the client app.  Therefore, all RFC calls made from a Gateway Hub to a backend should also be as lean as possible.  Otherwise, you end up creating a Gateway service with a lean client interface, but a bloatware backend interface.

        As an aside, as far as over-the-wire data volumes are concerned, on average, an OData message transmitted in JSON format will be 2.5 times smaller than the same message sent as XML.

        However, you should be aware here that there is no standardised representation of an Atom message in JSON format.  Therefore, if you are mapping OData properties to Atom properties (e.g. by using the set_as_title() or set_as_author() methods in the DEFINE method of your Model Provider class), then the mapped OData properties will be missing in the JSON representation of the message.

        As for the value proposition of SUP – this is a thorny question!

        For situations in which offline scenarios are needed, the use of SUP makes good sense.  Even there however, there are alternative solutions that could be implemented.  For instance, one of our Gateway ramp-up customers wrote a very nice iPad app that communicates directly with the Gateway server (via a reverse proxy) over a 3G network.  This client app can work quite happily in an online or offline mode because the developers built that functionality themselves.

        Also, you should bear in mind that the current state of play with SUP and Gateway is that SUP acts only as an HTTP proxy for OData communication (with some authentication capability).

        So to address your question of “Does SUP really add value to a mobile timesheet approval app…”, I think you’d need to evaluate more than simply the functionality of the client app.  You should also consider additional factors such as app onboarding, user management/authentication and client device management (e.g. Afaria).

        All things considered concerning Gateway installation options, I’ll have a pow-wow with the Solution Managers in WDF concerning the way in which this topic has been handled.

        Personally, I think we’ll have to position the “preferred” installation option based on the size of the customer’s system landscape; where the preference will vary based on system landscape size/complexity.

        To continue with the astronomy analogy, if your system landscape looks like a photo from the Hubble Space Telescope, then you will prefer a different installation approach than if your system landscape looks like a photo of the sun…

        I’ll have to get back to everyone on this…


        Chris W

        • Hi Chris,

          +1 on just about everything. It also sounds like you’re taking a great angle on GW100 – would be lovely if there was a version of this course in Australia at some time in the near future! Thank you for the great exchange of thoughts, and am always happy to help in any way I can.


          • Hi Sascha

            I’d love to take a trip Down Under again to run the course.  The only thing is, its a very long way to travel just to give a 3 day course.  So, I guess I’ll have to add at least week’s consultancy to the trip.

            Any openings?


            Chris W

          • There is a GW100 course scheduled in Melbourne later this month…. Is this a different course to the GW100 Chris is saying he’s just written? Its obviously not the same trainer.  😉

            I worry that the Melbourne one would be given by someone that has just come off the course themselves.

          • I’ve missed these threads and rather spellbound at its length and nature. Excellent.

            Thanks for your concern over the proposed GW100 in Melbourne.  I will be teaching this course in conjunction with SUP530 course covering SUP ODP online application development. 

            Chris, Jeff and myself are part of the same team (Customer Solution Adoption) and have been working extremely close with development providing your feedback in each iteration of the product.   We as a group have been involved with each project globally since its official release and have published many how to guides , Tech-ed sessions etc.  Given the very theoretical conversations posted in these threads I think is safe to assume my knowledge of Gateway will be more than sufficient. 

            I am based in Melbourne and interested in working with any customers thinking about Gateway.   If this is an agenda item at the Australian User Group then I will get involved to articulate gateway capabilities based on real experience.  JMOY – This would be a great opportunity to partner if you have a slot already booked. 



          • This is good to here Andrew. Unfortunately I can’t make this June course (someone rudely put a go-live at the end of june) but would like to do it later in the year if one is scheduled.

          • No problems.  Stay in touch as it is the community that can drive Education to schedule it again shortly.  My reply was a bit tongue in cheek so take it like Anthony’s comment below.

            Typically throughout the year we rollout numerous topic specific webinars so if there is demand I’m happy to run these in the local timezone and do Q&A.  I know they are not face to face but if there is something we can provide clarity around then there is nothing stopping us from doing it. 

            SAP Customer Solution Adoption Know-How


          • Hi Andy,

            good to hear that you’ll be teaching that course – I know the attendees will be in good hands for sure. Unfortunately I won’t be in a position to attend this one in June but would be interested in a course a little later on, maybe in late 2012/early 2013…

            (Andy helped us install and explore Gateway 1.0 as part of a customer validation exercise, so he sure knows what he’s doing).


          • Hi Andrew, thanks for the offer to partner on my presentation.  I’ll ping you next week and we can discuss options.  This year the event is co-hosted with the SAP World Tour so it is possible there might also be an SAP presentation planned for Gateway already.  Either way, as you know I’m always happy to collaborate.

            And great to see yet another Aussie enter into the discussions.



          • Hi John,

            No problem.  It will be great to have a chat.  We will have involvement via our Solution Management and Product Management Teams I’m sure.  We will take this offline.

            In regard to this topic I’m of the opinion SAP NetWeaver Gateway offers a flexible architecture which meets the needs of a customer subject to their own preferences around deployment and development.  With the exception of the abstracted theoretical discussion on REST this debate is similar to what we saw with PI and federation topics given the usual variables of security, TCO, performance, administration etc etc etc.  A customer needs to understand their priorities and deploy an architecture to meet it.

            The latest features and roadmap represent a significant step in capability in my opinion going beyond what a developer could realistically scale and maintain within the parameters of a normal implementation.  As an example in SP4 if you look at monitoring, tracing and error diagnostics there are really powerful tools available beyond application logs and ST22 dump analysis. You can forward navigate, jump into code where an error occurred, save payloads, provide reprocessing capabilities, system traversal, inbuilt REST client and save test cases for possible unit testing etc.  Just to name a few improvements.

            I tend stay out of the licensing discussions due to the nature of IT and the fact it changes so very quickly.  I personally concentrate on creating SDN content that articulates real capabilities to accelerate developers and increase adoption.

            Speak soon JM :-),


  • Hi All,

    I just wanted to point out that when Sascha wrote this his statement “However, it doesn’t provide any tools for building OData representations by composing or re-composing existing data from multiple systems” was true at the time…but as of SP4 this is no longer the case.

    Please have a look a the Multiple Origin Composition in the SP4 help documentation:


    • Great point Jeff, and the only thing I was going to chime in with…

      I love reading these high energy conversations in response to a great blog; to me it is such a direct indicator of how good and relevant a blog is.  Here I think it’s more of a case of something written 5 months ago based on what was known and being experienced then.  5 months is a long time for any technology let alone a new product trying to find its feet.

      I would love to see Gateway continue to evolve into something that justifies its current pricing model*, or if we are going to put a ceiling on what it is as an offering (what it can and cannot do and support) then it’s pricing model should reflect this….. and be about free in my opinion. <- please don’t take this as whinging… just an opinion from someone that has tried to justify to people why to spend their money on something where you can offer the same result for no increase in ongoing SAP fees.

      I could try the “It is what it is” line with the next CIO I talk to but I think I know the general response.



      *note: I’m not interested in whether people think it is or isn’t worth extra money, the very fact that it’s a continued topic of conversation means that it is not and has not been justified.

      • Thanks Anthony!

        As for pricing, I avoid that topic like the plague! 😉

        As for Gateway and the technology, I really like it…especially now that it supports JSON which shrinks payload by ~2.5X. This has ripple affects on both server and client…server is faster because the document it builds is smaller…client is faster because it doesn’t have to parse a giant XML document. Anyway, this technology is something that is much needed out there…and I have to believe that the pricing/demand will work its way out…we’ll see.


    • Hi Jeff,

      thank you very much for the info, and the link to the Help on this feature.

      It seems that this MOC feature only works when the backend services being called have identical signatures, e.g. a “find customer by name” service available on multiple ECC systems, each with its own data, could be combined into a single response by the Gateway Hub system whereby each result in annotated with the system it was sourced from? This is of course a nice feature for customers with different SAP systems globally as it allows API consumers to remain completely unaware of their architecture.

      I guess this won’t help with deploying a single Gateway service which funds customers across several ECC systems and maybe Salesforce or Sales OnDemand, as those systems won’t all implement the same interface? But then again, that’s not what I presume Gateway was designed for – to be a competitor to Apigee, Vordel or Mashery… Or am I on the wrong path here?

      Thank you for your response! Happy to continue the conversation of course.


      • Hi Sascha,

        yes, the OData signature would need to be the same…but that said, I would tink you could create a generic Signature for such a Customer odata entity no matter what the backend. Of course the internal implementation would be a bit different for SAP systems (RFC calls must likely or direct selects) vs. Salesforce systems (WS calls)…but technically it would certainly be possible.

        Another nice feature somewhat related to MOC is that you can do role based routing…so customers with large landscapes can direct some users to system in EMEA and other users to a system in North America based on assigned roles.

        Nice blog Sascha…cool that it is regained life 5 months later! 🙂


  • Hi Sascha,

      I’m on openSAP’s mobile course and your blog post is now really helpful in understanding options for someone like me who is an ABAP developer looking for ways to integrate our ERP background to mobile apps.

      Thank you for the effort.

    Best regards,

    • Thanks for the nice feedback Douglas!

      I can also recommend the newer blog by Andre Fischer on this topic. He also points out that as of 7.40, GW is part of the standard install so you effectively are nudged into the “distributed” deployment. (IMHO this is the better approach anyhow)


  • Hi All,

    Nice discussion.

    I believe that ‘Truth’ is always ‘in-between’, whenever there is an argument.

    NW Gateway is not a single software component and it can be logically seen as two different pieces. 1. Backend Enablement Part (also know as BEP) 2. Hub Part

    The first part gives a development environment and tools to ‘create’ a OData service but not to ‘expose’ it to the outside world.

    As per me this part is good to be with the ECC/backend thus making available all the backend objects accessible (Ex: Classes). Putting this part on a different system would make us dependent on RFCs alone.

    The second part/Hub part exposes the Services catalog and also can support multi origin services.  

    This part better sit in a separate box acting as a single ‘gateway’ for OData services, allowing better control. Also it makes sense to have a single services catalog for an enterprise.

    best regards!


  • Hi Sascha,

    exellent blog.

    I have just awoken this one and John Appleby ‘s  similar blog question.

    We’re a year down the line now, has anything changed, any lessons as this product matures.

    Shall we treat it like an Integrated ITS or like a Central Portal ?

    I’ve put the same question point on John’s blog and hopefully as they are so intertwined readers will be reading both blogs.

    For the sake of completeness it will be best if we choose one of the two blogs as the one to continue the conversation, I leave that decision to the first responder.

    Kind regards,


  • Thanks for the blog. If one decided to go with the NW GW standalone approach, is one GW enough to support let’s say Fiori for a user-base of 3000? Is there anyone that clustered more than one NW GW for load balancing?