Creating OData API based on a Mapped Data Source

lpodile · ‎04-07-2021

This blog post will provide the steps to implement the pagination in OData by leveraging the CDS view and the SADL framework based on Mapped Data Source.

Introduction:

SADL offers a mapping editor in the SAP Gateway Service Builder to bind one or several SADL models to OData entity sets. This enables you to use SADL models as an additional data source besides RFC and others. Once the OData properties are mapped, the system provides a standard, optimized implementation of the OData service to retrieve the data.

Please refer the below link for the prerequisites and supported SAP version.

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.52.4/en-US/820b24ce35c745bb9e0fb3a6e8...

Now let see how to create the Gateway project using CDS view and SADL framework.

Agenda:

Creating CDS view

Create Gateway project

Test from Gateway client

1. Create the CDS view:

Create the CDS view from Eclipse

Right click on the package icon, and from the context menu select New->other ABAP repository object.

Enter the CDS view name and description as below:

Create the CDS view as below by selecting required fields from ACDOCA table.

2. Create Gateway project:

Create the DDIC structure to map fields of a CDS view to your custom model.

Now create the Gateway project from SEGW as below.

Once Gateway project is created, Right click on the Data Model and select 'Import' and DDIC Structure.

Enter the Entity Type Name and ABAP Structure and click on 'Next'.

In the next screen, select the required parameters and click on 'Next'

In the next pop up window, select the required key fields and click on 'Finish'

As shown below, created the Gateway project with the entity type.

Next, in the service implementation, right click on the entity set and select the 'Map to data source'.

Select F4 help on the Name field and enter the SADL model type as CDS Core Data Services and SADL model name as ZCDSV_ACDOCA_TEST. Select Enter.

Now map the SADL model elements to properties as shown below.

Once the mapping is completed, Press the Generate Runtime Objects button.

Note: Using the Generate Runtime Objects button automatically saves the project.

Like below, the Runtime artifacts will be generated.

Expand the node Service Maintenance and right-click on GW_HUB and select Register

In the Add Service popup leave all values as defaulted and press the Local Object button to assign the artifacts to the $tmp package. Then press Enter to continue.

Double-click on the GW_HUB entry under Service Maintenance. Verify that the registration status on the right-hand side is showing a green traffic light.

3. Test from Gateway client:

Now select the 'SAP Gateway client' and execute the service with the $skip and $top parameters to implement the pagination.

Recommendation:

You have different options to generate a CDS view as OData service:

Options to Generate OData Services
Option	Use Case	Tool	More Information
Auto-Exposure	Let us assume that you created a quite elementary data model based on multiple CDS views. All these views together form a quite simple composition: One CDS view serves as root and the other CDS entities are children of your root CDS view. The CDS views of this composition might also have associations to other entities. With this option, a simple way of creating OData services has been introduced. Here, the OData model definition as well as the OData service runtime is provided generically and with low manual effort. Use this option if: You want to expose such an elementary CDS data model as an OData service, together with first the level of associations. Do not use this option if: Your data model composition is more complex and/or you need to include deeper association levels in your OData service. You want to create a hybrid scenario where implementations are based on CDS views and on custom logic.	ABAP Development Tools	Generating OData Service With Auto-Exposure
Referenced Data Source (RDS)	Use Case 1: You created several CDS views and complex CDS view compositions. You need to include in the OData service several levels of associations from CDS views to other entities. Use Case 2: You created a CDS view that contains features that are not supported by CDS or complex CDS view compositions. You need to implement these features manually in the model provider extension class (MPC_EXT class) or in the data provider extension class of your Service Builder project. To provide, for example, dynamic field control, you need to implement custom logic in a model provider extension class. Use this option if: The CDS model and the CDS annotations fully specify the OData Model and the runtime behavior Your data model is based on CDS, but is more complex than simple compositions and includes advanced features, such as transactional processing You want to modify the service with custom code implementations. Do not use this option if: Your data model is not only based on CDS.	Transaction SEGW	Generating an OData Service Based on a Referenced Data Source
Mapped Data Source (MDS)	You modeled an entity set in transaction SEGW from a DDIC structure. You want to map fields of a CDS view to your custom model. You furthermore want to reference from your custom model to another CDS view, for example, and therefore need to map the two different entity sets. Caution Future changes of the entities might invalidate the service runtime. Use this option if: Your data model includes non-CDS entities RDS is not available for your release version. Do not use this option if: One of the other options is applicable.	Transaction SEGW	Creating OData Services based on a Mapped Data Source (MDS)

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.52.4/en-US/ed2ed4e2cbc54ffdba3aead4f3...

Conclusion:

Creating OData service based on mapped data source using the CDS view with SADL framework, enable to optimized implementation of the OData service to retrieve the data along with pagination.