Preface – This post is part of the UI5 Programs series.
Table of Contents
Introduction
Whenever we create a UI5 application using Fiori Wizard, it creates the full layout of the App by itself. With the layout, it also creates required Manifest.json file with this. Also, it asks for required service, and if provided add a service with an unnamed model within the Manifest file. This model is the default OData model for the full application.
In many cases, we need multiple OData services for a single App. In that case, it gets important to manually add OData services with named Models. These models have to be accessed via their respective name from controller files. In this article, we will show how to create and use both named and unnamed OData models in UI5.
Adding OData Services in Manifest
To access an OData or XSOData in UI5, we follow following three steps:
- Add a new service in Manifest
- Add a new model in Manifest
- Get this Model in Controller
Add a new service in Manifest
In the Manifest, you need to an OData Service as shown below:
"dataSources": {
"oDataServiceName": {
"uri": "<Your Service Name>",
"type": "OData",
"settings": {
"odataVersion": "2.0",
"localUri": "<local Metadata>",
"annotations": [
"annotation0"
]
}
}
}
Here we have added a new OData service and called it “oDataServiceName”. Then we have added the following:
- uri: This is name of the service. In case it is an ABAP OData service then it looks like this: “/sap/opu/odata/sap/<name_of_OData>;v=0002/”
And in case it is XSOData and accessed via MTA file, then it looks something like this:
“../<MTA_Service_Name>r/xsodata/<Name_of_XSODATA>.xsodata/” - type: For OData case it is always “OData”
- settings: This is the place where we provide additional information like:
- odataVersion: OData is getting updated on regular basis, hence we use the one compatible with UI5 or our requirement
- localUri: Local URI points to the local service in case we link our OData to a local mock-up data. This is required mainly during development and connect a mock-up data to our service
- annotations: This is an array of the annotation file attached to a particular service. It is used for adding frontend based annotations. We will discuss this functionality in detail in a different article.
Add a new model in Manifest
In the Manifest, you need to an OData Model as shown below:
"ODataModelName": {
"type": "sap.ui.model.odata.v2.ODataModel",
"settings": {
"defaultOperationMode": "Server",
"defaultBindingMode": "TwoWay",
"defaultCountMode": "Request",
"json": true,
"defaultUpdateMethod": "PUT",
"useBatch": false
},
"dataSource": " oDataServiceName ",
"preload": true
}
Here we have added a new OData model and called it “ODataModelName”. Then we have added the following:
- type: It is again for specifying the OData Model version. It should be similar to the one we mentioned in service above
- settings: It is used to add the following relevant configurations:
- defaultOperationMode: It tells if the required operations (filter/orderby/etc) are executed on server or client. It mostly remains “Server” for OData use case.
- defaultBindingMode: A binding mode can be “OneWay”, “TwoWay” or “OneTime”. These values mean exactly how the services are called. For Smart operations, we always use “TwoWay”
- defaultCountMode: It represents if we need to get count separately via a request or via inline count. The values can be: “Inline”, “InlineRepeat”, “None” or “Request”
- json: It tells the type of Output of this model is JSON or not.
- defaultUpdateMethod: It tells if we will use “Merge” or “Put” for our update operation.
- useBatch: It tells if we are using batch operations or not. Batch is OData operation.
- dataSource: It is where we specify the name of service we have create earlier.
- preload: It tells, if we need to load this model before it is called or not. Generally, we load all our Models when we open our UI5 App.
In above use case, it is a named model. You can also create an unnamed model. For that you only need to make the name of the model as “”. Yes, that is blank. In this way it becomes a default model. In full Manifest file below, we have added both types of models.
Accessing named OData Model via Controller
Once we have given a name to an OData model (above we have called it “ODataModelName”), then we can access this model in controller via using below code:
// Binding based on Model defined in Manifest
var oModel = this.getOwnerComponent().getModel("ODataModelName");
Now this local variable “oModel” can be used to access the model data and bind to whatever table or element you want via controller.
Accessing default or unnamed OData Model via Controller
The concept is similar to the named Model, just we don’t mention name of any model here.
// Binding based on Model defined in Manifest var oModel = this.getOwnerComponent().getModel();
Now this local variable “oModel” can be used to access the model data and bind to whatever table or element you want via controller.
Full Manifest Code
{
"_version": "1.12.0",
"sap.app": {
"id": "testApp",
"type": "application",
"i18n": "i18n/i18n.properties",
"applicationVersion": {
"version": "1.0.1"
},
"title": "{{appTitle}}",
"description": "{{appDescription}}",
"sourceTemplate": {
"id": "servicecatalog.connectivityComponentForManifest",
"version": "0.0.0"
},
"dataSources": {
"oDataServiceName": {
"uri": "<Your Service Name>",
"type": "OData",
"settings": {
"odataVersion": "2.0",
"localUri": "<local Metadata>"
}
},
"oDataDefaultServiceName": {
"uri": "<Your Service Name>",
"type": "OData",
"settings": {
"odataVersion": "2.0",
"localUri": "<local Metadata>"
}
}
}
},
"sap.ui": {
"technology": "UI5",
"icons": {
"icon": "",
"favIcon": "",
"phone": "",
"phone@2": "",
"tablet": "",
"tablet@2": ""
},
"deviceTypes": {
"desktop": true,
"tablet": true,
"phone": true
}
},
"sap.ui5": {
"flexEnabled": false,
"dependencies": {
"minUI5Version": "1.65.6",
"libs": {
"sap.ui.layout": {},
"sap.ui.core": {},
"sap.m": {}
}
},
"contentDensities": {
"compact": true,
"cozy": true
},
"models": {
"i18n": {
"type": "sap.ui.model.resource.ResourceModel",
"settings": {
"bundleName": "testApp.i18n.i18n"
}
},
"@i18n": {
"type": "sap.ui.model.resource.ResourceModel",
"uri": "i18n/i18n.properties"
},
"ODataModelName": {
"type": "sap.ui.model.odata.v2.ODataModel",
"settings": {
"defaultOperationMode": "Server",
"defaultBindingMode": "TwoWay",
"defaultCountMode": "Request",
"json": true,
"defaultUpdateMethod": "PUT",
"useBatch": false
},
"dataSource": "oDataServiceName",
"preload": true
},
"": {
"type": "sap.ui.model.odata.v2.ODataModel",
"settings": {
"defaultOperationMode": "Server",
"defaultBindingMode": "TwoWay",
"defaultCountMode": "Request",
"json": true,
"defaultUpdateMethod": "PUT",
"useBatch": false
},
"dataSource": "oDataDefaultServiceName",
"preload": true
}
},
"resources": {
"css": [{
"uri": "css/style.css"
}]
},
"rootView": {
"viewName": "testApp.view.App",
"type": "XML",
"id": ""
},
"routing": {
"config": {
"routerClass": "sap.m.routing.Router",
"viewPath": "testApp.view",
"controlId": "app",
"bypassed": {
"target": ["NotFound"]
}
},
"routes": [{
"name": "Tab_1",
"pattern": "",
"target": ["masterTarget", "Tab_1"]
}, {
"name": "Tab_2",
"pattern": "Tab_2",
"target": ["masterTarget", "Tab_2"]
}],
"targets": {
"masterTarget": {
"viewType": "XML",
"transition": "slide",
"controlAggregation": "masterPages",
"viewId": "idMaster",
"viewName": "Master",
"viewLevel": 1,
"controlId": "Splitapp"
},
"Tab_1": {
"viewType": "XML",
"transition": "slide",
"controlAggregation": "detailPages",
"viewId": "idTab_1",
"viewName": "Tab_1",
"viewLevel": 1,
"controlId": "Splitapp"
},
"Tab_2": {
"viewType": "XML",
"transition": "slide",
"controlAggregation": "detailPages",
"viewId": "idTab_2",
"viewName": "Tab_2",
"viewLevel": 2,
"controlId": "Splitapp"
}
}
}
},
"sap.platform.hcp": {
"uri": "webapp",
"_version": "1.1.0"
}
}
0 Comments