Skip to Content
Technical Articles

OData service development options

When you develop an OData service there are different options you can choose from for your service implementation.

Which option you can or should go for first of all depends on the underlying SAP Basis release of your SAP Business Suite or S/4 HANA system. Options span from code based implementation to the use of the new ABAP programming model. As described by my colleague Carine in her blog Be prepared for the new ABAP programming model in SAP S/4HANA there is a clear recommendation for using CDS already in older releases.

The decision which implementation option to use also depends on the question which of the two versions of the OData protocol, namely V2 or V4, you want to use or that you must use. There are for example client libraries such as the Olingo OData Client for JavaScript which only support the OData V4 protocol.

On the other hand we have the new ABAP programming model which right now does not support OData V4 end-2-end. Here it is important to know that using the new programming model it is perfectly fine to stick to the OData V2 protocol which is supported end-2-end out of the box and wait for the upcoming OData V4 support since the service implementation is already protocol agnostic in general and agnostic to the OData version in particular.

In this blog I thus want to outline which options are recommended based on your business scenario and platform you are currently using thus answering the question where it is safe to invest now. I would like to start with a summary and will provide more detailed explanations in the remaineder of this blog.

Summary: Where to safely invest now?

Use CDS as the one and only data modelling language

  • Use CDS and BOPF integration and get familiar with BOPF concepts like determinations, validations and actions
  • Use OData exposure @OData.publish:true or the Service Builder (SEGW) with Reference Data Sources for OData V2
  • Avoid DPC / MPC specific coding wherever possible

If OData V4 is not mandatory for your business scenario

  • Use OData V2 and go for an implementation based on the new ABAP programming model
  • Wait for the planned end-2-end support of the OData V4 protocol by the new ABAP progamming model

If you must use OData V4 now

  • Go for a code based implementation, but use CDS views for read access.
  • OData V4 support for code based implementation is available as of SAP NetWeaver 750 SP04 (see more details below)

Evolution of OData service implementations

The first OData service implementations used the Service Builder to design the OData Model and a code based implementation of the methods of the data provider extension class. Using the SAP Gateway AddOns this kind of service implementation is available for all SAP Business Suite Releases that run on top of SAP NetWeaver 7.0 SP18 and later.

Since the advent of the new programming model that first became availble with AS ABAP 7.50 SP01 we see a growing adaption of the same and as a result the number of services that are using the direct OData exposure using the annoation odata.publish:true or that are using the Referenced Data Source approach is growing.

With the planned end-2-end support of the OData V4 protocol by the new ABAP progamming model we expect that code based implementation of the OData protocol specifics in the OData provider class becomes the exception.

If you nevertheless then still want to use a code based implementation you can do so also in the future. Important to note is that any service using code based implementation will continue to run in the future as well but it will not be able to support future OData versions out of the box.

By  choosing a service implementation based on the new ABAP programming model now, you are well prepared for the upcoming end-2-end  support of the OData V4 protocol. This is because the BO implementation and CDS implementation are both OData protocol agnostic and do not require any deep knowledge of any version of the OData protocol.

OData V2 service implementation options

There are basically 3 options that you can currently use to build an OData V2 service as shown on the following diagram.

  1. Code based implementation
  2. Mapped / Referenced Datasource
  3. OData.publish : true


Code based implementation

As mentioned above the first option that was avalilable and which is still widely used is using the Service Builder for OData V2 modelling and a code based implementation of the  data provider extension class that works as an adapter from business logic to protocol specifics. The implementation of the data provider extension class requires deep knowledge of the V2 OData protocol specifics and the developer has to build everything from scratch. The following two blogs provide comprehensive how-to guides for the implementation of such a service.

OData service development with SAP Gateway – code-based service development – Part I

OData service development with SAP Gateway – code-based service development – Part II

Since there is no option for code reuse of an existing V2 service implementation for a code based implementation that is leveraging the new OData V4 API’s of the SAP Gateway framework this additional effort has to be taken into account. 

Referenced and Mapped Datasources

When the new programming model became available it first only supported read access (AS ABAP 7.50 SPS01). Though with later versions (AS ABAP 7.50 SPS05) “Batch-input”-like SAP Fiori apps could be build the use of legacy write API’s is still not yet supported. This is where the Service Builder using  the Referenced Datasource approach comes into play.

Here the data model is based on CDS views and read access is provided out of the box by the underlying CDS Views. The  Service Bilder now generates a model provider extension class and data provider extension class that can be used to implement extensions using code based implementation while leveraging the generic support for read access. By implementing the create, update and delete methods it is for example possible to call a BAPI to update a business object such as a sales order as described in my following two blogs.

OData service development with SAP Gateway using CDS via Referenced Data Sources

OData service development with SAP Gateway using CDS via Referenced Data Sources – How to implement updates

