Skip to Content

* This was originally a part of my SAPTechEd Aftermath, but 7 pages was too much for one blog.


Seeing the screen persona’s for the (ITS) SAPGui, I understand that SAP wants to work on a fresher look for their GUI. There was already the corbu theme, which supposedly is better looking (I debate this statement), but seriously, who still wants to work in SAPGUI?

The fashion-word of the past 3 years has been “Mobile”. If you wanted to create a killer application, it’d better be on an iPhone. That is changing now. We’re finally seeing that “Mobile” goes beyond the iPhone or Android phone. Mobile is also the Web application that runs in your browser, on your laptop. It’s the very same web-application that automatically resizes to fit the screen of your Phone or tablet; a tablet that might be running Windows 8…

Microsoft has launched it’s Windows 8 based surface tablets, and was showcasing them in the exhibition hall. Knowing how Microsoft already dominates the enterprise market, it’s not unimaginable that they will soon take over the entire wave of “Bring Your Own Device” and become the standard for many enterprises that still fear the entire effect of consumerization.

What is more important is that everyone now seems to acknowledge that we should think platform independent, as it’s not feasible to create the same functionality for 3 or more platforms. This is where HTML5 comes into play. We already know that SUP supports HTML5 development, which is nice. But I still think it’s far too expensive in licenses to develop HTML5 applications on SUP. Especially since one of SUP’s key added values, is the buffering of data in MBO’s to reduce stress on the backend.

Hello HANA?

So why need a middleware? Can’t we just expose services, preferably RESTful, and consume them through HTML5 apps?

Hello SAPUI5 and Gateway!

Now I’m no fan of the NetWeaver Gateway. Any application which key-characteristic is, that it supports Batch-input and screen scraping, deserves a healthy dose of skepticism. I much rather like the eco-system powered approach with RESTful adapters in SICF nodes. (Thanks to DJ Adams)

Alternatively, you could just generate a SOAP service, and have it transformed to REST by an ESB. Like IBM DataPower. (Am I allowed to say that here? 🙂 )

You could also create your own, easy, intermediate app. Something I did on NW Cloud. It has an API to transform XML to JSON. EasyPeasy. So why would we pay hefty prices for NetWeaver Gateway if we have so many alternatives already.

Maybe it should be free, and standard on the NetWeaver ABAP Stack…

[Update: as of AS ABAP 7.4: Gateway is a standard installed component. It was already free for named users earlier (as mentioned by DJ) ]

Like they did with SAPUI5.

It’s free, and it will be shipped as a part of the NetWeaver Stack in future EHP’s. Briliant. SAPUI5 also has a mobile package now. The mobile package has responsive design, all the necessary elements and it looks great. It’s A pity though that the desktop version and the mobile version are not mutually compatible, although you could just consider creating only mobile applications and using the same on a desktop.

So it looks like SAPUI5 is cannibalizing on SUP (which now also hold the Agentry platform of Syclo). I’m pretty sure that there are still scenarios for SUP. Offline enabled applications with strong integration to hardware peripherals, and strong requirement to security. But those cases will surely not represent more than 20% of all cases.

But let’s not jump to conclusions too fast and risk panic 😉

To report this post you need to login first.

