The OData protocol became an OASIS standard with the release of OData 4.0. SAP NetWeaver 7.50 SP 04 started support for both OData 2.0 and OData 4.0.
Starting with SAP S/4HANA 2020 FSP1, OData 4.0 is also supported by the ABAP RESTful application programming model. In earlier releases of SAP S/4HANA and SAP Business Suite EHP8, you could only build OData 4.0 services using code-based implementations of SAP Gateway OData 4.0 framework APIs.
Let’s look at what’s new or different with OData 4.0 in SAP Gateway. In this post, we’ll concentrate on features in OData 4.0 that are most important for SAP products. A complete list of the changes in OData 4.0 compared with OData 2.0 can be found in the documentation at www.odata.org/documentation.
To set the stage, let’s highlight the guiding principle of the OData 4.0 paradigm— the reduction of data. This reduction is achieved through a more powerful query language and a new, optimized JSON protocol. At the same time, you can leverage richer metadata than in OData 2.0.
JSON is the recommended and default format used by OData 4.0 services. The JSON format has been redesigned completely in OData 4.0. The amount of data transferred over the wire has been reduced to the bare minimum. All unnecessary metadata has been removed so that the payload more or less only contains name-value pairs. With this approach, you can achieve a reduction in payload size up to 60 percent, as shown below.
Through the enhanced query language capabilities in OData 4.0, you can request exactly the desired subset of data with fewer roundtrips than in OData 2.0. Let’s look at two examples of the new query language’s capabilities.
Analytical query options such as groupby also come as part of OData 4.0, as shown in the figure below. Therefore, the result set can be significantly smaller than the source. An example is shown in the following syntax:
GET Sales?$apply=groupby((Product),aggregate(Amount with sum as Total))
In OData 4.0, it’s possible to filter expanded entities on each level. Consider a scenario where you want to retrieve one or more business partners located in one city (e.g., Walldorf) alongside those sales orders that have a gross amount larger than a certain threshold, with the objective of retrieving only those sales order items that contain the product HT-1041.
The corresponding request in OData 4.0 appears as follows:
/BusinessPartnerList?$filter=Address/City eq 'Walldorf'&
$expand=BP_2_SO($filter=GrossAmount ge 1100;
$expand=SO_2_SOITEM($filter=Product/ProductID eq 'HT-1041'))
The simplified results of the request are shown in this figure, where we’ve marked the values that fit the filter conditions.
Whereas in OData 2.0, you could only have navigation properties that point from one entity set to a second entity set in the same OData service, you can now have navigation properties that point to an entity of a referenced service.
Cross-service navigation can, for example, be used for reusing services. Consider an OData service used as a search help that can be leveraged by several other OData services. The portioning of services also helps speed up consumer applications because it allows for the lazy loading of huge service models.
A clear separation exists between nonmodifying and modifying requests that can’t be expressed via normal CRUD-Q requests. In contrast, the new edm:Action element defines the signature of an action describing a modifying request that goes beyond a simple CRUD request, and the edm:Function element defines the signature of a function that can be used to query data in a way that can’t simply be expressed with a classic OData query option.
In OData 4.0, vocabularies and annotations play an important role. SAP Gateway already supports SAP-specific annotations, such as sap:updatable, sap:creatable, and so on, and also supports OData 4.0 annotations.
Editor’s note: This post has been adapted from a section of the book SAP Gateway and OData by Carsten Bönnen, Ludwig Diehl, Volker Drees, André Fischer, and Karsten Strothmann.