In Dhimant Patel’s blog, How to use SAP HCP, mobile service for SAP Fiori, demonstrated end-to-end how to take a custom UI5 app and transform it into a branded native app that can be installed, managed, monitored and analyzed through SAP HCP, mobile service for SAP Fiori. The purpose of this blog is to dive a bit deeper into a concept of “packaging”, crucial to delivering the type of User Experience that consumers are accustomed to.
This blog is broken into three parts:
|Part 1||Covers the basic definition of what we mean when we use the term packaging, and why you want to package your apps.|
|Part 2||Explains what types of apps can be packaged, and covers when to use an Advanced Configuration File.|
|Part 3||Decomposes the Advanced Configuration File and shows the reader how to build one.|
But what exactly is “packaging?” What gets packaged? How can I package apps? What apps can I package? Great questions!
What exactly is “packaging?”
The benefit to this approach is that the app content should always be up to date, as it is requested online. The drawback is that the content has to be downloaded in real-time, which can at times distract from the user experience.
When creating an SAP Fiori packaged app, the UX is embedded in the hybrid app when the app is built. App content is only downloaded for the apps that are specified by the administrator. As such, these apps differ from the Fiori Launchpad, which presents a dynamic and customizable view of apps based on a user’s role. In a packaged app, the Fiori “tiles” are predetermined by the administrator/developer. This makes packaging very valuable when creating Line-of-business style apps. The following items are included in every SAP Fiori packaged app:
- The SAP UI5 runtime
- Fiori app UX resources (HTML, JS, CSS, media)
- Bootstrap code to launch the initial view
- Configuration metadata (describe to the bootstrap code what to show)
Only requests for data are made online, the UX is always loaded locally:
Two of the primary benefits of creating an SAP Fiori packaged app are performance and stability. Loading the UX remotely depends on the availability and throughput of the network. Despite advances in connectivity worldwide, coverage is not ubiquitous globally and bandwidth is not always predictable. Loading the UX locally will always be faster and more reliable than downloading it from a remote server (which may or may not even be reachable). Consumers expect an immediately response UX, and packaging allows SAP to deliver this same experience for a hybrid app to enterprise users. The user is immediately able to start being productive! Since this is a custom app, the configuration details are also built into the app, so the user is not required to enter anything other than his credentials to log on to the system. The drawback is that content updates require an app update, and the apps are in general going to be larger (because of the embedded UX and dependencies). To overcome any app management challenges, SAP HCP, mobile service for SAP Fiori, provides Mobile Place as an enterprise app store. MDM-enforced app management can be implemented quickly and easily through the addition of SAP HCP, mobile service for app and device management, which is tightly integrated. SAP Fiori packaged apps can also be distributed and managed by third party EMMs.
SAP Fiori packaged apps also have the benefit of being able to support local access to data; they can operate if the device is without network connectivity. This does require the app to be enabled to support offline. How to do this is outside the scope of this blog, but look for a blog covering that topic soon.
So we know what packaging is, and we know why packaged apps can benefit the end user.
How exactly do I use SAP HCP, mobile service for SAP Fiori to package my apps? And what apps can be packaged? That is the topic for Part 2 of this 3 part series.