Table of Contents
2. Motivation behind Core data services
3. ABAP CDS Entities
4. Access Control for CDS Entities
5. Virtual Data model in ABAP CDS
After the evolution of SAP HANA, the technology within the SAP is changing rapidly and there has been a paradigm shift in the way business applications are developed at SAP.
The rule of thumb is simple: “Do as much as you can in the database to get the best performance”.
Data models are a cornerstone of application development. They provide a standardized method for defining and formatting database contents consistently across systems, enabling different applications to share the same data — reducing development costs, speeding time to market, and improving quality and performance.
Those familiar with application development in the ABAP world are no strangers to the traditional data modeling tools included with SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP — in particular, the ABAP data dictionary (DDIC), which stores definitions of objects, such as database tables and views, that can be used in ABAP programs and then along came SAP HANA and the new paradigm of pushing down data-intensive logic to the database layer.
The concept of Virtual Data Model (VDM) was introduced with HANA Live few years ago, SAP HANA Live is a Virtual data model on top of suite tables which uses native SAP HANA SQL views called Calculation views for real-time operational Reporting.
This came with certain challenges:
- Didn’t support hierarchies properly.
- High quality data models should provide a single definition and format for the data. They should be clear and unambiguous, reusable and flexible, even extensible.
- Lead to duplication of data.
Now, some questions come in mind:
- So how can you capture the semantics of the data model in the database so that the model can be easily reused by different consumers, e.g. by OData clients and by OLAP tools?
- How can you extend the meta model to service your applications?
- Impossible, you say?
Maybe, if we didn’t have Core Data Services (CDS).
“Core Data Services to build design-time data-persistence models”
To take advantage of SAP HANA for application development, SAP introduced a new data modeling infrastructure known as Core data services. With CDS, data models are defined and consumed on database server rather than on application 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.
CDS simplifies and harmonizes the way you define and consume your data models, regardless of the consumption technology. Technically, it is an enhancement of SQL which provides you with a data definition language (DDL) for defining semantically rich database tables/views (CDS entities) and user-defined types in the database. Some enhancements include:
- Expressions used for calculations and queries in the data model
- Associations on a conceptual level, replacing joins with simple path expressions in queries
- Annotations to enrich the data models with additional (domain specific) metadata
CDS is supported natively in both the ABAP and the HANA Platforms!
In fact, CDS is (in my opinion) the most ambitious and exciting SAP development in the area of data modeling in recent years. You can finally define and consume your data models in the same way (syntax, behavior, etc.) regardless of the SAP technology platform (ABAP or HANA). Unwantedly the phrase: “One Data Model to rule them all” always comes to mind when I think of CDS.
Besides a great blog by Horst Keller, describes the two different flavors of CDS.
After going through the above blog, we came to know that CDS can be written in two different flavors and uses the “Code Pushdown” techniques introduced with NW AS ABAP 7.4 SP5 where SAP added new possibility for ABAP developers to leverage HANA capabilities. In code pushdown technique, all calculations are performed on database layer instead of application layer, which results in fast retrieval of data, resulting cutback of application execution.
Motivation behind Core Data Services
- Semantically Rich data-models.
- CDS is completely based on SQL.
- Fully Compatible across any DB.
- Support for Annotations.
- SUM ()
- Substring () [SQL functions]
- On model level through extensions.
- On meta-model level through annotations.
CDS entities and their metadata are extensible and optimally integrated into the ABAP Data Dictionary and the ABAP language.
Note: - For more information about ABAP Core data services, Click Here.
ABAP CDS Entities
ABAP CDS provides a framework for defining and consuming semantic data models on the central database of the application server AS ABAP. The specified data models are based on the data definition language (DDL) and the data control language (DCL) which are managed by ABAP Dictionary. So, a CDS entity or the enhancement of a CDS view is defined as source code in the CDS data definition.
To define an ABAP CDS entity, you first need to create a DDL source as the relevant development object with which you can use the standard functions of the ABAP Workbench – such as syntax check, activation, or connecting to the Transport Organizer. A CDS entity is defined in the text-based DDL editor of ABAP Development Tools in Eclipse/SAP HANA studio.
The following types of ABAP CDS entities are supported:
Defining ABAP CDS Views
A CDS view is defined for existing database tables and views, or for other CDS views in ABAP Dictionary, using the ABAP CDS statement DEFINE VIEW. A CDS view serves to define the structure of an SQL view and represents a projection onto one or several Dictionary tables or Dictionary views.
Note: - SQL views and CDS entities are part of one and the same namespace. Therefore, you must assign different names for an SQL view and the entity.
Figure 1: Defining the CDS view in the DDL editor.
In figure 1 the CDS entity ZCDS_VIEW defines a projection onto the database tables scustom. The generated SQL view (ZcdsView) comprises the ID, the name, and the city of all entries.
a). The actual CDS entity (Zcds_View)
b). An SQL view (ZcdsView).
The several distinct types in which we can define a view are:
1. Define view
2. Define view with join.
3. Define view with Association.
4. Define view with Parameters.
Note: - For more information on several distinct types of Define View, Click Here.
Defining ABAP CDS Table Functions
A CDS table function is defined using the ABAP CDS statement DEFINE TABLE FUNCTION and can be used as the data source in Open SQL read statements.
Each CDS table function includes the following components:
· The actual CDS entity of the table function that is generated in the ABAP Dictionary.
· The CDS table function implementation (ABAP class library)
Note: - In contrast to the CDS views, the CDS table functions can be implemented using Native SQL. This implementation is done within an AMDP method of an AMDP class and is managed as an AMDP function by the AMDP framework in the database system.
Figure 2: Defining and Implementing CDS table functions.
The name of the implementing AMDP method can only be specified in a single CDS table function (1: 1 relation).
Note: - For more information on ABAP CDS Entities, Click Here.
Access Control for CDS Entities
ABAP CDS enables access control based on a data control language (DCL). Access control in ABAP CDS further restricts the data returned from a CDS entity in ABAP CDS.
ABAP CDS access control is based on the following:
- Currently, a CDS role is mapped to each user implicitly. Therefore, they are also known as mapping roles.
- Access conditions defined in a CDS role CDS entities. Access conditions can be the following:
- Literal conditions.
- PFCG conditions.
If a CDS role is defined for a CDS entity, the access conditions are evaluated implicitly each time an object is accessed using Open SQL or using an SADL query, unless access control is disabled using the value #NOT_ALLOWED for the annotation @AccessControl.authorizationCheck. If access control is enabled, only that data comes which meets the access conditions.
Each CDS role is defined a separate piece of CDS source code using DEFINE ROLE DCL statement. This CDS source code can only be edited in the ABAP Development Tools (ADT). When activated, the CDS role is characterized as a global internal object in ABAP Dictionary. The CDS source code of a CDS role is edited in a different editor from the CDS source code of a CDS entity (CDS view or CDS table function).
Imagine we have written a nice CDS view, e.g. as follows:
Now, we can create a CDS role (as shown below) in a DCL source code for above view.
If you don’t want any access restriction, you must decorate your view with the annotation @AccessControl.authorizationCheck: #NOT_ALLOWED. Then and only then CDS roles are ignored.
Note: - For more information on Access Control for ABAP CDS Entities, Click Here.
Virtual Data Model
A Virtual Data Model (VDM) is a structured representation of HANA database views which was introduced to be used in SAP HANA Live for SAP Business Suite. It provides direct access to SAP business data using standard SQL or OData requests. The VDM exposes the Business Data of an SAP system as an Understandable, Comprehensive and Executable model for consumers in Transactional applications, Analytics, External interfaces fulfilling important product qualities.
Now, to take advantage of powerful functionality of virtual data model in ABAP CDS views, SAP introduced @VDM annotations to define an ABAP CDS view which can be consumed and interpreted by Analytics engine used in different tools for Analysis.
The several distinct types of VDM are:
1. Basic view (Interface View) - Views that form the core data basis without data redundancies.
2. Composite view - Views that provide data derived and/or composed from the BASIC views.
3. Consumption view - Views that serve for specific application purposes and may be defined based upon public interface (for example, BASIC and COMPOSITE) views.
We have already seen, different virtual data model view types that are used for Analytics purpose. But only using VDM view types is not just enough for consuming CDS view in analytics tools because till now we have just defined data model for CDS view, nothing related to type of data CDS view is returning. So, to let the Analytical manager know how to interpret each CDS entity we must declare Data Category for each ABAP CDS views with VDM view type annotations.
The several distinct types of Data Category are:
1. Dimension - Views representing master data should be annotated with @ObjectModel.dataCategory: #DIMENSION. If we want to use one of these views for replication or for a query, data category should be DIMENSION.
2. Fact - This value indicates that the entity represents transactional data (center of star schema). Usually it contains the measures. Typically, these views are necessary for replication, therefore, they should not be joined with master data views.
3. Cube - The #CUBE value (like #FACT) also represents factual data, but #CUBE does not have to be without redundancy. This means joins with master data are possible. Queries are usually built on top of #CUBE, where data is replicated from facts.
4. Aggregation Level - This value indicates a projection. For this kind of view, the analytic manager offers write-back functionality. Views in this category have to select from a view with data Category as CUBE, which supports the annotation Analytics.writeBack.className. No associations are allowed, and elements cannot be renamed.