Skip to Content
Author's profile photo Graham Robinson

Thoughts on NetWeaver Gateway

After a recent SAP Mentor webinar with the Gateway team (which I did not attend so had to listen to the replay) I tweeted “Replay of #SAPMentors Gateway webinar did nothing to convince me to jump on board”.

Well, as usual, the Mentors called me out on this pretty quickly. Vijay and Jon requested a blog and others reached out in other ways to get my thoughts. So here we go.

Firstly let me go over old ground. You might also like to view the JD-OD.COM interview I did with Dennis at SAP TechEd that covers much of this.

As I, and many others, have been saying consistently for about a year I think that SAP’s strategy to charge for pieces of the technology stack is flawed. SAP has built its software business by selling applications and bundling in the technology platform that the applications run on. i.e. When you buy ERP you get NetWeaver included. This is a pretty easy to explain and justify. It is the applications that provide the business benefits so that is what SAP charge for.

Recently SAP have added a couple of components to their technology stack. The Sybase acquisition gave them access to SUP and they have developed SAP NetWeaver Gateway “a technology that provides a simple way to connect devices, environments and platforms to SAP software based on market standards“. SAPs stated intention is to charge a license fee for both these technology pieces – although your guess is as good as mine as to what that will be. (Snide side comment – Perhaps the reason that SAP can’t name a price is that they have no idea what the value is?) For NetWeaver Gateway I heard two different pricing models mentioned by SAP representatives at SAP TechEd. One was to charge by data volume and the other by number of service calls.

As an independent developer I expect that I am just the sort of person SAP should be courting with these products. Independent Developers and ISVs will build the “hundreds of partner apps” that they keep referring to whenever someone asks them for a list of currently available mobile applications. So, maybe naively, I expect SAP would want me to vote with my feet (or at least my code) and start building apps for both the Unwired Platform and NetWeaver Gateway. (Side note – I still don’t know if SUP means SAP Unwired Platform or Sybase Unwired Platform so I am using more generic terms)

So let’s say I come up with my own killer app. It is an all-singing all-dancing mobile application that will provide huge business benefit to lots of SAP customers. In fact it is so good I can sell the idea to my favourite customers (those that trust me) with a business case that they will jump at. So I have the idea, I have the funding and foundation customer commitment – I am ready to go. So time to decide what technology I should use to build my application with. Let me focus on NetWeaver Gateway but I think similar arguments apply to the Somesortof Unwired Platform.

SAP collateral tells us that NetWeaver Gateway “offers connectivity to SAP applications using any programming language or model without the need for SAP knowledge by leveraging REST services and OData/ATOM protocols“. Without drilling down too much on the semantics of this statement I don’t see NetWeaver Gateway as that at all. I see NetWeaver Gateway as a programmer productivity tool. It provides a method for exposing SAP functionality using those standards mentioned – but we ABAP developers have been able to do that for years. Some of us have even built frameworks of varying sophistication to do things like expose backend functionality as REST services, parse SAP data structures into JSON or OData or XML or anything else we fancy. Some of these frameworks have been shared with the community via SDN and Code Exchange. I am not saying I am not interested in a toolset and/or framework from SAP that does this sort of thing as well, I am. But really the value proposition is that NetWeaver Gateway will save me development time on the backend in publishing the services I want to consume in my application.

BTW – I do not believe NetWeaver Gateway saves me any time developing the front end application despite all the great “app in a minute” demos we have seen. Whether I use NetWeaver Gateway to expose services or I handcraft my own as long as I conform to industry accepted standards the front end development tool should be able to introspect and the runtime consume these services identically.

So back to my killer app. Why should I take the funds my customer has committed to my app and pass some of them onto SAP? Even assuming I could get a straight answer from SAP on what the price would be – why should I do it unless the benefits outweigh the costs? How can a recurring pricing model on a piece of technology be weighed up against the value of saving me development time on a project I already have approval for? And why should I just let dollars go to SAP for my idea? And by the way my customers’ employees (the target audience for my killer app) are already licensed to use SAP anyway. Why should they pay again? (I have a few other objections as well but you get the idea.)

Returning briefly to the Sublime Unwired Platform – how do I justify the cost (albeit unqualified) of this platform against the benefits of my single, albeit killer, app? I can’t. And even if I could why would I confuse my customer with extra technology and extra licensing when I don’t need to? I wouldn’t.

So that’s the old ground. Sorry for taking so much space as I know you have all heard that before.

But the real problem has nothing to do with NetWeaver Gateway or the Someothername Unwired Platform.

The real problem is that SAP are struggling to find a way to monetise the millions, probably billions, of users they envisage connecting to their customers’ SAP systems via the internet. These will be their customers’ customers, their customers’ suppliers, their customers’ prospects, Joe Average searching for the cheapest widget. Basically it could be everyone in the world with a smart phone.

This is a new-ish problem, but I am sure SAP looked for old business models to learn from. I suspect the business model they took on board is that of the utility companies. IDEA! Let’s put a meter on the edge of the SAP landscape and charge for use just like the electricity, gas and water meters on the edge of everyones property. (In case I wasn’t obvious enough – SAP NetWeaver Gateway is the meter) Kar-ching! Brilliant!

And this brings up another worry for me. I am concerned that SAPs interest in the success of their meter will lead them to make it the centrepiece of every new development. So no matter what the problem the answer will include NetWeaver Gateway and/or the Super Unwired Platform whether or not they are the most suitable technology for the specific solution. In this respect we have been here before – just think of the applications that have been or are being ported from Web Dynpro Java to Web Dynpro ABAP.