Please note:
The use for the Referenced Datasource approach is not limited to access data via classic API’s. It can also be used as an extension layer for applications that are based on the new programming model and that perform their updates via BOPF. Here the ABAP layer can be used to add additional annotations to the metadata of a service that are not supported by CDS or it is possible to implement additional business logic via ABAP code, though both extension options should be avoided if possible.


If you are building an application using the new ABAP programming model for building state-of-the-art, intrinsically SAP HANA-optimized Fiori apps in SAP S/4HANA you can leverage an out-of-the-box OData V2 support. By simply adding the annotation @OData.publish:true in your CDS consumption view an OData V2 service is generated in the SAP Business Suite or S/4 HANA backend that can be published in the SAP Gateway Server.

The BO implementation and CDS implementation are both OData protocol agnostic and the OData protocol support is provided by the SAP Gateway framework. As a result no deep knowledge of the OData protocol is required. In addition there is only a minimal implementation effort needed to also support create, udate and delete functionality for your service. If you want to implement such a service yourself you can use the following how to guide in my blog

How to develop a transactional app using the new ABAP Programming Model for SAP Fiori.

OData V4 service implementation options

When it comes to OData V4 service implementation options it is planned to offer only two options. Beside the option to use a code based implementation it is planned to offer also support by the new ABAP programming model.

It is not planned to offer support for OData V4 for scenarios such as redefinition that are available for OData V2 in the Service Builder. As described in SAP Note 2485370 the use of the Service Builder for developing OData V4 services is also not recomended any more.

Code based implementation

As of SAP NetWeaver 750 SP04 there is first implementation of the new ODataV4 SAP Gateway runtime framework available as described in the SAP Oline Help. This first version however wasn’t complete. A broader support became available with AS ABAP 752.

As indicated in SAP Note 2512479 parts of SAP_GWFND 752 SP02 have been down-ported to SAP_GWFND 750 SP12, so you should not use 750 SP04 but upgrade SAP_GWFND 750 to the latest version.

But as indicated within the same note please note that future down-ports of the SAP Gateway Framework will only be available for SAP_GWFND 751 and 752 and no new down-ports are planned for releases prior to SAP NetWeaver 751.

Though there is an option to choose “OData 4.0 Service” as the project type in the Service Builder (SEGW) you will get a warning in future SP’s, since the use of the Service Builder for developing OData V4 services is not recomended any more. See also SAP Note 2485370.

Instead it is recommended to create manually both, a model provider class (which inherits from /IWBEP/CL_V4_ABS_MODEL_PROV) and a data provider class (which inherits from /IWBEP/CL_V4_ABS_DATA_PROVIDER), rather than using SEGW or to wait for the end-2-end support of OData V4 by the new programming model.

If it cannot wait:

I am preparing a blog series that provides recommendations on how to perform such a code based implementation. The main paradigm is to use CDS views that will allow you to use quite generic ABAP and OpenSQL code. Using CDS views for data access can easily be achieved since OData V4 does require at least an AS ABAP 750 SP04 runtime in the backend.

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)


Planned – New programming model

It is planned to provide an end-2-end support for the OData V4 protocol as described by my colleague Carine in her blog Be prepared for the new ABAP programming model in SAP S/4HANA.


