Core data services (CDS) models comprise the definitions of various CDS entity types such as CDS views and CDS abstract entities. These entity types will cover different use cases.
Typically, the CDS entity type can’t be changed after the corresponding CDS model is activated. From a technical perspective, all CDS entity types are assigned to the object type DDLS. The table below shows the fundamental definitions of these CDS entity types along with their envisioned usages.
As shown, there are three different types of CDS view models, which allow data selections to be performed in the SAP HANA database:
Views (aka V1 Views)
These represent the original CDS view models.
View Entities (aka V2 Views)
These represent the successor of V1 views. Compared to V1 views, V2 views don’t generate an additional ABAP Data Dictionary view upon their activation. This reduces the risk of technical inconsistencies and improves the overall activation performance. Furthermore, V2 views enforce more homogenous modeling and apply stricter syntax checks. For example, V2 views foster uniform client handling, which avoids some of the issues that might occur when defining and using V1 views. We recommend always defining V2 views instead of V1 views.
Migration of V1 Views to V2 Views
Because only view entities are expected to benefit from further improvements of the CDS infrastructure, we suggest migrating your existing V1 views to V2 views. This migration can be achieved by manually changing the statement define view … to define view entity …, or by running report RUTDDLSV2MIGRATION.
However, before migrating a V1 view, all the usages of its generated SQL view need to be removed. Additionally, the definitions of the V1 views and their extensions need to be aligned with the stricter syntax checks and behavior of V2 views prior to their migration. The migration report just mentioned performs some of the necessary adjustments automatically and provides you with information about potential changes in its log.
These represent a specialization of the view entities. Their main purpose is the definition of interfaces on their underlying CDS models with a modeled mapping of the corresponding functionality. As a result, projection views restrict the overall functionality of view entities to mere projection features.
For the sake of brevity, we’ll refer to CDS view entities when talking about CDS views or simply views unless explicitly mentioned otherwise.
Additional Definitions to Know
Here are some more terms to know about CDS views.
Extend views and extend view entities allow you to enhance a CDS view or a CDS view entity, respectively, with additional fields and associations; that is, they allow you to define extensions of CDS data models.
Whereas the selection logic of CDS views is implemented in the definitions of the CDS models themselves by applying a declarative CDS syntax, the implementation of table functions leverages native SAP HANA script syntax. The usage of SAP HANA script enables a higher degree of freedom in the way the selection logic is implemented. In addition, it provides you with the option to use functions that aren’t yet supported by the CDS syntax. However, there are also several drawbacks to using table functions.
Similar to table functions, custom entities only capture the signature of a data model within the CDS model definition itself. The actual implementation of custom entities occurs in ABAP code. As such, the logic of custom entities can’t be executed on the database level. Instead, custom entities can be used to define OData entity sets that are processed by the SADL infrastructure.
For more information, refer to http://s-prs.co/v529401.
ABAP Logic Can’t Be Used in Logic Accessed from SAP HANA: You can’t incorporate ABAP logic into the logic being executed on SAP HANA. ABAP logic can only be processed before or after processing the logic on SAP HANA.
Abstract entities are used to define signatures without implementation. In the context of the ABAP RESTful application programming model, you can use them for defining data structures for parameters and results of actions and functions. Furthermore, abstract entities may be used for defining proxies of external service models entities. For more information, refer to the SAP documentation at http://s-prs.co/v529421.
Hierarchy entities allow you to gain access to the functionality of SAP HANA hierarchies; that is, they allow you to leverage SAP HANA hierarchy features in your ABAP code.
Whereas all the aforementioned CDS models represent dedicated CDS entity types, metadata extensions represent an extension option of the CDS entity type instead. From a technical perspective, they are assigned the object type DDLX. The purpose of metadata extensions is to enrich and redefine annotations of CDS entities.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.