At Pangaea Solutions, our team is always looking for ways to enhance and streamline your experience with SAP platforms. If you’ve landed on this article, chances are your company is developing in SAP HANA and you’re interested in best practices and ways to optimize your development process. In this post, we will be covering how you can leverage the Manifest.json file often found in newly developed SAPUI5 applications.
SAPUI5 applications that run from a Component.js file have the ability to use an application descriptor file, more commonly known as the Manifest.json. The manifest is a useful tool for defining application settings and employing it can help shorten and optimize your app’s JavaScript files. However, the manifest itself can get complex, and it’s not always easy to recognize if you should be looking at the manifest or at your JS controllers. For reference purposes, the three most valuable use cases for the manifest file are listed below, along with examples of their syntax.
Utilize the Manifest.json for Models
It’s possible to build any models your app uses in the manifest, rather than having to create them in Component.js or in your controllers:
—————————————————-
“sap.ui5”: {
“models”: {
“modelName”: {
“type”: “sap.ui.model.odata.v2.ODataModel”,
“dataSource”: “mainService”,
“settings”: {
“metadataUrlParams”: {
“sap-documentation”: “heading”
},
“defaultOperationMode”: “Client”,
“defaultCountMode”: “Inline”
}
}
—————————————————-
Models defined this way can be accessed in your controllers via a call such as:
“this.getOwnerComponent().getModel(‘modelName’)”.
Properties that are part of the mParameters object in your model class’ constructor can be set under the “settings” heading when the model is created in the manifest. This means that you can customize the behaviour of your models without using controller code.
Utilize the Manifest.json to Define Data Sources
You’ll notice that the model above lists a “dataSource” – this determines what URI the model will use for CRUD operations, and can also be defined in the manifest:
—————————————————-
“sap.app”: {
“dataSources”: {
“mainService”: {
“uri”: “/destinations/DestinationName/ServiceName.xsodata/”,
“type”: “OData”,
“settings”: {
“odataVersion”: “2.0”,
“localUri”: “localService/metadata.xml”
}
}
}
}
—————————————————-
A data source’s URI can be a full (absolute) URL, or a relative path involving Hana Cloud Platform Destinations, as above. Remember that any destinations you access will also need to be defined in your neo-app.json file.
At this point, you’re all ready to read data from your back-end just by binding properties from your model to your view (i.e. by binding a list’s items to (“{modelName>EntitySetName}”). In theory, a simple read-only app that uses the manifest could work without any controller files at all!
Use the Manifest.json to Determine Routing
SAPUI5’s Routing concept allows your app to switch its display between views with a single method call and the manifest can be used to define your routes:
—————————————————-
“sap.ui5”: {
“routing”: {
“config”: {
“routerClass”: “sap.m.routing.Router”,
“viewType”: “XML”,
“viewPath”: “path.to.view.folder”,
“controlId”: ” controlId “,
“controlAggregation”: “detailPages”,
“bypassed”: {
“target”: [
“notFound”
]
},
“async”: true
},
“routes”: [
{
“pattern”: “ObjectType/{id}”,
“name”: “object”,
“target”: [
“detail”
]
}
],
“targets”: {
“detail”: {
“viewName”: “Detail”,
“viewLevel”: 1
“viewId”: “detail”,
},
“notFound”: {
“viewName”: “NotFound”,
“viewId”: “notFound”
}
}
}
}
—————————————————-
The controlId is the ID of the view control that will display routing targets. This could be your overall App control, or it could be a Page that only takes up part of the UI space. For instance, in a master-detail app, you can use the detail page as the routing control, so that it displays whichever object was selected in the master list.
When your Component is initialized, it should call “this.getRouter().initialize();” to begin routing. Afterwards, your controllers can make routing calls.
To walk through how this works, consider the routing call:
“sap.ui.core.UIComponent.getRouterFor(this).navTo(“object”, {id : 2});”
This line attempts to follow the route with name “object” and passes parameter “id = 2” to it. Since the route with the name “object” has target “detail”, it will select the “detail” target, which defines view Name “Detail.” This means that the routing control will attempt to display path/to/view/folder/Detail.view.xml.
Also, since the route included a parameter, it will call its “patternMatched” event with that parameter. Your controller can call router.attachPatternMatched with a function that reads the parameter and binds an appropriate model object to the newly displayed view.
One other element to note is the “bypassed” object defined in the routing config – since it defines a target of “notFound”, any routing call that fails will instead attempt to display NotFound.view.xml.
Now that you’re familiar with these three ways to utilize the Manifest.JSON file in SAP HANA, we would love to hear from you if you have any questions about this topic! Please leave a comment down below.
If you’d like to share your thoughts or wish to discuss any of our products and accelerators, please don’t hesitate to contact us.
Stay tuned for next month’s article on the 3 techniques that you can use today to secure your applications in SAP.
Thomas Rautenbach, Architect
Thomas Rautenbach has over 20 years of diverse systems experience with a strong focus on system and integration architecture and software design and development. He has detailed technical, functional and system knowledge across the SAP technology platform, including extensive experience with the Finance, Supply Chain, Sales and Distribution, and Human Resources modules.
Follow Pangaea Solutions on LinkedIn
