- SAP Managed Tags
To take advantage of SAP HANA for application development, SAP introduced a new data modelling infrastructure known as Core data services. With CDS, data models are defined and consumed on database server rather than on application server.
CSD Views are going to be default paradigm for BW datasources and embedded analytics in S/4.
What is CDS ?
1)CDS is a new language (Open SQL)
2)Objects (CDS Views, CDS Tables, CDS Functions)
Combination of Language and Objects together is called CDS.
What is CDS Views ?
1)ABAP CDS Views:- Provided by SAP NetWeaver ABAP in combination with HANA.
2)HANA CDS Views:- Provided by SAP HANA XS/XSA application server.
What is ABAP CDS Views ?
1.Select Query on tables [ Can also be select query on CDS view.]
2.Based on new ABAP OpenSQL syntax.
3.Achieves code push down to Database [HANA or other].
4.Embedded analytics = Set of CDS Views. [Previously called HANA Live (CLVs) are depreciated and taken over by CDS Views]
5.Semantic – Annotations(@). [Gives Properties to CDS Views].
6.Association – Joins on Demand.
7.Expressions [Limited in normal DB Views]
8.Parameterized[Input Parameter].
9.No need to activate any BI content and is a virtual data model.
Limitations in ABAP Dictionary Views
Due to certain limitation in ABAP view, the CDS Views comes in picture.
Below are the limitation :-
1.Could not write complex expression when creating a DB views
2.Union ALL were not allowed.
3.Inner Join and simple selection were only possible.
4.Calculation expression, aggregation and grouping were not possible
5.Nested Views(view inside view) is not possible.
CDS Views will be used to Overcome the limitation and to push down the data into the database to use the HANA DB capability.
CDS (Core Data Services)
Core data services are the collection of domain-specific language and services for defining and consuming semantically rich models.
DDL (Data Definition language):- Model and retrieve data on a semantic level higher than SQL. Ex: Create CDS Views, tables and extend the CDS Views
QL(Query Language):- To consume in ABAP code. (Ex:- Select* from CDS views).
DCL (Data Control Language):- Define Auth. For CDS Views.
It is tightly integrated with Transport layer as it is an ABAP entity.
CDS related Objects
DDL Source:- Dictionary Object, contains definition of SQL View and CDS View. Write your code here. Upon activation below two Objects will be generated SQL view and CDS View, neither of them can be edited directly.
SQL View:- Dictionary Object.(Can be seen in SE11). Representative of database Object. Do not create anything on top of SQL View
CDS View Entity:- The Actual CDS View. Not a Dictionary Object. Select * will happen on this Object.
Creating CDS related Objects
The name of the CDS entity is specified after the DEFINE VIEW statement. The maximum length is 30 characters.
It is recommended (not technical necessary), that the name of the DDL source and the name of the CDS View are identical[Best Practice].
The name of the SQL View is specified after the Annotation @AbapCatalog.sqlViewName. The maximum length is 16 characters(just like any dictionary view).
It has to be different from the name of the CDS Entity.
CDS View Syntax Example
View Level and Field Level Annotation
Creating ABAP CDS View
CDS view belongs to three category
Basic view :- We don’t use directly. [@VDM.viewType: #BASIC] These are used to bring data directly from the physical tables in the database.
Composite View:- Used in Reporting Gives the combination of dimension and facts. [@VDM.viewType:#COMPOSITE]. This type of view is used to link basic views together through associations (like SQL joins between views). They are then used by the consumption views.
Consumption View:-Used in reporting. Actual Consumer [@VDM.viewType: #CONSUMPTION]. These views allow you to create a specific query from a “composite” view. This is the only type of view that can be exposed to the OData or transient service to be consumed for reporting.
Used in BW, ODATA
Standard CDS Views
Architecture of Virtual Data Model
Dependency Analyzer
The Dependency Analyzer provides you with an overview of the complexity of the CDS entity with regards to the SQL definition.
This means, you can see which database tables are used by your query to select data from the database and you can easily identify redundant joins which might negatively affect the performance of your query.
The Dependency Analyzer recursively analyzes the data sources and also displays the indirect dependencies to other database objects in the SQL Dependency Tree tab.
BW Side Modelling
Creation of Datasource
The Datasource for Standard CDS view are present in BW system (unlike standard datasource which reside in source side).
Not all standard extractors are released for CDS views and SAP will release them gradually.
https://www.sap.com/documents/2017/06/4e8689f9-c17c-0010-82c7-eda71af511fa.html
Creation of Datasource on CDS view to consume it in BW is done by the below in BW side.
Source system: [ODQ_CDS] ODP-ABAP CDS Views.
The SQL View Name of the CDS View will be the name of the Operational Data Provider of BW datasource.
Annotations
Annotations(@) It Gives Properties to CDS Views to interact with the BW , Fiori, ODATA etc.
@AbapCatalog.sqlViewName
@OData.publish: true
@analytics.dataCategory: #FACT
@analytics.dataCategory: #CUBE
To enable the CDS view to be ready for extraction.
@analytics.dataExtraction.enabled: true.
@Semantics.systemDateTime.lastChangedAt: true
Datasource Property
The BW datasource can either be Full-Load or Overwrite Delta. It means this is After-Image only.
This datasource will not be visible in ODQMON(T-Code).
To have delta property in datasource additional annotations are required.
Annotation based delta datasource
@analytics.dataExtraction.delta.byElement.name: ‘lastChangedAt’.
@analytics.dataExtraction.delta.byElement.detectDeletedRecords: true
@analytics.dataExtraction.delta.byElement.maxDelayInSeconds: 300
This datasource will be visible in ODQMON T-Code.
CDS View Performance Guidelines
1.Use left outer join instead of Inner join.
2.No Join on Calculated column.
3.Join preferably on Key fields.
4.Use Parameters and where condition as much as possible.
5.Take only required columns.
6.Use Performance related annotations wherever possible.
Ex:- @ObjectModel.usageType.serviceQuality
@ObjectModel.usageType.dataClass
@ObjectModel.usageType.sizeCategory
Reference: -
| User | Count |
|---|---|
| 11 | |
| 7 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
