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:
These represent the original CDS view models.
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. Because primarily view entities are expected to benefit from further improvements of the CDS infrastructure, we recommend always defining V2 views instead of V1 views.
You can migrate your existing V1 views to V2 views. This migration can be achieved by manually changing the statement define view ... to define view entity.... Alternatively, because you can run report RUTDDLSV2MIGRATION or use the corresponding functionality Migrate to CDS View Entity of the context menu in the Project Explorer view of the ADT environment.
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 tools just mentioned perform some of the necessary adjustments automatically and provides you with information about potential changes in its log. Therefore, we suggest using the tools for migrating V1 views.
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.
Transient views (sometimes also referred to as V3 views) define CDS view entities without a direct representation on the SAP HANA database system. They act as mere declarative view models whose runtime behavior is governed and implemented by infrastructure components such as the analytical engine. This implies that you can neither use transient views as data sources for other CDS views nor can you select from transient views in your ABAP code.
For the sake of brevity, we’ll refer to CDS view entities when talking about CDS views or simply views unless explicitly mentioned otherwise.
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 Table functions of the CDS models themselves by applying a declarative CDS syntax, the implementation of table functions leverages native SAP HANA SQLScript syntax. The usage of SAP HANA SQLScript 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.
CDS simple types define reusable scalar type definitions. From the CDS perspective,
simple types can be interpreted as successors of the ABAP Data Dictionary data elements.
For CDS view models with simple logic, a buffer can be defined on the application
server. In this context, entity buffer definitions capture the required administrative data similar to table buffers that are managed by the ABAP Dictionary. Direct data selections from buffered CDS views via the ABAP SQL interface are automatically transferred to the buffer by the ABAP runtime environment, if the request can be processed on the buffer. This can help reduce the load of the SAP HANA database and speed up the provisioning of the requested data.
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.