In Part 1 of this 3 part series, we discussed what an SAP Fiori packaged app “is”, and why a customer would want to package their apps. Part 2 of this series discusses how a developer or publisher would package an app using SAP HCP, mobile service for SAP Fiori.
The first question that should be answered is this – what apps can be packaged?
The simple answer is this – any app built referencing the 1.28 SAP UI5 framework or later can be packaged.
The key thing to note here is that in order for an app to be packaged, it must have an App Descriptor (SAP Web IDE Developer Guide). The App Descriptor basically tells the package what components to package. App Descriptors became automatic for most templates in SAP Web IDE. So for any custom apps you might consider building, it is strongly recommended that you use that framework at a minimum. New Fiori apps built using this framework or greater also include the manifest. All of this makes packaging much easier.
Installing the UI Add-on 2.0 (link) will add 1.30 support to your Netweaver gateway and allow you to build apps with an App Descriptor automatically maintained by Web IDE. SAP Fiori, cloud service supports specifying the SAPUI5 Version via the SAP Fiori Configuration Cockpit. If you select the Innovation version, you will be ensured that you have selected a SAPUI5 version that will create an App Descriptor.
Installing the UI Add-on or specifying the Innovation SAPUI5 version in the cloud only affects NEW Fiori/UI5 apps that you build. What about the existing apps, many of whom were created using 1.28 (including most of the SAP Fiori, cloud service apps)? The answer here is….it depends. To answer that question requires us to talk about the next topic, how do I invoke the packager with SAP HCP, mobile service for SAP Fiori?
Creating an SAP Fiori Packaged app with SAP HCP, mobile service for SAP Fiori
Dhimant’s blog, Part 3 (link here) discussed the Fiori Mobile app workflow. In particular he showed this screen:
If you select the first radio button, you have indicated (whether you know it or not!) that you want to create an SAP Fiori packaged app.
After selecting this option, the next thing you’ll do is pick a server. Once you’ve done that, the mobile service for SAP Fiori will attempt to open a dialog with the Fiori server in order to determine how to render the next page shown below:
If the Fiori server is determined to be an SAP Fiori, cloud service destination, SAP will create and display a list that includes apps for which we can provide the App Descriptor, even though it’s not built into the app itself. These apps, even though they have no App Descriptor, can be packaged using the drag-and-drop interface without any additional effort. They can be combined at the publisher’s discretion to create any LOB-style app that can be imagined.
Remember that the mobile service for SAP Fiori can mobilize both on-premise Fiori apps as well as Fiori, cloud service apps. For an on-premise server, the first thing we do is check for the UI 2.0 Add-on. If this component is found, SAP will render a dynamic list of apps that can be packaged without any additional effort. These apps can, as in Fiori, cloud service be combined by the publisher to create LOB-style apps. To build this list, start with the list of apps that we already know about. We filter this list to only include the apps that we know to be installed. To that we add any app for which we determine to have an App Descriptor in its definition. The result is a list of all apps that can be packaged.
If the on-premise Fiori server does NOT have the UI 2.0 Add-on installed, we treat it in a way that is similar to SAP Fiori, cloud service in that we display a list of apps for which we provide an App Descriptor.
But what about everything else? As I mentioned previously, any 1.28 or above app can be packaged. But in some of the scenarios I’ve described, the list is potentially incomplete. How do they get packaged? The answer to that question is the Advanced Configuration File.
Using the Advanced Configuration File
Let’s start by saying that the drag-and-drop approach and the Advanced Configuration File approach are mutually exclusive. You either drag and drop components or you define the app completely within the ACF.
Keep in mind that you can use an ACF to define your app any time you want. But let’s start with the basic scenarios where you MUST create an ACF.
- For a Fiori, cloud service destination an ACF is required for any app outside of the apps listed in the drag-and-drop list.
- For an on-premise Fiori server without the UI Add-on 2.0 installed, an ACF is required for any app outside the apps listed in the drag-and-drop interface.
- If you want to combine anything that’s on the drag and drop list with something that is not, an ACF is required.
Additional, but more specific scenarios where you must use an ACF:
- If you want one app to be able to communicate with another app (cross app intents). For example, if you have “My Leads” that has a customer contact which should be loaded in the “My Contacts” app.
- If you want your app to support local access to data (offline).
At this point you might be wondering how and where the App Descriptor comes back into play. Remember that to be packaged, an app must have an App Descriptor. For some of the apps we supply it for you, for 1.30+ apps it’s created and managed automatically in Web IDE. What if I’m using a system that has 1.28, like a lot of our on-premise customers? The answer is that the file has to be created. Unfortunately there is no way getting around that. Directions for how to create an App Descriptor can be found here (https://help.hana.ondemand.com/webide/frameset.htm?07cbc55eba264c4c9bcf81c501601fbf.html).
The App Descriptor can be associated with the project itself by the developer OR, it can be included in the Advanced Configuration File during build time. See how it all comes back together!
We now know what types of apps can be packaged and more importantly, how a publisher interacts with SAP HCP, mobile service for SAP Fiori service to package an app. And we know in some scenarios we need to use the Advanced Configuration File. But what does this file look like? What can it contain?
Stay tuned for part 3 of this blog, where cover the Advanced Configuration File in detail!