Skip to Content
Technical Articles

OData service development options


  • 25.02.2021 – The end-2-end support of OData V4 with the ABAP RESTful Application Programming Model is now available in the ABAP environment of SAP Business Technology Platform as well as on premise with SAP S/4HANA 2020 FPS01



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, so that a service in such a scenario must support OData V4.

On the other hand we have the new ABAP RESTful Application Programming Model (RAP) now also does support OData V4 end-2-end.

The support of OData V4 in RAP is available in the ABAP environment of SAP Business Technology Platform as well as in SAP S/4HANA on premise systems as of Version 2020 FPS01

Here it is important to know that using the new programming model the service implementation is already protocol agnostic in general and agnostic to the OData version in particular.

This means that a service that has been developed with RAP in SAP S/4HANA 1909 or SAP S/4HANA 2020 will support OData V4 out of the box when the system is being upgraded to SAP S/4HANA 2020 FPS01.

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 remainder 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 RESTful Application Programming Model if you are on SAP S/4HANA 1909 or 2020
  • Wait for on upgrade to SAP S/4HANA 2020 FPS01 or higher

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 ABAP Programming Model for SAP Fiori that first became available 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 annotation odata.publish:true or that are using the Referenced Data Source approach is growing.

With the availability of the end-2-end support of the OData V4 protocol by the new ABAP RESTful Application Programming 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 RESTful Application Programming Model in SAP S/4HANA 1909, you are well prepared for the end-2-end  support of the OData V4 protocol in SAP S/4HANA 2020 FPS1. 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 Data sources

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 Data source 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 Data source 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 there are only two options.

Beside the option to use a code based implementation you can use the new ABAP RESTful Application Programming Model.

Please note that code based implementation of OData V4 services is only avaialable for on premise systems while using RAP is possible in on premise systems as of SAP S/4HANA 2020 FPS1 and in in the cloud in SAP Business Technology Platform ABAP Environment.

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


ABAP RESTful Application Programming Model

Using RAP any service does support OData V4 out of the box. You simply have to create an appropriate service binding to publish your RAP based business object using one of the two binding types

You find more information about this in the SAP Online Help

Version 2020 FPS01 – SAP Help Portal

Or have a look at the Hands-On session DEV260 that was conducted at SAP TechEd 2020

GitHub – SAP-samples/teched2020-DEV260: DEV260 – Build SAP Fiori Apps with the ABAP RESTful Application Programming Model



You must be Logged on to comment or reply to a post.
    • Yes, and I will publish a how to guide how to implement the same very soon. See my following blog that I will update accordingly.


  • @andre.fischer

    Hi Andre,

    I have an issue in creating odata V4. Please refer the below link

    Please let me know am i doing correct? please guide me.






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




  • Hi Andre,

    in case of FES 6.0 hub deployment with s/4HANA 2020 FPS 2 as Backend:

    Is it possible to deploy Z UI5 Apps to FES 6.0 and register OData Services while

    the OData Impl. resides on the s/4HANA 2020 Backend?


    The OData Version should be v2 in our case and is managed by the creation of the SEGW project

    on the s/4HANA 2020 backend (project type "Service with SAP annotations" - means OData v2)

    - is that correct or is there odata v4 out of the box enabled? How we can set up odata v2 for this scenario?

    Thanks a lot.

    Kind regards, Hans-Dieter

      • Hi Andre,

        thanks for your prompt response.

        Please let me describe our use case:

        1. FES:   Existing SAP FES 6.0 as hub
        2. BES1: Existing EHP8 FOR SAP ERP 6.0 SP14, NW 7.5 SP17, SAP_GWFND 750 SP17 -> ODATA Service A impl.
        3. BES2: Existing s/4HANA 2020 FPS2, FES 2020 -> ODATA Service B impl.

        One Z UI5 App (UI) needs to talk with both OData Services (A+B).


        How is it possible to get that working?

        I mean, where should OData Services going to be registraded and where is the correct place for UI deployment?


        Thank you for your guidance!


        Kind regards,


        • Hi Hans-Dieter,

          I have corrected my answer above which is only valid for the SAP standard content delivered by SAP.

          The restriction for SAP content stems from the fact that a Fiori App delivered with an SAP S/4HANA addon for the FES does not necessarily also work with older SAP S/4Backend releases.

          For custom developments this restriction does not apply since your SAPUI5 content is handled by yourself and you will have the same service "version" in both SAP ERP and SAP S/4HANA backend.

          In order to get the scenario described by you working you would have to register the OData Services A + B in the respective backends. Then you publish them in the Hub (the FES system).

          So you will get two OData Services (if the implementation is a different one) or you would get one OData service with two backends that means two system aliases (backend_a and backend_b) pointing two the respective backend (ERP and S/4 2020).

          Then you would have to build a SAPUI5 application that consumes the OData service and deploy it on the FES.

          Best regards,


          • Hi Andre,

            great  - sounds good!

            Just add. info: We are talking about different odata services.

            Now back to my very first question regarding OData V2.

            BES1: everything clear to me -> V2 Project

            BES2: Existing s/4HANA 2020 FPS2, FES 2020 -> ODATA Service B impl.

            How to create Odata v2 projects / services?


            Best regards, Hans-Dieter


          • In SAP S/4HANA 2020 you can create OData V2 services based on the new ABAP RESTful Application Programming Model (the recommended approach) or you can still use SEGW.

            However an implementation based on SEGW cannot be deployed to an a system that will in the future offer the  planned "embedded Steampunk" option.



  • Hi Andre,

    with the s/4 conversion we will follow the SAP recommendation to use embedded gateways on our landscape (beside one central gateway for special purpose).

    In case of custom apps in the new embedded gw landscape we have the following cross system scenario / use case:

    1. UIComponentA + OData + BusinessLogic on System A
    2. AppA1 on System A uses UIComponentA
    3. AppA2 on System A uses UIComponentA


    Data from System B should be displayed inside AppA1 and inside AppA2 etc.
    (best by the use of a UIComponent - we would like to use UIComponents due to get the same look and feel in each consuming Apps).

    What do you think about that approach and what is your recommendation for accessing data across different systems not using a central gateway?

    Thank you very much.,

    Kind regards,




    • The situation that you are describing looks a little bit like the scenario "development on the hub".

      When accessing data from another system you can either consume the data as a second OData service in your app or the ABAP backend business logic does perform these calls.

      You might also go for a loosely coupled approach you would have an app in backend b and you would use some kind of app to app integration and deploy both app in the new central fiori launchpad.

      Best regards,



      • Hi Andre,

        yes you are right - development on the hub.

        Let me summarize my understandings.


        Option 1:

        Apps calling 2nd OData from other system B - OData activation on system A and impl. on system B.

        This way we have a mixed gateway scenario in my opinion - embedded and hub.

        Option 2:

        Apps calling OData on system A and then RFC from system B.

        That way seems the embedded scenario.

        Option 3:

        The new central launchpad.


        From a technical point of view (performance, complexity, ...),

        which option seems to be better to go?

        Or does it make sense to use both (1,2) of them in combination?


        Kind regards,