Skip to Content

A couple of months ago I was invited to speak at the SAP Australia User Group (SAUG) annual summit on the topic of ‘How SAP NetWeaver Gateway can deliver you the user interfaces you’ve always wanted’.  I’ve felt strongly that the idea of what SAP NetWeaver Gateway represents is important, yet not well understood by many on-premise SAP customers.

To explain this, lets first understand a significant challenge which in my opinion most on-premise SAP customers deal with today.  In my mind, that challenge is that of keeping up with the latest consumer-grade trends in user interfaces and usability (such as, but not limited to mobile).  In fact, I would suggest that this challenge rates higher with most customers than dealing with in-memory or cloud.  We’ve heard it time and again … like a broken record … consumer user interfaces and technologies are far outpacing the rate of innovation by traditional enterprise vendors (not just SAP) and that is creating escalating user angst, and something which IT departments are finding it increasingly difficult to deal with.  Traditionally, user interface technologies delivered by SAP (and other traditional ERP vendors) have been tightly coupled to the underlying platform.  Which means this … if you want the latest and greatest user interface elements from SAP, you typically in the past needed to UPGRADE your core SAP system … and that’s something which most organizations cannot stomach more than once every couple of years.  On the other end, think about consumer technologies such as smartphones, or internet-enabled TVs, or new browser versions released to the market – in the past few years these technologies have accelerated their innovation cycles.  A consequence of this is the rate at which we upgrade the OS on our smartphones (once every 6 months or less), versus how often we upgrade our SAP systems.  It is demonstrated in the challenges SAP faces in keeping up with browser support (eg. Chrome) for those UI technologies which are delivered inside-out from within the core (eg. Web Dynpro).

Innovation Cycles.png

This brings me back to the concept of pace layering.  Pace layering (or shearing layers) is an architectural principle whereby you design for the various layers in your system to move based on the different rates of evolution.  So, the core SAP business logic layer is relatively mature (after decades of evolution) and you hopefully don’t need to mess with that too often.  However, we know that the user interface layer is in need of very rapid evolution to keep up with the escalating demands of end users, and end-user client technologies. 

So how does SAP NetWeaver Gateway support this concept of pace layering?  By enabling business logic and data from SAP to be exposed in a simple, lean and client-agnostic manner.  That means you can write a website today which interacts with data from your SAP system using Gateway services, and tomorrow you can write a mobile app over the top of the very same Gateway services without needing to make any further changes to the SAP system.  The following diagram illustrates this concept …

Pace Layering.png

Of course, writing custom UIs over the top of SAP is not typically in the DNA of SAP customers.  And no organization would seek to re-face every SAP business process or screen.  There is a cost to this (although SAP seeks to mitigate costs by providing libraries and code generation tools for various client-side technologies).  But there is a subset of use cases for which it might make sense to do this.  These are the scenarios which might span a broad spread of casual users, which are commonly used, and for which you really would benefit from a zero training user interface.  They are the scenarios which you might choose to embed in your corporate intranet, or onto a mobile device, or a kiosk.  Think scenarios such as ‘Leave Request’, or ‘Time Entry’.  When considering the cost of re-facing a key transaction, consider this … what is the price of training your casual users to use old SAPGUI screens?  What is the price of users turning to ‘shadow IT’ solutions and thereby bypassing your SAP processes and business rules? 

Lets take an example scenario …. you currently have a website with specific styling and you wish to elevate SAP data into that site.  As an example I chose to build a simple proof of concept by exposing a OData channel Gateway service querying SAP transaction codes (yes, not a great use case – but the best I could do against a Trial SAP NetWeaver Gateway system which I had installed on AWS).  Here is a screencam …

Then, suppose you subsequently also need a mobile app to access the same data.  You want an easy to use mobile web app to do that, but you don’t want to upgrade or even patch your SAP system to obtain the latest available user interface (‘inside out’).  Instead you simply build a user interface over the top of the same Gateway service (‘outside in’) which you previously enabled for the website, without needing to touch your SAP system.  This is an example of pace layering.  Here is a screencam …