You must be Logged on to comment or reply to a post.
  • Hi Andre,

    Nice blog and really help us like who is willing to start OData V4..

    Can you please share us how metadata looks like  in OData V4 since we have created Odata v4 which is not supporting offline store opening ..( Error is like (…)/$value not supporting )

    Please find the attached metadata screen shot.. and trying call metadata from ES5 system(trail) not able get the metadata..



  • Hi @andre.fischer,

    If we do a CDS + BOPF then using odata map data source in SEGW ( as I would need calculated fields added to the data with calculation logic ). in such case for create/udpate/delete will it work if I just provide map data source or should I do anything more.

    When I tested the above have been getting an error saying entity not found where the name of the entity on the error provided is same as the mapped CDS name.




  • Hi Andre,

    Very helpful blog. Does OData V4 currently support file/media upload? Are you able to show me the documentation around this or an example of this implementation

    Previously with OData V2, I was able to redefine the method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_STREAM to receive file upload request from my Fiori UI. However, I can’t find any equivalent method in the V4 class /IWBEP/CL_V4_ABS_DATA_PROVIDER or /IWBEP/CL_V4_ABS_MODEL_PROV.


    Thank you,


    • Please check in the SAP Gateway Client the V4 test Group that can be created if you choose from the menu: SAP Gateway Client -> Create V4 Test.

      Once you have registered and published the Service Group tea_tech you will find a (very technical) test Service.


      In OData V4 we now support properties of “Edm.Stream“.




      • Thanks for the heads up Andre.

        It seems there is an interface called /IWBEP/IF_V4_DP_MEDIA_RESOURCE to do the media handling, however the interface is empty (ie, no interface/attributes/methods whatsoever). I assume this means my system is not up-to-date to perform this.

        FYI – I’m on business suite. ABAP 750 SP9 / GWFND 750 SP10

        I will fall back on OData V2 for now. Thanks for your help.




  • Hi Andre,

    A nice blog giving overview of options that we have.

    After SAP Teched this year I understood that the recommended option for ODATA deployment is now CDS view as starting point. On top of that different deployment options are possible.

    I see that we must avoid manual implementations in SEGW and DPC_EXT class but prioritize CDS views first, optionally extending logic in DPC_EXT classes on top of that when needed. I see how much less effort it is if I compare to my manual implementation of sorting, paging and filtering from before.

    Thanks and greetings,

  • Hello Andre,

    thank you for providing insight regarding development options. I must admit, the thing I am still missing is a comprehensive approach for CRUD operation handling in OData.

    Following the recommendations, CDS views are the way to go. However since CUD scenarios cannot be done this way, it is still necessary to perform DPC_EXT implementation (like described in your blog: )

    For that reason, I find a framework like BOBF much more appealing, since it would make handling all operations possible, without having to switch between CDS for read and DPC_EXT implementation for “the rest”.

    I would be great to see SAP providing completely implemented BOPF model at least for the most common standard objects (like business partner), so they can be mapped directly to OData service.

    Best regards,


    • Hi Stanislaw,

      I agree that using CDS views just for reading and having CUD implemented via the implementation of the appropriate CUD Methods in the DPC_EXT class of your Service Builder Project that uses the referenced data source Approach is not ideal.

      Thats’s why with the ABAP Restful programming we will support both, the managed as well as the unmanaged use case.

      With SAP S/4 HANA SAP is delivering fully implemented business objects including the corresponding SAP Fiori UIs without the need to do any mapping since they are part of the SAP S/4HANA Standard delivery.

      Best Regards,


  • We are beginning a new project running 1809 on-prem SAP HANA.  I feel like if we were another year out a clear direction on either OData v4 code based, i.e _DPC or the REST Programming model would be available.

    I unfortunately believe the we will end up with BOPF with referenced CDS views generating OData v2 through the gateway.

    Would you agree?

    Thanks, Andrew


    • Hi Andrew,

      yes I would reccommend in your case that you should proceed with using BOPF and CDS views.

      But as indicated by my colleague Carine Tchoutouo Djomoin her blog Evolution of the ABAP Programming Model (PlannedIntegration) we plan to provide an integration option of the CDS-based BOPF BOs within the ABAP RESTful Programming Model to reduce significantly the migration effort from the ABAP Programming Model for SAP Fiori.

      But it would not be mandatory to migrate your scenario immediately since a service based on CDS/BOPF will continue to run also in SAP S/4HANA 1909 and later releases.

      Best Regards,


  • Hi @andre.fischer,

    Very nice blog.

    Same doubt as Andrew have, we are also in starting phase of new greenfield implementation for 1809 S4 HANA(On-prem), where in UI/UX team is in dot net framework.

    Not sure which approach to suggest to UI/UX team either using Odata V4 which is not yet supported by SAP or using new RAP(Restful ABAP Programming(using BO-CDS) ).

    In our UI/UX few services are coming from diffrent system which are in V4, so UI/UX team also thinking that from SAP also they can get services in V4.

    Is there is any clear road map coming from SAP for version 4, so that we can think  about design.


    Abhijeet kankani

    • Hi Abhijeet,

      strictly speaking OData V4 is already supported but only for code based implementation as I described above.

      But if you go this way it will be more complicated (since it is code based implementation) and it will be harder to port such an implementation to the upcoming ABAP RESTful programming model.

      As I indicated in my comment above the recommended way for an implementation following a green field approach would be to go for a CDS / BOPF based implementation.

      As described in the blog Evolution of the ABAP Programming Model (PlannedIntegration) we plan to provide an integration option of the CDS-based BOPF BOs within the ABAP RESTful Programming Model to reduce significantly the migration effort from the ABAP Programming Model for SAP Fiori.

      If you have to work with classic API’s for updates I would recommend to use the Referenced Data Source approach.

      The ABAP RESTful programming model which is right now only available in the SAP Cloud Platform ABAP environment is

      a) planned to become available with an upcoming on premise version of SAP S/4HANA

      b) planned to support an additional service binding option for OData V4

      We are working on a Roadmap when these features become available.

      I am not a .NET UI development expert, but what I would ask your .NET UI developers is whether there is big difference in .NET between consuming an OData V4 and an OData V2 Service?

      So would it potentially be possible to start with a V2 service and adapt the .NET client once you have ported your V2 service to V4?






  • Hi Andrew,


    I created a Fiori based Report using RAP, but now we have to schedule the report as batch job .

    Is it possible to schedule FIORI Based report of Consumption view as batch job as we used to do with SE38 report




  • Hi @andre.fischer ,

    Thanks for your wonderful blogs and knowledge sharing.

    I have a question for you…Are there any Best practices/Guidelines on annotations implementation. I Understand Frontend work can be reduced with backend annotations and fiori elements usage , but are there any guidelines when to go for  backend annotations and when it should be handled on Frontend side?

    Thanks for your inputs !