OData models form the backbone of data binding in SAPUI5 applications, allowing developers to seamlessly connect user interfaces with backend OData services.
With the evolution from OData V2 to OData V4, SAP has introduced improved capabilities for handling data operations, batching requests, and leveraging server-side processing. In this post, we’ll explore how the sap.ui.model.odata.v4.ODataModel class works, its configuration options, and how developers can use it to consume both OData V4 and OData V2 services within their SAPUI5 projects.
The class sap.ui.model.odata.v4.ODataModel provides the implementation of the model, which is intended for the consumption of OData V4 services. The OData V4 model supports the following functionalities:
Instead of smart controls (sap.ui.comp library) or sap.ui.table.AnalyticalTable (for analytical table scenarios), the SAP Fiori elements building blocks (sap.fe.macros) must be used with the OData V4 model in SAPUI5. The tree table isn’t supported in combination with the OData V4 model in SAPUI5.
The OData V4 model is primarily designed to work with OData V4 services. Nevertheless, OData V2 services can also be consumed with this model, but this requires an adapter, which is supplied by SAP.
In the following sections, we’ll see how an instance of the OData V4 model can be created and also how we can consume OData V2 services using the OData V4 model.
To instantiate an OData V4 model, only one map must be passed as a mandatory parameter. This map must contain at least the serviceUrl of the service. All other parameters are optional. This listing shows a code example in which an OData V4 model is instantiated.
let oModel = new sap.ui.model.odata.v4.ODataModel({
serviceUrl: "/sap/opu/odata4/IWBEP/V4_SAMPLE/default/IWBEP/V4_GW_SAMPLE_
BASIC/0001/"
});
If the OData service and the OData model were integrated via the application descriptor (manifest.json), which is also the more common way, this would look like the code below for this example.
{
"sap.app": {
"dataSources": {
"default": {
"uri": "/sap/opu/odata4/IWBEP/V4_SAMPLE/default/IWBEP/V4_GW_SAMPLE_
BASIC/0001/",
"type": "OData",
"settings": {
"odataVersion": "4.0"
}
}
}
},
"sap.ui5": {
"models": {
"": {
"dataSource": "default",
"settings": {}
}
}
}
}
The syntax of the OData V4 model’s constructor is as follows: new sap.ui.model. odata.v4.ODataModel(mParameters). Here, mParameters represents a map that can contain the following properties:
The URL (or an array of URLs) from which the annotation metadata is to be loaded. The specified annotation files are integrated into the service metadata in the order in which they are listed, with the last file loaded taking precedence. If annotations overlap, they are overwritten. However, if an annotation file contains other elements such as type definitions that have already been integrated, this leads to an error.
Determines whether the OData model automatically generates the system query options $select and $expand based on the binding hierarchy. Dynamic adjustments to the binding hierarchy aren’t taken into account. This parameter, which has been available since version 1.47.0 and since version 1.75.0, also allows the inclusion of navigation properties in $select via property paths.
Specifies whether the following resources are requested as early as possible:
Although the $metadata root document and the annotation files are retrieved, they are only converted from XML to JavaScript Object Notation (JSON) if they are actually required. This function has been supported since version 1.53.0. Note that the default value can be changed to true in future versions. To additionally speed up the start of an SAPUI5 component, you can also use the manifest model preload setting.
Determines how the model processes batch requests: With $auto, the model’s requests are combined into a single batch request and sent automatically before rendering. With $direct, the requests are sent immediately and without batching. All other values result in an error.
Defines how batch requests for application groups are handled. This is an assignment of application group IDs to an object that has exactly one property. Permissible values for this property are API, Auto, and Direct.
Defines a map of HTTP headers, which should be added to requests.
Specifies whether all annotations from the service metadata and cross-service references should be ignored. Only the value true is permitted. In this case, only the annotations from the annotation files specified in annotationURI are taken into account. This parameter isn’t transferred to value list models.
Additional assignment of URL parameters that are used exclusively for $metadata requests. Note that the parameter sap-context-token is only relevant for the master $metadata of the service, but not for cross-service references.
Defines the version of the OData service. Supported values are 2.0 and 4.0.
The operation mode for filtering and sorting. As of version 1.39.0, the operation mode sap.ui.model.odata.OperationMode.Server is supported. All other operation modes, including undefined, lead to an error if vFilters or vSorters are specified or if sap.ui.model.odata.v4.ODataListBinding#filter or sap.ui.model.odata.v4.ODataListBinding# sort is called.
The root URL of the service from which the data is to be retrieved. The path part of the URL must end with a slash in accordance with the OData V4 specification. It’s possible to append custom OData query options to the root URL of the service, separated by a ?, such as /MyService/?custom=foo. However, OData system query options and parameter aliases lead to an error.
Specifies whether all list bindings for the same resource path share their data so that it’s only retrieved once; only the value true is permitted. In addition, sap.ui.model. BindingMode.OneWay is set as the default binding mode, while sap.ui.model.Binding-Mode.TwoWay isn’t allowed. Note that this makes all bindings read-only, which can be particularly advantageous for value list models.
Specifies whether the <edmx:Reference> and <edmx:Include> directives are supported to load schemas from other $metadata documents and integrate them into the current service (cross-service references).
The group ID used for update requests. If no specific group ID is specified, the ID from mParameters.groupId is used. Permissible values for update group IDs are undefined, $auto, $auto.*, $direct, or an application group ID.
Specifies whether the XMLHttpRequest is called with the withCredentials option so that the user’s credentials are included in cross-origin requests from the browser.
The SAPUI5 framework can consume OData V2 services via an OData V4 model. The framework takes on the task of converting metadata and the data of the V2 service so that it can be used with the V4 model. For the developer, it basically makes no difference whether a V2 or V4 service is behind the V4 model. However, as OData V4 supports some functionalities that aren’t supported by OData V2, certain functions of the OData V4 model can’t be used. These restrictions are as follows:
To use an OData V2 service in an OData V4 model, the service and the model must be integrated via the app descriptor as follows in the listing below. It’s important that the odata-Version of the data source is set to 2.0 and that sap.ui.model.odata.v4.ODataModel is selected as the type for the model. In addition, at least SAPUI5 version 1.49 is required.
{
"_version": "1.1.0",
"sap.app": {
"dataSources": {
"default": {
"uri": "<ODataV2 Service URL>",
"type": "OData",
"settings": {
"odataVersion": "2.0"
}
}
},
},
"sap.ui5": {
"dependencies": {
"minUI5Version": "1.49"
},
"models": {
"": {
"dataSource": "default",
"settings": {
"autoExpandSelect": false,
"operationMode": "Server",
"synchronizationMode": "None"
},
"type": "sap.ui.model.odata.v4.ODataModel"
}
}
}
}
As the available types in OData V4 and OData V2 differ, it’s necessary to map between the datatypes. The following OData V2 types are supported and mapped:
Some datatypes are represented differently in OData V2 and OData V4. The application developer should use only the OData V4 values. The framework ensures that these values are converted properly before sending the request to the backend (e.g., as a value of a key property) and after receiving the response from the backend.
The OData V4 model brings greater flexibility, performance, and standardization to SAPUI5 applications. While it’s optimized for OData V4 services, SAP provides an adapter that enables backward compatibility with OData V2, helping developers transition existing projects without major rewrites. By understanding how to configure the model, define parameters, and manage service integration, developers can take full advantage of SAPUI5’s powerful data-binding framework to build scalable, efficient SAP Fiori applications.
Editor’s note: This post has been adapted from sections of the book SAPUI5: The Comprehensive Guide by Rene Glavanovits, Martin Koch, Daniel Krancz, and Maximilian Olzinger. Rene is an SAP consultant and developer who specializes in the latest SAP technologies. Martin conducts training for SAP and has developed four training courses on the topics of SAPUI5, SAP Fiori, cloud integration, and cloud security. Daniel is a software developer and consultant who focuses on full-stack development. Maximilian is a software developer and consultant.
This post was originally published 11/2025.