TLDR: Having recently used OData v4 (Open Data protocol version 4) on an extension project I recommend that you seriously consider using it on future projects. It's not as mature as v2 (in terms of SAP support, e.g. with SAPUI5), but it does have a better design and using it makes your developments more future proof. Support from SAP tools and products is improving fast.
OData is an API protocol. It defines how compliant RESTful services can be called and how they behave. Following the protocol gives our APIs consistency. For example, there's an agreed way to specify the filters in a query operation (e.g. OrderNo eq '123') and we don't need to invent a way of doing this every time we build an API. That consistency also means that frameworks like the SAP CAP (Cloud Application Programming Model) & RAP (ABAP RESTful Programming Model) can handle dataset operations like filtering, sorting and updating for us (indeed they can do all of CRUD-Q if the service is 'managed' by the framework).
There are other notable protocols, but OData is very much preeminent in the SAP world. Aside from SAP, other notable members of the OASIS standards body that now sits behind OData are IBM, Microsoft (the creator of OData v1) and Oracle.
As I see it the SAP ecosystem is currently a diverse and rapidly changing place. OData seems to be one of the few consistencies in that it is supported by the majority of SAP tools and products. Indeed when we talk about an SAP-stack or working with SAP technologies often what we mean in concrete terms is integration using OData. Can you think of any other standards, tools or products which are as pervasive?
Having established that OData is worth investigation, lets look into the different versions used in the SAP ecosystem.
In the SAP world the only OData versions that are relevant are v2 and v4. V4 was released in 2014 and it incorporates many lessons learned from extensive use of v2. It addresses many of the flaws of the earlier protocol. At the time of writing (early 2021) however the shift from v2 to v4 is very much a work in progress. In my experience the vast majority of productive use in the SAP-ecosystem is still with v2.
The list of new & improved features in v4 is extensive and I will highlight just a few here:
Lets consider the last point in more detail. With v2 we would query like this
With v4 we can query
It's clear that with this syntax we can expand to any number of levels. We can also apply parameters like $select or $filter at any level we choose, e.g.
What are we doing here? We select the Continents and expand to Countries. From Countries we expand to both Cities and CapitalCity. From Cities we expand again to Suburbs. For field selection we specify Name only for Continent and Name & Population for Countries and for Cities.
The CAP and RAP can provision OData v4 services (for others to consume) and indeed v4 is the default option. The SAP Cloud SDK can consume OData v4 services. SAP Integration Service also has v4 support. The Fiori Elements tool (for metadata-driven UIs) can consume v4 services from SAPUI5 version 1.84 onwards.
The excellent support for OData service consumption in SAPUI5 (in freestyle apps) is for me one of the most important features of that library. On a recent project we got to use the UI5 v4 ODataModel, which has been under development for some time. The project was a side-by-side SuccessFactors extension. Our CAP app consumed v2 OData services from SuccessFactors and provisioned v4 OData services which in turn were consumed by our freestyle UI5 apps.
We wanted to take advantage of v4 features (see above) and, given the ongoing shift from v2 to v4, we wanted to make our app as future-proof as possible. What we found was that in our case we could work around the relative immaturity of the v4 support in UI5.
The v4 ODataModel in SAPUI5 is quite different to the v2 implementation. A major difference is that many APIs have been moved from the ODataModel as they now strictly refer to the context instead. For example, rather than using callFunction() on the ODataModel one must create a so-called operation binding context instead e.g.
We used UI5 version 1.71 and we had to work around (OData v4 specific) issues like
As you start a new project it's definitely worth investigating whether you should be using v4 rather than v2 in order to build a more future-proof solution. Beware of limitations though which could be show-stoppers for you.
Please add a comment if you're 'live' with a project that uses v4, or if you have more info on the v4 support of SAP tools and products (I know my list isn't exhaustive).
What is OData?
OData is an API protocol. It defines how compliant RESTful services can be called and how they behave. Following the protocol gives our APIs consistency. For example, there's an agreed way to specify the filters in a query operation (e.g. OrderNo eq '123') and we don't need to invent a way of doing this every time we build an API. That consistency also means that frameworks like the SAP CAP (Cloud Application Programming Model) & RAP (ABAP RESTful Programming Model) can handle dataset operations like filtering, sorting and updating for us (indeed they can do all of CRUD-Q if the service is 'managed' by the framework).
There are other notable protocols, but OData is very much preeminent in the SAP world. Aside from SAP, other notable members of the OASIS standards body that now sits behind OData are IBM, Microsoft (the creator of OData v1) and Oracle.
As I see it the SAP ecosystem is currently a diverse and rapidly changing place. OData seems to be one of the few consistencies in that it is supported by the majority of SAP tools and products. Indeed when we talk about an SAP-stack or working with SAP technologies often what we mean in concrete terms is integration using OData. Can you think of any other standards, tools or products which are as pervasive?
Having established that OData is worth investigation, lets look into the different versions used in the SAP ecosystem.
OData v4 was released in 2014, the year of the selfie-stick craze (photo Marcos Mesa Sam Wordley / Shutterstock)
What's the difference between v4 and v2?
In the SAP world the only OData versions that are relevant are v2 and v4. V4 was released in 2014 and it incorporates many lessons learned from extensive use of v2. It addresses many of the flaws of the earlier protocol. At the time of writing (early 2021) however the shift from v2 to v4 is very much a work in progress. In my experience the vast majority of productive use in the SAP-ecosystem is still with v2.
The list of new & improved features in v4 is extensive and I will highlight just a few here:
- Better performance through reduced payload size (both for metadata and response data)
- Improved data types, e.g. separate date and time types rather than combined datetime only
- You can filter and sort on expanded properties. For example, we can query order headers expanded to order items, with a filter for only order item quantity > 100. In v2 we could only filter by the main entity (in this case the order header)
- The query syntax is much more logical with multiple expands. This is because the parameters are nested
Lets consider the last point in more detail. With v2 we would query like this
..../Continents?$expand=Countries/Cities
With v4 we can query
..../Continents?$expand=Countries($expand=Cities)
It's clear that with this syntax we can expand to any number of levels. We can also apply parameters like $select or $filter at any level we choose, e.g.
..../Continents?$expand=Countries($expand=Cities($expand=Suburbs;$select=Name,Population),CapitalCity;$select=Name,Population)&$select=Name
What are we doing here? We select the Continents and expand to Countries. From Countries we expand to both Cities and CapitalCity. From Cities we expand again to Suburbs. For field selection we specify Name only for Continent and Name & Population for Countries and for Cities.
How well supported is v4 by SAP products and tools?
The CAP and RAP can provision OData v4 services (for others to consume) and indeed v4 is the default option. The SAP Cloud SDK can consume OData v4 services. SAP Integration Service also has v4 support. The Fiori Elements tool (for metadata-driven UIs) can consume v4 services from SAPUI5 version 1.84 onwards.
The excellent support for OData service consumption in SAPUI5 (in freestyle apps) is for me one of the most important features of that library. On a recent project we got to use the UI5 v4 ODataModel, which has been under development for some time. The project was a side-by-side SuccessFactors extension. Our CAP app consumed v2 OData services from SuccessFactors and provisioned v4 OData services which in turn were consumed by our freestyle UI5 apps.
We wanted to take advantage of v4 features (see above) and, given the ongoing shift from v2 to v4, we wanted to make our app as future-proof as possible. What we found was that in our case we could work around the relative immaturity of the v4 support in UI5.
The v4 ODataModel in SAPUI5 is quite different to the v2 implementation. A major difference is that many APIs have been moved from the ODataModel as they now strictly refer to the context instead. For example, rather than using callFunction() on the ODataModel one must create a so-called operation binding context instead e.g.
model.bindContext("/myFunction(...)");We used UI5 version 1.71 and we had to work around (OData v4 specific) issues like
- Lack of synchronisation between bindings
- Issues with error handling, such as error handlers not being triggered on unsuccessful updates
- Absence of the setProperty method
Is it time to switch?
As you start a new project it's definitely worth investigating whether you should be using v4 rather than v2 in order to build a more future-proof solution. Beware of limitations though which could be show-stoppers for you.
Please add a comment if you're 'live' with a project that uses v4, or if you have more info on the v4 support of SAP tools and products (I know my list isn't exhaustive).
- SAP Managed Tags:
14 Comments
