CDS View

CDS VIEW – Core Data Services

CDS is an extension of the ABAP Dictionary that allows you to define semantically rich data models in the database and to use these data models in your ABAP programs. CDS is a central part of enabling code push-down in ABAP applications.

CDS views are the new programming design concepts which can achieve Code-to-Data paradigm which actually means Code push down into the database for processing.

Types of CDS View

Define View

> Define View with Join

> Define View with Association

> Define View with Parameters.

2. Extend View

3. Define Table Function with parameters

Step to Create CDS View

> Create an ABAP project within Eclipse by logging in to S4 HANA system

> Right Click on Your username under Local Objects and choose New->Other ABAP Repository

Objects. Core Data Services->Data Definition

Simple View will be created. All the statement starting with @ at the start of the view are called ‘ANNOTATIONS’ and they play a very important role in design and development of the cds view. They are the building block behind the CDS views configuration. They also define how the CDS view will behave in different scenarios.

Details about default annotations

1. @AbapCatalog.sqlViewName: ‘sql_view_name’ :- Within the first annotation ,provide SQL

View name. This is the DDIC SQl view which gets generated once the CDS view is activated

and can be seen in SE11 Tcode. This name must be less than or equal to 16 characters as per

DDIC SE11 view name limitations.

2. @AbapCatalog.compiler.compareFilter:true: This annotation defines the behaviour of the

filtering the data i.e. this first compare the filter conditions and if they match then only the data is

fetched. If the CDS view has join conditions, they are executed only after the filter conditions are

matched. In DDIC views data if first fetched and filtered.

3. @AbapCatalog.preserveKey:true:- As you know all the DB tables in SAP do have keys defined

and the CDS Views are always created on top of those DB tables. Now any DB table can have

multiple keys defined and you might not want those keys to be the key fields of your view. So if you

set this annotation as true, the only fields you define as key fields within your CDS view by adding

word ‘Key’ in front of those fields will be the key fields for the CDS view and the DDIC SQL view

which gets generated.

4. @AccessControl.authorizationCheck: #NOT_REQUIRED:- This annotation is used to add

‘Security’ piece to the CDS view. When CDS view is ready to be rolled out to a bigger audience

within or outside the organization. It is very important to restrict the data based on the authority.

5. @EndUserText.label: ‘CDS view type#BASIC’ :- This annotation is used to apply business labels other than attached in the DB tables, to the fields within the CDS view. This annotation will override

the DB table business label and provides what you specify with this annotation.

While Activating 2 Objects are Created.

1. DDIC SQL view – its design time object and can be seen by SE11

2. HANA view – it is run time object and gets created in HANA DB

CDS View Used in ABAP Report

Example

CDS View With Expression

Output

CDS View with where clause and SESSION Variable

CDS View With Parameters

Report to consume parameter based CDS view:

CDS View Extend

SAP provides multiple standard CDS view related to each functional module and also during a project implementation you will create tons of CDS custom views. Since the CDS views are just virtual data models, you will want to reuse the view created in one project or for one object to another project/object. Let’s assume you created a CDS view with 5 fields on TABLE A and for another scenario in a different project you need 8 fields from the same TABLE A. So instead of creating new CDS view from scratch, we can use the concept of CDS View extension and re-use the previous view we created and extend it with 3 new fields.

Add the field which needs to be extend

Join with CDS View

1. Inner Join

2. Left Outer join

3. Right Outer Join

Basic syntax for Join

Example

ASSOCIATIONS:

ASSOCIATIONS are kind of Joins to fetch data from multiple tables on Join Conditions but these are ‘JOINS ON-DEMAND’ i.e. they will only be triggered when user would access the required data which needs the Association of tables. For example, your CDS view has 4 Associations configured and user is fetching data for only 2 tables, the ASSOICATION on other 2 tables will not be triggered and the system would return the results quickly, so it enables really high turn-around time as compared to regular SQL JOINS.

Associations are defined with ‘Cardinality’. Syntax : association[<cardinality>]

Cardinality concept is not new and holds the same concept with CDS views as well. There are 4 types of Cardinality possible based on the data and relationship in the tables joined;

0..1

0..n or 0..*

1..0

1..n or 1..*

NOTE: If you are confused on what kind of association I should configure in my CDS view then you can apply a rule of thumb: ‘always use this : association[1]. This will always trigger an OUTER join and will work in all the cases.

Execute and look at highlighted – CDS View name and CARRID data AA and AZ. Also that No data from table SPFLI is displayed as NO join is yet performed