Skip to Content

OData V4 code based implementation – Overview

This blog is meant as an introduction of a series of blogs in which I will explain the use of the new SAP Gateway V4 framework.

It is meant for those readers that must create OData V4 series now and that cannot wait until an end-2-end support for OData V4 will be available through the new ABAP programming model.

Before starting code based OData V4 development you should check my blog OData service development options where I outline in more detail what the recommended options for OData development are right now.


  • 13.12.2017 – added link to the first how to guide and the blog that explains the OData service devlopment options in more detail

Table of contents

This blog is part of blog series about OData V4 code based development

OData V4 code based implementation – Overview

OData V4 code based implementation I (basic interface, read access)

OData V4 code based implementation I (basic interface, create&update)

Demo system ES5

In order to access the source code below you have to register in the new ES5 demo system

Sign up for a demo account on ES5 here

More details about the ES5 demo system as such you will find in my following blog

New SAP Gateway Demo System available

Source code

If you have a user in ES5 you will be able to access the ABAP code via the following links.

Data provider class – zcl_e2e001_odata_v4_so_data

Model provider class – zcl_e2e001_odata_v4_so_model

Exception class – zcx_e2e001_odata_v4_so

Interface – zif_e2e001_odata_v4_so_types

Consumption view – sales order – ze2e001_c_salesorder

Consumption view sales order items – ze2e001_c_salesorderitem

Interface view – ze2e001_i_salesorderitem_e

What’s new in the protocol?

The main paradigm: Reduction of data

The main paradigm of the OData V4 paradigm is the reduction of data. This reduction is achieved through a more powerful query language and a new optimized JSON protocol. At the same time it is possible to leverage richter metadata as compared to OData V2.

New JSON format

The OData V4 protocol comes with a very lean JSON procol. The response payload now basically only contains name value pairs. The metadata has been reduced to a a single line

"@odata.context" : "$metadata#SalesOrder/$entity"

as opposed to the more richer metadata information in the V2 response payload, both highlighted in blue in the following figure.

Cross service references

Cross service navigation enables inter communication of services. With this, navigation properties of entities of one service can reach entities of another service in a service group. With the support of cross service navigation several requirements of SAP Fiori like applications can be addressed.

1.) The rich metadata can be leveraged but at the same time not the complete data model has to be loaded at startup time of an application. There is rather the option to have a lazy loading of parts of a service model on demand.

2.) Services can be reused more easily since services can be partioned without the loss of navigation.

Examples of such services that can be reused in various SAP Fiori applications are Users, Attachments, Conditions, Addresses, …

Please note:

Cross service references are only possible within one service group.

If a request like the following is issued:

…/SalesOrderItems(SalesOrder='500000000', SalesOrderItem='10')/_Product

one would receive a response like the following where it is indicated via the @odata.context annotation that this response stems from another service.

