Skip to Content
Technical Articles

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

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

 

/
Selfie stick 101
8 Comments
You must be Logged on to comment or reply to a post.
  • 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 

  • 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 https://sapui5.hana.ondemand.com/1.86.1/#/topic/03265b0408e2432c9571d6b3feb6b1fd

    @Sergio
    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
    Holger

  • 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:

    https://raw.githubusercontent.com/qmacro/odata-specs/master/overview.md

    Cheers!
    dj