SAP ABAP Central: OData Versioning

OData has become an inevitable topic for any SAP ABAP developer. I am sure most of us are involved in an OData development one way or the other.

Let’s discuss versioning, one of the advanced concepts of OData.

Note – I are working with OData version 2.0 in this article.

Motivation

Ever wondered if the business logic of an OData can be modified and activated as a different version without effecting the current business logic? I did and some of the scenarios I have faced are

Front-end team is not yet ready for the change but I would like to keep going.

I was working on an API and wanted to roll-out version 2 but wanted to maintain an active version 1 as well.

What kind of changes?

Mostly breaking changes that will not go well with the front-end implementation of the OData. Some of them are

◉ Adding a mandatory filter to the OData the front-end has not implemented

◉ New validation on the back-end that front-end is not adhering to

◉ Changing the key fields

◉ Deleting a field that is utilized by the front-end

Metadata based categorizing of OData versioning

These changes can be broadly categorized into 2 types based on the metadata

1. OData versioning not including metadata change

2. OData versioning including metadata change

Let’s discuss each one with an example.

Example OData

I have created an OData with the well known SAP’s FLIGHT test data.

1. Using SEGW transaction create an OData project ‘ZODATA_VERSIONING’.

OData Versioning, SAP ABAP Tutorial and Materials, SAP ABAP Career, SAP ABAP Learning, SAP ABAP Study Materials, SAP ABAP Preparation

2. From the context menu of ‘Data Model’ create entity type ‘AvailableFlight’ and generate the OData project.

3. Change the ‘Technical Service Name’ to ‘FLIGHT’ and take a note of the Service Version 1. This is the default version of the OData ‘FLIGHT’ .As displayed below new Model Provider and Data Provider Classes are generated.

4. Using transaction code ‘/IWBEP/REG_MODEL’ we can verify that the ‘Technical Model Name’, ‘Model Version’, ‘Model Provider Class’ are registered in the back-end system. We can verify the same and ‘/IWBEP/REG_SERVICE’ respectively.

5. The model is registered stand alone.

6. Using transaction code /IWBEP/REG_SERVICE we can verify that the ‘Technical Service Name’, ‘Service Version’, ‘Data Provider Class’ are registered in the back-end system.

7. While the model is registered stand alone the service is registered in combination with the model

8. Now maintain the service in the Gateway system using T-CODE ‘/IWFND/MAINT_SERVICE’. Please note the service version ‘1’ and the Model version ‘1’ which were retrieved from the FLIGHT Technical Service Registration version 1 in the back-end.

9. OData service ‘FLIGHT’ with version 1 on both backend and the Gateway is maintained successfully.

10. The OData can be accessed via URL ‘/sap/opu/odata/sap/FLIGHT/AvailableFlightSet?$format=json’.

11. This is nothing but the default version 1 of the OData.

12. Adding ‘?v=1’ to the URL after the OData name provides the same result.

OData versioning not including metadata change

Let’s modify the OData logic without modifying the metadata.

Let’s say the requirement is to add a mandatory filter ‘CONNID’ but only to the new version.

1. Copy the respective data provider class(*DPC_EXT) class as below and add the required mandatory filter

METHOD AVAILABLEFLIGHTS_GET_ENTITYSET.

DATA: LR_CONNID TYPE RANGE OF S_CONN_ID.

DATA(LT_SO) = VALUE #( IT_FILTER_SELECT_OPTIONS[ PROPERTY = 'CONNID' ]-SELECT_OPTIONS OPTIONAL ).

IF LT_SO IS INITIAL."Return no data if CONNID filter is blank.

RETURN.

ENDIF.

SELECT *

FROM

SFLIGHT

INTO TABLE @DATA(LT_SFLIGHT)

WHERE

CONNID IN @LT_SO.

ET_ENTITYSET = CORRESPONDING #( LT_SFLIGHT ).

ENDMETHOD.

2. Register the new data provider class using transaction code ‘/IWBEP/REG_SERVICE’.

i. Make sure to select OData name as ‘FLIGHT’, same as the previous ‘Technical Service Name’ and version 2.

ii. Add the new data provider class as below and save.

iii. Click on ‘Assign Model’ button and assign the old model provider class and version 1.

iv. Maintain the service in the Gateway using T-CODE ‘/IWFND/MAINT_SERVICE’.

v. Please note the service version ‘2’ and the Model version ‘1’ which are retrieved from the FLIGHT Technical Service version 2 Registration in the back-end.

vi. On Gateway system via T-CODE ‘/IWFND/MAINT_SERVICE’, 2 versions of the OData FLIGHT are maintained.

vii. Both versions with different business logic can be accessed now.

1. Accessing data via the version 1 or default version of the OData with no mandatory filter

2. Version 2 of the OData does not return any data unless mandatory filter is added to the query.

OData versioning including metadata change

Now the new requirement is to add version 3 of FLIGHT OData with no Price field and add the mandatory CONNID filter as per version 2 to ‘AvailableFlight’ entity.

For the metadata change we need to create a new version of the Model Provider Class. But we need to do this without loosing SAP Gateway Service Builder(SEGW) tool assistance.

1. Copy the existing project via the SEGW T-CODE

2. Remove the ‘PRICE’ field from the OData ‘AvailableFlight’ entity.

3. Generate the OData and change the ‘Technical Service Name’ to ‘FLIGHT’ and the ‘Service Version’ to 3.

4. Add the mandatory filter logic as required in the data provider class

‘ZCL_ZODATA_VERSIONING3_DPC_EXT’. This code is same as version 2 of the OData.