"@odata.context" : "../../sap/Product/0001/$metadata#Product/$entity",
  "value" : [
      "Product" : "HT-1000",
      "Currency" : "EUR",

Support for Any and All

New is the support of the query options any and all.

With these it is now possible to find all sales orders where at least one of the items contains a particular product

…/SalesOrders?$filter = _Item/any(d:d/Product eq 'HT-1007')

or it is possible to find all sales orders where every item has a price greater than $100

…/SalesOrders?$filter = _Item/all(d:d/Price ge 100)

Filter on expanded result sets

New in OData V4 is the option for filtering on each level of an expanded enttiy set. In the following figure you see a request that

  1. reads all business partners that are located in ‘Walldorf’
  2. reads all sales orders of those business partners where the gross amount exceeds 1100 Euro
  3. reads only those items that contain the product HT-1041.

What’s new in the framework?

Advanced, intermediate and basic interfaces

The API that is used to develop OData V4 services has significantly changed compared to the API that is used to develop OData V2 services.

When you implement the methods of the basic interface you will get a working OData V4 service that will satisfy most requests. Complex requests such as $expand are then handled by the framework that will call the methods for the basic interface in the correct order.

The mplementation of the intermediate or advanced interface should however also be taken into account if your service implementation would be able to handle specific requests such as specific $expand or navigation calls more efficient than by calling the methods of the basic interface recursively.

 Name  Purpose
  • Methods provide basic functionality
  • (Create, Update, Delete, Navigation, …)
  • When being implemented à Working OData service supporting most requests
  •  Medium complex functionality
  • eTag handling, PATCH, $expand
  • Contains generic calls to other (especially the basic) interfaces
  • Always called first by the framework
  • Contains generic calls to the other (especially the basic) interfaces
  • Will for example be overwritten by the new RESTful ABAP Programming model (planned)
  • $batch. Generic $batch and changeset
  • Transaction and lifecycle handling

io_request and io_response

All interface methods have an import parameter called io_request. It can be used to retrieve all information you need to handle the request in your service implemenation.

A UPDATE_ENTITY method for example will have the following methods

  • GET_BUSI_DATA to retrieve entity data from the request, for example the payload of the incoming request.
  • GET_ENTITY_SET to retrieve the entity set of the processed entity. So we can switch to entity set specific methods

The corresponding parameter ip_response is used to return business data to the SAP Gateway framework and to tell the framework which processing steps the service implementation has handled iself (see todo and done flags below).


Generic framework support – example $expand

As already mentioned you will get a working OData V4 service by only implementing the methods of the basic interface.If a client calls the following URL:

GET .../ze2e001_salesorder/0001/SalesOrder('500000000')?$select=Salesorder,Customer&

the SAP Gateway framework will call the following basic methods in your service implementation:

 # Method call Purpose
 1  …_BASIC~READ_ENTITY This method will read the data of the sales order header
 2  …_BASIC~READ_REF_TARGET_KEY_DATA This method will read the key fields of the items that can be used by the READ_ENTITY_LIST method as a $filter statement

This method reads the items.



and would finally return the following data

  "@odata.context" : "$metadata#SalesOrder(Salesorder,Customer,_Item(Salesorderitem,Product,Grossamountintransaccurrency,Transactioncurrency,Salesorder))/$entity",
  "Salesorder" : "500000000",
  "Customer" : "100000000",
  "_Item" : [
      "Salesorder" : "500000000",
      "Salesorderitem" : "10",
      "Product" : "HT-1000",
      "Transactioncurrency" : "EUR",
      "Grossamountintransaccurrency" : 1137.64
      "Salesorder" : "500000000",
      "Salesorderitem" : "20",
      "Product" : "HT-1001",
      "Transactioncurrency" : "EUR",
      "Grossamountintransaccurrency" : 2972.62

Please note:
With OData V4 now query options are supported on all levels of an $expand statement.

ToDo and Done-Flags

The SAP Gateway V4 framework has introduced so called ToDo-Flags which provide a hint for the application developer what his implemenations has to do. Depending ont the query options that have been used in the request you will get simple list with boolean values for the following flags:

deltatoken, select, filter, skip, orderby, skiptoken, search, top, …

Done-Flags confirm that the response fits to the request. They allow the application developer to inform the framework to handle feature generically e.g., $top, $skip, and $select. Using such flags also allows an implementation tobe compatible in the future. Instead of a wrong result an exception will be raised if a done flag is not set.

The list of todo and done flags will vary depending on the method which is called. (READ; READ_LIST, CREATE, …)

For a simple GET request with a $filter query option:

…/SalesOrder?$filter=Customer eq ‚SAP‘

a service implementation would have to look like as follows.

At the beginning of our service implementation we have to check whether we have to handle the filter option. For this we call the method io_request->get_todos. Then we have to check whether the flag ls_todo_list-process-filter is set. If yes, the filter string is requested via the method io_request->get_filter_osql_where_clause and the flag that we have handled the filter query option is set in the structure ls_done_list. This information is at the end sent back to the framework via the method io_response->set_is_done that takes the done-list as a parameter.

io_request->get_todos( importing es_todo_list = ls_todo_list ).
if ls_todo_list-process-filter = abap_true.
  io_request->get_filter_osql_where_clause( importing ev_osql_where_clause = lv_where_clause ).
  ls_done_list-filter = abap_true.
" Report list of request options handled by application
io_response->set_is_done( ls_done_list ).


You must be Logged on to comment or reply to a post.
    • Odata v4 was first supported as of SAP Netweaver 750 SP4.

      This implementation still lacks some features. There is however planned a downport of SAP Gateway features from 752 to older releases down to 750 SPx, if the corresponding 750 SPx allows such a downport .

      Best regards

      • Andre


  • Hi Andre,


    The blog is very nice and helpful.

    But i am unable to open the source code that you have given. As because i am new to Odata i just want to see the coding style.



  • Hi Andre Fischer, how are you?

    I’ve seen that SEGW transaction is in maintenance mode.

    What is the correct tool to use if I’m on an ABAP ECC environment and we still use standard tools as SE38, SE80 etc?

    Is Eclipse a mandatory way to go? If so is there any documentation showing how to do this from absolutely scratch?


    Thank you!


    • Hi Douglas,

      thanks for bringing up this question.

      SEGW is still the tool of choice when developing OData V2 services as they are currently used in ECC systems as well as in SAP S/4 HANA systems.

      Only when it comes to the development of OData V4 services the recommendation is to use pure ABAP code based development. Here my recommendation would be ABAP in Eclipse but it is not mandatory. SE24 would work.

      Links that show how develop OData V2 services from scratch you can find in my blog about OData development options.

      Best Regards,




      • Hi Andre, thank you very much for the reply and clarifications around this!

        Do you know of any guide to building OData V4 services from scratch using SE24 ?


        Thank you and best regards,


        • Hi Douglas,

          sure. You can use my three blogs that I have mentioned above that explain code based development of OData V4 services.

          When using SE24 be sure to use the source code based view.

          Best Regards,



      • Hi Andre,

        that is clear. However, with SEGW you can generate quite a few services; eg via a simple redefinition for ODP. Are you going to add some features, ie one interface for an ODATA-Service via ODP, in order to implement that in an efficient and stable way? The ODP framework consists of several interfaces which are not released. So redoing that yourself is not that straightforward and involves quite some maintenance.

        A lot of 3rd party applications which might consume OData do not really like v2. And, especially important for data export like ODP, v2 has same nasty deficiencies regarding date/time. You will lose some information. That got solved with v4.

        thanks, C

  • Your blogs have been very useful. There is one thing to be aware of though, with respect to setting the ‘done’ flags. I would recommend setting those flags when the filter (for example) criteria have been applied successfully, not immediately after you have retrieved the criteria – just in case…

  • How do I create a deep insert

    I am getting an error:


    “code” “/IWBEP/CM_V4S_RUN/066”,
    “message” “Application did not set DONE list for an expand node ‘_OBJECT'”


    How do I set a done list for an expand node ?



  • Hi,

    In note 2485370 it is stated that it is still recommended to use Odata V2 if it is not mandatory for the business scneario to use Odata V4. The note version is from 2017/09/11.

    is this still the current recommendation, are there any restriction in Odata V4 we should be aware of if we develop our REST Services with Odata V4?



    • Hi Silvia,

      I have just updated the note though the changes are not visible due to a 4 eyes principle that is in place when SAP Notes are changed.

      Unfortunately the main statement still holds true that if you must use OData V4 now you have to perform a code based implementation. And here it is recommended to use the approach I described above because this way your data model will already be based on CDS views and it will be more easy to reuse this in the ABAP RESTful programming model which is available in SAP S/4HANA as of SAP S/4HANA 1909.

      Restrictions with regards to the support of OData V4 are not on the service implementation side if you go for a code based implementation. The only problem you will have is that such a code based implementation is implementing the OData V4 API’s of the SAP Gateway Framework, rather than using the OData protocol agnostic implementation of the ABAP RESTful Programming Model.

      So you would have to adapt your coding manually when moving to the ABAP RESTful programming model at a later point in time.

      The restrictions are more on the UI side since there is currently no support for OData V4 for SAP Fiori elements applications. Though this is planned.

      So if you are planning to build SAP Fiori applications the recommendation is still to use OData V2.

      Best Regards,

      Andre Fischer

  • Hi Andre,

    Thanks for your helpful blog.

    For one of our project requirements, we had to use V4 O-Data implementation. So I referred the blog to set-up and implement my service successfully in my development environment. Our service is defined in Back-end system(SAP_ABA-Version 7.50 SP-Level 11) with the service Group registration done at Gateway system(SAP_GWFND-Version 7.52 SP-Level 0 ).

    After transporting my Back-end / GW transports to IT system, my service in IT is not working (Table /IWFND/C_V4_RSAG is not having respective entries ).

    Just wanted to confirm that the service registration has to be manually configured in each of IT/Production environment.

    Also we need to have client-open for the configurations set-up?

    Thanks & Regards,