To illustrate for the technically minded, in both of the demos above, when selecting a transaction code (for the detail view) the following request is sent from the client (in example 1 from the website, and in example 2 from the mobile app) …

HTTP ‘GET’ REQUEST SENT FROM CLIENT TO SERVER:

http://<gateway server>:8000/sap/opu/odata/sap/Z_TCODE_SERVICE_MOY/TCodeCollection(transactionCode=’SE80′)?$format=json

And the response returned is as follows …

RESPONSE FROM SERVER:

{

  “d”: {

    “__metadata”: {

      “uri”: “http://<gateway server>:8000/sap/opu/odata/sap/Z_TCODE_SERVICE_MOY/TCodeCollection(‘SE80’)“,

      “type”: “Z_TCODE_SERVICE_MOY.TCode”

    },

    “transactionCode”: “SE80”,

    “program”: “SAPMSEU0”,

    “screen”: “0000”,

    “transactionDesc”: “Object Navigator”

  }

}

Note how lean the above JSON-formatted response is.  In fact it is only 256 bytes.  That is important when sending data over low bandwidth networks (eg. mobile networks).   Lean data feeds translate to better response times, and improved usability.  It is also why these days I prefer JSON feeds over XML (which can suffer from tag ‘bloat’). 

Each of the above examples took only a few hours in an evening to build.  Imagine what you could accomplish with skilled mobile, web or other UI developers with your key high usage data and business logic exposed through SAP NetWeaver Gateway.  It should be noted that the use cases for SAP NetWeaver Gateway are not limited purely to user interfaces, however that is the focus of this blog.

So, what does SAP NetWeaver Gateway deliver?  In my mind, and in the context of this blog, it is an enabler for pace layering in a world when user interfaces and user expectations are evolving at a rapid pace, above our stable and mature on-premise ERP installations.

If you would like to see the full slide deck from my SAUG Summit presentation on SAP NetWeaver Gateway, it is available here.  If you would like to trial your own user interfaces on top of a SAP NetWeaver Gateway system, you can access the online demo system provided by SAP here, or install a pre-packaged trial on your local system here, or if you prefer you can install a trial version in the cloud (useful for trialing mobile scenarios to your smartphone) on Amazon Web Services via my blog series here.

To report this post you need to login first.

