CDS VIEW

In cods view all parameters are obligatory.

Entity
The entity is the core artifact for persistence-model definition using the CDS syntax. You create
a database entity as a design-time file in the SAP HANA repository.
The entity is used to fetch data from UI or any other service and give back data from database to
UI.
A CDS entity has a specified number of columns, defined at the time of entity creation, but can
have any number of rows. Database entities also typically have meta-data associated with them;
the meta-data might include constraints on the entity or on the values within particular columns.
e.g. her MyTable entity is created
namespace com.acme.myapp1;
@Schema : 'MYSCHEMA'
@Catalog.tableType : #COLUMN
@Catalog.index : [ { name : 'MYINDEX1', unique : true, order :#DESC, elementNames :
['ISBN'] } ]
entity MyTable {
key Author : String(100);
key BookTitle : String(100);
ISBN : Integer not null;
Publisher : String(100);
};

Entity Element Definition

You can expand the definition of an entity element beyond the element's name and type by using
element modifiers. For example, you can specify if an entity element is the primary key
or part of the primary key. The following entity element modifiers are available:

 key

Defines if the specified element is the primary key or part of the primary key for the
specified entity.

Note
Structured elements can be part of the key, too. In this case, all table fields resulting from
the flattening of this structured field are part of the primary key.

 null
 Defines if an entity element can (null) or cannot (not null) have the value NULL. If
neither null nor not null is specified for the element, the default value null applies (except
for the key element).

 default <literal_value>

Defines the default value for an entity element in the event that no value is provided
during an INSERT operation. The syntax for the literals is defined in the primitive data-
type specification.

entity MyEntity {
key MyKey : Integer;
key MyKey2 : Integer null; // illegal combination
key MyKey3 : Integer default 2;
elem2 : String(20) default 'John Doe';
elem3 : String(20) default 'John Doe' null;
elem4 : String default 'Jane Doe' not null;
};

Case :
Case statement is used to manipulate data in cds view , we cant use if statement in cds.
e.g.
case partner.bp_role
when '01' then 'customer'
when '02' then 'supplier'
end as partner_role  store value in partner_role.
Association
Association is also known Lazy Join / No Demand.
Association also pull data from database but unlike join it will not all data all together.
Association pull data from database based on demand. Association will create joins
automatically based on requirement.
Association should be public In association we can’t use fields of associated table while creating
new association. We can only use fields from base statement while creating new association.
e.g.

In 3rd association used vbap table field to compere with field of i_material cds so its getting error.
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.
Another example: suppose we are selecting field mara only but we defining the association
between mara and marc table. Then it will fetch data from mara table and it will not create any
join between mara and marc table.

AD Hoc in Association
AD Hoc is a functionality of Association. It is used when we want to map source table data and
target table in one go. While creating AD Hoc we have to mention target table field for which we
are going fetch data.
e.g. we are going to fetch data from vbak & vbap table _sitem is a alias used for vbap table and
posnr is a field of vbap table. When ever using field from target table that field should be unique.
Cardinality in Associations
When using an association to define a relationship between entities in a CDS document, you use
the cardinality to specify the type of relation, for example, one-to-one or one-to-many. the
relationship is with respect to both the source and the target of the association.

Cardinality always denotes the min records and max records in the target table( Right table )

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.

Annotations
A CDS annotation (or annotation for short) enables you to add ABAP and component-specific
metadata to the source code of any CDS entity.
Types of annotation
 ABAP annotations are evaluated by the ABAP runtime environment.
 Component annotations are evaluated by the relevant SAP framework.
In addition, you can use annotations in metadata extensions to define customer-specific metadata
for a CDS view without modifying SAP's CDS entities itself. When using metadata extensions,
you can overwrite specific annotation values defined in a data definition or add additional
annotation values to an entity. Note that you can only use those annotations in metadata
extensions that are not relevant when activating CDS entities.
VDM (Virtual Data Model)
VDM or Virtual Data Model is a combination of semantically enriched CDS Views that logically
combine database tables to create a meaningful data set. It is basically built to create a
consumption model from any system or an environment.

