Technical Articles
Creating OData API based on a Mapped Data Source
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.
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:
|
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:
Do not use this option if:
|
ABAP Development Tools |
|
|
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:
Do not use this option if:
|
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.
Use this option if:
Do not use this option if:
|
Transaction SEGW |
https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.52.4/en-US/ed2ed4e2cbc54ffdba3aead4f3a73640.html
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.
I don't think it is a good idea to dev odata in this way.
you should not map to sql view, sql view should be considered not existed.
if you need query function only, you can use annotation to expose cds as odata
in new version, you can use data source reference to expose cds as odata.
Jun Wu , I wouldn't say it's "Not a good idea", this is definitely beneficial in the older system, for instance in my case I do this more often and it comes in handy. Moreover, OP is not mapping the SQL view, it's the CDS view that is mapped there (you can check the CDS view name is given in the SEGW).
my bad, mislooked.
Hi Jun Wu, I have used the CDS view as mapped data source. I have also updated the recommendation and diff options to generate the CDS view.
I hope that helps.