Varad
CDS Section 3: Using annotation, expose CDS views as an OData service , You are probably already familiar with CDS Views if you have been following our series on SAP ABAP on HANA. If not, kindly refer to our HANA ABAP Parts IV and V, where we covered a thorough analysis of CDS Views and the introduction of Core Data Services, respectively. Additionally, you are aware that SEGW is the t-code for generating OData Projects and ultimately publishing an OData Service if you have been using our SAP Netweaver Gateway and OData Services Tutorial Course.
However, would it surprise you if we told you that you could establish your OData projects without utilizing a SEGW transaction?Today, we’ll demonstrate how to expose CDS View as an OData service using only a few annotations (i.e., SQL code).
Overview
We have thoroughly investigated the CDS perspectives with key features.Another wonderful power that CDS offers users is the ability to expose views as OData services. Importing the view you built is a traditional method of creating a service in SEGW.
This article shows how to reveal a view as a gateway service using only a subtle annotation.There’s no need to use SEGW to construct services.Sounds fantastic?See if we can make that happen.
Technical Context
We have been using Eclipse Luna for CDS views.
The gateway application has been implemented with OData version 2.
Step I: Construct a view that joins tables VBAP and MARA on the left. We have classified MARA as “prod” and VBAP as “soitem.” An outside connect on the left between
Fig. 1-Make the Initial View
Step II: Work with the Association to create a second view.Associations in Gateways are more similar to those in CDS perspectives. To associate or conceptually join one data source to a target data source subject to a specified condition, you build an association. In theory, associations connect two entities if data sources are thought of as OData service entities.
Fig. 2: Establish a view using OData annotation and association
Pay close attention to the annotation on the sixth line:True, @OData.publish.This is the article’s magic spell for today.
Step III: Our view is now prepared. We should be able to view data from the Header table (VBAK), Item table (VBAP), and Product table (MARA) using the DDL view.
Fig.3- DDLS
Data from the view in Fig. 3
Fig. 4: View of OData Exposure
Step V: To register the service generated by CDS, proceed as directed to transaction /IWFND/MAINT_SERVICE in the gateway system.
Fig.4- OData Exposure in View
Step – V :
Fig.5- Find Service in /IWFND/MAINT_SERIVCE
Step – VI :
When the service is located, select it to register and store it in the relevant package.Take note that we haven’t created any services using SEGW.The OData Annotation maintained allowed this service to be generated automatically.
Step VII:
Use the appropriate OData query to test your service now using the /IWFND/GW_CLIENT transaction. Note that in contrast to a typical gateway, the query uses “to_{association name>” to travel to the second data set. Since vbeln was added as an association condition to our “ZTEST_ASSOC_VIEW2,” an OData query must be used to retrieve the value in order to retrieve the data.
Fig.7: Data Fetch for Test Gateway
Restrictions
Additionally, please be aware that this service can only do GET operations.With this CDS view OData Exposure, no other CRUD actions are possible.
This technique of exposing CDS views as OData services is quite useful, even with the aforementioned limitation, since CDS views are often developed for data fetching (GET operations). This further demonstrates the strength of the Core Data Services’ annotations (New SQL).
you may be interested in this blog here:-
Get Latitude and Longitude of any place using Google Map API in SAP
5 Methods for Using Your Salesforce Email Sender Reputation: An Story of Redemption