Basic interface views

are placed directly on top of the database tables and are the only views that access the database
tables directly. Basic interface views have the following purposes:

 The table fields in the database layer have names that are hard to understand. In the basic
interface view layer, they're renamed in terms of business semantics, resulting in more
comprehensible field names.

 Basic interface views enrich the data model derived from the underlying database tables
with additional metadata, such as annotations and relations between different views.

Basic interface views have the annotation @VDM.viewType: #BASIC.

Composite interface views

are based on basic interface views and may also have associations to other composite views.
They don’t access the database tables directly, but only through the basic view layer. Composite
interface views combine multiple basic interface views or other composite interface views to
form new semantic entities. These can be used, for example, as analytical cube views. Composite
interface views have the annotation @VDM.viewType: #COMPOSITE

Restricted reuse views

are similar to basic or composite interface views, but they're not intended for reuse by customers
and partners. They may have the annotation @VDM.viewType: #BASIC or @VDM.viewType:
#COMPOSITE.
Consumption Views

The top layer of the VDM CDS view stack is made up of consumption views. They're based on
reuse views and access the database tables only indirectly through the reuse view layer. These
views are

designed for a particular purpose with specific requirements, such as use by a particular
transactional or analytical app. Consumption views are the only VDM view type that can
function as an analytical query.

Consumption views have the annotation @VDM.viewType: #CONSUMPTION.

DATA type in VDM

FACTS: Facts hold the values we can measure and are extracted based on the filters. They
generally represent transactional data.

 DIMENSIONS: These are the measures or the master data like date, customer, and
person responsible. This is the key factor to derive our analysis. They are generally the
attributes of the master data.
 CUBE: When we connect all the FACT and DIMENSIONS, we come upon CUBES
which represent the factual data. This is the view where the analytical queries are built
upon.
 ANNOTATION: The Annotation that differentiates an Analytical model in CDS is
@Analytics.dataCategory: #VALUE
#VALUE can be replaced by:

 #CUBE
 #AGGREGATIONLEVEL
 #DIMENSION
 #FACT
What is kernal in badis
T code : SDDLAR
Cl_salv_gui_table_ida (class to dis)

AMDP (ABAP Managed Database Procedures)

 AMDP is nothings but a class , class should be always public. It can have static and Instance
methods.
 In AMDP class we can write AMDP Methods, AMDP Function Methods, Normal
methods also
 AMDP Methods will allow only pass by value
 We should not use nested structures, tables
 AMDP method will not allow returning parameter
 Another procedure can call in side AMDP Method or AMDP Function Method. We need
to mention that procedure (class_name=>method_name) in using (method
implementation)
 We should use IF_AMDP_MARKER_HDB interface in the class
 AMDP Method or Function Method should not be empty
  If we create the AMDP class and method, Database Procedure will not save in DB for the
first time. Once we execute the method, then only system will create procedure in DB
 If we want to declare variable by using data element in the AMDP method, this is the
syntax: DECLARE LV_VBTYP "$ABAP.TYPE( vbtypl )";.
 Declarations we can’t write at middle of the method implementation. Those should be at
the beginning of the method implementation.
 Need to maintain client handling by using session_context('CLIENT')

AMDP implement from a class

CLASS zamdp_customer DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .

PUBLIC SECTION.
TYPES: tt_kna1 TYPE TABLE OF kna1.
INTERFACES: if_amdp_marker_hdb.
METHODS: get_customer
IMPORTING VALUE(imp_kunnr) TYPE kna1-kunnr
EXPORTING VALUE(it_kna1) TYPE tt_kna1.
ENDCLASS.

CLASS zamdp_customer IMPLEMENTATION.

METHOD get_customer BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS
READ-ONLY USING kna1.
Select statement to fetch all the
it_kna1 = select * from kna1 where kunnr = :imp_kunnr;
field from kna1 table into
it_kna1 internal table
ENDMETHOD.

ENDCLASS.

