Introduction

Extenstions of OData Services that have been created using the Reference Data Source (RDS) approach do not work out of the box. When you try to add additional entities to the SEGW project that redefines an RDS based OData service these entities are not part of the $metadata document.

This is quite unfortunate since most of the OData services hat have been delivered with SAP S/4HANA are based on RDS.

It is however possible to redefine a reference data source based OData service and perform certain adjustments in the MPC_EXT and DPC_EXT class to achieve this goal.

In the following I will describe the steps that are needed in order to redefine a reference datasource based OData service and how you can use the reference datasource approach in order to add additional entities that are handled by the SADL framework as well.

To make the live of the ABAP developer easier I have provided a report that lets you select the source and the extended SEGW project that will generate the aforementioned boiler plate coding.

The source code of the report can be found on GitHub

There I have also posted a code sample that has been generated by this report for the simple extension example described in this blog post.

Example of generated MPC_EXT and DPC_EXT code

Summary

In the following I will use the following terms. In the following I will use a simple example of an RDS based source SEGW project Z_SRC_RDS that uses two CDS views: SEPM_I_SALESORDER_E and SEPM_I_SALESORDERITEM_E.

This project is redefined in a second SEGW project called Z_REDEF_RDS where two additional CDS views ZI_Currency and I_CurrencyText have beend added.

Adjust the MPC_EXT class

In the method IF_SADL_GW_MODEL_EXPOSURE_DATA~GET_MODEL_EXPOSURE, the SADL framework generates the SADL definition, an XML file that contains the structure and the datasources that have been added to your SEGW project using RDS.

The following code snippet shows the sadl definition of an RDS based service Z_SRC_RDS that is based on two CDS views, SEPM_I_SALESORDER_E and SEPM_I_SALESORDERITEM_E.

DATA(lv_sadl_xml) =
               |<?xml version="1.0" encoding="utf-16"?>|  &
               |<sadl:definition xmlns:sadl="http://sap.com/sap.nw.f.sadl" syntaxVersion="" >|  &
               | <sadl:dataSource type="CDS" name="SEPM_I_SALESORDERITEM_E" binding="SEPM_I_SALESORDERITEM_E" />|  &
               | <sadl:dataSource type="CDS" name="SEPM_I_SALESORDER_E" binding="SEPM_I_SALESORDER_E" />|  &
               |<sadl:resultSet>|  &
               |<sadl:structure name="SEPM_I_SalesOrderItem_E" dataSource="SEPM_I_SALESORDERITEM_E" maxEditMode="RO" exposure="TRUE" >|  &
               | <sadl:query name="SADL_QUERY">|  &
               | </sadl:query>|  &
               |</sadl:structure>|  &
               |<sadl:structure name="SEPM_I_SalesOrder_E" dataSource="SEPM_I_SALESORDER_E" maxEditMode="RO" exposure="TRUE" >|  &
               | <sadl:query name="SADL_QUERY">|  &
               | </sadl:query>|  &
               | <sadl:association name="TO_ITEM" binding="_ITEM" target="SEPM_I_SalesOrderItem_E" cardinality="zeroToMany" />|  &
               |</sadl:structure>|  &
               |</sadl:resultSet>|  &
               |</sadl:definition>| .

When you create an extension project Z_REDEF_RDS and when you add two additional CDS views using the reference data source approach you will find that the MPC class also contains a SADL definition. But this SADL definition only contains the newly added entities.

    DATA(lv_sadl_xml) =
               |<?xml version="1.0" encoding="utf-16"?>|  &
               |<sadl:definition xmlns:sadl="http://sap.com/sap.nw.f.sadl" syntaxVersion="V2" >|  &
               | <sadl:dataSource type="CDS" name="I_CURRENCYTEXT" binding="I_CURRENCYTEXT" />|  &
               | <sadl:dataSource type="CDS" name="ZI_CURRENCY" binding="ZI_CURRENCY" />|  &
               |<sadl:resultSet>|  &
               |<sadl:structure name="I_CurrencyText" dataSource="I_CURRENCYTEXT" maxEditMode="RO" exposure="TRUE" >|  &
               | <sadl:query name="SADL_QUERY">|  &
               | </sadl:query>|  &
               |</sadl:structure>|  &
               |<sadl:structure name="zI_currency" dataSource="ZI_CURRENCY" maxEditMode="RO" exposure="TRUE" >|  &
               | <sadl:query name="SADL_QUERY">|  &
               | </sadl:query>|  &
               | <sadl:association name="TO_TEXT" binding="_TEXT" target="I_CurrencyText" cardinality="zeroToMany" />|  &
               |</sadl:structure>|  &
               |</sadl:resultSet>|  &
               |</sadl:definition>| .