8 Comments

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

  1. Bjorn Vilhjalmsson

    Thanks for the blog, appreciate you taking the time to share.  One thing to keep in mind with SUP and other platforms that mobilize the business, they are not just taylor made solutions just for SAP data but can be used for other backends as well.  I have been involved in projects where half of the apps developed on SUP were non SAP apps but the end user did not notice or care. 

    I have said before that I see the major trend happening not being mobility but user experience/interface trend.  HANA falls under that trend, web solutions on pc browsers, NWBC with their chips, sidepanels, POWL lists, there is a lot available now and so much more just around the corner to make me believe that the end of standalone SAPGUI is approaching for the majority of users while it may still be far away for a minority. 

    HTML5 will be great but comes with it´s own cost as well, there is no develop once deploy everywhere in sight.  Surface might make things more complicated for mobile developers since so far they are mostly working with Webkit based browsers on device but if Microsoft succeeds then you have to make sure that the Metro based IE browser works well with your web app (or container/wrapper).  I believe users expect an app experience from enterprise apps, really high performing, snappy apps with offline capability and utilizing the device capabilities.  So far I see almost all apps on the SAP App store being native apps, if not all?  This might change now with SUP 2.2 and the improved support for html5 frameworks/tools but I believe it when I see the performance and features of these apps. 

    (0) 
    1. Tom Van Doorslaer Post author

      Hi Bjorn,

      It’s nice to hear that you put HANA, SAPUI5 and mobile all in the User Experience basket. I had come to the same conclusion and am planning to write an article on it. It still has to sink in a bit though. I’m seeing a bigger picture.

      You are right that all of the apps in the SAPP store are native. I had been questioning already how you can put an HTML5 app in the SAPP store. Haven’t looked into the issue yet, though.

      The fact that SUP is not only for SAP is absolutely right. You can enable other datasources as well. But let’s be honest, a decent ESB can act as a central source system as well. In that light, the licences for SUP are still hard to explain.

      Users expect the app experience: yes. Users also expect that they can bring any device. For companies, it’s not feasible to create native apps for all sort of devices that people may bring. So I think we’ll either see a move to BYOD + HML5, or Corporate standard devices + Native. (or corp standard and HTML5 anyway)

      I believe that the adoption of the MS Windows 8 will be key here. MS has a strong ground in 90% of the enterprise. If even only half of those enterprise decides to standardise on all MS platforms for integration and compatibility reasons, than we’ll witness a huge shift in enterprise mobility.

      Exciting!

      (0) 
  2. DJ Adams

    Hi Tom

    Nice post, I like the provocative themes and ideas 🙂

    Thanks for the pointer to my homebrew ADL (Alternative Dispatcher Layer). Interestingly, you mention it in the same paragraph as you talk about Gateway:

    Any application which key-characteristic is, that it supports Batch-input and screen scraping, deserves a healthy dose of skepticism

    I thought it might be worth putting the record straight. While the IW_SCS component of Gateway does support screen scraping (or, as the typos in some documentation put it: “screen scrapping”(!)) it’s not a core feature nor have I ever seen it being sold as a “key characteristic”. At best, this functionality is good for prototyping. To be honest, apart from when I was following some early tutorials and learning about Gateway, I’ve never used these features.

    You also talk about alternative home-grown apps (and by inference, integration) thus:

    You could also create your own, easy, intermediate app. Something I did on NW Cloud. It has an API to transform XML to JSON. EasyPeasy. So why would we pay hefty prices for NetWeaver Gateway if we have so many alternatives already.

    Bear in mind that consumption of SAP data and functions is never going to be free. I know you didn’t say that, but I think the contrast between Gateway, where there’s a focus and a dialogue on licences, and homebrew solutions, is in danger of masking the real issue, that of “indirect usage“. It’s almost as if Gateway was the catalyst for a re-focus on usage licensing by SAP. I don’t want to put words in SAP’s mouth, but I think the fundamental difference is that with Gateway, the licence debate is on the table and explicit; whereas in other situations there is a risk that SAP will eventually get round to auditing and charging for indirect access, which may turn out to be more costly than the explicit Gateway licences.

    One good thing to come out of the recent Gateway licensing debate is that Gateway-based consumption for existing SAP users is now not subject to any extra cost. Anonymous usage is still going to be metered, but maybe it’s a case of better the devil you know?

    dj

    (0) 
    1. Tom Van Doorslaer Post author

      Hi DJ,

      The batch input and screenscraping was indeed part of tutorials and early hands-on sessions. It kept nagging in my brain though.

      The licensing for hidden consumption is indeed an important remark. I automatically assume that anyone working on SAP data has a named user in the system. If you start using technical users for webservices, than this can be considered as a violation of use-terms. (so Very Important Remark)

      The main issue for me was that a user would have to pay twice. Once for a named user in the system, and a second time for Gateway. (And a Third time for SUP if he uses that, and a fourth time for whatever is next..)

      Thanks for the info that Gateway would become free-of-charge for named users. That falls in my latter scenario, where GateWay is free (for named users), and standard available on the stack. Don’t know abot the last part yet.

      Is it still a separate component, or will it indeed become a standard component on the NetWeaver ABAP stack?

      Cheers!

      (0) 
      1. DJ Adams

        Hi Tom

        Yes, I remember too the screen scraping components being covered quite considerably in early tutorials; in hindsight that was probably OK as it got people over the initial Gateway hump, as the whole OData Channel concept was still a bit of a mystery at the time.

        Gateway still is a separate component, but I don’t see it that way. In other words, you can still choose to install it into your core ECC system, for example, or install it into a separate stack, depending on your preference. And there’s no single answer here, as you know 🙂

        Interestingly, I’ve just been reading some docu for the UI add-on for SAP NetWeaver (i.e. the new, optional — but interesting — ABAP stack side of things for SAPUI5, put coarsely), and I came across a clear recommendation for installing Gateway into the core. It was in the context of SOP (Same Origin Policy) and contrasted with the use of SAP Web Dispatcher as a reverse proxy mechanism. Well, I thought it was interesting, anyway 🙂

        dj

        (0) 
        1. Tom Van Doorslaer Post author

          Yes, I can see where that comes from.

          If they are going to deliver SAPUI5 library in the mime repository of BSP’s and the Gateway is on a different host, than many browsers (if not all) may consider this as cross side scripting.

          Unless you have your web dispatcher which takes care of everything (single point of entry)

          It can abstract your physical devices, so that it looks like your UI comes from the same place as your service.

          Meanwhile in the parent blog, Yariv Zur made some interesting comments on SAPUI5 for BPM and Visual composer.

          I definitely notice a trend here, that SAPUI5 is quickly becoming the technology of choice for decoupled Web clients. (and mobile)

          I like!

          (0) 
  3. Frank Koehntopp

    I may sound like a broken record, but “let’s quickly expose some RESTful services and write some Javascript code to consume it” scares me to death.

    I’ve looked at 20+ mobile applications from a security perspective this year, and believe me, you do want those SUP services to protect your ERP infrastructure:

    – an “intelligent proxy” if you will that filters for registered devices, users and user to application relationships before any malformed http request hits your backend (if you think that’s not necessary, post your web service URI on reddit and see what happens…)

    – consistent authentication and authorization services that work for more than just your app. If you’re the person responsible for rolling out mobile apps I’m sure you appreciate if you can manage all of them in a unified manner.

    – the option to add Afaria for software distribution and automated configuration

    – one central platform to manage all those apps wanting to consume ERP services

    – client libraries that have proven and secure methods to talk to a server, and allow you to securely store data and configuration on device

    I’m still not seeing how you do that in your open RESTful world, but I’d like to see some actual customers chime in. What is your mobile strategy, how do you envision managing a mobile Application repository across an enterprise???

    (0) 
    1. Tom Van Doorslaer Post author

      From a customer perspective: (only obvious highlights)

      – no Webservice is allowed to leave the corporate network.

      – devices need VPN with strong authentication. (I still debate on the strong authentication. I much rather see password and client certificate)

      Afaria and SUP are 2 separate products. I don’t debate the importance of device management.

      but if external access is impossible (except for VPN), than what is still the security advantage of SUP? (knowing that you can disable the VPN via device management in case of loss)

      The central platform to manage apps, could just as well be a simple Web Application server on the intranet. The services can be on your ESB. Authentication could go via the client certificates. Identity propagation via SAML, or….

      Now I can see that, if you have none of those, (No VPN, No ESB, No WAS, No Device management) you would benefit from SUP, because all those components together may cost more than SUP (if even…)

      I used to be convinced of SUP because of the native part, but with the quick rise of HTML5 as front-end, I started to seriously doubt the added value of SUP.

      (0) 

Leave a Reply