Skip to Content

We’ve all heard a lot about SAP UI5 by now. It’s being touted as the UI of choice by SAP, with plans to move towards using it in every facet of SAP, originally starting with HR & Finance transactions, and now in Fiori and HR Renewal. This was, and still is, exciting news when you think about the UI that we have had to tolerate in standard SAP. Most users will tell you that navigating SAP is never an enjoyable experience. You eventually get used to it, but you never look at it and go “WOW. I’m SO glad I get to look at this everyday”.

To be fair, a lot of the functionality in SAP is process and task driven, so you are given all your options, giving you the choice of which ones you want to perform your daily tasks. However, this means that users get too much information and too many options, which leads to confusion and frustration. Imagine their excitement when SAP announced Fiori, the new kid on the block that promises to soothe your battered senses while still letting you do your job.

There’s no need for me to get into Fiori too much; there is a plethora of information on this as SAP prepares to love bomb us in the UI stakes. I’ve seen it, and it definitely looks really good, far and away the best UI I’ve ever seen in SAP. It’s built on the SAP UI5 framework, which combines HTML5 and JavaScript to produce a UI that is finally up to the Web standards we have become so used to now.

Naturally there has been a lot of interest in Fiori, and therefore UI5 as the way forward in user interface of choice. Customers who have been starved for a decent user experience are now clamouring for this new kid, but are they really being informed as to what it involves? I had the opportunity late last year to implement a mobile web app based on UI5 and Gateway at a customer, which has given me some interesting insights into adopting this framework. The purpose of this blog is to explore my experience implementing this UI framework and the customer’s reaction to it.

The requirement at the customer was to have a mobile web app that supports purchase order approval. As time wore on, the requirements evolved a little, but in the end I built an app that provided the following:

  • List of purchase orders awaiting approval at the user’s release level
  • Details of purchase order when selected from list
  • Ability to approve selected purchase order
  • Ability to search for another purchase order when not in the list
  • Ability to emergency approve to all levels a purchase order not in the list when searched for

This may sound like a small list of requirements (I may have summarized it a little), but it was not entirely simple providing robust functionality that was similar enough to backend SAP, but also looked good. Below is a diagram of the architecture that was used from end to end:

MGC PO Approval App Architecture.PNG

The architecture was a bit more clunky that I would have liked, but it was the client’s decision to use this design to facilitate their authentication and data integrity needs. In summary, the user would load the web app on their device (could be a phone, iPad or even desktop browser) and the call would be routed through the web dispatcher and the portal login screen (I modified this to handle the mobile screen) would show up. After authenticating in the portal, this provided them SSO into Gateway, which would serve up the data and communicate with the backend ECC system through SSO as well. In this scenario, the UI5 libraries and application was hosted in the Gateway system.

I won’t go into the details of the web dispatcher setup, but here are the technical steps I had to perform to achieve the outcome:

  • Build the Gateway service and implement the logic to retrieve data from ECC
  • Build the UI5 application and host it on Gateway
  • Modify the portal login screen to handle a mobile device (a different screen is used)
  • Create a small HTML resource in portal KM that the web dispatcher URL routes to (and subsequently calls the portal login action)

Here are the key learnings I experienced while implementing this solution:

  • UI5 is very performance heavy, and in some cases took up to 40 seconds to load the very first time
  • Testing on a desktop browser produced different results than an actual phone browser (I used Chrome which is more tolerant) so I did a lot of testing and debugging on actual devices
  • Designs sometimes had to be simplified with only what is required on the screen due to size
  • Using ABAP tool in Eclipse to handle versioning after the UI5 application was loaded into Gateway as a BSP was quite a hassle so I did a lot of testing on my local machine before deploying
  • Supporting and implementing this solution required skills not usually found within the average ABAPer (HTML5, CSS, JavaScript, and Gateway)
  • Designing a solution from a technology perspective does not always result in the best user experience

The key thing that I learnt about UI5 is that is very slow to load. We tried to improve performance in numerous ways, but in the end it came down to how the framework rendered the elements, due in no small part to how it spawns .js files at runtime. Most of the user base were in metropolitan areas, and still sometimes struggled to load the screen faster than 10 seconds.

Given the set architecture coupled with the tight time frame and rigid requirements we had a successful outcome, but there are plenty of other ways we could have skinned this cat. I’m very glad to see customer adoption of UI5, and I’m really hoping to see SAP improve it from a performance point of view so users can have an excellent user experience without compromising on certain parts of usability. I’m also hoping that customers will be able to go into this process with their eyes open, being informed of all the factors involved before jumping in headlong.

Below is a short demo of the app:

To report this post you need to login first.

7 Comments

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

  1. Robin van het Hof

    I was wondering, those 10-40 seconds loading time, I assume that’s only the initial load? Once the bootstrapper is loaded, the screens should render just blazingly fast.

    Also, did you only load the libraries you needed, or were all libraries loaded at once? That may impact performance as well

    (0) 
    1. Joanna Chan Post author

      Hi Robin,

      10-40 was the initial load time, but even with user interaction after it wasn’t as fast as I’d hoped. Not in the seconds but not super reactive. The libraries were loaded from the Gateway server so it only loaded the ones it needed.

      Jo

      (0) 
      1. Robin van het Hof

        Hi Joanna, the initial load time I can somehow understand, if you’re on a slow network (longest load time I had to suffer is ~10 seconds).

        But once they are loaded, UI5 user interaction should not take more than a 3-5 milliseconds to render a different page — IMHO this is impossible for someone to notice 😉

        (0) 
  2. Tino Behrmann

    Thanks Joanna for sharing your experiences with UI5 with us. I agree that performance is an issue in SAPUI5 today, but SAP already did a ton of improvements in the latest releases (1.22). To eliminate the long boot time of the initial load, you can put your sources and the runtime directly on the device, e.g. by wrapping them in a cordova/phonegap container.

    (0) 
    1. Joanna Chan Post author

      Hi Tino,

      Yes this was done before 1.22 was released so that wasn’t available. Also the client wanted a web app that could be run from desktops as well, so that ruled hybrids out. Thanks for your feedback.

      Jo

      (0) 
  3. Vivek Nidhi

    Thanks Joanna great blog and nice attention to detail.


    I can see portal is used as a launcher into the app. I think customers who has portal in their landscape will find this an easy approach. I can see that you did try with KM applications to launch UI. KM applications are known to be very slow. I think Portal on Mobile –  desktop with a SAP UI iview will be a better approach. Just a thought.


    You can take a look with HTTPWatch to see where most of them time is spend when its loaded on the browser

    Many thanks

    Vivek

    (0) 
    1. Joanna Chan Post author

      Thanks Vivek. We did a lot of analysis to try and reduce the performance hit so I think that was the best we could get with the architecture restriction placed upon us. Appreciate your thoughts. Jo

      (0) 

Leave a Reply