In order to leverag all reference data source based entities one has to merge both SADL definitions. The merged SADL xml file has than to be provided in the redefined method IF_SADL_GW_MODEL_EXPOSURE_DATA~GET_MODEL_EXPOSURE of the MPC_EXT class of the project Z_REDEF_RDS.

In addition we have to redefine the DEFINE method so that it calls the DEFINE method of its parent class.

Adjust DPC class

The method IF_SADL_GW_DPC_UTIL~GET_DPC contains (for historical) reasons the same sadl definition. We have hence to provide the merged SADL xml file in the redefined method in the DPC_EXT class of the extended SEGW project as well.

When adding additional CDS views to your redefined RDS based SEGW project Z_RDS_SRC you will find that no entity specifc methods are generated in your extended SEGW project Z_REDEF_RDS.

It is thus necessary to add manually entity specific methods such as

i_currencytex_get_entity

i_currencytex_get_entityset

zi_currency_get_entity

zi_currency_get_entityset

The generic methods control which entities can be reached in the service at runtime. Please note that the entity specific methods ultimately only contain a delegation to the SADL runtime. In the generic methods

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITY,

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITYSET,

you have to provide appropriate CASE statements so that your entity specific methods are being called when an appropriate OData request is handeled by the SAP Gateway framework.

METHOD /iwbep/if_mgw_appl_srv_runtime~get_entity.
    DATA(my_entity_name) = io_tech_request_context->get_entity_set_name( ).
    CASE io_tech_request_context->get_entity_set_name( ).
      WHEN 'I_CurrencyText'.
        i_currencytex_get_entity( EXPORTING io_tech_request_context = io_tech_request_context
                                       IMPORTING er_entity               = DATA(i_currencytex_entity)
                                         es_response_context     = es_response_context ).
        IF i_currencytex_entity IS NOT INITIAL.
          copy_data_to_ref( EXPORTING is_data = i_currencytex_entity
                           CHANGING  cr_data = er_entity ).
        ENDIF.
      WHEN 'zI_currency'.
      ...
ENDCASE.

Result

When having performed the aforementioned adjustments the OData service of the redefined SEGW project now contains four CDS based entities.

Problems when redefining large OData Services

Failures during consistency checks

You might encounter the problem that SEGW will not be able to redefine one of the huge OData services that are part of SAP S/4HANA since consistency checks fail.

To overcome this issue several notes have been created that are also part of the latest deliveries of the SAP Gateway framework.

2853065 – SEGW Tool update – Association & Referential Constraints

3115221 – SEGW Tool – Covert Error Messages to Warnings during check

Time out problems

Redefinition of large OData service might take several minutes so that the maximum runtime of a workprocess is exceeded. The profile parameter “rdisp/scheduler/prio_high/max_runtime” is used to configure the dialog request run-time limit, i.e., the time that a request is allowed to run in a dialog work process without interruption.

Fortunately it is possible to change the setting of this profile parameter online using transaction RZ11. So you can adapt this setting without the need to reboot your development system.

Tool support

Since merging XML files and creating additional methods in the DPC_EXT class is a time consuming and errorprone task I have developed a report that lets you select two SEGW projects. A source project and an extension project.

The report will generate the source code in a separate text file that has to be implemented in the MPC_EXT and the DPC_EXT class of your SEGW extension project.

The only thing that is left to do for the developer is that he or she has to copy and paste the generated code into the MPC_EXT and the DPC_EXT class.

At the moment it is also necessary to select the TYPES that have been generated in the MPC class via code completion.

Outlook

I am currently testing code snippets that can be added to your MPC_EXT and DPC_EXT class that are calling the so called flex classes. Flex classes are part of SEGW projects where the OData services have been prepared to support the extension by key user tools.

Flex classes are parent classes of the MPC_EXT and DPC_EXT class of an OData service and they are in turn inheriting from the MPC and DPC class of the SEGW project delivered by SAP.

This code is needed so that fields that have been added using the custom fields key user tool are also visible in the SAP FIori application if the underlying OData service has been redefined.