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.
- Code based implementation
- Mapped / Referenced Datasource
- 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 ...
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 Applicat...
- SAP Managed Tags:
47 Comments
| User | Count |
|---|---|
| 15 | |
| 13 | |
| 11 | |
| 11 | |
| 11 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 6 |