IF_AMDP_MARKER_HDB is the interface to maintain in class definition without fail. If we maintain this
interface in the class definition then only system will consider it as AMDP.

In the above class, get_customer is the method. We have mentioned one importing and exporting
parameter. For exporting parameters, system will not allow dictionary table or views for declaring.
We need to declare by using local objects. Importing and exporting parameters must be pass by value.
In class implementation, implemented the method.
METHOD get_customer BY DATABASE PROCEDURE
FOR HDB
Here we are creating one database procedure in DB level by using AMDP. So we need to mention it.
LANGUAGE SQLSCRIPT
AMDP Script is database dependent. If we are using HANA database, it will allow SQLSCRIPT. If we are
using other DB, we need to mention which script (language) that database will allow.
 OPTIONS READ-ONLY

AMDP can read, modify, update the data in the DB level. So we need to mention that we are reading
data or modifying data. If we are modifying, not required to mention this ‘Options’ here.
USING kna1.

We are using KNA1 table in the method implantation. We need to mention all table names or view
names, which are using in the method implementation.

Select-options in AMDP:
1. Declare Select-options in the program
2. Convert the select-options values into a string using standard class and method.
cl_shdb_seltab=>combine_seltabs( it_named_seltabs = value #( ( name = 'KUNNR' dref = ref # ( s_kunnr[]
) ) ) ).

3. Pass the string into procedures using import parameters

4. In Procedure use APPLY_FILTER into the string values which got received

REPORT zp_amdp2.

types: BEGIN OF ty_kna1,

kunnr type kna1-kunnr,
name1 type kna1-name1,
ort01 type kna1-ort01,
end of ty_kna1.

data it_kna1 type table of ty_kna1.

data lv_kunnr1 type kunnr.

select-OPTIONS: s_kunnr for lv_kunnr1.

*Convert s_kunnr to string

