Rebooting your User Interfaces with SAP NetWeaver Gateway

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

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 …

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.