Skip to Content
Technical Articles
Author's profile photo Mike Doyle

Is it time to switch to OData v4?

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.

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.

Selfie stick 101

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


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.

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.


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).


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Christopher Linke
      Christopher Linke

      Very informative, thank you!

      Author's profile photo Sergio Guerrero
      Sergio Guerrero

      great blog (as always), Mike. You bring up a great point. I have been in a few situations where the opportunity has presented and as you mentioned, OData v4 was released a few years ago. I believe the not all the Fiori extensions (or even some of the tools ie the Fiori tools for VS code) accept OData v4. I believe the freestyle apps do work better for this situation, IMO.

      Glad to see some other companies out there facing this and people like you that are making it happen and sharing details! have a great weekend!


      It is definitely time 

      Author's profile photo Holger Schäfer
      Holger Schäfer

      Hi Mike,
      great informational blog.

      Over the last year, i was also working on multiple projects and had to decide v2 or v4 for projects that will go live mid of this year.

      The whole sapui5 freestyle apps are using v4 model, which also support v2 service, but only for reading!

      The main pain point is the missing RAP support for v4 (which was announced a year ago at TechEd).
      End of last year, it was available in ABAP Cloud but not onPremise. There are still rumors, that it may find his way into s4 onprem with a service pack, so we do not have to wait till next major release.

      Concerning UI5, i created a lot of tickets, but now, most of the stuff is running as expected.
      Also have a look at the updated SDK for 1.86 (you have to choose the version explicitly) or use the link

      Here you will also find information, which Fiori Elements are working with v4.
      Currently, the most stuff seems to be developed and tested with CAP.
      Also Fiori Elements v4 is completely redesigned and using the sap.fe library internally.

      Concerning benefits for UI5, my main benefit is the odata type binding for your freestyle apps, that even works for OpenUI5! (no need for smart controls) and native support for value helps.

      You should definitely give it a try, especially if you are working with CAP.

      Best Regards

      Author's profile photo Luisa Grigorescu
      Luisa Grigorescu

      Great article!

      Author's profile photo Rajesh Akarte
      Rajesh Akarte

      Wonderful article ..

      Author's profile photo DJ Adams
      DJ Adams

      Great post, Mike. That's a nice example dataset that you were using in the URL examples (continents, countries, etc). Is that something you made up, or is there an OData service that serves those entities? Might be a nice alternative test service to play with.

      On the versions and standards, I was fascinated by how OASIS managed its standards documents and versions, and document types, and that they used a well-known method for maintaining stable URLs (used by the IETF too). I dug into that a little bit to understand how the V4 spec came about, and documented it in a sort of tree, here:


      Author's profile photo Mike Doyle
      Mike Doyle
      Blog Post Author

      Thanks DJ! My example dataset is entirely fictitious I'm afraid. I'm giving a brief talk on the subject SAP APJ UX Practitioners forum (March 18th) so I'll likely look into v4 test services that I can demo

      Author's profile photo DJ Adams
      DJ Adams

      Of course you and I and everyone knows about Northwind, which is still great, of course, and there's a V4 flavour of it. Did you also know about TripPin? Strange name* but nice demo v4 service

      *I guess it might be a play on trippin' but I can't be certain.


      Author's profile photo Rufat Gadirov
      Rufat Gadirov

      Hey Mike Doyle ,

      thank you for your great blog post.

      Indeed, for our current project we use OData V4 - but in combination with OData V2. Reason for doing so is, that we created a fiori elements application fully in OData V4 which was enabled by SAP with 1.84 back then. But V2 we use for a freestyle application which has been developed and used in another project and is now partly reused. Our UI architecture is indeed very interesting because we navigate from a FIORI elements based V4 app into a completely freestyle application in OData V2 (using the V2 proxy adaptor). On top of that, we use XML fragments that we embedded into our main FIORI elements application. The page map editor that modifies the manifest.json of the corresponding app makes it possible to configure these kind of navigations (in Business Application Studio).

      With UI5 1.84 - the first V4 supported FIORI elements list report template - indeed did have some bugs - like synchronization was an issue when many-to-many relationship was implemented. On top of that, the UI target navigation container (navigation from fiori elements to freestyle) didn´t update but still contained the old content and the user had to close it - it didn´t disappear automatically. These mentioned errors were fixed when 1.88 came out but forced us to change some UI5 code as well because there were quite changes in the UI5 core that led to incompatibility.

      So far, we are doing good, but or big worry is the UI5 versioning, e.g. 1.89 is our used version right now. It was released in April 2021 and is now out of maintenance. We can go to a working higher version like 1.90 and with some minor UI changes the app works fine. But with the latest version 1.91 we meet additional issues and the complete FIORI freestyle application is no longer working. We already communicated these kind of issues to SAP directly and we hope that we find a solution.