data(lv_kunnr) = cl_shdb_seltab=>combine_seltabs (it_named_seltabs = value #( ( name =
'KUNNR' dref = ref # ( s_kunnr[] ) ) ) ).

zcl_amdp2=>get_data(
EXPORTING i_kunnr = 'abc'
im_kunnr = lv_kunnr
IMPORTING et_kna1 = it_kna1[] ).
In the above program I’m just converting select-options into string. Name = ‘KUNNR’ passing
in the IT_NAMED_SELTABS, it means we need to pass the where condition field (it field should
be in the select query and should not provide alias name with different name. for example for
KUNNR, I can give alias name as ‘Customer’. In this case system will not allow you. Better to
don’t provide any alias name for it otherwise give the alias name as field name only).

CLASS zcl_amdp2 DEFINITION PUBLIC .

PUBLIC SECTION.
INTERFACES if_amdp_marker_hdb.
types: begin of ty_kna1,
kunnr type kna1-kunnr,
name1 type kna1-name1,
ort01 type kna1-ort01,
end of ty_kna1.

types: tt_kna1 type table of ty_kna1.

class-methods get_data IMPORTING VALUE(i_kunnr) type

kunnr
value(im_kunnr) type string

EXPORTING VALUE(et_kna1) typett_kna1.

protected SECTION.
private SECTION.

ENDCLASS.

CLASS zcl_amdp2 IMPLEMENTATION.

method get_data BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY using kna1.

et_kna1 = select kunnr, name1, ort01 from kna1;

et_kna1 = APPLY_FILTER ( :et_kna1, :im_kunnr );

endmethod.

ENDCLASS.

CALLING CDS IN AMDP :

CDS Table Function
If we are not able to write something in CDS view then we can use table function. Table
function is one place where we can write SQL code. We can use single table function into
multiple CDS view. For using Table function, we need to follow the below steps.
 Create table function
 Create one AMDP class & methods
Use that table function in multiple CDS views.

Table Function Creation:

Right click on package in ABAP perspective  New Expand Core Data Services select
Data Definition Click on Next button  Select TR  select template as ‘Define Table
Function with Parameters’ click on Finish Button.

Table Function

@EndUserText.label: 'table function demo'

define table function zcds_table_func1
//with parameters parameter_name : parameter_type
returns {
client : abap.clnt;
Product_order : aufnr ;
Order_type : auart ;
routing : co_aufpl ;
counter : co_aplzl;
 std_val1 : vgwrt ;
std_val2 : vgwrt ;
}
implemented by method zcl_tab_fun=>get_data;
In table function we must use return parameters (CDS view consumable fields) and mention
Class name and method name which will fill the return parameters.
There is no mandatory semantics for table function and don’t provide SQL name also.
AMDP Class for table function
CLASS zcl_tab_fun DEFINITION PUBLIC .
PUBLIC SECTION.
interfaces if_amdp_marker_hdb.
class-methods: get_data for table function zcds_table_func1.
ENDCLASS.

CLASS zcl_tab_fun IMPLEMENTATION.

method get_data BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY
USING aufk afko afvv afvc.
lt_aufk = select mandt, aufnr, auart from aufk;

lt_afko = select aufnr, aufpl from afko where aufnr in ( select aufnr from :lt_aufk
);

lt_hours = select afvv.aufpl, afvv.aplzl, afvv.vgw01, afvv.vgw02, afvv.iedd,

afvc.vornr from afvv as afvv inner join afvc as afvc
on afvv.aufpl = afvc.aufpl and afvv.aplzl = afvc.aplzl;

return select hdr.mandt as client, hdr.aufnr as product_order,

hdr.auart as order_type, oper.aufpl as routing,
hrs.aplzl as counter, hrs.vgw01 as std_val1,
hrs.VGW02 as std_val2
from : lt_aufk as hdr
inner join : lt_afko as oper on hdr.aufnr = oper.aufnr
left outer join : lt_hours as hrs on oper.aufpl = hrs.aufpl;

ENDMETHOD.
ENDCLASS.
In class declaration interface IF_AMDP_MARKER_HDB should be consider and provide
method as static method. For that method we need to write extra code as
FOR TABLE FUNCTION <Table Function Name>. It is mandatory otherwise will through
error. In method implementation, need to provide like this
BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT USING <table1 table2>.
Required to write like RETURN select statement to fill return parameters (Table function
return parameters).

One more real time example for table function:

@EndUserText.label: 'testing' define
table function zaoh2_cds24 returns {
client : abap.clnt; vbeln : vbeln_va;
POSNR : posnr_va;
AUDAT : audat;
MATNR : matnr;
@Semantics.quantity.unitOfMeasure: 'VRKME'
[email protected]: ''
KWMENG : kwmeng; --100, 259
VRKME : vrkme;
DEL_NUM1 : vbeln_vl;
DEL_ITEM1 : posnr_vl;
DEL_DATE1 : audat;
@Semantics.quantity.unitOfMeasure: 'VRKME'
DEL_QTY1 : kwmeng;
DEL_NUM2 : vbeln_va;
DEL_ITEM2 : posnr_va;
DEL_DATE2 : audat;
@Semantics.quantity.unitOfMeasure: 'VRKME'
DEL_QTY2 : kwmeng;
DEL_NUM3 : vbeln_va;
DEL_ITEM3 : posnr_va;
DEL_DATE3 : audat;
@Semantics.quantity.unitOfMeasure: 'VRKME'
DEL_QTY3 : kwmeng;
@Semantics.quantity.unitOfMeasure: 'VRKME'
TOT_DEL_QTY : kwmeng;
@Semantics.quantity.unitOfMeasure: 'VRKME'
PEND_QTY : kwmeng;
 } implemented by method
zcl_aoh2_amdp7=>final_output;

We need to mailtain @Semantics.quantity.unitOfMeasure: 'VRKME'

If we don’t use the above semantics and used this table function in any other CDS view, it will
through error. So we need to maintain this semantics.
Once the method is completed, we can use this Table Function in any number of CDS views.

Note  if we want to do arithmetic operation on Select statement fields in AMDP method then
we just need to perform operation and to pass value from method to CDS we just need to use
alias name.

In this statement PROFIT is an a Alias.

HOW TO SORT FIELDS:

we can use Table Fucation to do sorting in CDS. Order By is not possible in CDS directly so
we have to use Table Function.

By default eBY is in ascending but if want field in descending from then we just need mention
‘DESC’ after the field we want in descending order.
VIRTUAL ELEMENTS

IF_SADL_EXIT_SORT_TRANSFORM is a interfaces that can used in CDS for sorting.

$Session variables are system variables they can be used as input parameter.
CREATE RECORDS:

We can create records through the CDS view using certain annotation “ @Object model “.

“modelCategory: # Business object “ this statement is used to create business object

compositionRoot: true,

“transactionalProcessingEnab1ed.• true“ this statement will be enable transactional

capabilities of CDS.

createEnab1ed: true,

updateEnabIed: true,

deleteEnab1ed: true,

writeActivePersistence: 'yeo tel ' this statement will tell in which table record has to created.

Step1: created CDS and add “ @Object model” annotation with some values.
Step2: Create OData Services using CDS.
ACEESS CONTROL(DCL)
Access Rules
 Conditional Rule : which control access using access conditions
 Grant Rule : Grant unrestricted access
 Inherited Rule : Applied from existing CDS roles (it can be occur only once in CDS
ROLE)

We can define multiple Access Rule in DCL for CDS entity. It can be same CDS or different
CDS entity in same DCL.
As per SAP it is advisable to use only one access rule in a CDS role.

Access Rule 1

Access Rule 2

Grant Rule :

GRANT SELECT ON without the addition WHERE it will give full access.

Partners and customers can use full access rules to override roles supplied by SAP.
Conditional Rule :

It is same as a grant rule but it is restricts access to a CDS entity using WHERE Condition.

A single CDS entity can be specified in multiple access rules of a CDS role.
-COMBINATION MODE ANDIOR (Optional) used for multiple access rules for same CDS
entity.

Condition through Authorization object

Condition through Literals

In conditional rule we use literal or authorization object.

PFCG_AUTH is a predefined aspect

Aspect :-Object used for the definition of user-specific values and their use in the conditions of
a CDS role.

To create authorization object we have to go SU21 TCode.

Multiple conditions using authorization object.

Step1: go to SU21  create authorization object class  create authorization object.

Add fields which you want to use in DCL. In this case VKORG field from vbak table.

ACTVT field tells the system what kind of activity this authorization object will perform.
If we use this auth object we will not get any output in CDS view because we have to assign
role to object for user.

Step2: go to TCode PFCG to create role

Give authorization object which you created  give values to the field in this case
VKORG = ‘SUNF’ and select value for ACTVT  click on Generate  back.

Add user in User window  user comparison  SAVE.

Inherited Rule :

 Inherit For Grant

 Inheriting Conditions From Entity
 Inheriting Conditions From Super

Inherit For Grant:

Suppose we have 2 CDS YDDLS_SAMPLE_04 and CDS YDDLS_SAMPLE_05.

For CDS YDDLS_SAMPLE_04 we have access control YDCL_04 and for CDS
YDDLS_SAMPLE_05 we have access control YDCL_05.

Now we are consuming YDDLS_SAMPLE_04 CDS in YDDLS_SAMPLE_05 then we can

inheriting access control of YDCL_04 in YDCL_05.

access control of YDCL_04 will be apply to CDS YDDLS_SAMPLE_05 through YDCL_05.

NOTE : Full Access Control can not inherited.

If the CDS entity does not have any access conditions yet, the addition DEFAULT must be
specified.

If wrong field or path is specified, all access rules of the parent CDS role are ignored.
 No full access rule CDS role cannot be activated.
 Full access rule CDS role can be activated with syntax warning .

>This variant also allows the inheritance of a full access rule

Inheriting Conditions From Entity :

Access control is inherited from the CDS Entity.

Here YDCL_01 access control is created and CDS YDDLS_SAMPLE_04 is inherited and
access control of YDCL_04 will be automatically inherited.
COUNT : it is used to get number of records.

Here we are get total number of records available in snwd_so_i table for parent_key filed.