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. |
As the astute observer will quickly notice, part of what I said just now is not true. It's not really a native app, it's a hybrid. And more specifically the output is an SAP Fiori packaged app. An SAP Fiori packaged app is a hybrid app type, built using the Cordova plugin architecture, supplemented with the SAP Kapsel SDK. More simply a hybrid app is an application where the UX is implemented using HTML/Javascript/Css and is rendered within a native container. The container manages the User Experience and also enables the app, through the plugin interface, to communicate with assets outside of the container. Think things like barcode scanner, beacons, sensors, other device features that normally wouldn't be accessible to a web app. SAP includes the Kapsel SDK (http://scn.sap.com/docs/DOC-65386) as part of the container. Kapsel enables the application to operate within the SAP mobility solution framework, which includes SAP HCP, mobile service for SAP Fiori and SAP HCP, mobile service for development and operations in the cloud and SMP on premise.
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 term packaging refers to the act delivering the User Experience of a Fiori app as part of app deployment rather than as part of app execution. To get a better picture of packaging, it is helpful to understand how the App Store Fiori client works (this is identical to the custom SAP Fiori client). When using the SAP Fiori client, the user is prompted to enter the destination URL as part of initial app configuration. Tools like SAP HCP, mobile service for app and device management can make that easier through configuring settings via MDM or the Configuration Discovery service, but in general the app doesn't know anything about the backend until it loads for the first time. At that point, it requests the URL specified during the configuration. Once the user successfully authenticates, the app content starts to download in real-time. This includes all the UX resources, such as HTML, CSS, Javascript and any multimedia that are part of the app. These resources are downloaded as they are accessed. Also download in real-time is the UI5 runtime dependencies on which the app is built.
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.
Summary
So we know what packaging is, and we know why packaged apps can benefit the end user.
What's next?
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.
- SAP Managed Tags:
2 Comments