14 Comments

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

  1. Patrick Brandicourt

    Yes I do agree and I like your picture. Now we need to roll-out this concept at an “industrial” scale.

    I am still not clear about few items like :

    + I am hearing that Gateway is designed for ‘low volume’ type of data (let’s call it mobile type of application). What are the solutions to have a “pace layering” approach for “professional users” / “heavy transactions ?

    + Will Gateway be sufficient to enhance the user experience ? We have some fundamental pain points (Googe type of search behavior, reduced help field proposal) which may require to go beyond a pure UI. The 

    (0) 
    1. John Moy Post author

      Hi Patrick,

      I haven’t heard that Gateway is only targeted at low volume scenarios, but yes I agree this concept needs to scale across the full suite of user interfaces.  In fact I alluded to that by indicating in my full slide pack that perhaps one day this architecture may become the mainstream approach to surfacing user interfaces in SAP … that has not been stated by SAP, but I would not be surprised if it becomes the general architectural direction.  I can see SAP itself providing out of box user interfaces which sit on top of Gateway (eg. mobile scenarios, some HR Renewals components).  This will allow SAP itself to accelerate the innovation cycles and delivery of out of box user interfaces.  But note that Gateway (or more accurately REST APIs) is simply an enabler .. not the full solution.  I agree with your comments that on its own it is not sufficient to fully enhance the user experience across the board. 

      Regards

      John

      (0) 
  2. Krishnakumar Ramamoorthy

    John

    Good blog as usual. One of the pain points in my mind is that there is STILL no clear messaging about the UI layer from SAP. We started with ABAP Dynpro, then we said we need to go web, so we did ITS. Then we said, we need better solution than ITS, so we went BSP. Then we said, Java is going to solve world hunger, so we went Java WebDynpro. Then we said, we need some controlled UI framework for large scale custom developments, so we went ABAP WebDynpro. Ofcourse, we wanted a piece of RIA, so we went Flex/SliverLight and their respective islands. Then we said we need a lean UI model, so we did SAPUI5. And let’s not forget the GuiXT and Personas of the world.

    Interestingly, all the above technologies are STILL used in different shape and form in various SAP applications even today. And I wonder, why a new SAP customer wouldn’t be confused with the UI messaging of SAP. I recently came across two different screens within SAP SRM, one developed using BSP and the other using WebDynpro and they looked totally different. I had no good answer for the customer when questioned why SAP did it this way.

    Hopefully in the next couple of years, we will have THE UI framework and the only one to deal with.

    Cheers

    KK

    (0) 
    1. John Moy Post author

      Hi KK,

      Thanks for you post.  Yep, you said it perfectly.  And I’ve lived through all of those UI innovation cycles which you mentioned.  And one of the challenges I find with SAP is that it is a victim of its own massive installed base and decades of history – and basically that is that older technologies remain supported and persist in the landscape (like the ones you mentioned, as well as others such as sapscript etc.).

      Web Dynpro is an interesting one to discuss … the idea was that it would provide a layer of abstraction between the developer and the end-client technology.  The developer would model the user interface layer, and SAP would provide rendering engines for future UI technologies to render the UI in that technology.  The theory was that this would ‘future proof’ the UI investment.  But in hindsight I believe the plans were too ambitious.  After almost a decade, we haven’t really seen new rendering engines beyond the HTML client (correct me if I am wrong here).  And SAP lost years of R&D in making the shift from Web Dynpro Java to Web Dynpro ABAP.  Now we have seen that the seismic shift brought about by mobile UIs has proven to become a bridge too far for Web Dynpro (and when you consider the new mantra about ‘mobile first’, you have to wonder about the longer term relevance of Web Dynpro … already people are wondering if UI5 may be the successor).  But Web Dynpro was still an attempt by SAP to wholly ‘own’ the User Interface technology with a proprietary approach. 

      I believe a shift towards UIs built upon loosely coupled APIs via Gateway is different to the Web Dynpro days.  The architectural lines more cleanly separate the user interface from the business logic layer – enabling pace layering.  And because the communications are via lean HTTP Rest APIs, that is something pretty much all modern day UI technologies can speak.  Compare that with the original Web Dynpro Java days when you needed to rely on a JCo connector in the UI layer – there is no concept of that in (for instance) iOS.  With Gateway an SAP customer can choose to step off the SAP treadmill and adopt it’s own user interface technology of choice (at least for key use cases).  So in my example 1 above, if the customer already uses a web portal based on some other technology, they can easily ‘wire in’ data feeds from SAP and users will be none the wiser about any shift in UI technology.

      Anyway, I agree with you that the next couple of years will be very interesting.

      Regards

      John

      (0) 
      1. Krishnakumar Ramamoorthy

        Agreed on the WebDynpro Runtime engine. I still think it’s a great concept but needs some flexibility. It is OK to generate HTML/Javascript code dynamically but the framework should also provide capabilities for the developer to extend them. Some SAAS vendors like SFDC have done a great job with this. Configuring a UI in SFDC is very simple and yet powerful.

        Islands concept was probably a step towards a plug-in like enhancement concept but it had it’s own performance issues. There is a reason many of us still like BSP framework better than WDA. It is very flexible and let’s us do more with less. SAP should have created an IDE to support MVC based development for BSP with Syntax checking instead of closed WebDynpro concept (they partly tried it in CRM).

        And oh, making the WDA session model stateful by default didn’t help either.

        I know some SAP customers have totally revamped their CRM UI with Adobe Flex based AIR applications with integration using RFCs through Life Cycle Designer. It has its own performance limitations but there are certain use cases like call center applications where usability takes priority.

        Good times for usability consultants and developers with some neat design and coding skills. Because customers have had enough with the stereotype UIs and the consumer apps has raised the bar for enterprise applications, as you stated.

        Cheers

        KK

        (0) 
        1. Dhananjay Kumar

          There is a reason many of us still like BSP framework better than WDA. It is very flexible and let’s us do more with less. SAP should have created an IDE to support MVC based development for BSP with Syntax checking instead of closed WebDynpro concept (they partly tried it in CRM).

          That pretty much summed up all. Its so painful to watch SAP UI fragmented in so many directions. Its like Android which has an huge but highly fragmented install base. I like the way you appreciate BSPs over WDA. I have implemented some if the UI solution primarily using BSP with other client side technologies like jquery, flex in a way which was simply not possible in WD and yet half of the time I had to give explanation to the clients for the reason I chose BSPs over WDA for which I do not blame them as it is quite understandable from their POV, that the latest offering from any company would be better than the previous one.

          From developers perspective , it would so much helpful if SAP can build or atleast integrate BSPs with any of the good HTML/JavaScript IDE (Webstorm/DW comes into my mind) ,like the the way they are enabling ABAP on Eclipse IDE. If they still want some control over UI, they can go with their tried n tested solution of BSP tags where they can encapsulate HTML5 with JavaScript into new tags.

          (0) 
          1. John Moy Post author

            Hi KK & Dhananjay,

            I wholly agree with your comments.  I still use BSP for that very reason.  Although I am wondering if the architectures are moving towards ‘single-page web apps’, that perhaps BSP is not the optimum delivery mechanism for web templates and resources.  Instead perhaps serving these pages via ICM file system is a more effective mechanism, because (1) It is faster since there is no ABAP session to be instantiated, and (2) there is no BSP URL mangling to worry about.

            I am also intrigued by the Portal On Device offering and the potential of that. 

            Just some of my current thoughts.  Thanks for your comments.

            Regards

            John

            (0) 
  3. Filip Misovski

    Rock on John!  Your findings in this blog resemble what powered us at SAP in the last couple of years to re-think the way we develop and deliver UI technology and features.  The NetWeaver UI Add-on with its components is one small step in that direction.

    Couple of questions to you and the others in the community who may share similar experiences:

    1. In the sample scenario you used a JSON data format, however in your presentation there’s a reference to OData as the lightweight data format.  What’s your experience so far on the benefits, pain-points, and scenarios to use the one standard over another?  Is the “theory” different than the customer “reality” when using OData?

    2. How easy is to face-lift the scenarios mentioned Leave Request and Time Entry by customers or partners using NetWeaver Gateway?  Are there any typical, “top 3” challenges you see where SAP could help in the whole UI “face-lifting” process by customers and partners?

    I really enjoy your customer touch in reviewing all the SAP technology, and also thinking strategically what all that means to people adopting it.  Good stuff!

    (0) 
    1. John Moy Post author

      Hi Filip,

      Thanks for your comments.

      Just some responses to your questions …

      1. It is a personal preference of mine to consume services based on JSON whereever possible.  I am sure I am not the only web developer with that view.  When consuming into web apps using AJAX, you benefit from JSON on several fronts, all impacting usability …

      – The service payloads are generally leaner than those based on XML, and in the world of mobility in particular (and of course we are being taught to think ‘mobile first!’)  every byte counts – it can mean the difference between getting the response to the handset with a poor network connection, or getting no response at all. 

      – JSON feeds can be processed natively in modern browsers, whereas with XML you generally need something to assist with processing the feed.  That ‘something’ is generally in the form of an extra framework (eg datajs) that needs to be downloaded with the webapp.  Once again, in a mobile world you want to minimise the amount of downloads necessary to get the app to work.  It can mean the difference between a working app, or a blank screen.

      –  And the actual work to process XML feeds takes additonal processing time.  Probably this is insignificant, but right now we are trying to get javascript to run as fast as possible on mobile web apps so that they can try and get closer to the responsiveness of native apps.  So any work you can offload to the server is a good thing from my point of view.

      –  Also when I look at XML OData feeds they don’t look as lean as I would like.  In my opinion one of the reasons for the success of REST APIs is that they are simpler and leaner.  Then it looks like people from the SOAP world decided to walk into the REST camp and make the feeds look like SOAP, thereby diluting the original benefits.  Probably this is a controversial opinion but it is my opinion nonetheless.  If you look at the JSON responses generated by Gateway in my blog they look nice, simple, and lean.

      2.  Facelifting leave request is relatively easy because I have done that myself, and also seen it done by others.  I think facelifting time entry is a little more challenging but I know people have done that also.

      The top 3 challenges for customers? Here they are ..

      i.  Many customers take a view that SAP UIs are ‘best practice’.  I think that is flawed thinking in present times.  And it is simply a comvenient approach to because it makes a project’s life easier, but not necessarily the end user’s.  SAP delivers UIs that are customizeable (think FPM etc.) but many customers don’t take the time to open up the possibilities offered by these tools.

      ii.  Skills.  Simply put, a large proportion of developers I see in the SAP ecosystem have not kept up. They still rely on a world of coding SAPGUI interfaces or SAPGUI reports.  To illustrate, at last year’s SAPTechEd 2011 in Las Vegas the first hands on workshop to be booked out was ‘Introduction to Web Dynpro’.  What SAP sees internally and what goes on at customer sites can be generations apart.  I know of course that there is now a great focus on UI5 within SAP internally.

      iii.  Attracting a new breed of Long Haired Developers.  I wrote a blog about this a year ago, so I won’t repeat that here.

      Thanks again for your comments!

      John

      (0) 
      1. David Knittle

        John Moy wrote:

                               

        ii.  Skills.  Simply put, a large proportion of developers I see in the SAP ecosystem have not kept up. They still rely on a world of coding SAPGUI interfaces or SAPGUI reports.  To illustrate, at last year’s SAPTechEd 2011 in Las Vegas the first hands on workshop to be booked out was ‘Introduction to Web Dynpro’.  What SAP sees internally and what goes on at customer sites can be generations apart.  I know of course that there is now a great focus on UI5 within SAP internally.

        One big issue here is the SAP assumption that everyone is on the latest version. When new technologies are released, they are mostly released only to the current highest versions. how many companies can support keeping up with upgrades at the pace they come out? We have had to forego most of the new technologies because of this.

        As long as SAP keeps the new technologies out of reach, there are some of us that will remain in Web Dynpro and BSP-land.

        I am not even sure we will be able to USE gateway, which would put a damper on SAPUI5.

        (0) 
        1. John Moy Post author

          Hi David,

          You don’t necessarily need to be on the absolute latest releases.  If you look at this link http://help.sap.com/saphelp_gateway20sp04/helpdata/en/52/fc994f456a4573957461be15520fe8/content.htm you will see that some aspects of NetWeaver Gateway are supported back to NetWeaver 7.0, and I believe that if you run it as a stand-alone instance you can connect back to even older releases via RFC.  If that still doesn’t suffice, the concepts in my blog can be achieved in a rudimentary manner by coding your own REST APIs using basic HTTP Handlers (on very old SAP systems).  See for instance this blog I wrote last year … http://scn.sap.com/community/abap/user-interface-development/blog/2011/04/07/deliver-dynamic-search-of-sap-data-into-a-website-using-restful-services

          So, you don’t need to remain in Web Dynpro and BSP land alone, irrespective of your release level.

          Also, whilst SAPUI5 out of the box can communicate via OData, since it is basically based on jQuery you could still communicate via your own custom built HTTP Handlers feeding JSON APIs.

          Regards

          John

          (0) 

Leave a Reply