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.
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.
- 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.
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.
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
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. It is planned to make these features also available for older SAP NetWeaver stacks (AS ABAP 751 and AS ABAP 750). As mentioned in the SAP Gateway roadmap no downports are planned for releases prior to SAP NetWeaver 750.
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.
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.