Skip to Content
Technical Articles
Author's profile photo Andre Fischer

OData service development options

Updates

  • 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

 

Introduction

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.

OData.publish:true

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

 

 

Assigned tags

      41 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Syam Babu
      Syam Babu

      Hi Andre,

      Nice Info.

      is there any method available in V4 like CREATE_DEEP_ENTITY  in V2 or any new name in V4

       

      Thanks,

      Syam

       

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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. https://blogs.sap.com/2017/12/12/odata-v4-code-based-implementation-overview/

       

      Author's profile photo Mike Doyle
      Mike Doyle

      Thanks Andre for writing this very comprehensive reference. One to bookmark! Do you know when UI5 will offer full support for v4?

      Author's profile photo Former Member
      Former Member

      Thanks Andre!! Exactly what i was looking for today:-)

      Author's profile photo Gowtham Raja M
      Gowtham Raja M

      @andre.fischer

      Hi Andre,

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

      https://answers.sap.com/questions/456972/odata-v4-service-creation-issue.html

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

       

      Thanks,

      Gowtham

       

       

      Author's profile photo Sreenivas Pachva
      Sreenivas Pachva

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

       

       

      Author's profile photo Former Member
      Former Member

      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.

      Thanks

      Nafran

       

      Author's profile photo Clement Lau
      Clement Lau

      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,

      Clement

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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.

      /sap/opu/odata4/iwbep/tea/default/iwbep/tea_tech/0001/$metadata

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

      Regards,

      Andre

       

      Author's profile photo Clement Lau
      Clement Lau

      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.

       

      Clement

       

      Author's profile photo Adam Krawczyk
      Adam Krawczyk

      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,
      Adam

      Author's profile photo Stanislaw Cyganik
      Stanislaw Cyganik

      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: https://blogs.sap.com/2016/06/02/odata-service-development-with-sap-gateway-using-cds-via-referenced-data-sources-how-to-implement-updates/ )

      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,

      Stanislaw

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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,

      Andre

      Author's profile photo Andrew Harvie
      Andrew Harvie

      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

       

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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,

      Andre

      Author's profile photo abhijeet kankani
      abhijeet kankani

      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.

      Regards,

      Abhijeet kankani

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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?

      Regards,

      Andre

       

       

       

      Author's profile photo saurabh tiwari
      saurabh tiwari

      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

       

      Regards,

      Saurabh

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      Are you asking for SAP S/4 HANA on premise or for SAP Cloud Platform, ABAP Environment ?

      Author's profile photo Vijay Sharma
      Vijay Sharma

      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 !

      Regards

      Vijay

       

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

      Hallo Andre,

      thanks for this heavily awaited update on v4 with FPS01.

      It took more time than expected, but SAP finally did it!

      Very great news.

      Best Regards
      Holger

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      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

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      Hi Hans-Dieter,

      for SAP standard content FES 6.0 does only support backend systems up to SAP S/4HANA 1909.

      Please check

      SAP Fiori Front-End Server - SAP Help Portal

      Best regards,

      Andre

       

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      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,

      Hans-Dieter

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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,

      Andre

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      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

       

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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.

       

       

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      Thank you for your feedback.

      Regards, Hans-Dieter

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      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

      Question:

      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,

      Hans-Dieter

       

       

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      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,

      Andre

       

      Author's profile photo Hans-Dieter Mader
      Hans-Dieter Mader

      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,

      Hans-Dieter

      Author's profile photo Anurag Shrivastava
      Anurag Shrivastava

      Hi Andre,

      ODATA created by CDS VIEW - Referenced data source and CRUD with BOPF, only for Fiori/UI5, or can we expose it to any other app like Mendix?

      My system is non-S/4 HANA system ( 7.50 version SP14, HANA DB )

      Thanks,

      Anurag

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      You can consume an OData service with any client.

      SAP Fiori Elements has however the option to leverage the annotations out of the box and also in UI5 you have means to read what's in those annotations.

      When you use another platform you would have to write code yourself if you are interested to leverage those annotations.

      Kind regards,

      Andre

       

      Author's profile photo Pavel Belski
      Pavel Belski

      Hi @andre.fischer

       

      I faced with the issue to publish OData V4 on-premise 2020? Service Binding is created without any issues.

      Error text:
      "(Un-)Publishing of SRVB ZUI_FLIGHT_R_O4 in Customizing Client not allowed"

       

      thx in advance,

      Pavel

      Author's profile photo Lea Zimmermann
      Lea Zimmermann

      Hi Pavel,

       

      I faced the same problem and the solution was to change the role of the client.

      In transaction SCC4 you can see a list of clients. For the one you are working on, change the role from Customizing to Training/Education. Afterwards you should be able to publish the service.

       

      Best regards,

      Lea

      Author's profile photo Pavel Belski
      Pavel Belski

      Hi Lea Zimmermann thx for your solution,

      but I guess it should work in Customizing system as well, @@andre.fischer isn't it?

       

      Regards,

      Pavel

       

       

      Author's profile photo Sören Schlegel
      Sören Schlegel

      Hi Pavel,

       

      sad to say, but that's the limitation for the moment. Alternativly, the publishing can be done in the Test-System - that's also possible.

      There are some workaround, but all in all, it's not really satisfying.

       

      Regads,

      Sören

      Author's profile photo Andre Fischer
      Andre Fischer
      Blog Post Author

      Why should this work in a customizing client?

      In a customizing client you do customizing, not ABAP development.

      Or have I missed something here?

      Author's profile photo Pavel Belski
      Pavel Belski

      sounds logical, but why is able to publish OData V2 in customizing client without any issue?

      Author's profile photo Thomas Feyer
      Thomas Feyer

      SCC4 doesn't have a separate setting for development clients, "Customizing" means customizing and development.

      Author's profile photo Ravi Singh
      Ravi Singh

      Hi Andre, Nice blog.

      One thing which is missing is post Actions in v4. Really appreciate if you could give some example for the same.

      Thanks !