As a final note let me add, 1 billion users paying $2 per month equals $24 Billion per year. And that could be for just one app.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jarret Pazahanick
      Jarret Pazahanick
      This is a very good article and I think your points are dead on. It is interesting in the last week two other articles have been written by SAP mentors on the mobility/gateway model. (what are the other 97 mentors waiting for) ๐Ÿ™‚

      Dennis Howlett - "SAP launches free app to universal raspberry"

      Me - "Is SAP Using the Right Mobility Strategy"

      Is SAP Using the Right Mobility Strategy

      Author's profile photo Dennis Howlett
      Dennis Howlett
      @graham - plenty of peeps at SAP understand the problem but I don't see too many understanding the solution. You came to the same number as I did when I spoke with McDermott about SUP, albeit I used different ways to get there.

      And to add fuel to the argument:

      Author's profile photo Fred Verheul
      Fred Verheul
      I really love it, especially the Somewhatunclearnamed Unwired Platform.
      And I couldn't agree more on NetWeaver Gateway being a developer productivity tool, which in my opinion should be part of the NetWeaver license, period.
      Thanks for writing it down once again!


      Author's profile photo Daniel Graversen
      Daniel Graversen
      Hi graham,

      Good job on this, it is never easy to figure out what to do about your SAP system and the licenses for the users.

      I hope that SAP will be able to clearly communicate the license and make it possible to small ISV to help with development.


      Author's profile photo Frank Stรธdle
      Frank Stรธdle
      Great article! As a developer (and early adopter) I am disappointed in learning about this licensing model for Gateway. Much of my excitement about this new tool waned after reading your article. It is hard for me to see why I should go through the hassle of one more piece of middleware with a mysterious pricing model when I can easily create my own little web service passing out JSON or whatever through and ICF node. Or am I actually missing something great about Gateway after all?
      Author's profile photo Stephen Johannes
      Stephen Johannes
      The real question is this going to become link Adobe Forms which probably has a ton of awesome business cases, but never gets widespread customer adoption due to licensing issues.

      I know that's a slightly different case in terms of who made the tools, but I can only imagine the adoption rate if the licensing process was not a barrier.

      Take care,


      Author's profile photo Nigel James
      Nigel James
      I thought SUP stood for Stand Up Paddle which looks a lot more fun than the Somewhat Uncomplicated Platform.

      I agree whole heartedly with your comments. If I develop an app, why would I take half that money and give it to SAP? or alternatively force my client to pay for extra technology.


      Author's profile photo Henrique Pinto
      Henrique Pinto
      I'll try to get my SAP hat off now, if possible at all, and comment on this particular part of the discussion.

      "If I develop an app, why would I take half that money and give it to SAP?"

      Well, that's a similar question to "If I'm a development company, why should I become an official SAP partner instead of being an independent firm?". There are spaces for both. If you think your business would benefit on being an official SAP partner, because that would bring more customers, visibility, credibility etc., then it makes sense. If  you're a small code shop with a faithful customer base and without any need to grow beyond that, probably it doesn't make any sense.

      Similarly, if you want to develop an app for a particular customer with a specific business case in place (tailor made), maybe it won't make sense to leverage such a platform. On the other hand, if your idea is to put your app in the SAPp Store (soon to be born) for thousands or potentially million of users to download it, connect to their several different companies' servers and monetize on the volume, it makes total sense to leverage reusable & cross-company standard interfaces such as Gateway REST services.

      Of course, there's still a long way to go. A platform without content is as good as any other (i.e. partners will go for the cheapest one), so Gateway devs know they need to build a comprehensive set of services asap, but it'll come. It's coming already, actually. But anyways, it is possible to leverage Gateway and its benefits for a partner's business. Just because it doesn't match one's particular business model, it doesn't mean it won't fit any.

      Just my 2 cents.

      Author's profile photo Stephen Johannes
      Stephen Johannes
      I feel that this scenario is another repeat of these let's build:
      - IDOC's to interface externally
      - BAPI's to interface externally
      - Web Services to interface externally
      - Enterprise Services to interface externally

      The real problem is that did we ever change the foundation that building the next new interface will be problem.  Nope instead we can do better "screen-scaping", it feels like 1999 all over again to generate services.  Modern models such as BOL aren't even supported.

      Perhaps all these solutions are like a doctor trying to treat the symptoms instead of the disease.  However the good news with the recent announcements about extending maintenance till 2020, I don't think we will cure our problem.

      Take care,


      Author's profile photo Henrique Pinto
      Henrique Pinto
      I'd separate these into categories.

      1) IDOCs & BAPIs -> proprieatary protocols mean no one in the real world will ever consume that. It's just a way to say "we haz API". But they were never practical at all.

      2) Web/Enterprise services (more or less the same) -> Though SAP started to track the right path (of open standards), the whole semantic layer was making it more confusing than simplifying the whole thing. What's the point of an enterprise service with 3000 different fields, when you need 3???

      3) Gateway is the first time SAP has combined open standards + actual simplification of the business (semantic) layer. KISS (keep it simple, stupid) for the first time in our lives. I'm not sure it'll be successful, but it's definitely a shot in a new (and, at least apparently, proper) direction.

      Author's profile photo Sascha Wenninger
      Sascha Wenninger
      Hi Henrique,

      I actually agree with the previous comment by Stephen and really feel that this "Gateway is a game changer" notion is very much overcooking its benefits and impact; in fact I am thinking of writing a blog on this very topic!

      Let me preface this comment by saying that I have only worked with Gateway 1.0 and the generation tools, and have not used the OData channel introduced with 2.0.

      From what I have seen so far though, I cannot see how Gateway will provide anything other than a siloed API with only minimal embrace of the HATEOAS principle which defines REST *unless* it makes significant use of the BOL or its supposed successor (the name escapes me).

      REST APIs are defined through their use of hyperlinks to guide consumers on how to drive the API. If you don't have those, you're not doing REST.

      While it's certainly possible to insert links into Gateway representations using the OData channel, I have not seen how this can be done in a standardised way without effectively hard-coding the URLs used in those links. This means it's a lot of effort and they will break easily. Also, because Gateway services have 'magic' (speak system-generated) URLs, it's dangerous and/or brittle for me to predict what they're going to be in my code as this means predicting what a framework I have no control over is going to do.

      (And yes, Gateway does provide links via the generation tools but they are just going 'down' into more detail rather than 'across' to other resources and are thus of limited use).

      Unless SAP roll out a "protocol state machine" or "semantic model" (neither term is a 100% fit) which describes which state transitions are possible between objects of the BOR/BOL under which conditions, and layers interaction and rendering mechanisms on top of this, Gateway is just another siloed API builder tool like the web services runtime, and like Graham I see little hard value in it.

      What I want is a model which describes how I can get from one resource to another. If I have an invoice, how can I see the customer it's for? How can I find out more about the materials shown in the line items? How do I find a related payment advice? These links are what makes for a rich API and I would like something better than hard-coding URL templates!

      Unless this is there, I'm afraid Gateway cannot be called radically different to what's been there before.



      Author's profile photo Ralf Handl
      Ralf Handl
      Hi Sascha,

      OData channel allows you to describe your model in the DEFINE method of your model provider class, so you can easily pull it from a metadata repository of your choice. If that model contains associations and navigation properties, you'll find the corresponding links in your resource representations. Just use the URLs in the href attribute of the  elements, no need to guess/predict/construct them.

      This doesn't give you HATEOAS yet, but there are discussions in that direction, see


      Author's profile photo Stephen Johannes
      Stephen Johannes
      An interesting comment that during a presentation I attended on gateway, the concept of modeling Gateway services from the BOL/BOF objects was not even a current consideration.

      I asked about this during the presentation and the awesome guys presenting, said they had not thought about that yet.  I mentioned that for current applications like CRM, being able to model from BOL objects is a must.  I probably need to followup(idea place) on a feature request to gatweay.  However without a unified BOL like layer to hide all the mess of the suite, it looks like everyone is going to be re-inventing the wheel for each particular need instead of using a "library".

      Take care,


      Author's profile photo Chris Paine
      Chris Paine
      Some great and nicely put points there.
      I think that it is clear (perhaps to me) that there is a problem with Gateway when it comes to licensing existing ESS type users for which a client already has a licence - the use in this case should be (IMNSHO) free or a single charge (not per app or user) for the Gateway stack in your environment.

      For non-licensed users there is the problem on how to capture this info and charge appropriately. Perhaps Gateway will make this easier - I'm not sure how - and I can even see some pretty ugly solution designs coming out in order to minimise licensing costs. In much the same way as I've seen SOA services that do everything because an architect somewhere has put a restriction on the number of allowed services, I'd expect a bastardisation of RESTful design if having multiple resources means a higher licence cost.

      Now to add a few additional thoughts of my own.
      Market standards - OData doesn't really have much of an adoption outside of Microsoft (surprise, surprise as it is an MS standard). Even where it has been used elsewhere (Ebay for example) the opinions I have read have been that this is just to enable MS product ease of interface - not because this is a good way to expose data. There are alternate W3C standards like OWL, RDF that could be used (refer to the whole linked data discussion). SAP had to build Gateway to make Duet Enterprise work, claiming that it was designed to be SAP's standards based web interaction tooling either points at architects in SAP who don't pay enough attention to the world outside SAP (this I do not believe, I know some of the people at SAP, they are well read, clever people) or that SAP saw a way to capitalise on development already completed and extend it to a larger market. After all if you've already built something then why not reuse it. But please don't tell me that you intended to build this as a best practice solution.
      REST - not really - look at the OData FAQ - it's interesting to read:
      "OData follows many of the principles of REST."
      NB not _all_ the principles, just many.

      On the other hand, I can only think that if SAP persists in confusing us on Gateway then it is going to keep those of us who know how to develop and build an ICF based RESTful solution much busier in the next few years.

      Btw - first blog I read after a month away on holiday - hope the rest I read live up to this quality! ๐Ÿ˜‰
      Cheers, Chris

      Author's profile photo Nigel James
      Nigel James
      you make good points Chris ... just to add that some of googles interfaces are built on atom and atompub which is what odata is built on.


      Author's profile photo Sascha Wenninger
      Sascha Wenninger
      Hi Chris,

      great comment! And thanks Graham for kicking off a good discussion so far.

      From what I learned at TechEd - specifically the lounges and pods - I understand that the "reuse something we already have" argument definitely came into it although I cannot say how strongly.

      The fact that Gateway technical objects and transactions start with /IWFND for "Information Worked Foundation", and that the Information Worker team in SAP also had a leading hand in Duet Enterprise, I dare say someone decided to leverage existing development. So that explains why we have OData as the first format out of the gate.

      However your "Please don't tell me that you intended to build this as a best practice solution." comment still very much applies.

      I would have less of a problem with the current "OData or the highway" approach if there was a well-defined approach to bypassing certain layers in Gateway. However OData seems to be getting baked right into the product portfolio by top-down mandate...

      I understand SAP customers want apps and out-of-the-box integration, as well as the short-term convenience (and long term PITA) of statically binding brittle proxy code to interface contracts based on strict metadata, and I guess OData does that about as well as XML Schema. So if that sort of stuff floats your boat, then great, knock yourself out.

      However SAP should recognise that not everybody will want to go down that path. Many people will look upon OData as yet another proprietary interface mechanism pushed by SAP (and who else?). I know some of the long-haired Java devs I work with on some REST-enabled UIs have either never even heard of it, or wouldn't go near 'proprietary frameworks' like those OData libraries so conveniently provided by MS.

      A layered architecture would imply that there are well-defined ways around these higher-level features to help those of us who want to do things better/leaner/more JSONy... So where is it? This picks up on Alisdair's thinking as well, so I'll let him blog/comment about that further.

      So, I guess all I'm really trying to say is +1 to Graham and all of the insightful comments he's inspired. I'll get off my soapbox now and go home :-).


      Author's profile photo Ralf Handl
      Ralf Handl
      OData is the first protocol (it's actually more than just a format) for Gateway because it's a very good fit for our lightweight consumption scenarios (which include mobile). I've described some of the reasons in [original link is broken] [original link is broken] [original link is broken]

      One of the reasons is that it offers metadata describing the contract of each concrete service. Which you can use to generate brittle proxies, or which you can dynamically interpret at run-time in generic clients.


      Author's profile photo Former Member
      Former Member
      1. Licensing for internal users to access SAP makes no sense since they are already a fully licensed self-service user most likely.
      2. Enterprises always have a buy over build and configure over customise mentality - the reason that we don't see many mobile apps out on the market in my opinion is that Enterprises avoid development even when it's appropriate (blog forthcoming on this topic).
      3. External users do not have a standard license model that typically works so at least Gateway can potentially solve that problem with a cost effective (?) model.  For example, what will your account manager do if you want to connect up internet users to your SAP application via a web service, HTTP handler or Restful ICF interface?  I can guess what the pricing book would say which would not be acceptable to anyone (how many billion named users????)
      4. That said, SAP - give some developers some credit and if they want to count number of interface calls - let them build it into their system directly without Gateway.
      5. NetWeaver gateway could be part of your DMZ after your reverse proxy or a layer between your reverse proxy and application server, so this is still definitely a pro position. - More a large enterprise concern probably though.
      6. Point 5 is possibly the biggest selling point for me when combined with easy to consume service enablement.  Plus with further internet capabilities to support monitoring/management/caching/queuing/etc - may provide significant value.
      6. Gateway should at least help with authentication of users (though haven't played with this).
      7. As you say - SAP appear to have the words oData appearing everywhere (including SUP) so like BPM - we may need to accept this as a part of the solution - but hey - let's talk about licensing some more.

      In summary, I definitely support getting this right - Licenses should never get in the way of good architecture and slowing innovation on SAP.

      Author's profile photo Henrique Pinto
      Henrique Pinto
      I won't comment on the forementioned problems that Gateway licensing model has brought to existing named users. But for the external non-employee users, as you have mentioned, it does officially brings the first actually feasible option SAP has ever come up with to externalize its data.

      In the past, for such a scenario (external 3rd-party app consuming SAP data) you had to either license advanced platform users (with pricing equivalent to actual named users) or submit your 3rd-party app for SAP homologation and, if approved, you could consume SAP data thru standard platform users, which were cheaper but would still financially derail any thousands-user scenario (such as B2C). Any 3rd-party app that made use of SAP data and exposed it to external users, no matter thru which interface (ICF, SOAP, RFCs + JCo etc.), needed to use platform users, or else you'd have an auditing time bomb bound to explode at some point in time.

      Thus, Gateway brings the first financially viable option to be properly licensed in an external SAP data consumption scenario.

      Author's profile photo Chris Paine
      Chris Paine
      Wouldn't it be nice though to have a truly RESTful solution as an option for that properly licensed external application? Building the licensing solution directly into the ICF instead of through Gateway would mean that we would still be free to build true RESTful code and then Gateway could really be just the tool to allow a simple CRUD HTTP interface with SAP rather than mangling the two together for a suboptimal experience? Or perhaps the layer that is OData translation could be removed/replaced and just the licensing layer retained?
      Author's profile photo Henrique Pinto
      Henrique Pinto
      I'm not really an expert to comment on the advantages/disadvantages of OData versus other options. I can just say that I'm pretty sure SAP "won't not have a standard". And it also has learned its lesson that proprietary protocols won't cut it in the long run.
      So they want (more like need) to have an open standard and OData seemed like a good choice by then.

      Just as a comparison though, the other time SAP  chose Microsoft as a development partner (Silverlight as the frontend framework for ByD) it ended disastrously, as MS made it clear they'd redirect their resources into HTML5 instead...

      Author's profile photo John Moy
      John Moy
      Thanks for an excellent blog and it's good to see you get this angst off your chest.
      You raise some very good points.  In particular I agree that there is an un-stated intent of Gateway to act as a licensing meter.  And I agree (as do others in the comments) that this raises interesting questions when exposing services to users who are already fully licensed NetWeaver users.  However, when exposing services to external parties (imagine exposing services to be consumed by your corporation's public iOS app) then it proves one possible solution to the licensing question.  I am no licensing expert, but I would presume that if you bypassed Gateway and coded a custom handler in the ICF but exposed that to external (non-licensed) users, that would attract licensing concerns with SAP.  I would like to share a comment that Alisdair Templeton sent to me which very much accords with my thinking (he gave me permission to post this) ... "Gateway deals with the questions on how to license access to SAP via the ICF...Now imagine that Gateways scope was just licensing, logging, throttling and security concerns, and I could then build any Representations I like (not just ODATA)".

      One thing I think that is POSITIVE in relation to the emergence of Gateway is that customers are finally becoming educated on the possibilities of coupling SAP data and business logic with almost any UI technology.  Of course some developers have known that you could accomplish this in the ICF using custom ABAP HTTP handlers for years.  However if you ask the average ABAP developer to code a custom HTTP handler for you more likely than not they will look blankly at you.  Maybe we need Gateway to 'help' these developers along.  Gateway has elevated the attention of customers to the fact that you can access SAP data and processes with any UI representation (not just SAPGUI, WebDynpro etc), and along with it they are seeing that you can also accomplish this without Gateway (licensing considerations aside).  At TechEd Las Vegas this message came across in more than one session (I counted at least 3).

      One thing that does perplex me about the current release of Gateway is that JSON is not yet supported (in 2.0).  JSON is becoming the new lingua franca of data exchange on the internet. XML is so year 2000.  If Gateway is to promote innovation, I would have liked to see the innovative support for JSON early on.

      Thanks for kicking off a very healthy discussion.

      Author's profile photo Henrique Pinto
      Henrique Pinto
      I've heard from trustable sources that JSON is on the oven for the next major release. Let's hope so!
      Author's profile photo Sascha Wenninger
      Sascha Wenninger
      Yes, but is this the JSON version of OData, or any JSON I want? If the former, it won't be much better than the current OData-XML as it will still be a not-very-widely supported format...
      Author's profile photo Henrique Pinto
      Henrique Pinto
      I'm honestly not sure which version it is, so I won't make any assumption.
      Author's profile photo Former Member
      Former Member
      In regards to oData - while I understand the point about more open standards, provided there are light weight libraries for all UI development platforms; it doesn't really phase me, and having some field labels come through by default could come in handy!  Possibly may limit access to some cool stuff in the future but...
      Author's profile photo Chris Paine
      Chris Paine
      The JSON OData format ( ) - although much more liberal in its representation than the strict XML of AtomPub is still based on the same idea, encompassing some of the media components of AtomPub (author, media types, etc.) Rather than the user being free to define their schema based on the resource being addressed it is still a formatted collection. I can see why MS and Google with a similar solution in GData chose this, but that doesn't mean I have to like it ๐Ÿ˜‰

      I heard 2.1 for JSON , or right now using off the shelf Code Exchange tools not using Gateway or OData at all ๐Ÿ˜‰

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      I think you touch part of the core argument for gateaway when you state:
      "Of course some developers have known that you could accomplish this in the ICF using custom ABAP HTTP handlers for years. However if you ask the average ABAP developer to code a custom HTTP handler for you more likely than not they will look blankly at you."

      From a maintenance point of view in an enterprise (and 80% of all IT costs are in this area), it makes sense to have a uniform way of exposing data from the SAP system. This is one way gateway is more than a productivity increasing tool for developers.

      A strength of Gateway, and a potential weakness, is the structure OData provides to requests and data objects. It is small things as data types, paging (or fetching a limit number of entities at a time), links between entities and queries/filters, that can provide huge benefits in the consumption layer over a custom built API. SAP's extensions with SAPData goes even further with for example the actions object type.

      It is this structure and standardization that allowed me to envision the SAPData Explorer side-project. And hopefully, this may become a generic client in the enterprise for consuming all gateway and OData related services (which include Sharepoint 2010). Preview video of the android tablet solution can be found
      (I'm currently checking out various open-source license possibility and where it is best to continue to drive this project)

      However, all these additional functionalities do come at a price wrt. to complexity, and I would generally recommend some form of OData/SAPData library on the consumption side (JSON might help in this area). Hopefully the complexity and incompatabilities between libraries will be limited or else we might end up in WS-* waters.


      Author's profile photo Former Member
      Former Member
      First of all let me state that I like your style of writing, allthough I think the names you make up for SUP are pretty 'meh'.

      You state that you can not justify the cost of SUP against the benefits of your single app. You are right. You can't and SAP doesn't ask you to.

      The way I see it is that SAP is positioning SUP as the central hub for mobile apps to use for development of apps, data extraction and load balancing. If your idea is hugely succesfull your customer is most definitely moblizing more processes and will use several data sources. The traffic will grow. The number of devices will grow. The diversity of devices will grow. Apps will get more complex and difficult for functional and technical admins to monitor and control. SUP is providing tools for all of this. 

      Second of all, SAP has bought SUP for billions of dollars. The license prices haven't changed. Sybase was charging more or less the same for it's products. SAP enables it's partners to sell the licenses as well.

      Again: I don't know anything particular about Gateway, but I think their can be made good business cases for SUP. We allready did for some customers in The Netherlands.



      Author's profile photo Henrique Pinto
      Henrique Pinto
      I tend to agree that it's hard for a company experimenting mobilization for the first time to see a strong value proposition in SUP (or any other MEAP*, for that matter). These guys are more worried about agility & flexibility than governance & cost control. Even more if you consider that typically each LoB will be pursuing it (mobilization) at their own pace, for their own particular needs - it's hard to centralize these kind of unstructured business-driven decision rounds on an IT-centric approach.

      On the long run, though, it does tend to change, and these once differentiation-driving business scenarios will become commodity, and it'll be up to IT to maintain them. By that time, the companies that have been working on mobilized scenarios for a while will start to look for a platform that allows them to reduce TCO, enforce security policies & still maintain the level of flexibility they have with their tailor-made apps.

      So, in the end, IMHO, companies that have been mobilized for a while are more prone to look for a MEAP* than companies mobilizing for the first  time. Hence, business-wise, mobilization without SUP is even more beneficial for SUP, in the long run.

      *MEAP: Mobile Enterprise Application Platform

      Author's profile photo Chris Paine
      Chris Paine
      Eventually SAP will have to bring SUP (or some sort of mobile device management/deployment solution - or MEAP if you will - anyway) into part of its core offer. With most forecasters predicting the demise of the desktop, the mobile environment will be the main delivery/interaction platform. A solution which at it's core does not support this will have difficulty surviving in the future. I'm pretty sure those at the top level of SAP understand this. The problem is how we get to there and how does this currently external plug-on get there and pay for the huge amount SAP spent on purchasing it?

      It might be part of the future, but our problem is that the ROI on moving there now for most companies is probably only over a longer term than the CIO's contract with the company - and that means we will see a much longer time before we really start to adopt such a solution. Surely a pricing model that took this into account would make more sense and lead to earlier adoption?

      Author's profile photo Henrique Pinto
      Henrique Pinto
      (everything below is pure speculation on my part)

      This is an interesting comment. Even more if you compare the 2010's mobile boom with the 90's web bubble.

      By that time, SAP's challenge was how to bring web based UI into its products. Some 15 years later, SAP (or rather Shai Agassi) comes up with NetWeaver and, embedded in it, WebDynpro.

      I'm not trying to diminish it or anything, but I don't the see the technical challenge now as much different. I mean, the worst part (coming up with a platform) is done - via an acquisition, but it isn't much of a problem. It runs on Java 6 - we have a JEE engine. It's just a matter of time for us to see SUP on SAP JEE (and potentially Unwired Workspace merged with NWDS). It is for sure much easier now then by the time SAP acquired Shai's dad's company - we only had an ABAP platform then, and everything else ran on Java.

      The real challenge - IMHO - is how to make it in 3 to 5 years, instead of 10 to 15. SAP cannot afford to wait up to the 2020's to have mobility integrated into its core platform.

      Author's profile photo Chris Paine
      Chris Paine
      +1 - I speculate very much the same and would hazard a guess that something has to be there when all the current ERP solutions hit end of life in 2015. Pure speculation - but SAP has been surprising me in happy ways recently - I'll keep my fingers crossed!
      Author's profile photo Henrique Pinto
      Henrique Pinto
      Good insight into the 2015 end of maintenance for ERP 6.0. I also think it'll be part of NGAP, together with HANA-native ABAP coding.

      So much to do at the same time - SAP developers sure have a hard yet thrilling time on the next couple of years.

      Author's profile photo Marlo Simon
      Marlo Simon
      Hello Chris and Henrique,

      This really is starting to feels like the early NewtWeaver days...
      Lot's of new things happening and no clear directions just yet.

      On a side note: All Webish/UI experts that I known and follow on the SAP world are in this post. This should mean something!

      Marlo Simon.

      Author's profile photo Henrique Pinto
      Henrique Pinto
      Just to (try to) make myself clear: it's not that I don't think there is value in using SUP upfront for a company's mobilization strategy. As a matter of fact, investing on a MEAP from the start is way cheaper than investing on SDK-based development & the resources to maintain them just to change it all for a MEAP later on, when the maintenance costs are too high to cope with.

      It's just that I'm a bit skeptical on how many companies have that kind of long term vision in order to invest upfront on something that will be cheaper on the long run, instead of investing on something that means a lower cash flow for the first years. I mean, how many companies had SAP as their first-ever ERP??

      Author's profile photo Chris Paine
      Chris Paine
      On could argue that the world has changed a little - companies that previously wouldn't have gone with SAP as their ERP are now going with SaaS solutions instead, and rather than migrating from them to SAP are instead staying there. Perhaps solutions like Capgemini selling SUP as a PaaS to link into your existing SAP ERP solution may overcome this hurdle, but given that Capgemini need to make some money out of offering the solution too, one would doubt it is going to be incredibly attractive - but I don't know the details - perhaps it will be! ๐Ÿ™‚

      I understand your point, and I agree, companies really need to think about the longer term and a MEAP, I'm just not sure it is in SAP's best interest to make people 1) build alternate potentially incorrectly licensed solution 2) wait until they are so mobile based that they have no choice.

      BTW I am really loving the very intelligent and thoughtful comments that are being made on this post - well done Robbo for bringing it up!

      Author's profile photo Jarret Pazahanick
      Jarret Pazahanick
      Very well said Chris that the world is changing and it is important to note that the major SaaS vendors are including mobile for free in their base subscription (and offering free apps) as they feel like you it is going to be the new desktop. Customer will ultimately demand this from SAP or speak with their wallets and leave.  I am hoping they are proactive instead of being reactive.

      As far as the Capgemini I cant see how bundling SAP licensed products and putting their margin on top of that is going to be beneficial for SAP customers.

      On a side note maintenance was extended to 2020 last week as I noticed some 2015 mention in the comment thread. 

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      SUP == Sybase, an SAP company Unwired Platform. With this, you should be on the safe side ๐Ÿ™‚

      - licenses: SAP is doing a great job in preventing adoption of their solutions because of the price.
      - developers: if only SAP would give developers free access to their software. Now we have a (currupted) Gateway download here on SCN, but SUP? Requested it via, and still no feedback. If that's how SAP wants to get developers, well, than it will be without me.
      - Access: Gateway, Sybase, River, Portal, on-demand, etc. Don't know why SAP is putting out X products that do more or less the same.


      Author's profile photo Former Member
      Former Member

      My side note / thoughts as an uneducated customer:

      Author's profile photo Former Member
      Former Member
      ...part of the kernel. My view is that Gateway is a REST/OData adapter and should be included in the kernel, just as SOAP adapter is part of the kernel. I do not see any reason to:

      1. offer it as a separate product
      2. charge any money for it

      Positioning Gateway as a separate product results in complicating an already complex middleware landscape. In the mobile space, SAP has NW MI, Mobile BI, and SUP. Adding Gateway as a separate product is only making things worse, especially since the focus of Gateway is beyond consumption of data.

      At best, an OData adapter in PI should also be made available for customers with versions lower than ERP 6.0. As SAP looks to position PI as an ESB, loosely coupled light weight REST based interfaces should be fine in a mediated SOA landscape.

      As far as licensing SUP is concerned, I believe SUP in PaaS mode is a sensible way to make money from it. Expecting customers wishing to mobilize workforce to invest in MEAP is not the right mindset. SAP did announce plans to offer SUP   PaaS mode. (The implications are significant. Imagine SAP as a mobile infra provider managing millions, if not billions, of mobile devices).

      Also, as Dennis highlighted in his blog at, Capgemini is partnering with SAP to offer SaaS/PaaS based mobility solutions. This shows that:

      1. SAP Partners have the option to host the MEAP themselves and develop targeted mobile apps for their customers on SAP technology

      2. SAP hosted MEAP can be made available to independent developers/smaller ISVs to build apps which SAP then sells in its AppStore.

      Clearly, it will take a while before SAP nails this down. However, the pace of tech innovations is only increasing and LOB SaaS vendors are catching up fast through PaaS based offerings. The next couple of years are all about PaaS and developing ecosystems around these. SAP has a thriving ecosystem. They need to sort out the PaaS strategy fairly quickly though.

      My few cents.



      Author's profile photo Former Member
      Former Member
      At best, an OData adapter in PI should also be made available for customers with versions lower than ERP 6.0. As SAP looks to position PI as an ESB, loosely coupled light weight REST based interfaces should be fine in a mediated SOA landscape.

      And why only for sub-6.0 customers? wouldn't an oData adapter suite anyone well with PI already in place?

      Author's profile photo Former Member
      Former Member
      Hi Anton,

      Thanks for the comments. Didn't mean to exclude ERP 6.0 customers. All I wanted to highlight was that if SAP didn't want to go too far behind to update kernels of sub 6.0 versions, PI is a viable option.

      For ERP 6.0 and above, both kernel support for OData/REST as well as PI based adapter are fine. It will be up to customers to decide which option suits best based on integration strategy.

      For customers without PI, SAP can leave it up to partners to develop these adapters


      Author's profile photo Sascha Wenninger
      Sascha Wenninger
      I don't think PI and REST are very well suited to each other. PI is very strongly based in the SOA/EAI world, and REST is an almost polar opposite of this from an architectural perspective, so I'm not sure it would be an easy merge, or even make a lot of sense.

      One of the nice things about REST is that it almost explicitly does away with the concept of middleware in the sense of an ESB.

      However, OData is based on AtomPub which is really just XML. Gateway supports the POST operation of HTTP, and PI does this as well through both the SOAP and plain-HTTP adapters, so at least some basic integration between the two should be possible now...


      Author's profile photo Gregory Misiorek
      Gregory Misiorek
      even if SAP hadn't written one single app i would still find a way to run SAP on my iPhone and my iPad
      Author's profile photo Trond Stroemme
      Trond Stroemme
      If I'm a soft drinks manufacturer, and I buy trucks from, say Ford, using them to transport bottles of soft drinks to various shops, does it mean I should pay a small commission to Ford Motor Company for each trip I make? Or pay a similar commission based on the mileage of the trucks?

      Even if my customers are given the pleasure of seeing their goods arrive in a shiny Ford?

      Didn't think so.

      Author's profile photo Joerg Singler
      Joerg Singler
      1) get in touch with your sales and you will wonder about the licenses...
      2) try to develop a Gateway Service for yourself and you will wonder how efficient you are, even for complex scenarios and in an E2E perspective.

      In sum: give it a try first.

      Cheers Joerg

      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author
      Hi all,

      Firstly thanks for all your feedback on this blog. It has been a humbling experience to see how many people are interested in what I said and were motivated to join the discussion. Because these discussions have been so active I have refrained from commenting myself because, as I tweeted a day or so ago, I didn't want to "disturb the force".

      Now might be the appropriate time to try and draw together some of themes I've see in these comments and other feedback I have had over the past few days.

      Gateway Licensing.
      I have a better understanding now that the issue of licensing what I will call "Internet Users" is more than a problem for SAP. It is a major issue for SAP customers as well who want some certainty around this as soon as possible. The consensus seems to be, and I agree with this, that any technology for use-based metering should be decoupled from point solutions like NetWeaver Gateway. More than one person has come to the logical conclusion that, for the ABAP stack, the appropriate place for metering is deep inside the ICF. This allows measurement of all interactions no matter where they originate from, what facilities they use or what data format they provide. As a developer this also gives me the freedom to select the most appropriate technical design for the problem I am working on.

      Gateway Capabilities.
      Many people find that NetWeaver Gateway is not ideal for their purposes. The OData versus JSON debate is a symptom of this. My perception is that it is pretty difficult to hit the mark with something like this when there are so many permutations of what people want to use. I think Sascha came closest to the mark when he called for a Layered Architecture that provides "well-defined ways around these higher-level features to help those of us who want to do things better/leaner...".
      There were several people who objected to my description of NetWeaver Gateway as a developer productivity tool. No one really expanded too much on this so I would encourage you to more fully share your thoughts - perhaps in a blog?

      Many leapt to the defence of the Sensitive Unwired Platform. Some seemed to object when I said I couldn't justify the cost of the Sweeping Unwired Platform to support my killer mobile app - we will just have to agree to disagree on this. Others raised the level of the debate by talking about the value proposition of a Mobile Enterprise Application Platform (MEAP) and how the Superior Unwired Platform fits into this role. My view on the whole MEAP argument is that we will lose interest in having special pieces of middleware to support certain device types. When it comes to the runtime environment we will expect our chosen UI technology to support everything out of the box. I see merit in the device/user/application management capabilities attributed to a MEAP, just not the runtime pieces. Disclosure - there are many more knowledgable people than I in the mobility space who disagree with me on this. I am still to be convinced.

      Finally thanks for all the great feedback on the SUP definitions - best summed up by Jan's 'meh'.

      Graham Robbo

      Author's profile photo Thomas Jung
      Thomas Jung
      This week's episode of the Enterprise Geeks podcast begins with a 40 minute discussion that was directly kicked off by this excellent blog.  We thought about commenting here directly, but lets face it we didn't get into programming because of our excellent typing skills. ๐Ÿ™‚ In all seriousness, I think you have sparked an important discussion and one that I hope many within SAP are listening to.  On the podcast I also played "devil's advocate" and tried to express some of the arguments I hear from within SAP for way we are setting up the licensing around Gateway and similar products.
      Author's profile photo Yariv Zur
      Yariv Zur
      Thought provoking as usual. Interesting to see how the inner decision making is focused on some points and once it hits the outside (motivation meets the ground :)) it is percieved in a very difference manner.
      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author

      Hi everyone,

      I just wanted to close the loop on this blog.

      Shortly after SAP TechEd 2012 Las Vegas SAP made some changes to the licensing terms for NW Gateway in, at least some part, a response to the issues raised by this blog and associated comments as well as many other conversations between SAP & other stakeholders over the past couple of years.

      While I was briefed on these changes shortly before they were implemented I didn't want to publicly talk about them until SAP had announced them or given me formal permission to do so. While neither of these things has happened the details are certainly widely available now so I will briefly mention them here. Of course for the absolute and definitive answer for your particular circumstances you will need to check with the appropriate SAP Account Executive.

      In simplistic terms, SAP now include NW Gateway licensing with existing named user licenses. This has the obvious caveat that you wont use NW Gateway for anything beyond what the user is licensed to do.

      So in this respect my understanding is that you can treat NW Licensing the same as other enabling technology like SAPGUI or RFC. ๐Ÿ˜›

      Let me give a very much contrived example in an attempt at clarification.

      Say you are licensed as a ESS (Employee Self-Service) User. You are therefore licensed to be able to create Leave Requests. You can do this using the SAP delivered ESS Leave Request WDA screen. You can also create Leave Requests using a SAPGUI transaction, or a purpose built BSP applications, or .Net application, or PHP application, or a Java application and these applications can leverage NW Gateway to perform the Leave Request process if you so desire. Just because you may choose not to use the standard screens delivered by SAP to create a leave request you are still able to do so because it is the business function that is specifically licensed - not the technology. In short the license lets you create Leave Requests any way you like. But approving a leave request is NOT covered by an ESS user license. To be able to approve a leave request you need a MSS (Manager Self-Service) license. This trivial example makes sense to me so I hope I have explained it well enough for you as well.

      So while NW Gateway provides a facility to leverage pretty much any functionality on the SAP back-end system (just like RFC & SAPGUI) you are still constrained by your user license as to what you can actually use it for.

      Now it is possible that you will want to use NW Gateway to do everything that your ESS license lets you do plus 1 or 2 little functions that normally require a much higher (and more costly) end user license - say a Full Professional License. Anticipating this requirement SAP have also created a couple of new named user types that will allow you to do this without having to stump up for the cost of a Full Professional User license. Talk to your Account Exec if you need to know more about this.

      If you wish to use NW Gateway for an application where the users are not covered by existing licenses - usually so called "Unnamed Users" - the usage-based licensing option is still available to you. Again check with your Account Exec for details.

      This all seems very reasonable and appropriate to me and I hope you guys as well. I must thank and congratulate the NW Gateway team for their engagement and initiative on this and other issues around this product. These guys rock - and they listen as well. 😘

      Next steps? Well for me I look forward to having NW Gateway just delivered as part of the SAP NetWeaver ABAP stack - not as an add-on. I want to be able to have certainty that NW Gateway is available on my customers' application server without having to ask them to specifically install it. That is just friction I don't need and it only complicates my message when I am talking to them. I know the NW Gateway team would like to see this too - but there are no commitments or timeframes on this yet.

      Thanks to all of you for your interest and engagement on this topic. It helps - a lot!


      Graham Robbo

      Author's profile photo Martin English
      Martin English


           From what I can see, this is similar to what currently applies for non Gateway applications.  The big difference is that if I use CRM Web Gui, or BSP, or one of the other methods of accessing SAP data, I don't have the choice of paying by usage

      In other words, if I have an online application, where everyone (no age limit, citizen or not,....) is a potential client or 'user' then .. without prior consultation with SAP, I should be licencing up to 23 Million users ?


      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author

      Hi Martin,

      you are absolutely correct that all users must be licensed. And the old trick of using the same SAP user account to allow what is essentially anonymous access to the SAP backend is - and has always been - contrary to both the content and spirit of the SAP license agreement.

      So the problem becomes how do you get a licensing model that allows - say 23 million Australians - to use your application that calls the SAP backend. This is the issue that SAP, and others, are struggling with. It makes sense to have some sort of usage-based licensing model for this use case.

      The problem, as I see it and you point out above, is that this is currently only available for NW Gateway and not for other SAP technology. I believe that all licensing should be decoupled from technology. So then you could negotiate a usage-based license agreement for these anonymous (unnamed) users and then implement your application in any way you want.


      Graham Robbo