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:
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:
- SAP Managed Tags:
7 Comments
