ABAP Programming
ABAP Programming
Day 6 & 7
Introduction to ABAP CDS
How to define CDS Views
• DDL-> Creating DB objects like tables and views and to maintain their properties such as
CREATE, ALTER and DROP
• DML-> Reading and Changing the Contents of DB table such as SELECT, INSERT, UPDATE and
DELETE
• DCL -> Covers the aspects of data integrity and security such as GRANT and REVOKE.
Open SQL covers mostly the DML part of SQL; Prior to ABAP 7.4 there were a lot of limitations w.r.t Open
SQL such as limited support for JOINS, No use of UNION and UNION ALL, General Restrictions such as no
usage of CASE expression, No SQL functions, No Computed Values and certain restrictions with DB views
as well.
So, to benefit most from SAP HANA’s capabilities its better to do extensive calculations and aggregations
on the DB itself rather than to transfer huge amounts of data onto the ABAP application server. This is a
fundamental change to the ABAP programming paradigm and hence it now it becomes “CODE-TO-DATA”
rather than the other way round.
This all restrictions related to Classical ABAP programming went away when starting with release 7.4 SAP
HANA was fully supported by ABAP systems so as to fully utilize HANA’s potentials.
As a part of CODE-TO-DATA pushdown CDS i.e. Core Data Services came into picture which can be used
for defining and consuming semantically rich data-models.
Basically, it means that it is a group of languages like DDL, QL and DCL and semantically rich data-models
means DB views and Tables.
• ABAP CDS views are meant for ABAP applications and are DB-independent and they provide much
more SQL features than classical Dictionary Views as in Advanced View Building Capabilities.
• Here we don’t create any Data Model from scratch; we just define and consume them as in we
use the existing DB views and tables
• Annotations to add Semantic Information as in to connect existing tables to new technologies like
OData and UI5 and advanced joining of tables by making use of Associations.
• ABAP CDS views reside in the Application Server and is fully integrated in the ABAP Data Dictionary
but logic is processed in the DB.
1. DDL source
2. DCL source
How to define CDS Views & CDS definition & SQL example: - A CDS view is defined in a DDL source
which is a new type of repository object. There is no editor for DDL sources in the classical ABAP
Workbench. This new type of repository object has to be analyzed and developed in the ABAP tools for
Eclipse.
I. Upon activation of the DDL source; two objects are created as shown above and neither of them
can be edited directly in the ABAP workbench.
II. The SQL view is visible as an object in the ABAP dictionary where it cannot be edited and it serves
as a representation of the DB object.
III. The CDS view carries more semantics than its SQL view. It is neither created on the Database nor
it is visible in the ABAP dictionary directly; but we can however consume it via Open SQL (Which
got introduced as a part of NW 7.40 SP5).
It is recommended though not technically necessary, that the name of the DDL source and the name of
the CDS view are identical. The SQL view name has to be different from the CDS entity name and like any
other Dictionary View the max length is 16 characters.
Naming rules and recommendation: -DDL Source and CDS view Name: - Max 30 characters and are unique
throughout the System.
Start creating a CDS view via ADT w.r.t DDL repository and once we have reached the Data Definition
Wizard=> Refer to ZSYARD27_DEMO_CDS (Creation of very first CDS view)
@AbapCatalog.sqlViewName is mandatory in every CDS view; even though SAP uses a set of predefined
annotations which are mostly optional. (View Annotation; Element Annotation)
When we activate a DDL source, the development environment sends a SQL statement to the database
to create the SQL view. This SQL statement can be also viewed. (Show the participants the steps as to how
the SQL statement can be seen)
Similarly, we can see the Active Annotations as well by Right Click on DDL source at Project Explorer or
Editor Window/ Similarly we can see the Dependency Analyzer which offers a simplified view by focusing
on the dependency tree and disregarding the rest.
Data Preview allows us to analyze the data returned by CDS view without the need to implement any
SELECT statement itself. There are various options available as a part of Data Preview such as SQL console,
Filtering the data and number of entries and so on.
If we Right click on the View Name Under Views at Project Explorer Pane; Open With-> Definition => Gives
the associated CDS if it exists for navigation from SQL to CDS view.
Since CDS views were introduced as a part of NW 7.40 SP5 hence the new open SQL syntax is mandatory
when using a CDS view in a select statement.
To use CDS in ABAP Open SQL, we can read either from SQL view or CDS view. But this may be surprising
to hear as only SQL view exists physically in the DB. So, when we read from CDS view the DB interface
replaces the name of the CDS view with the corresponding SQL view while translating Open SQL to Native
SQL statement and this is the recommended way to access CDS views in ABAP.
Alternatively, it is also possible to read from SQL view directly but this is not recommended by SAP and it
became obsolete since NW 7.50.
Show the participants the DDLDEPENDENCY table w.r.t CS view and SQL view name by giving the DDL
source name.
Show the participants a demo w.r.t CDS view with join: - Refer to ZSYARD27_DEMO_CDS1 =>
Note:- The table name will come into picture in case we are not using Table alias and
for the fields which are common to both tables we need to give table name else not
required and the other way is to use Table alias as well and if we are using Element
Level alias then the same will be visible for SQL view-> view fields as well.
If we give key fields, we need to keep in mind that the key fields must be contiguous and also must start
at the first position.
The use of key comes into picture suppose when we want to use this CDS view with our Open SQL at App.
Server Level and we want to do ‘ORDER BY PRIMARY KEY’.
@AbapCatalog.sqlViewName Mandatory -> Specifies the SQL View Name for the
respective CDS view
@ClientHandling.type Determines the Client Dependency of the View. The
Value can be #INHERITED, CLIENT_DEPENDENT or
CLIENT_INDEPENDENT and by default the value is
INHERITED if the Annotation is not given
@Semantics.quantity.unitOfMeasure To link every amount field to a Currency Code
@Semantics.amount. currencyCode To link every quantity field to a Unit field
@AccessControl.authorizationCheck Defines the implicit access control when Open SQL is
used to access CDS view
Concepts of character, Numeric Literals, Current Client, User, System-date and Language -> Refer
to ZSYARD27_DEMO_CDS
CASE Statement -> ZSY_CDS_EXPRCASE for reference (Refer to below Diagram for Concept)
Arithmetic Expressions -> ZSY_CDS_ARITH_EXPR for reference (Refer to below Diagram for
Concept) ->
Concept of Type Conversion is also covered=> ABAP CDS doesn’t understand implicit Type
Conversion; we need to implement explicit Type Conversion. (Refer to ZSY_CDS_EXPRCAST)
CDS with Parameters and also how to consume CDS views in ABAP
program
Till now we saw simple examples of CDS views which are a type of a select statement and you
could surely add ‘WHERE’ clause to filter the data. But this where clause is static with a non-
parameterized view and may not fulfill the project requirements where a user interaction is
required. So, it is absolutely possible to add ‘Parameters’ to take user input and filter out the
data from the CDS view accordingly;
We can provide the parameters to the ABAP CDS Views by adding the syntax WITH PARAMETERS
p1, p2… (Data Dictionary ABAP data types can be used while defining the parameters to the ABAP
CDS Views).
We can use the parameters p1, p2.. in CDS Views using the syntax parameter name prefixed with
a colon :p1 or parameter with $parameters keyword=> $parameters:p1
Refer to ZSYARD27_DEMO_CDS3 and also navigate to SQL view and show Selection
Conditions and also show how Parameters can be used in a Select List as well as in Case
Statement, Arithmetic Expression or SQL Functions.
Refer to ZREPORT_CDS_PARAMETERS to consume the above CDS view with Input
Parameters at ABAP using Open SQL.
Also show the participants as in how to Call a CDS View with Parameters inside a CDS view
=> Refer to ZSYARD27_DEMO_CDS4
To summarize, in live projects 95% of analytics needs selection screens to get user input. This is
also very important to reduce the amount of data hit by the CDS view which subsequently
improves the CDS view performance to fetch only the required data out and CDS with input
parameter is supported only from 7.40 SP8 onwards.
How does Transport look with CDS? (Refer to CDS TR as shown below)
Only Data Definition Language Source object is saved. Usually we have the same name for the
Data Definition Language Source and CDS Entity View. Therefore, we wrongly assume it is CDS
Entity View.
Give 3 different names while creating CDS View. ZCDS_DDLS, ZCDS_Entity and ZCDS_SQL and
save in the transport. You will then understand.)
The Technical Object Type created for CDS Entity View is ‘STOB’ and CDS SQL View is ‘View’ and
we can find the same in DDLDEPENDENCY table.
CDS Views offer a nice way to abstract that code-pushdown process and mask it behind
something all developers are familiar with in OPEN SQL. The dual benefit of simpler and faster
code makes the discipline well worth the effort.
If we are on a system with SAP HANA underneath you can and should use CDS views and go for
the code pushdown.
If you are developing on a customer system with a non-HANA DB underneath CDS views are not
the preferred choice. If the customer is likely to switch to SAP HANA or S/4HANA soon, it might
make sense to think about applying them. Nevertheless, you have to test the things very
accurately and in case the performance. Be aware that the tests have to be done on the same
database type as on the productive system – otherwise, maybe there is a big surprise after go-
live.
Furthermore, CDS views push the logic to the client-side, because CDS views are able to
control SAP UI5 Smart Controls and SAP Fiori Elements by annotations through OData services
that can be generated from a CDS view.
Now large parts of the logic of an ABAP application can be outsourced from the ABAP code to
CDS views and therefore from the application server to the database.
Limitations of CDS
i. Cannot Debug
ii. Only one Result Set can be returned
iii. We cannot join 2 fields with Data type and length mismatches in the 2 tables. In such
scenario we need to use AMDP