Let us start our encounter with Core Data Services (CDS) View with questions and answers. Before we explain What is CDS View, let us ask, Why CDS View?
Question: Why do we really need CDS Views?
Answer: According to SAP, CDS Brings Conceptual and Implementation Level Closer Together.
What does this mean?
Say our requirement is to get the id, name and the respective zip code of the home address for all employees in org_unit ‘4711’.
In order to meet this requirement, SQL developers write below SQL.
The issue with the above SQL: Large Semantic Gap between Requirement and SQL Code.
If you are not an experienced SQL developer, you would find it complex/difficult to understand the meaning/semantic of the SQL. Therefore SAP wanted something simpler and better. This is one motivation for CDS.
Being an ABAPer you find the above SQL complex and you decide to write your own Open SQL in ABAP.
Issue with the above Open SQL: SQL Complexity Leads to Imperative Code (codes which are like instructions/statements which change its state. Imperative programming focuses on describing how a program operates.)
There are performance concerns in the above Open SQL. Loops in loops, nested queries with many round trips is not advisable. This is another motivation for CDS.
Now, let us see how CDS would do the same task.
Same requirement: Get the id, name and the respective zip code of the home address for all employees in org_unit ‘4711’.
With CDS, SQL developers see small or no semantic gap and ABAPers do not need any coding. You get the result directly from the CDS. Isn’t this motivation enough?
Question: We already have Database Views in ABAP (SE11), then why do we still need “CDS views”? Or, What are the advantages of using “CDS views”?
Answer: CDS is much more powerful than what it appears. The CDS concept is far more than simple view building but describes a DDL for building a meta-model repository involving database tables, database views, functions, and data types.
CDS was invented by SAP, because the modeling capabilities of the ABAP Dictionary and of the “SAP HANA Studio” are not sufficient for the needs of all fully blown business applications with modern needs.
With “HANA CDS”, CDS is available for SAP HANA in the SAP HANA studio. With “ABAP CDS”, the CDS concept is also made available for the AS ABAP, where the features of CDS surpass the modeling capabilities of SE11. ABAP CDS is open and not restricted to SAP HANA (i.e. database independent).
If we need meta-models for our application, that can be built with CDS, then we need CDS views.
Question: OK, we read above that CDS was invented to facilitate needs which ABAP Dictionary and HANA Studio could not meet. So, what are the types of CDS Views?
Answer: There are two types of CDS Views.
- ABAP CDS
- HANA CDS
Also, CDS Views can be categorized as of two types:
1) CDS Views without Parameters
2) CDS Views with Parameters
Question: Why was CDS introduced? (same question in a different way)
Answer: With CDS, data models are defined and consumed on the database rather than on the server. CDS also offers capabilities beyond the traditional data modeling tools, including support for conceptual modeling and relationship definitions, built-in functions, and extensions. Originally, CDS was available only in the design-time and runtime environment of SAP HANA. Now, the CDS concept is also fully implemented in SAP NetWeaver AS ABAP, enabling developers to work in the ABAP layer with ABAP development tools while the code execution is pushed down to the database.
Question: Finally, What is Core Data Services?
Answer: CDS is an infrastructure layer for defining semantically rich data models, which are represented as CDS views. In a very basic way, CDS allows developers to define entity types (such as orders, business partners, or products) and the semantic relationships between them, which correspond to foreign key relationships in traditional entity-relationship (ER) models. CDS is defined using an SQL-based data definition language (DDL) that is based on standard SQL with some additional concepts, such as associations, which define the relationships between CDS views and annotations, which direct the domain-specific use of CDS artifacts. Another example is expressions, which can be used in scenarios in which certain CDS attributes are considered as measures to be aggregated.
Similar to the role of the DDIC in the traditional ABAP world, data models based on CDS serve as central definitions that can be used in many different domains, such as transactional and analytical applications, to interact with data in the database in a unified way . However, CDS data models go beyond the capabilities of the DDIC, which were typically limited to a transactional scope (think of traditional online transaction processing functionality). For example, in CDS, you can define views that aggregate and analyze data in a layered fashion, starting with basic views and then adding powerful views that combine the basic views. Another difference is the support for special operators such as UNION, which enables the combination of multiple select statements to return only one result set.
CDS artifacts are stored in the DDIC and can be accessed in ABAP programs via Open SQL in the same manner as ordinary ABAP tables or views.
In simple words:
Core data services are a new infrastructure for defining and consuming semantically rich data model in SAP HANA. Using a data definition language (DDL), a query language (QL), and an expression language (EL), CDS is envisioned to encompass write operations, transaction semantics, constraints, and more.
We can use the CDS specification to create a CDS document which defines the following artifacts and elements:
Entities (tables)
Views
User-defined data types (including structured types)
Contexts
Associations
Annotatin
Question: When do we need CDS Views?
Answer: It depends on reusability. If the functionality of a view is only needed once, then no need to create CDS Views. We can use Joins, SQL expressions, subqueries etc in Open SQL for this code push down. But if we want to reuse a view, need semantical or technical capabilities of CDS that exceed those of Open SQL (but we try to keep the technical capabilities on the same level, e.g., CDS knows UNION, Open SQL will know UNION with an upcoming release) or we just want to push down the full data model to the database, we need CDS.
Question: What is the fundamental difference between HANA CDS and ABAP CDS?
Answer: The subtle differences between CDS in native SAP HANA and CDS in ABAP lies in the view definition. In both the ABAP and HANA scenarios, views are created on top of existing database tables that are contained in the DDIC. With CDS in native SAP HANA, we must create the basic entity types that correspond to the DDIC tables as part of the CDS view definition. With CDS in ABAP, we can refer to any underlying DDIC table, view, or type from within the CDS view definition, avoiding the need to “duplicate” the DDIC table definitions on the CDS layer. In the ABAP scenario, the CDS definitions are considered DDIC artifacts and need to be activated like any other DDIC artifact and when changes are made, their impact is propagated to dependent artifacts.
Question: What is preferred ABAP CDS or HANA CDS if the client is in ABAP on HANA DB?
Answer: If you use ABAP on HANA DB, you can work directly on the DB and also use HANA CDS there. But then the CDS objects created are not managed by the ABAP Dictionary meaning you cannot access them directly with Open SQL and they are not TYPEs in the ABAP TYPE system.
Question: When should we use ABAP CDS and when should we use HANA CDS?
Answer: If you run SAP HANA standalone or in a side-by-side scenario (there is no ABAP stack on top) you cannot use ABAP CDS. You must use HANA CDS.
If you have an ABAP stack on top of a HANA database (an AS ABAP uses the HANA database as central database) then:
i) If you want to access the CDS entities in ABAP as data types or in Open SQL or if you want to evaluate the CDS annotations in ABAP, you must use ABAP CDS.
ii) If you do not want to access the CDS entities in ABAP, but you want to transport and upgrade them like ABAP repository objects, you can use ABAP CDS.
iii) If you do not want to access the CDS entities in ABAP as data TYPEs or in Open SQL, you can use HANA CDS, which is better integrated into SAP HANA. An access from ABAP is then possible using Native SQL (ADBC, AMDP) only.
Question: Can we consume ABAP CDS natively in HANA?
Answer: Yes we can. For each CDS view a database view (SQL view) is created in the database during activation. We can access that database view natively if we want to. CDS table functions are managed by AMDP. The respective database functions can also be accessed natively.
Question: Is it also possible to access the database views (generated by having a corresponding ABAP CDS view) in HANA natively and simultaneously consider the authorization logic defined in the corresponding DCL?
Answer: Yes. Open SQL checks the authorization implicitly but is of course translated into native SQL code doing that on DB level (implicit conditions). Same for the SADL framework that checks the authorizations itself natively. The problem is that you need to have access to the internal role representation which is not published and subject to change or you have to build a framework yourself that parses the role definition and creates the corresponding conditions.
Question: How can we find all CDS views in SAP?
Answer: Check the table TADIR in SE16; PGMID = ‘R3TR’, OBJECT = ‘DDLS’; here we find all DDL sources and the package of each source in column DEVCLASS. Knowing the package, we can use ADT (ABAP Development Tool in HANA Studio) to find the DDL sources in ADT.
Examine table DDLDEPENDENCY in SE16; it contains the names of all DDL sources and the names of the CDS entities (value STOB in column OBJECTTYPE) defined therein as well as the names of the generated database views (value VIEW in column OBJECTTYPE); (one row for each -> two rows for each DDL source). => Selecting VIEW for OBJECTTYPE gives you all CDS database views.
Now let us try to open the DDL source of the CDS in SE11.
Check it would prompt us to go to ADT Tools to view it.
Now, let us open the DDL SQL View of the CDS. Note the warning below which says DDL SQL views are only supported in a limited way by SE11.
Having one name is just not good enough in CDS; we need two names.
One name is for the SQL view that is going to be created in the dictionary (the one we will be able to look at in SE11), and the other name we have is a name for the CDS view entity, which is viewed and changed via Eclipse.
PS: We could name both the SQL view and the CDS view the same, but we should not as they are different things, so the name should reflect the difference.
SQL view is visible in SE11, however, we cannot edit it in SE11.
CDS View entity is the one we should refer to in SELECT statements in our ABAP programs. Although we can use DDL SQL View in our programs, but we should not.
Question: How can we use CDS views?
Answer: Basically, a CDS View is an entity that can be addressed by its name:
in ABAP as a TYPE
in Open SQL as a DATA SOURCE
Basically, a CDS View is an entity that can be addressed by its name in ABAP as a TYPE in Open SQL as a data source
Seeing a CDS View in SE11 is kind of a technical artifact and we should not address the database view that is shown there in our ABAP programs. From SE11 you can also navigate to the database object that is generated from the definition. This database object can even be accessed directly with Native SQL.
This means we can access our CDS Views directly in ABAP programs or from elsewhere. For evaluating the semantic properties (annotations) of a CDS View (stored in system tables) we should use an appropriate API (CL_DD_DDL_ANNOTATION_SERVICE if available in your system).
The database views created from the CDS source code are merely “for technical” reasons. The CDS source code and the CDS entity defined there should be the “real thing”.
Question: What are the Salient Features of CDS?
- Semantically Rich Data-Models
- Domain specific languages (DDL, QL, DCL)
- Declarative, close to conceptual thinking
- CDS is completely based on SQL
- Any ‘Standard SQL’ features (like joins, unions, built-in functions) is directly available in CDS
- Fully Compatible with Any DB
- Generated and managed SQL Views
- Native integration in SAP HANA
- Common Basis for Domain-Specific Framework e.g. UI, Analytics, Odata, BW,…@AnalyticsDetails.aggregationBehaviour: SUM
- Built-in Functions and Code Pushdown
- Table Functions for Breakout Scenarios
- Rich Set of Built-in SQL Functions
- Extensible
- On model level thru extensions
- On meta-model level thru annotations
