In the Part 2 of this 3 part series, we discussed what an the minimum requirements for packaging, and when the drag-and-drop interface can be used as opposed to the Advanced Configuration File. The purpose of this, the last in our blog series, is to examine the Advanced Configuration File in more detail, providing insight into how it can be constructed and what it should contain.
The need for ACF arises when user wants to
- Define an app (which is not listed)
- Define additional capabilities for an app, which a user couldn’t accomplish in other ways. Examples of such capabilities are: dependencies for app, offline support for the app, inter-app communication.
The advanced configuration file is a .json file that describes an array of components (using properties) that should be packaged with the app. Your ability to create an advanced configuration file is dependent on selecting I want to create a local launchpad with only the apps I want to mobilize on the Fiori App Scenario page.
The settings from ACF overrides settings for the app that are described in other places, such as the manifest file or titles, icons etc.
The configuration file should conform to JSON syntax. The basic structure is:
Sample Code
{
"appConfig": {
...
},
"applications": [
...
]
}
Property | Comments |
applications | The applications property determines what apps will be packaged. This section is compulsory. The applications property is an array, comprised of the following subproperties: id, intent, title, url, scenario,reuse, and offline |
applications: id | Fiori component ID. |
applications: intent | Optional but needed if inter-app navigation is required. Applications that have an intent property are mapped to tiles in the launchpad. The display name for the tile is derived from the title property or from the application manifest file if no title is provided. Icons shown on the tile are derived from the application manifest file. Syntax: <semantic object>-<action> |
applications:title | Optional but needed if the app is deployed to the FES with no manifest or app descriptor. Display name for the app's launchpad tile. This overrides any title obtained from the application manifest file. Syntax: <string> |
applications:url | The url property reflects the resource path (the location of the manifest and resources files) associated with the installed Fiori app, which will be the underlying app installation path. On FES with UI Add-On 2.0, this path is automatically determined; on earlier systems, this value needs to be supplied. |
applications:scenario | Indicates the component that provides the boot logic and offline store definitions for offline-enabled apps. When "scenario":true, the packager checks the application manifest file for the offline setup. |
applications:reuse | "reuse":true indicates that the component is a reuse component, such as a common library. |
applications:offline | Set to true to create offline OData stores. Offline apps require SAP Mobile Platform ("fioriURLIsSMP":true). |
applications:cloudComponentId | Used in FCE scenario to identify subscription in Hana cloud cockpit. |
applications:cloudComponentVersion | Used in FCE scenario to identify the version of cloud component. |
applications:manifest | If an app doesn’t have manifest file, the manifest file content can be mentioned here. |
Some examples of ACF
1. ACF for a single app in FCE scenario
id = your app id (it's located in webide > app_project folder > webapp > manifest.json
cloudComponentId = app subscription name in HCP
url = the location under which the application is registered in Fiori Launchpad. By default when deploying the app via SAP WebIDE it is /sap/fiori/[heliumhtml5appname] ... it is NOT the subscription name but the name of the app that you subscribe to.
{
"applications":[
{
"id":"com.sap.fiori.products",
"cloudComponentId":"productlistingsub",
"url": "/sap/fiori/productlisting"
}
]
}
2. ACF for a single app in FES scenario
If FES has UI Add on 2.0 and the app has manifest file, then ACF can be very simple with just the app id.
{
"applications": [
{
"id": "nw.epm.refapps.shop"
}
]
}
3. ACF with multiple apps with library and inter-app navigation
The following advanced configuration file for three applications defines inter-app navigation intents for a FES that has UI Add-On 2.0, and where the apps have been deployed to the FES with manifest files.
{
"applications":[
{
"id":"cus.crm.mycontacts",
"intent":"ContactPerson-MyContacts",
"title":"My Contacts",
"url":"/sap/bc/ui5_ui5/sap/crm_mycont"
},
{
"id":"cus.crm.myaccounts",
"intent":"Account-MyAccounts",
"title":"My Accounts",
"url":"/sap/bc/ui5_ui5/sap/crm_myaccounts"
},
{
"id":"sap.cus.crm.lib.reuse",
"url":"/sap/bc/ui5_ui5/sap/crm_lib_reuse/sap/cus/crm/lib/reuse",
"reuse":true,
"scenario":true
}
]
}
And that's it! These are just a couple different scenarios where the Advanced Configuration File can be useful to SAP HCP, mobile service for SAP Fiori. We'll do our best to add more examples in the future.
In this three part series, we covered quite a bit of ground. We started by talking about the fundamentals of app packaging and why you should use this feature. Then we moved on to a discussion of what types of apps can actually be packaged, and more importantly, when an Advanced Configuration File is required. In the last and final part of our series, we dove deep into the structure of the Advanced Configuration File itself.
A special thanks to radhakrishna.bodapati2 for providing the technical content for this section of the series!
