Building Offline PWA Using UI5 and BTP: Part-1

[AshGoyal]

In this blog series, I’ll take you through full details plus tricks and tips on how to successfully deliver and deploy an offline Progressive Web App (PWA in short) using OpenUI5 & SAP Business Technology Platform (SAP BTP). This blog is first part in the series. Please follow me to get updates on when I post the next part in this series.

Offline apps are not that difficult to build if you know what you are getting into technology wise. Native Android and Apple iOS apps have been among the most popular options to build offline apps in the SAP World. However, I believe that PWA apps bring in exciting new differentiators which are hard to beat for any of the native technologies, including hybrid/cordova based technologies, and may very well become the standard for how offline apps are built in the future. PWAs are already really popular in the open source and non-SAP world (think Twitter Mobile, Google, Microsoft and the list is endless). I think with SAP BTP offering excellent deployment and development capabilities on par with the open source world, PWA’s can deliver new and exciting capabilities in the enterprise world.

I have divided this blog into a multi-part series. I’ll cover the following topics in this blog series:

1. Comparison with other technologies for offline use case


2. Building, Deploying & Testing PWA app in SAP BTP


3. How to handle Single Sign On (SSO) with PWA Fiori apps when online and when offline


4. How to manage update lifecycle of the app including updates to code and local device database definitions


5. How to integrate QR Code/Barcode scanning feature in PWA OpenUI5 apps


6. Instructions for end users to prevent data loss

The following topics are not yet covered in this blog series, and I may either add them later to this series or create new blogs for them.

1. End to end design considerations for offline use cases and offline apps


2. Conflict management and Delta handling (This is a complex topic which probably deserves a series of its own)

Important notes:

I’ll be using OpenUI5 for this blog because at the time of writing this blog, officially the UI5 team does not support UI5 based PWA apps fully even though they are working on providing this support. The reason for that is that the UI5 library utilizes synchronous HTTP calls in certain places in its code (for example to read locale specific calendar configurations) and synchronous HTTP calls do not work well with PWAs in Google Chrome and Safari (See https://newbedev.com/can-service-workers-respond-to-synchronous-xhr-requests for more details of the issue). However, there are simple workarounds possible which I will explain in the later parts of this blog series when we jump into the details of how to build the app.

In my personal experience in delivering offline enabled PWA with normal UI5 (I did not use OpenUI5 for that customer project), this issue did not stop me from delivering an excellent UX and offline capability to my customers as the offline enablement in UI5 is generally independent of the UI5 library except for the synchronous call part. The UI5 team did immediately fix bugs I raised on any of the library related issues. I thought that I must call this out so that you can make your own informed decision whether this approach is for you or not.

A Brief Overview of PWA

MDN defines PWAs as web apps that use service workers, manifests, and other web-platform features in combination with progressive enhancement to give users an experience on par with native apps. Google defines them as web applications that have been designed so they are capable, reliable, and installable. These three pillars transform them into an experience that feels like a platform-specific application.

With Web browsers becoming more capable day by day, PWAs have evolved to take advantage of browser’s new features. For example, nearly all major browsers (Microsoft Edge, Google Chrome, Safari, Firefox and so on) bundle IndexedDB database system as part of the browser which allows you to store data offline within the browser. Same browsers also support ServiceWorkers which makes it possible to serve a complete web application in offline mode. Google Chrome and Microsoft Edge also offer the feature of “installing” a PWA app. Such installed apps in Windows 10 and Android, feel and behave like native apps.

Comparison with Other Technologies for Offline Access Use case

At a high level there are 5 choices to build an offline app (there are other options also available like SAP BTP S/4HANA Side by Side Extensions which I have omitted from here.). Each have their own pros and cons. The build effort on all is different. The options are:

• PWA (Progressive Web Application) – PWA’s is a Web technology and not an SAP specific technology but works with OpenUI5 as OpenUI5 is based on open standards. This kind of an app does not require Apache Cordova Container, SMP or any special software or license to develop or to go-live. It can be built using any SAP ERP or S/4HANA version. For the very first time of usage, users have to open the app when online. Users can then either bookmark the app URL or add it to their mobile device’s home screen. After that every time they open it, even when they are offline, it’ll open as if it was installed on the device. On Android and Windows 10 systems they behave very much similar to native installed apps. Microsoft Edge and Chrome automatically provide option to install them.
  
  
  
  1. Pros – Build once run anywhere. They are not required to be published on any app store and thus also do not require corporate mobile management solutions to be managed. Are OS independent. Apps works on Windows, Apple iOS, and Android in offline mode. Apps are responsive, therefore same app can be used on desktop, laptop, tablet or mobile device. Existing backend logic can be used by wrapping existing Function Module based APIs in a HTTP service without any major change. Easy to maintain as the code resides in SAP S/4HANA or SAP BTP like any other normal Fiori app. Works with integrated or external barcode scanners (for example, Zebra devices or bluetooth scanners).
  
  
  2. Cons – Performance can be slower than Native apps. Native features may not always work to the best of the ability for example: UI5 Library delivered Barcode scanning is little bit slower and clunkier than it would be in native apps (though QR Code scanning works really well in UI5). Once installed, these apps look and feel like native Apps in Windows 10, 11 and Android but not in iOS. RFID/NFC support is experimental.
  
  
  
  


• Non-SAP Native App – These apps are standard Android or iOS apps (Non-SAP) which talk to S/4HANA HTTP/S APIs.
  
  
  
  1. Pros – Run faster, better performance. Existing backend logic can be used by wrapping existing Function Module based APIs in a HTTP service without any major change. Native features are well supported (for example Barcode scanning). Possible to integrate custom libraries/capabilities, for example, the ones available on Zebra handheld Devices.
  
  
  2. Cons –Apps needs to be installed on the device and the installation must be managed in some way, either by using company app store or public app store. Separate app required to be built for Apple iOS, Android and Windows leading to higher effort and costs.
  
  
  
  


• Cordova Apps/Hybrid Apps using SAP Mobile Services - These are normal Fiori UI5 HTML apps which are wrapped in Cordova Native container. They are installed as Native apps and are required to be published on either company’s internal app store or on public app store.  They require signing and Hybrid build as provided in WebIDE. This option is also very similar to the Fiori Client approach. SAP Fiori Client has been deprecated by SAP and will be taken out of App stores in 2022 therefore SAP recommends moving away from it. See blog Update to SAP Fiori Client strategy in context to Fiori In-Store Merchandising — SAP note # 2992772 .... However, it is still possible to publish your own Fiori client in the app stores.
  
  
  
  1. Pros – Native device features, such as Mobile Barcode scanning, are available in Cordova wrappers. Lower effort and cost to build as compared to native apps.
  
  
  2. Cons – Apps needs to be installed on the device and the installation must be managed in some way, either by using company app store or public app store. Separate app required to be packaged for Apple iOS and Android. Windows app is not supported (The webapp can be deployed on SAP to offer desktop or laptop-based access within customer’s network, with no offline capability).
  
  
  3. Performance - These can be slower than Native apps.
  
  
  4. In general, this option does not offer much more than PWAs in my view.
  
  
  
  


• Native apps using either SAP BTP SDK for Android or iOS – SAP BTP SDK lets you develop native apps in programming language of your choice. They bring the Fiori Design Language to the iOS & Android platform and allows you to tap into the services and functions available on SAP BTP so you can build powerful and elegant native applications.
  
  
  
  1. Pros – Native device features, such as Mobile Barcode scanning, are available out of the box.
  
  
  2. Cons – Apps needs to be installed on the device and the installation must be managed using Mobile Device Management in some way, either by using company app store or public app store. Separate app required to be built for Apple iOS and Android which increases the cost of build and long-term maintenance. Windows is not supported.
  
  
  3. Performance – OData based delta handling is slow in my experience developing these apps for a customer in 2018. That had caused scalability issues for us then. I have not checked the performance of these after that and lot would have had changed by now. There are blogs like this one that guide developers on how to design for performance and do conflict resolution when building offline apps on SAP SMP/CPms.
  
  
  
  


• SAP BTP MDK Multi Channel App – The SAP Mobile Development Kit enables developers and technical business users to build multi-channel applications. It allows you to build your application once, in an integrated development environment, and run it natively on mobile devices (Android & iOS) and as a web application (online) in the browser.

1. 
   
   
   
   1. Pros – Native experience for IOS & Android and web access for browser on Windows. May have lower build and maintenance cost because of single development code line and automatic deployment of updates across platforms.
   
   
   2. Cons – MDK Client App needs to be installed on the iOS and Android device. Installation must be managed for MDK Client app using Mobile Device Management in some way, either by using company app store or public app store. Windows native app is not supported. Offline support for web app is a question mark as I have not been able to find a clear guidance on that.
   
   
   
   

Lifecycle and Extension Support for PWA Applications

PWA is open-source technology shipped by browser vendors and operating system vendors. It has been there for a long time but not popularized earlier. At the moment all major vendors support it. Please read more on google official page on PWA Storage for the web

• Within SAP world, PWA apps are built as a custom app from grounds up and not as SAP standard delivered app. Therefore, enhancements can be made directly in the code.


• End user or business user extensibility and personalization is not available out of the box and should be built by the developer if required.


• You cannot build a Fiori Elements app as an offline PWA app. An offline Fiori app must be a FreeStyle app (Source: Fiori Elements Usage Guidelines).

Browser Support

Source: Introduction to progressive web apps - Progressive web apps (PWAs) | MDN (mozilla.org) and Is service worker ready? (jakearchibald.github.io)

PWAs don't depend on a single API, but rather using various technologies to achieve the goal of delivering the best web experience possible.

The key ingredient required for PWAs is service worker support and IndexedDB support. Thankfully service workers and IndexedDB are now supported on all major browsers on desktop and mobile.

Other features such as Web App Manifest, Push Notifications, and Add to Home Screen functionality have wide support too however these features are not mandatory for you to be able to rollout a PWA app in your organization. Currently, Safari has limited support for Web App Manifest and Add to Home Screen and no support for web push notifications. However, other major browsers support all these features.

Service Workers Browser Support Matrix: https://caniuse.com/serviceworkers

IndexedDB Browser Support Matrix: https://caniuse.com/indexeddb

How Much Can I Store?

Here’s an excerpt answering this from Storage for the web.

In short, a lot, at least a couple of hundred megabytes, and potentially hundreds of gigabytes or more. Browser implementations vary, but the amount of storage available is usually based on the amount of storage available on the device.

Chrome allows the browser to use up to 80% of total disk space. An origin can use up to 60% of the total disk space. You can use the StorageManager API to determine the maximum quota available. Other Chromium-based browsers may allow the browser to use more storage. See PR #3896 for details about Chrome's implementation.

Internet Explorer 10 and later can store up to 250MB and will prompt the user when more than 10MB has been used.

Firefox allows the browser to use up to 50% of free disk space. An eTLD+1 group (e.g., example.com,www.example.com and foo.bar.example.com) may use up to 2GB. You can use the StorageManager API to determine how much space is still available.

Safari (both desktop and mobile) appears to allow about 1GB. When the limit is reached, Safari will prompt the user, increasing the limit in 200MB increments. I was unable to find any official documentation on this.

If a PWA is added to the home screen on mobile Safari, it appears to create a new storage container, and nothing is shared between the PWA and mobile Safari. Once the quota has been hit for an installed PWA, there doesn't appear to be any way to request additional storage.

In the past, if a site exceeded a certain threshold of data stored, the browser would prompt the user to grant permission to use more data. For example, if the origin used more than 50MB, the browser would prompt the user to allow it to store up to 100MB, then ask again at 50MB increments.

Today, most modern browsers will not prompt the user, and will allow a site to use up to its allotted quota. The exception appears to be Safari, which prompts at 750MB, asking permission to store up to 1.1 GB. If an origin attempts to use more than its allotted quota, further attempts to write data will fail.

On Apple devices, the app’s contents are cleared after 7 days of no use.

Conclusion

PWAs are fast becoming a valid alternate to native apps for offline use cases. There are some specific use cases where a native app does make sense, for example an app intended to run on a handheld scanner used in a warehouse may have better outcomes when built natively for that scanner and it’s OS.

But there are a lot of usecases and organizational circumstance which can benefit immensely from offline PWAs because they don’t require any installation, can run on any device securely even if the device is not company managed, are easy and cheaper to maintain and do not require any additional knowledge to build which a normal web developer who knows their craft wouldn’t already know. They look and feel like a normal Fiori app.

Though, I must point out that the effort to build these is more than effort to build a normal online Fiori app as these are freestyle apps plus there is additional effort required to manage local database sync but generally this is true for any technology for offline apps, most of the time they all cost more than building a normal online app.

The toolsets for building PWA are mature and these apps run beautifully on SAP BTP. Add to that rapidly increasing feature set on browsers and you have a perfect storm brewing which threatens to dislodge native apps from their pole position for offline enterprise use cases.

Update 29 Sep 2022: Microsoft seems highly committed to PWAs and is reducing the gap between capabilities of native Windows apps and PWAs by letting PWA use more real estate now, which was earlier wasted as top bar. See official Microsoft updates detailing this new capability for PWAs: https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel-gap-native-web-window-controls-overlay/