Full End To End Information On S/4 Hana Database

 FULL END TO END INFORMATION ON S/4 HANA DATABASE :-
 S/4 HANA DATBASE FOOTPRINT :-
 NORMAL R/3 DATABASE V/S HANA DATABASE SYSTEM .

 DIFFERNCE BETWEEN S/4HANA AND ECC ?
1. -> Architecture: S/4HANA uses a new, re-architected system design that is optimized for
in-memory computing and real-time data processing. ECC, on the other hand, uses a
traditional, row-based architecture that is optimized for transactional processing.
2. Database: S/4HANA uses the SAP HANA in-memory database, while ECC can be used
with a variety of traditional relational databases.
3. User interface: S/4HANA has a new, modern user interface that is designed to be more
intuitive and user-friendly than the interface in ECC.
4. Analytics and reporting: S/4HANA includes advanced analytics and reporting capabilities
that are built-in to the system, while ECC requires separate reporting tools to be
integrated.
5. Cloud deployment: S/4HANA is designed to be deployed in the cloud, while ECC is
typically deployed on-premises.
6. Simplification: S/4HANA has a simplified data model with less customizing and fewer
tables which means less maintenance and faster performance. ECC has a more complex
data model with more customizing and more tables which means more maintenance
and slower performance.
These are just a few of the major differences between S/4HANA and ECC, and there are
many more differences that can be found in the official SAP documentation. It's
important to note that S/4HANA is the latest version of SAP's ERP software and it brings
a lot of new features, improvements and simplifications.
One major difference between ECC and S/4HANA related to RAM in SAP is the way in
which memory is managed and utilized. Here are two key differences:
1. In-Memory Computing: S/4HANA is built on an in-memory computing platform, which

means that it uses a significantly larger amount of RAM compared to ECC. This allows
for faster data processing and real-time analysis of data. In contrast, ECC relies on a
traditional disk-based database system, which can result in slower processing times and
longer wait times for data retrieval.
2. Reduced Data Footprint: S/4HANA uses a more efficient data storage format, known as
columnar storage, which reduces the amount of data that needs to be stored in
memory. This means that S/4HANA can perform faster and more efficiently with smaller
amounts of RAM compared to ECC.
 NORAML SAP DB SYSTEM :-
 DIFFERNCE B/W COLUMN AND ROW STORAGE IN SAP ?
1. Purpose: Column storage is used for reporting and analytics, whereas row storage is used for
transactional processing.
2. Structure: Column storage organizes data in columns, whereas row storage organizes data in rows.
3. Data Compression: Column storage uses more advanced compression techniques, leading to smaller
storage footprint and faster data retrieval, whereas row storage typically uses less advanced
compression techniques.
4. Data Loading: Column storage is optimized for bulk data loading, whereas row storage is optimized
for transactional processing.
Query Performance: Column storage provides faster query performance, especially for complex queries
with multiple aggregations and filters, whereas row storage may be slower for complex queries but is
faster for transactional processing.
5. Data Modification: Row storage supports data modification operations such as insert, update, and
delete, whereas column storage does not support these operations.
6. Data Types: Column storage supports a wider range of data types, including text and binary data,
whereas row storage may have limitations in the types of data it can store.
7. Indexing: Column storage uses columnar indexes, which are optimized for analytical queries, whereas
row storage uses row-based indexes, which are optimized for transactional processing.
8. Concurrency: Row storage supports high concurrency for transactional processing, whereas column
storage may not support high concurrency for analytical processing.
9. Memory Usage: Column storage uses more memory to store data, whereas row storage uses less
memory, which may be important in resource-constrained systems.
Column storage refers to storing data in a columnar format, where each column is
stored separately. This is different from row storage, where each row is stored
separately. Column storage is particularly useful for analytical workloads, where large
amounts of data need to be scanned quickly. This is because column storage allows for
efficient data compression and can reduce the amount of data that needs to be
scanned.
Row storage, on the other hand, is better suited for transactional workloads, where
individual rows need to be updated or inserted quickly. This is because row storage
allows for faster access to individual rows, as they are stored sequentially.
In SAP HANA, column storage is the default storage mode, as it is optimized for
analytical workloads. However, row storage can also be used in certain scenarios, such
as for tables with a small number of columns or when row-level updates are required.
Overall, the choice between column storage and row storage depends on the specific
can improve performance and optimize the use of resources.
 ROW STORAGE DISADAVNTGE:-
 HERE WE ARE ROW STORING , DATA WILL BE STORED IN ROW , IF

I HAVE ALREDY STORED ONE ROW DATA ,NOW IM STORING
ANOTHER ROW DATA THAT IF I MAKE ANY CHANGES IN THAT
DATA TIME ROW WON’T GET UPDATED IT WILL BE SAVED IN SAP
CHANGED DOCUMENT .
 HERE WE HAVE TO CREATE SECONDARY INDEX FOR SPEED UP

THE SELECTION AND MAINY IF I WANT TO ADD PRICE THAT TIME
OUR PRICE FIELD IN THE 4TH ROW IF I WANT ADD THAT SAP WILL
REaDING FROM THE 1ST ROW TILL 4TH ROW AND IT TAKES TO
MUCH TO FECTH, MEMORY WILL INCREASED , FOR THAT WE
CREATED INDEX FOR SPEED UP BUT IF THE DATAS ARE TO MUCH
BULK THAT TIME OUR INDEX ALSO NOT SPEEDIING UP THE
SELECTION PROCESS.
 THEN IF WANT SPEED UP THE READING PROCESS THAT STORE THE

DATA IN BW SYSTEM LATER PROCESS WILL BE FASTER .
 WE CAN’T DO AGGREATE FOR LARGE AMOUNT OF DATA.
 COLUMN STORAGE ADVANTGES TO OVERCOME THE

DISDVANTGES OF ROW STORAGE:-
 HERE DATA WILL BE STORED IN THE COLUMN WAY AND EACH
COLUMN WILL CREATE TINY TINY TABLES FOR STORGING.
 IT WON’T ALLOW OR STORE DUPLICATES VALUES, IT WILL STORE

UNIQUE VALUES.
 WE CAN DO AGGREGATE FUNCTION WITH LARGE AMOUNT OF

DATA.
 HERE READ PROCESS WILL BE FASTER , DON’T NEED TO READ

FROM INITIAL AS LIKE ROW STORAGE.
 NO NEED TO CREATE INDEX BECAUSE EVERY EACH COLUMN ARE

INDEX.
 IF WE MAKE CHANGES THE DATA , DATA WON’T BE SAVED IN

CHANGE DOC , HERE HANA WILL INSERT THE UPDATED DATA
ALSO .
 WHILE READING DATA IF WE HAVE 2 SAME DATA WITH SAME

PRIMARY KEY THAT TIME HANA WILL INSERT THE LATEST DATA ,
AND LATEST TIME STAMP.
 CDS BASIC THINGS :-
Introduction to ABAP CDS Views - Go Coding

 LIFE CYCLE OF CDS :-
1. When we create View in HANA, it is sent to quality via a HTC (HANA

Transport Container) or directly with delivery unit to quality and
production.
2. CDS View are defined in ABAP Layer, when activated an SQL view in
HANA gets generated. Hence the execution of CDS view occurs in
under-laying DB layer.
 ADT TOOLS :-
1. When we create a CDS view we create a CDS Data Definition.

2. When we activate CDS view in ADT, following things will get
create.
A. CDS SQL View(Which we can even open in HANA SE11).
B. CDS Entity. (SQL View in HANA – under laying HANA view).
3. So, when we activate the real view or the artifacts will get generate.
 Note: To quality and production Only the File will be sent not the
CDS SQL view and CDS Entity. Once in the quality and Production
the activation takes place again the Run time objects will get
generate. Hence no HTC and delivery is required.
 CDS Data Definition is also known as CDS Document or CDS
Source Code.
 CDS CODE PUSH DOWN :-
 Code push down is a feature in CDS (Core Data Services) views in SAP HANA
that allows for filtering, aggregation, and calculation logic to be executed
within the database layer, rather than in the application layer. This results
in improved performance, as the amount of data that needs to be
transferred between the database and application is reduced. Code push
down can be achieved by using SQLScript or by using the HANA-optimized
CDS language syntax.
 HOW TO USE CDS VIEW WITH OTHER ANNOTATIONS DIFFERENT

CONSUMER :-
 WHY CDS VIEW AFTER WE HAD NORMAL VIEW IN DDIC VIEWS ?
1) CODE TO DATA PARADIGM :-

 IN CDS THE VIEW IS CREATED UNDERLIYG THE DATABASE LAYER.
 IN DDIC VIEW SYSTEM WILL CREATE THE VIEW IN DDIC LAYER ,
TRANSFER TO ABAP LAYER THROUGH DB LAYER, NO NEED TO
CODE.
2) EXECUATION :-
 IN CDS EXCUATION WILL BE HAPPENED UNDER DB LAYER.
 IN DDIC VIEW EXEUACTION OF VIEW , QUERY OF VIEW , TAKES
CARE IN ABAP LAYER.
3) SQL QUERY GENERATE :-
 IN CDS IF QUERY GENERTES IT WILL MOVE TO DB LAYER NOT OUR

EXECUATION.
 IN DDIC IF QUERY GETS GENERATE DATA WILL BE TRANSFERD TO
DB LAYER THROUGH ABAP INTERFACE LAYER.
4) COMPLEXITY :-
 CDS IS EASY TO LEARN AND UNDERSTAND.
 DDIC VIEW IS NOT EASY TO LEARN AND UNDERSTAND.
5) OUTER JOIN :-
 OUTER JOIN IS POSSIBLE IN CDS
 OUTER JOIN IS NOT POSSIBLE IN DDIC VIEW.
6) COMPLEX EXPRESSION(CASE STATEMENT, REUSE FUCNTION) :-
 COMPLEX EXPRESSION IS POSSIBLE IN CDS.
 COMPLEX EXPRESSION IS NOT POSSIBLE IN DDIC VIEW.
7) ODATA CONNECTION :-
 ODATA WE CAN CREATE WITH CDS DIRECTLY WITH SOME
ANNOTAION.
 ODATA WE CAN’T CREATE WITH DDIC VIEWS.
8) TYPE DECLEARTION :-
 WE CAN DECLEARE TYPE WITH CDS BECAUSE IT IS EXTESION OF
DDL.
 WE CAN’T DECLEARE TYPE WITH DDIC TYPE.
9) METDATA :-
 METADAT IS POSSIBLE WITH CDS.
 METADAT IS NOT POSSIBLE WITH DDIC VIEW.
10) BULILT- IN-FUNCTION :-
 WE CAN USE BUILT IN FUN WITH CDS LIKE UNION, INTERSCTION

ETC.
 WE CAN’T USE BUILT IN FUN WITH DDIC VIEW.
11) PARAMETER :-
 WE CAN CREATE PARAMETER WITH CDS VIEW.

 WE CAN’T CREATE EXPLICTLY PARAMETER IN DDIC VIEW.
12) SYSTEM VARIBLES :-
 WE CAN USE SYSTEM VARIBLE LIKE $SESSION.USER TO KNOW

THE CURRENT USER.
 WE CAN’T USE SYSTEM VARIBLE.
 DIFFERNCE BETWEEN CDS VIEW AND DDIC VIEW :-
 CDS views are based on the Core Data Services (CDS) framework and are used to
define and consume semantically rich data models in SAP. DDIC views, on the
other hand, are based on the Data Dictionary (DDIC) and are used to define and
consume data models at the database level.
 CDS views are used to define and consume semantically rich data models, while
DDIC views are used to define and consume data models at the database level.
 CDS views support advanced features like associations, annotations, and
calculated fields, while DDIC views do not.
 CDS views support the creation of reusable, composable data models, while DDIC
views do not.
 CDS views can be consumed by various SAPUI5-based applications and tools,
such as SAP Fiori, while DDIC views can only be consumed by ABAP-based
applications and tools.
 CDS views can be used to define and consume data models for both
transactional and analytical use cases, while DDIC views are mainly used for
transactional use cases.
 CDS views can be exposed as OData services, while DDIC views cannot.
 CDS views support filtering, sorting, and pagination, while DDIC views do not.
 CDS views support multi-language support, while DDIC views do not.
 CDS views support to create views based on HANA Calculation views, while DDIC
views do not.
 VDM :-
 Definition: VDM is a special annotation which used when we
create a view in S/4 HANA. (This annotation cannot be used in
ABAP on HANA etc.).
 When we design CDS view in S/4, We need to follow best practice
(VDM Annotations).
 VDM is an annotation which indicates that, What type of data is
exposed out of this CDS view (XL, L,S) (This will standardize the
code).
 VDM A ND IT’S TYPES :-
VDM stands for Virtual Data Model. It is a feature in SAP's Core Data
Services (CDS) that allows users to define and consume data models in
a simplified, abstracted way. VDM allows users to create views of data
from multiple underlying data sources and to expose these views as
entities, which can then be consumed in other parts of the system, such
as by ABAP programs or in the SAP HANA database.
There are two types of VDM in CDS:
1. Consuming VDM: This is used to define views of data from one or more
underlying data sources, such as database tables or other CDS views.
2. Providing VDM: This is used to expose a data model as a service,
making it available for consumption by other parts of the system.
Both types of VDM can be defined using the CDS modeling language,
which is similar to SQL.
 VDM AND IT’S SIZE :-

Here is a brief explanation of the different sizes:
 "X" size: Indicates that a view is expected to be small in size and have simple
logic. This would be a good candidate for a small lookup table or simple data.
 "S" size: Indicates that a view is expected to be medium-sized, with moderate
complexity. This would be a good candidate for reporting or other tasks that
require a moderate amount of data.
 "XL" size: Indicates that a view is expected to be large in size and have complex
logic. This would be a good candidate for data intensive reporting, analytics or
data warehousing.
 TYPES OF CDS VIEWS :-
 Basic view
 Composite view
 Consumption view
 PRIVATE VIEW
1) Basic View :-
 VDM Basic views are created on the top of DDIC tables or views. It is
the only view that interacts directly with the database.
 Annotation: @VDM.Viewtype : #BASIC
 Properties for Basic View:
1. Basic views can directly access the database tables and other basic views.
2. They have an association with other basic views.
3. Free of redundancies.
4. They expose all business data.
2) Composite view
 The composite view is created on top of the VDM Basic view. It interacts
with Basic views for the result set and does not interact with the
database directly.
 Annotation: @VDM.Viewtype : #COMPOSITE
 Properties of Composite View:
1. They can access other Composite views but not database tables.
2. They can have an association with other composite views and basic views.
3. Redundancies might be possible.
4. They should be reusable.
3) Consumption view :-
 The consumption views are built on top of Interface views. By the name
Consumption, we can assume that this view is meant to be consumed
by SAP UI5 through OData, Analytical queries, Transactional service
models.
 Annotation: @VDM.Viewtype : #CONSUMPTION.
4) PRIVATE VIEW TYPE :-
 In SAP, a Core Data Services (CDS) view is a way to define and

expose data in a specific format and structure. A private view is a
CDS view that is only accessible within the same module or
package where it is defined. It cannot be accessed by other
modules or packages, and is not exposed to external systems or
applications.
 CDS is created for the purpose of its consumer:
FIORI Application (@UI Annotation).

Transactional App using BOPF (@ObjectModel – this is for
DML(Data Manipulation Language)).
Analytical Tool (@Analytics).
S/4 HANA Embedded Analytics (Query Browser App)
 Note: S/4 HANA Embedded analytics and FIORI cannot consume

CDS View directly hence they need to use ODATA Layer in
between.
 CDS PRACTICLES PEOGRAMMS :-
 FIRST WE HAVE TO CREATE PROJECT AFTER 2 ANNOTATIONS GET

GENERATED .
 1) CDS SQL VIEW , 2) CDS ENTITY .

@AbapCatalog.sqlViewName: 'ZSRNORMAL'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'NORMAL PRORAMM'
define view ZSR_CDS_NORMAL as select from vbak
{
key vbeln,
auart,
erdat,
ernam,
erzet
}
where vbeln = '0000000005'
 We can see in sap application our DDL .

 DATA DEFINIATION WE CAN SEE IN SAP BUT WE CAN’T EDIT THAT
ONE IN SAP ONLY WE CAN DO IN ECLIPSE EDIT.
 FETCHING DATA BY USING VIEW IN REPORT :-
REPORT ZSR_CDS_VIEW_PROGRAM.
SELECT * FROM ZSRNORMAL INTO TABLE @DATA(LT).
LOOP AT LT INTO DATA(LS).
WRITE : / LS-VBELN,
LS-AUART,
LS-ERDAT,
LS-ERNAM,
LS-ERZET.
ENDLOOP.
 INNER JOIN BETWEEN SALES ORDER INVOICE HEDER AND

BUSINESS PARTNER .
 @AbapCatalog.sqlViewName: 'zjjoins'
 @AbapCatalog.compiler.compareFilter: true
 @AbapCatalog.preserveKey: true
 @AccessControl.authorizationCheck: #NOT_REQUIRED
 @EndUserText.label: 'JOINS'
 define view ZSR_JOINS_BUSINESS as select from snwd_so_inv_head as inv
 inner join snwd_bpa as bp on inv.buyer_guid = bp.node_key
 {
 bp_id,
 company_name,
 sum( gross_amount ) as totalsales


 }
 group by bp_id, company_name having sum( gross_amount ) > 40000
 CDS VIEW WITH SELECT OPTION :-
 WE CAN’T WRITE SELECT-OPTION DIRECTLY IN CDS BUT WE CAN

WRITE IN ABAP PROGRAM IN CDS VIEW .
*&---------------------------------------------------------------------*
*& Report zview_select_option
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZVIEW_SELECT_OPTION.
DATA : LS TYPE MARA.
SELECT-OPTIONS:S_MATNR FOR LS-MATNR.
SELECT * FROM MARA INTO TABLE @DATA(LT) WHERE MATNR IN @S_MATNR.
LOOP AT LT INTO LS.
WRITE : / LS-MATNR,
LS-ERNAM,
LS-ERSDA,
LS-ERNAM,
LS-MATKL.
 ENDLOOP.
 BUFFERING IN CDS VIEW :-

 Like Data Base tables, CDS views can also be buffering enabled with
different buffering type set based on the below annotations.
 @AbapCatalog.buffering.status – #ACTIVE , #NOT_ALLOWED,

#SWITCHED_OFF
 @AbapCatalog.buffering.type- #FULL , #GENERIC , #NONE , #SINGLE
 @AbapCatalog.buffering.numberOfKeyFields – Relevant if the buffering

type is set as GENERIC.
 PROGRAM WITH PARAMETER :-
@AbapCatalog.sqlViewName: 'ZPARAMM'
@EndUserText.label: 'CDS PARAMETER'
define view ZSR_PARAMETER
with parameters FLIGHT_CODE : s_carr_id
as select from sflight
{
key carrid,
connid,
currency,
fldate,
seatsmax
}
where carrid = $parameters.FLIGHT_CODE
 WITH TWO PARAMETERS :-
 WE NEED TO MENTION DATA ELEMENT WHILE WE CREATING

PARAMETER :-
 @AbapCatalog.sqlViewName: 'ZPARAMM'
 @EndUserText.label: 'CDS PARAMETER'
 define view ZSR_PARAMETER
 with parameters
 P_CARRID: s_carr_id,
 P_CONNID: s_conn_id
 as select from spfli

 {
 key carrid,
 key connid,
 cityfrom,
 arrtime,
 period
 }

 where carrid = $parameters.P_CARRID and connid = $parameters.P_CONNID
 WITH PARMETER IN ABAP PROGRAM .
*&---------------------------------------------------------------------*
*& Report zsr_cds_select_option
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CDS_SELECT_OPTION.
PARAMETERS : S_CARRID TYPE SFLIGHT-CARRID.
START-OF-SELECTION.
SELECT * FROM SFLIGHT INTO TABLE @DATA(LT) WHERE CARRID = @S_CARRID.
CL_DEMO_OUTPUT=>DISPLAY_DATA(
EXPORTING
VALUE = LT
NAME = 'FLIGHT DETAILS'
).
 JOINS IN CDS VIEW :-

 In ABAP CDS, Join between two data sources is allowed. Allowed
joins are:-
 Inner Join/Join
 Left Outer Join
 Right Outer Join
 CROSS JOIN.
 INNER JOIN :-
 @AbapCatalog.sqlViewName: 'ZINNERJOIN'
 @EndUserText.label: 'JOINS'
 define view ZSR_INNER_JOINS_SAPCODES
 as select from spfli as HD inner join sflight as IT
 on HD.carrid = IT.carrid
 {

 key HD.carrid,
 HD.airpto,
 HD.connid,
 HD.cityfrom,
 IT.fldate,
 IT.price,
 IT.currency

 }
 CROSS JOIN :-
 A cross join returns the Cartesian product of rows of the two joined data
sources. All entries on the left side are combined with all entries on the
right side. The number of rows in the result set is the number of rows on
the left side multiplied by the number of rows on the right side.
 @AbapCatalog.sqlViewName: 'ZCROSSJOIN'
 @EndUserText.label: 'JOIN'
 define view ZSR_CROSS_JOIN as select from sflight as SF
 cross join scarr as SR
 {

 key SF.carrid,
 SF.currency,
 SF.fldate,
 SR.carrname,
 SR.currcode
 }
 where SF.carrid = 'AA'
 Disadvantages of Joins:
1. Whether we need the data at the end for joined table or not, the join
is always be performed, which is a cost to database.
2. When we build on odata service on such view, The service will
expose all the data always, whether u need or not. High network
Traffic.
3. Writing joins is to technical from developer point of view. So, to
overcome these disadvantages, cds views have something called
associations.
 CASE STATEMENTS :-
 @AbapCatalog.sqlViewName: 'ZCASEST'
 @EndUserText.label: 'CASE STATMENT'
 define view ZSR_CASE_STATMENT as select from spfli
 {
 key spfli.carrid,
 spfli.cityfrom,
 spfli.countryfr,
 spfli.countryto,

 case
 when distance >=10000 then 'LONG WAY JOURNEY'
 when distance >=5000 and distance <=10000 then 'SHORT WAY JOURNEY'
 else 'NO LONGER JOURNEY'
 end as JOURNEY_TYPE
 }

-----------------------------------------------------------------------------
 @AbapCatalog.sqlViewName: 'ZCASE2'
 @EndUserText.label: 'CASE STATMENT'
 define view ZSR_CASE_STATMENT4 as select from marc
 {

 key marc.matnr,
 marc.matgr,
 marc.ausdt,

 case
 when plifz >=10 then 'GREATER'
 when plifz <10 then 'SMALLER'
 else 'NOTHING'
 end as Planned
 }
 CASE STATEMENT WITH WHERE CONDITION :-
@AbapCatalog.sqlViewName: 'ZCASE5'
@EndUserText.label: 'CASE STATMENT'
define view ZSR_CASE_STATMENT5 as select from vbrp
{
key vbrp.vbeln,
vbrp.ernam,
vbrp.erdat,
vbrp.posnr,
case
when netwr>=300 then 'HIGH NET WEIGHT'
when netwr<=100 then 'MIDDLE NET WEIGHT'
else 'SMALL NET WORTH'
end as NET_WEIGHT
}
where vbeln = '0090016826'
 Aggregate expression in CDS View :-
 An aggregate expression calculates a single value from an

operand operand by calling an aggregate function from multiple rows of a
results set. They need Group By clause to aggregate values from multiple
rows and the non-aggregated fields are specified in the GROUP BY clause.
 Aggregate Functions:
 CDS WITH SUM AGGREGATE FUNCTION :-
 FIRST IT WILL GROUP ALL SAME DATA LATER IT WILL ADD SAME
FIELD DATA ALL.( IF CARRID ARE 4 FIELDS WITH SAME VALUES THAT
TIME IT WILL ADD SAME VALUES FROM THE 4 FIELDS).
@AbapCatalog.sqlViewName: 'ZAGGREGATE_FUN'
@EndUserText.label: 'AGGREGTE FUNCTION'
define view ZSR_AGGREGATE_FUN_SUM as select from sflight as A
{
key A.carrid,
key A.connid,
sum(price) as TOTAL_AMT,
A.currency
}
group by carrid, connid, currency
-------------------------------------------------------------------------
@AbapCatalog.sqlViewName: 'ZAGGREGATE2'
define view ZSR_AGGREGATE_FUN_SUM1 as select from vbrp as M
{
key M.vbeln,
M.posnr,
M.erdat,
M.ernam,
sum(netwr) as AMT
}
group by vbeln, posnr, erdat, ername
 CDS WITH SUM AND COUNT :-
 COUNT IT WILL COUNT THE SAME FIELDS DATA ( IF IN THE NAME

OF CARRID ‘AA’ ARE 10 DATA IN DB TABLE , THAT TIME COUNT
WILL ALL 10 DATA AND PRESENT IN THE OUTPUT).
@AbapCatalog.sqlViewName: 'ZSRAGGR_COUNT'
define view ZSR_AGGREGATE_FUN_COUNT as select from sflight as A
{
key A.carrid,
A.connid,
sum(price) as MONEY,
A.currency,
count(*) as LINES
}
@AbapCatalog.sqlViewName: 'ZSRAGGRCOUNT'
define view ZSR_AGGREGATE_FUN_COUNT1 with parameters P_WERKS: werks_d as select from
mard
{
key mard.werks,
mard.ersda,
mard.lgort,
count( *) as LINES
}
where werks = $parameters.P_WERKS group by matnr, werks, ersda, lgort
 CDS WITH MAXIMUM AND MINIMUM :-
 MAX WILL DISPLAY THE MAXIMUM VALUES FIRSTLY , MINIMUM

WILL DISPLAY THE MINIMUM VALUES.
@AbapCatalog.sqlViewName: 'ZSRAGGRMAXMIMUM'
define view ZSR_AGGREGATE_FUN_MAX as select from sflight
{
key sflight.carrid,
key sflight.connid,
max(price) as MAXIMUM,
sflight.currency
}
@AbapCatalog.sqlViewName: 'ZSRAGGRMAXMIMUM'
define view ZSR_AGGREGATE_FUN_MAX as select from sflight
{
key sflight.carrid,
key sflight.connid,
min(price) as MANIMUM,
sflight.currency
}
 CDS WITH AVERGE AGGREGTE FUNCTION:-
 AVERGE WILL WORK LIKE FIRST IT WILL ADD THE DATA OF SAME
FIELDS LATER IT WILL DO AVERGE.
 @AbapCatalog.sqlViewName: 'ZAGGRAVG'
 @EndUserText.label: 'AGGREGET FUNCTION'
 define view ZSR_AGGREGATE_FUN_AVERGE as select from sflight as S
 {

 key S.carrid,
 key S.connid,
 sum( price ) as PRICE,
 avg( paymentsum ) as PAYMENT,
 count( *) as LINES


 }
 group by carrid, connid
--------------------------------------------------------------------------------
@AbapCatalog.sqlViewName: 'ZAGGRAVG'
@EndUserText.label: 'AGGREGET FUNCTION'
define view ZSR_AGGREGATE_FUN_AVERGE as select from sflight as S
{
// AVERGE //
key S.carrid,
key S.connid,
sum( price ) as PRICE,
avg( paymentsum ) as PAYMENT,
// AFTER AVERGE AGAIN MULTIPLED BY 2//
paymentsum * 2 as MULTI_PAYMENT,
count( *) as LINES
}
group by carrid, connid , paymentsum
@AbapCatalog.sqlViewName: 'ZAVG'
@EndUserText.label: 'AGGREGET FUNCTION'
define view ZSR_AGGREGATE_FUN_AVERGE1 as select from vbrp as V
{
key V.vbeln,
V.posar,
sum( netwr ) as NET_WEIGHT,
count (*) as counting,
avg( netwr ) as net
}
group by vbeln, posar
 CDS VIEW WITH AIRTHMATIC OPERATION ( + , -, *, /) :-
 SUBSTRACTION :-
 @AbapCatalog.sqlViewName: 'ZSRAIRTHMATIC'
 @EndUserText.label: 'AIRTHMATIC_OPERATION'
 define view ZSR_AIRTHMATIC_OPERATION as select from sflight as S
 {

 // SUBSTRACTION //
 key S.carrid,
 key S.connid,
 S.fldate,
 S.price,
 S.currency,
 S.seatsmax - S.seatsocc as SEATS_IN_ECONMIC_CLASS,
 S.seatsmax_b - S.seatsocc_b as SEATS_IN_BUSINESS_CLASS,
 S.seatsmax_f - S.seatsocc_f as SEATS_IN_FIRST_CLASS

 }
 ADDITION :-
define view ZSR_AIRTHMATIC_OPERATION as select from sflight as S

{
// ADDIATION //
key S.carrid,
key S.connid,
S.fldate,
S.price,
S.currency,
S.seatsmax + S.seatsocc as SEATS_IN_ECONMIC_CLASS,
S.seatsmax_b + S.seatsocc_b as SEATS_IN_BUSINESS_CLASS,
S.seatsmax_f + S.seatsocc_f as SEATS_IN_FIRST_CLASS
 MULTIPLICATION :-
define view ZSR_AIRTHMATIC_OPERATION as select from sflight as S

{
// MULTIPLICATION //
key S.carrid,
key S.connid,
S.fldate,
S.price,
S.currency,
S.seatsmax * S.seatsocc as SEATS_IN_ECONMIC_CLASS,
S.seatsmax_b * S.seatsocc_b as SEATS_IN_BUSINESS_CLASS,
S.seatsmax_f * S.seatsocc_f as SEATS_IN_FIRST_CLASS
 DIVISION :-
 IF WE WANT ACHIEVE THE DIVISION OUR DATA TYPE SHOULD BE
FLOAT TYPE.
 CURRENCY CONVERSION :-
 HERE WE ARE CONVERTING CURRENCY FROM ONE COUNTRY TO

ANOTHER COUNTRY.
 @AbapCatalog.sqlViewName: 'ZSRCONVERSION'
 @EndUserText.label: 'CURRENCY_CONVERSION'
 define view ZSR_CURRENCY_CONVERSION
 with parameters P_CURR: abap.cuky( 5 ),
 P_DATE: abap.dats
 as select from sflight as A
 {

 //CURRENCY_CONVERSION//

 key A.carrid,
 key A.connid,
 A.fldate,
 currency_conversion ( AMOUNT => A.price,
 SOURCE_CURRENCY => A.currency,
 TARGET_CURRENCY => $parameters.P_CURR,
 EXCHANGE_RATE_DATE => $parameters.P_DATE) as LOCAL_AMT
,
 $parameters.P_CURR as LOCAL_CURRENCY



 }
 where carrid = 'AA'
 CDS VIEW WITH STRING OPERATION :-
1) CONCAT(arg1, agr2) :- string function can be used to

concatenate two character strings.
2) CONCAT_WITH_SPACE(arg1, arg2, spaces) :- This string
function is used to concatenate two character strings with
space. The number of blanks between the
arguments arg1 and arg2 is specified in spaces.
3) SUBSTRING(arg, pos, len) :- To get sub string of arg from the

position pos in the lenght len.
4) LENGTH(arg) :-It returns the no of characters in the string

which is passed as a argument arg. It ignores trailing blanks.
5) LEFT(arg, len) & RIGHT(arg, len) :-

 LEFT(arg, len) – It returns the left-side part of the string which is
passed as argument arg of length len.
 RIGHT(arg, len) – It returns the right-side part of the string which is
passed as argument arg of length len.
 Note: Trailing blanks are ignored.
6) LTRIM(arg, char) & RTRIM(arg, char) :-

 LTRIM(arg, char) – It removes the trailing blanks and leading
character which matches the parameter char.
 RTRIM(arg, char) – It removes the trailing blanks and trailing
character which matches the parameter char.
 ALL STRING FUNCTION PROGRAM :-
@AbapCatalog.sqlViewName: 'ZSTRINOPER'
@EndUserText.label: 'STRING_OPERATION'
define view ZSR_STRING_FUNCTION as select from kna1 as K
{
key K.kunnr,
K.name1,
K.ort01,
CONCAT(K.kunnr, K.name1) as CONCAT_FUN,
concat_with_space(K.name1, K.ort01, 2) as CONCATING_WITH_SPACE,
SUBSTRING(K.name1, 3, 5) as SUB_STRING,
LENGTH(K.name1) as LENGHT_STRING,
LEFT(K.ort01,3) as LEFT_LENGHT,
RIGHT(K.ort01,3) as RIGHT_LENGHT,
// IT WILL REMOVE THE ZEROS AND AVOIDING SPACE//
LTRIM(K.kunnr, '0') as LEFT_TRIM,
RTRIM(K.kunnr, '0') as RIGHT_TRIM
}
 OUTPUT :-
 SESSION VARIBLES :-
 They are like system variable. In CDS view only 4 different session
variables.
Session Variable ABAPsystem
field
$session.client sy-mandt
$session.system_date sy-datum
$session.system_language sy-langu
$session.user sy-uname
Example:
Output:
 Access in CDS Views
 Syntax – $Session.vname can be used in CDS views to access the
ABAP-specific session variable. The VNAME are as below:
 client – sy-mandt
 user – sy-uname
 system-language – sy-langu
Example:
@AbapCatalog.sqlViewName: ‘CDS_SESSIONVAR’
define view CDS_SESSIONVAR_DEMO
as select from demo_expressions {
$session.client as sys_client,
$session.user as sys_user
$session.system_language as sys_language
}
 ASSOCIATION :-
 Associations define relationships between entities such as a
database table or another CDS view. Associations can also be
viewed as a Join-On-Demand. This means that the association will
only be executed when the fields from associated entity are
referred. Typically, CDS associations can be compared to LEFT
OUTER Joins.
 TYPES OF ASSOCIATION :-
1) EXPOSED ASSOCIATION :-
 HERE IN EXPOSED JOIN DOES NOT HAPPEN IN DB LAYER , IT IS LAZY

JOIN AND IT IS ON DEMAND, BECAUSE EXPOSED WILL WORK LIKE ,
WE HAVE TWO TABLES HEADER AND ITEM HERE WE DON’T WANT
FETCH THE DATA FROM BOTH TABLE, WE CAN FECTH THE DATA
ONLY FROM ITEM , IF WE WANT FETCH FROM HEADER WE CAN
FETCH LATER LIKE ON DEMAND.
2) AD-HOC ASSOCIATION :-
 IT IS SAME AS LIKE OUR REAL JOINS INNER JOIN , BECAUSE IT WILL

FETCH THE DATA FROM BOTH FIELD , NOT LAZY , NOT ON
DEMAND.
 CARDINALITY :-
 Cardinality is the relationship between the source and associated
view in the form of [ min .. max ] (only the target cardinality is
stated).
 RULES FOR ASSOCIATION :-
 DIFFERNCE B/W JOINS AND ASSOCIATION :-
 JOINS :-
1) IN JOINS WE CAN’T DO ANY ON DEMAND PROCESS HERE WE

HAVE TO FECTH DATA FROM TWO TABLES.
2) IN JOINS CARIDINALITY IS NOT AVAILABLE .
3) IN JOINS WE HAVE 3 TYPES OF JOINS ALL ARE HARD JOINS.
 ASSOCIATION :-
1) 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.
2) Associations are defined with ‘Cardinality’. Syntax

: association[<cardinality>]
 NOTE :- FIRSTLY THE DEFAULT CARDINALITY IS “[0…1]”.

AND CARDINALITY IS NOT MANDATORY OK, IT IS IS OPTIONAL, IF
WE WON’T GIVE IT WILL CONSIDER 0…1.
 NOTE :- CARDINALITY IS ALWAYS BELONGS TO TARGET TABLE

(ASSOCIATED TABLE).
 EXAMPLE FOR HOW CARDINALITY WILL ASSIGN :-
 IF [1..0] CONSIDER 1 AS MINIMUM AND 0 AS MAXIMUM , IN

TARGET TABLE AT LEAST MINMUM 1 WILL BE THERE OR MAXIMUM
0 SHOULD BE THERE.
 NOTE :- BUT SOME EXCEPATION CASE

1) MINMUM CAN’T BE * .
2) MAXIMU CAN’T BE 0.
3) IN ASSOCATION 2 TYPES OF ASSOCIATION ARE THERE
EXPOSED :- IT IS EXPOSING WHOLE JOIN ON DEMAND , IT IS
LAZY JOIN, JOIN DOES NOT HAPPEN IN DB LAYER.
AD-HOC :- IT IS HARD JOIN, ALWAYS HAVE JOIN CONDITION.
 DIFFERNCE BETWEEN JOINS AND ASSOCIATIONS :-
1. Definition: Association is a way to define relationships between different entities in a

Core Data Service (CDS) view, while a join is a way to combine data from multiple tables
in a SQL-like manner.
2. Syntax:
3.
4. Association is defined using the "association" keyword in the CDS view, while join is
defined using the "join" keyword.
5. Cardinality: Association defines the cardinality of the relationship, such as one-to-one,
one-to-many, or many-to-many, while join does not.
6. Navigation: Association allows for navigation between entities, while join does not.
7. Performance: Association is typically more performant than join, as it allows the system
to optimize the data retrieval.
8. Data restriction: Association can be used to restrict the data that is returned, by using an
"on-condition" clause, while join does not provide such feature.
In summary, Association is a way to define the relationships between entities in a CDS
view, whereas join is a way to combine data from multiple tables. Association is more
powerful than join as it allows for navigation, performance optimization and also data
restriction.
 ASSOCIATION WITH [1…1] EXPOSED:-
 @AbapCatalog.sqlViewName: 'ZASSOCIATIONcar'
 @EndUserText.label: 'ASSOCIATION'
 define view ZSR_ASSOCIATION1 as select from spfli
 association [1..1] to scarr as _Scarr
 on spfli.carrid = _Scarr.carrid
 {

 spfli.connid,
 spfli.airpfrom,
 spfli.airpto,

 _Scarr

 //association_name // Make association public
 }
 IN DDIC VIEW :-
 ASSOCIATION WITH [1…1]AD-HOC :-
@AbapCatalog.sqlViewName: 'ZASSOCIATIONcar'
@EndUserText.label: 'ASSOCIATION'
define view ZSR_ASSOCIATION1 as select from spfli
association [1..1] to scarr as _Scarr
on spfli.carrid = _Scarr.carrid
{
key spfli.carrid,
spfli.connid,
spfli.airpfrom,
spfli.airpto,
_Scarr.carrname,
_Scarr.currcode
//association_name // Make association public

}
 IN DDIC VIEW :-
 ASSOCIATION WITH [1..*] EXPOSED AND AD-HOC :-
 NOTE :-FISRT WE HAVE TO DO EXPOSED ASSOCIATION AFTER WE

NEED TO SEE THE MULTIPLE ASSOCIATION FOR EACH FIELD , DO
RIGHT CLICK ON FIELD CLICK ON FOLLOW ASSOCIATION.
 NOTE :- AFTER DONE AD-HOC IT WILL SHOW NO DEFINATION.
@AbapCatalog.sqlViewName: 'ZASS1MANY'
@EndUserText.label: 'ASSOCIATION'
define view ZSR_ASSOCIATION_ONE_TO_MANY as select from scarr
association [1..*] to spfli as _SPFLI
on _SPFLI.carrid = scarr.carrid
{
key scarr.carrid,
scarr.carrname,
scarr.currcode,
_SPFLI.connid // EXPOSING ASSOCIATION
}
 ASSOCIATION WITH [0..*] :-
 IT WILL FETCH ALL DATA FROM THE PRIMARY TABLE NOT FORM
THE ASSOCIATED TABLE .
 @AbapCatalog.sqlViewName: 'ZASSC0TOSTAR'
 @EndUserText.label: 'MANY'
 define view ZSR_ASSOCIATION_MANY as select from scarr
 association [0..*] to spfli as _SPFLI
 on SCARR.carrid = _SPFLI.carrid
 {

 *
 }
 ASSOCIATION WITH FILTER OPTION WITH ONLY SOURCE DATA 1ST

TABLE :-
 ABAP CDS on HANA-15 – SAPCODES
 @AbapCatalog.sqlViewName: 'ZFILTERASSC'
 @EndUserText.label: 'FILTER OPATION'
 define view ZSR_ASSOCIATION_FILTER2 as select from spfli[ countryfr = 'US']
 association [1..1] to scarr as _SCARR
 on SPFLI.carrid = _SCARR.carrid

 {

 key spfli.connid,
 spfli.cityfrom

 }
 BASIC VIEW :-
@AbapCatalog.sqlViewName: 'ZBASIC_VIEW1'
@VDM.viewType:#BASIC
@Analytics.dataCategory: #DIMENSION
@EndUserText.label: 'BASIC VIEW'
define view ZSR_BASIC_VIEW as select from sflight
association [1..1] to spfli as _SPFLI
on sflight.carrid = _SPFLI.carrid
{
key sflight.carrid,
sflight.connid,
sflight.currency,
_SPFLI.airpto,
_SPFLI.airpfrom
 COMPOSITE VIEW :-
 @AbapCatalog.sqlViewName: 'ZCOMPOSITEVIEW'
 @VDM.viewType: #COMPOSITE
 @Analytics.dataCategory: #CUBE
 @EndUserText.label: 'COMPOSITE_VIEW'
 define view ZSR_COMPOSITE_VIEW as select from ZSR_BASIC_VIEW
 {
 ZSR_BASIC_VIEW.carrid,
 @DefaultAggregation: #SUM
 ZSR_BASIC_VIEW.seatsmax,
 ZSR_BASIC_VIEW.connid,
 ZSR_BASIC_VIEW.airpto,
 ZSR_BASIC_VIEW.currency


 }
 COUSMPATION VIEW :-
@AbapCatalog.sqlViewName: 'ZCONSUMPTION'
@VDM.viewType: #CONSUMPTION
@EndUserText.label: 'CONSUMPATION'
define view ZSR_CONSUMPTION_VIEW as select from ZSR_COMPOSITE_VIEW
{
ZSR_COMPOSITE_VIEW.carrid,
ZSR_COMPOSITE_VIEW.seatsmax,
ZSR_COMPOSITE_VIEW.connid,
ZSR_COMPOSITE_VIEW.airpto,
ZSR_COMPOSITE_VIEW.currency
 ANNOTATION :-
 An annotation enriches a definition in the ABAP CDS with
metadata. Or it is used to define additional characteristics or
capabilities to the ABAP CDS object. It can be specified for a
specific scope of the CDS object such as specific places in a piece of
CDS Source code.
 SAP Annotations are evaluated by SAP framework and can be

either ABAP Annotations or Component Annotations.
 ABAP Annotations are evaluated when the DDL object is activated

or the DDL object is used on the ABAP runtime environment.
Annotations for which ‘ABAP’ is entered in the framework column
are evaluated as ABAP Annotations by the ABAP runtime
environment.
 Component Annotations are evaluated by frameworks of other

software components. Annotations for which a different
component[ other than ABAP] is entered in the framework column
are component annotations. The component defines the technical
and semantic attributes of the CDS objects required by the specific
software component such as OData, UI, BOPF, Enterprise Search or
Analytics.
 ABAP Annotations:
 AbapCatalog Annotations
 AccessControl Annotations
 ClientDependent Annotations
 DataAging Annotations
 EndUserText Annotations
 Environment Annotations
 Component Annotations:
 Analytics Annotations
 AnalyticsDetails Annotations
 Consumption Annotations
 DefaultAggregation Annotations
 EnterpriseSearch Annotations
 Hierarchy Annotations
 ObjectModel Annotations
 OData Annotations
 Search Annotations
 SearchIndex Annotations
 Semantics Annotations
 UI Annotations
 VDM Annotations
 TYPES OF ANNOTATIONS :-
A header annotation is an annotation that is placed at the top of the CDS view
definition, and it is used to define the overall structure of the view. It can be used to
specify things like the name of the view, the type of data, and the key fields.
A body annotation, on the other hand, is an annotation that is placed inside the body of
the CDS view definition, and it is used to provide additional information about the fields
or entities in the view. It can be used to specify things like the data type, the length, and
the label of a field, or the relationships between different entities.
For example, if you have a CDS view with a header annotation that defines the structure
of the view, and a body annotation that provides additional information about the fields
in the view.
@AbapCatalog.sqlViewName: 'ZSALES_ORDER'
define view ZSALES_ORDER as select from sales_order
key so_id,
sales_order_date,
@EndUserText.label: 'Total Amount'
total_amount,
@Semantics.currencyCode: true
currency_code
}
 EXTEND (EXTENSION CDS VIEW ) :-
 Normal standard SAP tables can be extended with APPEND

structure. Similarly standard CDS views can be extended with
EXTEND View which works with the same principle as APPEND
structure.
 NOTE :- There are also some restriction where the CDS view can’t
be extended if the CDS base view contains GROUP BY clause, etc.
 FIRST WE HAVE TO FETCH SOME FIELDS FROM ONE TABLE .
 @AbapCatalog.sqlViewName: 'ZEXTENDVIEW'
 @EndUserText.label: 'EXTESION VIEW'
 define view ZSR_EXTEND_VIEW as select from spfli
 {
 spfli.connid,
 spfli.airpfrom,
 spfli.airpto,
 spfli.distance

 }
 OUTPUT :-
 NOW WE ARE APPENDING OUR 3 FIELDS TO THE CDS VIEW BY
USING EXTEND VIEW.
 NOTE :- WE NEED TO USE “@SQLAPPENDVIEWNAME”
 WE HAVE TO PROVIDE THE PREVIOUS VIEW NAME WHICH IS
GOING EXTENDED AND PRESENT VIEW.
@AbapCatalog.sqlViewAppendName: 'ZSR_APPEND'
@EndUserText.label: 'EXTEND'
extend view ZSR_EXTEND_VIEW with ZSR_EXTEND_VIEW_CONTINUE
{
spfli.deptime,
spfli.countryto,
spfli.period
}
 OUTPUT :-
 DISPLAYING THE DATA IN ALV GRID FORMAT :-
 ONLY ENTITY NAME SHOULD BE MENTIONED .
*&---------------------------------------------------------------------*
*& Report zsr_alv_grid1
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_ALV_GRID1.
data(oalv_obj) = cl_salv_gui_table_ida=>create_for_cds_view(
CONV #('ZSR_EXTEND_VIEW') ).
OALV_obj->fullscreen( )->display( ).
 UNION AND UNION ALL BULIT-IN-FUCNTIONS IN CDS VIEW :-
In CDS (Core Data Services) views, the UNION and UNION ALL functions are used to
combine the result sets of two or more SELECT statements.
The UNION function returns distinct rows from the combined result sets, meaning it
eliminates any duplicate rows.
The UNION ALL function returns all rows from the combined result sets, including any
duplicate rows.
 UNION AND UNION ALL EXAMPLES:-
@AbapCatalog.sqlViewName: 'ZUNIONFUN'
@EndUserText.label: 'UNION FUNCTION'
define view ZSR_UNION_FUN1 as select from sflight
{
carrid,
connid
}
union
select from spfli
{
carrid,
connid
}
@AbapCatalog.sqlViewName: 'ZUNIONFUN'
@EndUserText.label: 'UNION FUNCTION'
define view ZSR_UNION_FUN1 as select from sflight
{
carrid,
connid
}
union ALL
select from spfli
{
carrid,
connid
}
 AMDP (ABAP-Managed Database Procedures):-

 AMDP, on the other hand, can be used to both read and even
process data from the database layer and modify it. The main
difference here is AMDP provides you to write using SQL Script in
the database layer and OpenSQL provides writing in ABAP layer.
 WHY AMDP INSTEAD OF CDS :-
 In AMDP, we can call one function inside the other, it is helpful in

returning multiple result set on complex logics. Whereas, CDS is
dedicated for single set of logic and return only one result set. CDS
views can be created to read and process data at DB layer.
 AMDP CLASS :-
 An AMDP class is a global class that contains special tag interface

that starts with – IF_AMDP_MARKER_* .
 For HANA Database- the interface – IF_AMDP_MARKER_HDB – the
suffix HDB indicates the database system for which the ABAP
managed database procedure can be implemented in the AMDP
method of AMDP class. AMDP class can contain both normal
regular methods as well as AMDP methods. It can contain one or
more AMDP methods for each database system specified by the
special tag interface.
 AMDP METHOD :-
 Constructors can’t implemented as AMDP method. There are two

types of AMDP methods: 1-AMDP Procedure Implementation and
2-AMDP Function Implementation.
 The AMDP method for AMDP procedure implementation must be
flagged with addition- BY DATABASE PROCEDURE & AMDP method
for AMDP Function Implementation must be fla gged with addition-
BY DATABASE FUNCTION.
1) AMDP PROCEDURE IMPLEMENTATION :-
 AMDP method for implementing database procedure. It can be a

static or instance method and can be declared in any section. The
parameter interface must follow the below mentioned rules:
 Parameters must be declared using pass by value ( pass by
reference not allowed).
 Return values can not be declared using RETURNING.
 RAISING can only be used to specify the exception classes which are
AMDP specific- CX_AMDP_* ( subclass of CX_DYNAMIC_CHECK).
 The method implementation- must not be empty, no DDL
statements like creating/change or deleting database objects, no
execution of transactional statements like COMMIT WORK/
ROLLBACK WORK, method don’t have any implicit enhancement
option, write can not be performed on DB tables with buffering
switched on ( SQL script access are ignored by buffer
synchronization). Dynamic programming should not be used[ write
can be made dynamically on a buffered table leading to
inconsistencies in buffer synchronization].
2) AMDP FUNCTION IMPLEMENTATION :-
 method for implementing database function. An AMDP Function

implementation is marked in the method implementation with
addition- BY DATABASE FUNCTION.
 AMDP Functions are:
 1-AMDP Table Function
 1.1- AMDP Table Functions for AMDP Methods :- Function that
can be accessed on other AMDP methods.
 1.2- AMDP Table Functions for CDS Table Functions:- Function
that implements CDS table function that can be accessed in ABAP
SQL.
 2-AMDP Scalar Function
 AMDP Table Functions for AMDP Methods: An AMDP function
implementation for an AMDP table function can be declared as
static or instance method in any visibility section of an AMDP
class and can be called in ABAP like regular method. The method
interface must follow the below rules:
 Must have a return parameter with pass by value defined using
RETURNING and the data type of the return value must be tabular
with a structure row type with elementary components.
 Can have elementary or tabular input parameters but can’t have
output parameters.
 Class based exceptions can not be declared using RAISING in the
method interface.
 AMDP Table Functions for CDS Table Functions: this can only be
declared in the public section of a static AMDP class and addition-
FOR TABLE FUNCTION must be used in the declaration. The
parameter interface is generated as per the associated CDS table
function. The return value “RESULT” with type of standard table
with empty key is created where the components of the row type
are determined by the elements of the CDS table function.
 CDS VS AMDP :
1. In AMDP, we can call one function inside the other, it is helpful in

returning multiple result set on complex logics. Whereas, CDS is
dedicated for single set of logic and return only one result set.
2. CDS views can be created to read and process data at DB layer.
Whereas AMDP can be created to process and modify data at DB
layer.
3. AMDP is used to work with stored procedures, which further go to
HANA DB layer and execute that. This functionality can’t be
achieved by Open SQL and CDS.
Common features/ Benefits of CDS and AMDP :
1. We are creating/using DB Procedures in AMDP and views in CDS

without having access of HANA DB layer.
2. AMDP and CDS can be created in eclipse only not in GUI as ADT
(ABAP Development Tool) plug-in is needed for this (also in HANA
Studio).
3. CDS and AMDP does not need HANA license, when it is executed
first time, it automatically create views and procedures
respectively in HANA DB. Next time it will take same from HANA
DB buffer.
4. Transferring data to other systems, CDS will create views and
AMDP will create procedures automatically in the new system.
Note: CDS Views are compatible with any database whereas AMDP
needs HANA as a database and this is the reason CDS is more popular
and is in demand.
 AMDP PROCEDURE IMPLEMENTATION (NO RETURN ) :-
 AMDP FIRST NORMAL CODE :-
1) FIRST WE HAVE TO CREATE CLASS :-
CLASS ZCL_AMDP_DEMO DEFINITION

PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
TYPES : TT_VBRP TYPE STANDARD TABLE OF VBRP.
INTERFACES : IF_AMDP_MARKER_HDB.
METHODS : GET_VBRP_DATA IMPORTING VALUE(IV_VBELN) TYPE VBELN

EXPORTING VALUE(EX_VBRP) TYPE TT_VBRP.
ENDCLASS.
CLASS ZCL_AMDP_DEMO IMPLEMENTATION.
METHOD GET_VBRP_DATA BY DATABASE PROCEDURE FOR HDB

LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY USING VBRP.
EX_VBRP = SELECT * FROM VBRP AS VB

WHERE VB.vbeln = :IV_VBELN;
ENDMETHOD.
 ENDCLASS.
-----------------------------------------------------------------------------
 NEXT WE HAVE TO CALL IN ABAP PRORAM :-=

*&---------------------------------------------------------------------*
*& Report zsr_calling_amdp_class
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CALLING_AMDP_CLASS.
PARAMETERS : P_VBELN TYPE VBRP-VBELN.
DATA : LT_VBRP TYPE STANDARD TABLE OF VBRP.
DATA : OB_SALV TYPE REF TO CL_SALV_TABLE.
DATA : OBJ TYPE REF TO ZCL_AMDP_DEMO.

CREATE OBJECT OBJ.
OBJ->GET_VBRP_DATA (
EXPORTING IV_VBELN = P_VBELN
IMPORTING EX_VBRP = LT_VBRP
).
TRY.
CALL METHOD CL_SALV_TABLE=>FACTORY
IMPORTING
R_SALV_TABLE = ob_salv
CHANGING
T_TABLE = LT_VBRP
.
CATCH CX_SALV_MSG.
ENDTRY.
ob_salv->display( ).
 SECOND PROGRAM :-
CLASS ZCL_AMDP_DEMO1 DEFINITION

PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
TYPES : TF_SFLIGHT TYPE STANDARD TABLE OF SFLIGHT.
METHODS : GET_FLIGHT_DATA
IMPORTING VALUE(IV_CARRID) TYPE SFLIGHT-CARRID
EXPORTING VALUE(EX_FLIGHT) TYPE TF_SFLIGHT.
ENDCLASS.
CLASS ZCL_AMDP_DEMO1 IMPLEMENTATION.
METHOD GET_FLIGHT_DATA BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT

OPTIONS READ-ONLY USING SFLIGHT.
EX_FLIGHT = SELECT * FROM SFLIGHT WHERE CARRID = :iv_carrid;
ENDMETHOD.
ENDCLASS.
-----------------------------------------------------------------------------------------------
*&---------------------------------------------------------------------*
*& Report zsr_calling_amdp_class1
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CALLING_AMDP_CLASS1.
PARAMETERS : P_CARRID TYPE SFLIGHT-CARRID.
DATA : OB_SALV TYPE REF TO CL_SALV_TABLE,

LT_SFLIGHT TYPE STANDARD TABLE OF SFLIGHT.
DATA : OBJ TYPE REF TO ZCL_AMDP_DEMO1.

CREATE OBJECT OBJ.
OBJ->GET_FLIGHT_DATA(
EXPORTING IV_CARRID = P_CARRID
IMPORTING EX_FLIGHT = LT_SFLIGHT
).
TRY.
IMPORTING
CHANGING
T_TABLE = LT_SFLIGHT
.
CATCH CX_SALV_MSG.
ENDTRY.
Important Points:
1. Transaction control commands like COMMIT WORK /ROLLBACK WORK

are not allowed inside AMDP method.
2. Update statement can not be performed on BUFFERED tables inside

AMDP method.
3. AMDP are a part of native SQL and don't support automatic client
handling.
 HERE WE ARE ASSIGNING READ ONLY FOR THAT WE CAN’T

CHANGE , IF WE WANT TO DO ANY CHANGE THAT TIME WE NO
NEED TO WRITE THE READ ONLY.
 The above AMDP method is used just to read some data [OPTIONS
READ-ONLY]. Lets add one more method where we can do change
on DB record. Then for such a method OPTIONS READ-ONLY must
not be specified.
Test. Check what are the values.
Modify fields for CARRID.
Check again.
So its updated.
 AMDP WITH INNER JOIN :-

CLASS ZCL_AMDP_INNER_JOIN DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
TYPES : BEGIN OF TT_FLIGHT,

CARRID TYPE SFLIGHT-CARRID,
PRICE TYPE SFLIGHT-PRICE,
FLDATE TYPE SFLIGHT-FLDATE,
CITYFROM TYPE SPFLI-CITYFROM,
CITYTO TYPE SPFLI-CITYTO,
AIRPFROM TYPE SPFLI-AIRPFROM,
AIRPTO TYPE SPFLI-AIRPTO,
END OF TT_FLIGHT.
TYPES : TF_FLIGHT TYPE STANDARD TABLE OF TT_FLIGHT WITH DEFAULT KEY.
METHODS : GET_FLIGHT_DETAILS IMPORTING VALUE(IV_CARRID) TYPE SFLIGHT-CARRID
EXPORTING VALUE(EX_FLIGHT) TYPE TF_FLIGHT.
ENDCLASS.
CLASS ZCL_AMDP_INNER_JOIN IMPLEMENTATION.
METHOD GET_FLIGHT_DETAILS BY DATABASE PROCEDURE FOR HDB

LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY
USING SFLIGHT SPFLI.
EX_FLIGHT = SELECT SFLIGHT.CARRID, SFLIGHT.PRICE, SFLIGHT.FLDATE, SPFLI.CITYFROM,

SPFLI.CITYTO , SPFLI.airpfrom, SPFLI.airpto
FROM SFLIGHT AS SFLIGHT INNER JOIN SPFLI AS SPFLI
ON SPFLI.connid = SFLIGHT.connid WHERE SFLIGHT.CARRID =
:iv_carrid;
ENDMETHOD.
 ENDCLASS.
 ABAP PROGRAM :-
*&---------------------------------------------------------------------*
*& Report zsr_calling_amdp_inner_join
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CALLING_AMDP_INNER_JOIN.
DATA : O_SALV TYPE REF TO CL_SALV_TABLE.
DATA : OBJ TYPE REF TO ZCL_AMDP_INNER_JOIN.

CREATE OBJECT OBJ.
OBJ->GET_FLIGHT_DETAILS(
IMPORTING EX_FLIGHT = DATA(LT_DATA)
).
TRY.
IMPORTING
R_SALV_TABLE = o_SALV
CHANGING
T_TABLE = LT_DATA
.
CATCH CX_SALV_MSG.
ENDTRY.
o_salv->display( ).
 SESSION VARIABLES IN AMDP METHOD :-
 Session Variables are global variables of the database system that

contains information about the current context. SAP HANA DB has
special ABAP specific session variables whose counterparts
matches with the ABAP system fields.
 Access in AMDP Methods
 The predefined function SESSION_CONTEXT( ) is used to access

the session variables of SAP HANA database . Few session
variables are as below:
 CLIENT – sy-mandt
 APPLICATIONUSER – sy-uname
 LOCALE_SAP – sy-langu
 How they can be Accessed:

 SESSION_CONTEXT(‘CLIENT’)
 SESSION_CONTEXT(‘APPLICATIONUSER’)
 SESSION_CONTEXT(‘LOCALE_SAP’)
Example:
METHOD get_session_variables_amdp
BY DATABASE PROCEDURE FOR HDB
LANGUAGE SQLSCRIPT.
clnt := session_context(‘CLIENT’);
unam := session_context(‘APPLICATIONUSER’);
lang := session_context(‘LOCALE_SAP’);
ENDMETHOD.
 AMDP WITH 2 METHODS ONE PUBLIC AND PRIVATE AND HOW TO
CALL :-
 Below we have 2 AMDP methods and one AMDP method(public)

calls another AMDP method (private method) and the call of the
private AMDP method is not as how a normal private method is
called from a normal public method.
 The public AMDP method must include the private AMDP method
in the USING option .
 It must not a call method but CALL and AMPD method must be
called inside double quotes an d capital letters.
CLASS ZCL_AMDP_DEMO1 DEFINITION

PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
TYPES : TF_SFLIGHT TYPE STANDARD TABLE OF SFLIGHT.
METHODS : GET_FLIGHT_DATA
PRIVATE SECTION.
METHODS : GET_FLIGHT_DATA_DB
ENDCLASS.
CLASS ZCL_AMDP_DEMO1 IMPLEMENTATION.
"WE ARE CALLING PRIVATE AMDP METHOD INSIDE ANOTHER AMDP METHOD"
METHOD GET_FLIGHT_DATA BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT
USING ZCL_AMDP_DEMO1=>GET_FLIGHT_DATA_DB.
CALL "ZCL_AMDP_DEMO1=>GET_FLIGHT_DATA_DB"(iv_carrid => IV_CARRID,
EX_FLIGHT => :ex_flight);
ENDMETHOD.
"HERE IN PRIVATE AMDP METHOD WE ARE WRITING THE SELECT QUERY"

METHOD GET_FLIGHT_DATA_DB BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT
USING SFLIGHT.
EX_FLIGHT = SELECT * FROM SFLIGHT WHERE CARRID = :iv_carrid;
ENDMETHOD.
 ENDCLASS.
 CALLING IN ABAP :-
*&---------------------------------------------------------------------*
*& Report zsr_calling_amdp_class1
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CALLING_AMDP_CLASS1.
DATA : OB_SALV TYPE REF TO CL_SALV_TABLE,

LT_SFLIGHT TYPE STANDARD TABLE OF SFLIGHT.
DATA : OBJ TYPE REF TO ZCL_AMDP_DEMO1.

CREATE OBJECT OBJ.
OBJ->GET_FLIGHT_DATA(
IMPORTING EX_FLIGHT = LT_SFLIGHT
).
TRY.
IMPORTING
CHANGING
T_TABLE = LT_SFLIGHT
.
CATCH CX_SALV_MSG.
ENDTRY.
 AMDP FUNCTION IMPLEMENTATION (WITH RETURN ) :-
 IMPLEMENATION CDS WITH AMDP METHOD ( TABLE FUNCTION ) :-
 FIRST CDS VIEW CREATES DEFINIATION IN APPLICATION LAYER .
 NEXT IT WILL GENERTES ARTIFACTS IN ABAP REPOSITRY, FOR

IMPLEMENATION WE GET ADVANTGE OF NATIVE SQL IN HANA
DATABASE.
 FOR WE CREATE STRUCTURE IN CDS VIEW AFTER WE DO

IMPLEMENATION BY USING AMDP METHODS IN AMDP CLASS.
 AMDP METHOD WILL RETURN ALL OPERATION BY USING CDS VIEW

STRUCTURE.
 AMDP METHOD USE NATIVE SQL SO WE CAN DO CODE

PUSHDOWN AND PARALLEL EXECUATION.
 NATIVE SQL IS CLIENT DEPENDENT .
 FOR CDS VIEW WE HAVE TO MAKE IT AS CLIENT DEPENDENT BY

USING ANNOTATION LIKE “CLIENT_DEPENDENT #TRUE OR #FALSE”.
 IF WE WANT WRITE CDS VIEW IN ABAP CODE , WE NEED TO DO

SOME MODIFICATION LIKE , PORGRAM WILL PASS THE CLIENT TO
NATIVE SQL LATER IT WILL EXCUTE RESULT SET.
 CDS IMPLEMENTION WITH AMDP CLASS BY MAKING CDS AS CLIENT
DEPENDENT : FALSE .
 IF YOU ARE NOT MAKE CLIENT DEPENDENT AS FALSE , YOU HAVE

TO PASS THE CLIENT THROUGH PARAMETER.
 CDS CLIENT DEPENDENT :-
@ClientDependent: false
@EndUserText.label: 'CDS WITH AMDP'
define table function ZSR_CDS_AMDP
//HERE WE ARE PASSING CLIENT THROUGH PARAMETER//
with parameters P_CLIENT : abap.clnt,
P_CARRID : s_carr_id
// HERE WE ARE RETURNING//
returns {
CLIENT : abap.clnt;
CARRID : s_carr_id;
CARRID1 : s_carr_id;
}
implemented by method ZCL_CDS_AMDP=>GET_DATA;
 AMDP CLASS AND METHOD FOR IMPLEMENTION :-
CLASS ZCL_CDS_AMDP DEFINITION

PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
class-METHODS : GET_DATA FOR TABLE FUNCTION ZSR_CDS_AMDP.
ENDCLASS.
CLASS ZCL_CDS_AMDP IMPLEMENTATION.
METHOD GET_DATA BY DATABASE function FOR HDB

LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY
return SELECT sflight.mandt as client, sflight.carrid AS CARRID,

spfli.CARRID AS CARRID1
ON SFLIGHT.CARRID = SPFLI.CARRID WHERE SFLIGHT.CARRID =
:P_CARRID
and sflight.mandt = p_client;
endmethod.
 ENDCLASS.
 ABAP PROGRAM TO CALL :-
*&---------------------------------------------------------------------*
*& Report zsr_cds_amdp_calling
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CDS_AMDP_CALLING.
PARAMETERS : P_CD TYPE SFLIGHT-CARRID,

P_CT TYPE SFLIGHT-MANDT.
SELECT * FROM ZSR_CDS_AMDP( P_CLIENT = @P_CT, P_CARRID = @P_CD ) INTO TABLE

@DATA(LT_RESULT)
##DB_FEATURE_MODE[AMDP_TABLE_FUNCTION].
TRY.
IMPORTING
R_SALV_TABLE = oB_SALV
CHANGING
T_TABLE = LT_RESULT
.
CATCH CX_SALV_MSG.
ENDTRY.
oB_SALV->display( ).
 NOTE :- BY USING ABAP PROGRAM WE ARE CALLING CDS

STRUCTURE BY USING SELECT QUERY.
 AMDP WITH CLIENT INDEPENDENT AS TRUE :-
 CDS VIEW :-
//@ClientDependent: false//
@ClientDependent: true
@EndUserText.label: 'CDS WITH AMDP'
define table function ZSR_CDS_AMDP with parameters @Environment :
{
systemField: #CLIENT
}
//HERE WE ARE PASSING CLIENT THROUGH PARAMETER//
P_CLIENT : abap.clnt,
// HERE WE ARE RETURNING//
returns {
CLIENT : abap.clnt;
CARRID : s_carr_id;
CARRID1 : s_carr_id;
implemented by method ZCL_CDS_AMDP=>GET_DATA;
 AMDP CLASS AND METHOD :-
CLASS ZCL_CDS_AMDP DEFINITION

PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
class-METHODS : GET_DATA FOR TABLE FUNCTION ZSR_CDS_AMDP.
ENDCLASS.
CLASS ZCL_CDS_AMDP IMPLEMENTATION.
METHOD GET_DATA BY DATABASE function FOR HDB

LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY
return SELECT sflight.mandt as client, sflight.carrid AS CARRID,

spfli.CARRID AS CARRID1
ON SFLIGHT.CARRID = SPFLI.CARRID WHERE SFLIGHT.CARRID =
:P_CARRID
and sflight.mandt = p_client;
endmethod.
ENDCLASS.
 ABAP PROGRAM :-
*&---------------------------------------------------------------------*
*& Report zsr_cds_amdp_calling
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZSR_CDS_AMDP_CALLING.
PARAMETERS : P_CD TYPE SFLIGHT-CARRID.
"P_CT TYPE SFLIGHT-MANDT.
SELECT * FROM ZSR_CDS_AMDP( P_CARRID = @P_CD ) INTO TABLE @DATA(LT_RESULT)

##DB_FEATURE_MODE[AMDP_TABLE_FUNCTION].
TRY.
IMPORTING
R_SALV_TABLE = oB_SALV
CHANGING
T_TABLE = LT_RESULT
.
CATCH CX_SALV_MSG.
ENDTRY.
oB_SALV->display( ).
 DIFFERENCE BETWEEN CDS VIEW AND AMDP :-
1. CDS views are declarative, whereas AMDP methods are procedural.

2. CDS views are defined in the data dictionary, whereas AMDP methods are defined in the
ABAP class.
3. CDS views are used for data modeling and consumption, whereas AMDP methods are
used for data manipulation.
4. CDS views support more advanced features such as associations, annotations, and
calculated fields, whereas AMDP methods are more limited in functionality.
5. CDS views can be exposed as OData services and consumed by various clients, whereas
AMDP methods are typically only used within the ABAP system.
6. CDS views can be used with other ABAP development objects, such as BOPF and Fiori,
whereas AMDP methods are typically used only with traditional ABAP development.
 HOW TO EXPOSE CDS VIEW DATA WITH ODATA SERVICE :-

 HERE WE ARE CONSUMING THE CDS VIEW DATA TO ODATA
THROUGH 3 WAYS DDIC, REFERNCE, ANNOTATION.
 NOTE :- HERE FLOW GOES FROM CDS TO ODATA THROUGH
GATEWAY.
 CDS DATA GOES TO THE SERIVCE CREATION LATER IT WILL
CONNECT TO THE ODATA.
 CDS WITH ODATA SERVICE THROUGH DDIC :-
 FIRST WE NEED TO CLICK ON DATA MODEL -> IMPORT -> DDIC .

 NEXT WE NEED TO GIVE SQL VIEW NAME IN STRUCTURE .
AFTER WE NEED TO CHOOSE THE FIELDS AND KEY FIELDS ALSO.
 AFTER WE NEED TO MAP THE DATA CLICK ON SERVICE

IMPLEMENATION -> MAP DATA TO SOURCE -> CHOOSE BUSINESS -
> PROVIDE CDS VIEW NAME .
 AT THE LAST WE NEED TO REGISISTER AND OPEN GATEWAY RUN
METDATA AND ALSO WANTED DATA.
 EXPOSING CDS DATA WITH ODATA THROUGH REFERNCE :-
 FIRST WE HAVE TO WRITE THE CDS VIEW WITH ASSOCIATION .
 @AbapCatalog.sqlViewName: 'ZCDSWITHREFERNCE'
 @EndUserText.label: 'REFERNCE'
 define view ZSR_CDS_WITH_REFERNCE as select from spfli as FLY
 association [1] to sflight as _FLIGHT on
 _FLIGHT.carrid = FLY.carrid
 {

 key FLY.carrid,
 FLY.connid,
 FLY.airpfrom,
 FLY.airpto,
 _FLIGHT

 }
@AbapCatalog.sqlViewName: 'ZCDSREFER'
@EndUserText.label: 'REFERNCE'
define view ZSR_CDS_WITH_REFERNCE1 as select from sflight as FLIGHT
association [1] to ZSR_CDS_WITH_REFERNCE as _RE
on $projection.carrid = _RE.carrid
{
key FLIGHT.carrid,
FLIGHT.connid,
FLIGHT.currency,
_RE
// Make association public

}
 IN SEGW WE CREATE NEW PROJECT AND CLIKC ON DATA MODEL

SELECT REFERNCE CLICK ON DATA SOURCE ONE POP WILL APPEAR
THEIR WE HAVE TO GIVE OUR ASSOCIATION AND ACTIVATE THE
RUNTIME OBJECT.
 UI ANNOTATIONS AND IT’S INFORMATION AND IT’S USAGES :-
 WHY AND HOW ANNOTATIONS ARE BEING USED ?
Annotations are used in CDS (Core Data Services) Views to provide additional
information about entities, associations, and elements in the data model. They help to
enrich the semantic information of the model and to support tools like code generation
and smart controls in user interfaces.
Annotations can be defined as metadata, i.e., data about data, and are attached to the
elements in the CDS View. They can be used to provide additional information, such as a
description, label, or type, to the elements in the view, as well as to s upport data
validation, data formatting, and access control.
For example, an annotation can be used to specify the label for a field in a CDS View,
which will be displayed as the column header in a table, or to specify the format of a
date field, which will be used to display the date in the desired format in a UI.
 UI ANNOATION :-
 UI Annotation in CDS view refers to adding additional information to the
view fields and definitions, like labels, descriptions, and restrictions, to
improve the user experience in the UI.
 HOW CDS ANNOATION FLOW TECHINCALLY :-
 WE HAVE WRITTEN ANNOTATION IN CDS THAT WILL BE STORED IN

GATWAY ABAP SERVER LATER IT WILL GO TO HANA DB TO FECTH
DATA IN HANA DB OUR DATA AND AMDP ARE THERE AFTER WE
NEED TO HAVE ONE WEB ID AFTER IT WILL BE EXUCTED IN THE
FORM OF LIST.
 BULIDING CONNECTION FROM CDS TO ODATA AND WITH UI5 TO

DISPLAY :-
 FISRT WE HAVE TO CREATE ONE CDS VIEW PROGRAM .

NOTE :- WE SHOULD MENTION ONE ODATA ANNOTATION TO CONNECT
ODATA. “@OData.publish: true”
@AbapCatalog.sqlViewName: 'ZSRUI2'
@EndUserText.label: 'UI'
@OData.publish: true
define view ZSR_CDS_WITH_UI_2 as select from ekko as KO
left outer join ekpo as PO on KO.ebeln = PO.ebeln
{
key KO.ebeln,
KO.ernam,
coalesce ( ebelp, 'NOEB') as EBB,
PO.matnr
 NEXT WE HAVE TO OPEN ODATA SERVICE MAINTAIN BEFORE WE

HAVE TO COPY THE CDS ENTITY NAME.
 WE NEED TO GIVE /IWFND/MAINT_SERVICE, WE WILL GET ONE
SCREEN.
 CLICK ON ADD SERVICE THERE WE SHOULD MENTION 2 THINGS.
 CLICK ON GET SERVICE WE WILL GET BACKEND
 WE SHOULD SELECT THAT BACKEND CLICK ON ADD SELECTION

SERVICES BUTTON THERE WE PROVIDE LOCAL LATER OBJECT
CREATED.
 CLICK ON FILTER PROVIDE OUR ENTITY NAME.

 AFTER CLICK ON SAP GATEWAY THERE EXCUTE METDATA NEXT
EXCUTE TOP= 10 RECORDS.
 LATER CONNECT WITH UI5 AND DISPLAY IN UI5.
 UI ANNOTAION WITH POSITION , LABEL , IMPORTANCE :-

 NOTE :- HERE WE ARE USING @UI.LINEITEM ANNOTAION.
 The @UI.LineItem annotation in SAP CDS (Core Data Services)

views is used to specify the layout and behavior of fields in the
user interface when a view is displayed as a table or list. It allows
defining field labels, alignments, and currency, unit and measure
fields. It also helps to control the columns sorting and filtering
behavior, as well as to set field-level properties such as visibility
and required fields.
 The @UI.LineItem annotation contains the following properties:
 label: A user-friendly label for the field that is displayed in the UI.
 position: The order in which the field is displayed in the table or list.
 type: The type of the field, such as currency, unit, or measure.
 criticality: Specifies if a field is critical or not.
 criticalityCalculation: A calculation expression to determine the criticality of a field.
 quickInfo: A tooltip text that is displayed when the user hovers over the field.
 semanticalObject: Specifies the semantic object of a field, which is used to identify
the field in the UI.
 semanticObjectAction: Specifies the semantic object action of a field.
 sorting: Specifies the sorting behavior of a field.
 filter: Specifies the filter behavior of a field.
 width: Specifies the width of a field.
 labelPlacement: Specifies the placement of the field label in relation to the field
value.
 inline: Specifies if a field should be displayed inline or in a separate row.
 visible: Specifies if a field is visible or not.
 mandatory: Specifies if a field is required or optional.
 @AbapCatalog.sqlViewName: 'ZSRUI4'
 @EndUserText.label: 'UI'
 @OData.publish: true
 define view ZSR_CDS_WITH_UI_4 as select from ekko as EE
 association [1] to ekpo as _EP
 on _EP.ebeln = EE.ebeln
 {

 @UI.lineItem: [{
 position: 1,
 label: 'PURCHASE_ORDER',
 importance: #HIGH
 }]

 key EE.ebeln,

 position: 3,
 label: 'NAME',
 }]
 EE.ernam,

 position: 2,
 label: 'PURCHASE_DATA',
 }]
 _EP.ebelp,

 position: 5,
 label: 'MATERIAL_NUM',
 }]
 _EP.matnr,

 position: 4,
 label: 'ERR',
 }]
 _EP.erekz
 }
 @ENDUSERTEXT TO GIVE INFORMATION WHEN WE PLACE THE
CURSOR ON FIELD :
 This annotation allows developers to provide clear, concise and user-

friendly descriptions of data elements in the view, which can be used to
improve the usability of the UI and make it easier for end users to unde
rstand the data.
 @EndUserText : {
quickInfo: 'CREATED'
 ADDING A SELECTION FIELD FROM THE BACKEND :-

 WE HAVE A STANDARD OPTION IS THER IN UI5 “ADPAT FILTER”
BUT IF WE WANT PROVIDE FROM BACKED WE NEED TO USE UI
ANNOTAION .
 @UI.selectionField: [{
position: 1
}]
 ADDING IMG URI AND DISPLAYING IN UI5 AND NAME

CONCATINATION WITH FUZZINESS SEARCH HELP AND PROVIDING
SEARCH HELP FOR EMPLOYEE ID AND MOVING TO NEXT AND
USING HAEDER ANNOTAION:-
 @AbapCatalog.sqlViewName: 'ZIMG'
 @EndUserText.label: 'IMAGE DISPLAYING'
 define view ZSR_CDS_WITH_IMAGE as select from snwd_employees as EMP
 {

 key EMP.employee_id as EMP_ID,
 EMP.first_name as EMP_FISRT_NAME,
 EMP.last_name as EMP_LAST_NAME,
 CONCAT('HTTP://183.82.98.9:8057',EMP.employee_pic_url) as EMP_IMG

 }
 IN UI5 WE ARE DISPLAYING AND COPY THAT URI EXECUTE IN

CHROME
 IMAGE WITH FUZZ SERACH HELP :-
 MANDATORY ANNOTATIONS SHOULD BE DECLEARED FOR
FUZZYSEARCHHELP
 SEARCH HELP FOR EMP_ID
 USING HEADER ANNOATION , MOVING NEXT PAGE.
@AbapCatalog.sqlViewName: 'ZIMG'
@EndUserText.label: 'IMAGE DISPLAYING'
@Search : {
searchable: true
}
// HERE HEADER WE ARE PASSING //
@UI.headerInfo: {
typeName: 'Employee',
typeNamePlural: 'Employees',
title: {
value: 'employee_id'},
description: {
value: 'FullName'},
imageUrl: 'urlIMG'
}
define view ZSR_CDS_WITH_IMAGE as select from snwd_employees

{
@UI.lineItem: [{
position: 10,
label: 'EMP ID',
importance: #HIGH }]
@UI.selectionField: [{
position: 10 }]
key snwd_employees.employee_id as employee_id ,
@UI.lineItem: [{
position: 20,
label: 'First Name',
importance: #HIGH }] //link is open through mobile at the time this field should mandtory dis
@Search: {
defaultSearchElement: true,
fuzzinessThreshold: 0.6, //fault-tolerant search
ranking: #HIGH
}
snwd_employees.first_name as firstName,
@UI.lineItem: [{
position: 35,
label: 'Last Name',
importance: #HIGH }]
@Search: {
defaultSearchElement: true,
fuzzinessThreshold: 0.6,
ranking: #MEDIUM
}
snwd_employees.last_name as LastName,
concat_with_space(snwd_employees.first_name,snwd_employees.last_name,1) as FullName,
concat('http://183.82.98.9:8057',snwd_employees.employee_pic_url) as urlIMG
}
 UI ANNOATION WITH SOME NEW ANNOATIONS BY BINDING THE
SEREVICE IN ADT TOOL ITSELF :-
 @AbapCatalog.sqlViewName: 'ZUIANNO'
 @EndUserText.label: 'ANNOATION'
 define view ZSR_UI_ANNOATION as select from mara
 {
 @UI.lineItem: [{ position: 01 , label: 'MATERIAL_NUM' }]
 key matnr,

 @UI.lineItem: [{ position: 02 , label: 'MATERIAL_DESC' }]
 matkl,

 @UI.lineItem: [{ position: 03 , label: 'CREATED_BY' }]
 ernam,

 @UI.lineItem: [{ position: 04 , label: 'CREATED_ON' }]
 ersda
 }

 FIRST WE HAVE TO CREATE THE SERVICE BY RIGHT CLICKING ON

THE CDS.
 LATER WE HAVE TO CREATE WITH “_SRV” SUFFIX .
@EndUserText.label: 'SERVICE'
define service ZSR_UI_ANNOATION_SRV {
expose ZSR_UI_ANNOATION;
}
 LATER WE HAVE TO BIND THE SERVICE BY RIGHT CLICKING ON THE

SERIVCE NAME.
 NOTE :- FOR ARRANGING TWO FIELDS VALUE IN ONE COLUMN BY
GIVING ONE TEXT .
@ObjectModel.text.element: ['MATERIALNUM']
@UI.textArrangement: #TEXT_FIRST
@AbapCatalog.sqlViewName: 'ZUIANNO'
@EndUserText.label: 'ANNOATION'
define view ZSR_UI_ANNOATION as select from mara as ma
{
@UI.lineItem: [{ position: 01 , label: 'MATERIAL_NUM' }]
@ObjectModel.text.element: ['matkl']
@UI.textArrangement: #TEXT_FIRST
key ma.matnr as MATNR,
// @UI.lineItem: [{ position: 02 , label: 'MATERIAL_DESC' }]

ma.matkl as matkl,
@UI.lineItem: [{ position: 03 , label: 'CREATED_BY' }]

ernam,
@UI.lineItem: [{ position: 04 , label: 'CREATED_ON' }]

ersda,
@UI.lineItem: [{ position: 05 , label: 'MATERIAL_TYPE' }]

mtart,
@UI.lineItem: [{ position: 06 , label: 'IND_SECTOR' }]

mbrsh
}
 UI VALUE HELP DEFINATION FOR THE SEARCH HELP :-
 AFTER WE EXECUTE IF WE CLICK ON SEARCH HELP

AUTOMATICALLY RELATED DATA SHOULD BE DISPLAYED.
 FIRST WE HAVE TO CREATE ONE CDS.
 @AbapCatalog.sqlViewName: 'ZVALUEHELP'
 @EndUserText.label: 'PROVIDING VALUE HELP'
 define view ZSR_VALUE_HELP as select from mara
 {
 key matnr,
 matkl
 }

@Consumption.valueHelpDefinition: [{ entity : { element:

'MATNR', name: 'ZSR_VALUE_HELP' } }]
 FOR PROVIDING THE DROPDOWN
@ObjectModel.resultSet.sizeCategory: #XS
define view ZSR_VALUE_HELP as select from SPFLI
{
@ObjectModel.text.element: ['CARRID']
key CARRID,
CONNID
}
 MAKING THE FIELD AS MANDATORY FIELD
@Consumption.filter: { mandatory: true }

 ASSIGINING DEFAULT VALUES FOR THE FIELD
@Consumption.filter: { mandatory: true, defaultValue:

'TG10', multipleSelections: true, selectionType:
#SINGLE }
 DISPLAYING THE DATA AFTER YOU CLICK ON THE PARTICULAR
FIELD
@UI.headerInfo :
{
typeName: 'MATERIAL ', typeNamePlural: 'MATERIALS',
title: {
type: #STANDARD,
value: 'MATERIAL_NUM'
},
description:{
type: #STANDARD,
value: 'MATNR'
}
}
 ASSIGNING TAB AND FIELDS
@UI.facet: [{
id: 'MATERIAL_INFO',
type: #COLLECTION,
label: 'MATERIAL',
position: 10 },
{
id: 'MATERIAL_NUM',
type: #IDENTIFICATION_REFERENCE,
label: 'MATERIAL_DATA',
PARENTID: ‘MATERIAL_INFO’
position: 10
}
 IF YOU MENTION #IDENTIFIACTION _REFERNCE
@UI.identification: [{ position: 10 }]
key ma.matnr as MATERIAL_NUM,
 PROVIDING DROP DOWN.
@ObjectModel.resultSet.sizeCategory: #XS
define view ZSR_VALUE_HELP as select from mara
{
@ObjectModel.text.element: ['matnr']
key matnr,
matkl
}
 MAKING THE GROUP AND ADD DATA UNDER TAB
//GROUPING FIELDS//
{
id: 'CREATIONINFO',
type: #FIELDGROUP_REFERENCE,
label: 'CREATION_INFO',
parentId: 'MATERIAL_INFO',
targetQualifier: 'TQDATA',
position: 10
}]
 ASSIGNING TO THE PARTICULAR FIELD
@UI.fieldGroup: [{ qualifier: 'TQDATA' }]

ernam,
 DISPLAYING THE DATA IN OBJECT .
 WE HAVE TO CREATE ONE CDS VIEW .
 @AbapCatalog.sqlViewName: 'ZMARD'
 @EndUserText.label: 'MARD'
 define view ZSR_UI_MARD as select from mard
 {

 @UI.lineItem: [{ position: 10 , label: 'MATERIAL'}]
 key matnr,

 @UI.lineItem: [{ position: 20, label: 'PLANT' }]
 key werks,

 @UI.lineItem: [{ position: 30, label: 'STORAGE' }]
 key lgort,

 @UI.lineItem: [{ position: 40, label: 'DATE' }]
 ersda,

 @UI.lineItem: [{ position: 50, label: 'MAINT_STATUS' }]
 pstat
 }

 LATER WE HAVE TO MENTION TARGET CDS NAME AND DO

ASSOCIATION.
// DISPLAYING ITEM DATA AND OBJECT BY USING TARGET //
{
id: 'MARD',
purpose: #STANDARD,
type: #LINEITEM_REFERENCE,
label: 'MAT',
position: 30,
targetElement:'_MD'
}]
 OVER ALL UI.ANNOTAION IN ONE CODE :-
@AbapCatalog.sqlViewName: 'ZUIANNO'
@EndUserText.label: 'ANNOATION'
@UI.headerInfo :
{
typeName: 'MATERIAL ', typeNamePlural: 'MATERIALS',
title: {
type: #STANDARD,
value: 'MATERIAL_NUM'
},
description:{
type: #STANDARD,
value: 'MATNR'
}
}
define view ZSR_UI_ANNOATION as select from mara
association[1..*] to ZSR_UI_MARD as _MD on $projection.MATERIAL_NUM = _MD.matnr
{
@UI.facet: [{
id: 'MATERIAL_INFO',
type: #COLLECTION,
label: 'MATERIAL',
position: 10 },
{
id: 'MATERIALNUM',
type: #IDENTIFICATION_REFERENCE,
label: 'MATERIAL_DATA',
position: 10
},
//GROUPING FIELDS//
{
id: 'CREATIONINFO',
type: #FIELDGROUP_REFERENCE,
label: 'CREATION_INFO',
targetQualifier: 'TQDATA',
position: 10
},
// DISPLAYING ITEM DATA AND OBJECT BY USING TARGET //
{
id: 'MARD',
purpose: #STANDARD,
type: #LINEITEM_REFERENCE,
label: 'MAT',
position: 30,
targetElement:'_MD'
}]
@UI.lineItem: [{ position: 01 , label: 'MATERIAL_NUM' }]

@UI.selectionField: [{ position: 01 }]
// @ObjectModel.text.element: ['matkl']
//@UI.textArrangement: #TEXT_FIRST
@Consumption.valueHelpDefinition: [{ entity : { element: 'matnr', name:

'ZSR_VALUE_HELP' } }]
//IF I WANT TO MAKE THE FIELD AS THE MANDATORY FIELD //

@Consumption.filter: { mandatory: true, defaultValue: 'TG10', multipleSelections:
true, selectionType: #SINGLE }
key matnr as MATERIAL_NUM,
// @UI.lineItem: [{ position: 02 , label: 'MATERIAL_DESC' }]
matkl as matkl,
@UI.lineItem: [{ position: 03 , label: 'CREATED_BY' }]

ernam,
@UI.lineItem: [{ position: 04 , label: 'CREATED_ON' }]

@UI.fieldGroup: [{ qualifier: 'TQDATA' }]
ersda,
@UI.lineItem: [{ position: 05 , label: 'MATERIAL_TYPE' }]

mtart,
@UI.lineItem: [{ position: 06 , label: 'IND_SECTOR' }]

mbrsh,
//PUBLIC ASSOCIATION//
_MD
 CDS VIEW ANNOTATION WITH ANALYTICS :
Analytics in CDS (Core Data Services) view is a feature of SAP HANA that allows for
the creation and execution of analytical queries on top of the data stored in a CDS
view. It provides a way to perform advanced calculations and data aggregation for
business intelligence and reporting purposes. Analytics in CDS views can be used
in combination with other SAP HANA features, such as the modeling and
calculation views, to create a complete end-to-end data analysis solution.
 BASIC MODELING FOR ANALYTICS WITH CDS VIEW :

 Modeling in CDS (Core Data Services) views refers to defining data
structures and relationships between them in a semantic and abstract
way in the SAP HANA database.
 FIRST WE HAVE TO DO #DIMENSION AFTER

#CUBE(CUSOMPUATION).
@AbapCatalog.sqlViewName: 'ZMODELDIM'
@EndUserText.label: 'MODEL'
define view ZSR_MODEL_DIMNISION as select from sflight

association [1..1] to spfli as _SPF
on $projection.carrid = _SPF.carrid
{
key sflight.carrid,
sflight.connid,
sflight.currency,
_SPF.airpto,
_SPF.airpfrom
}
 @AbapCatalog.sqlViewName: 'zmodeldim1'
 @EndUserText.label: 'MODEL1'
 @Analytics.dataCategory: #DIMENSION
 define view ZSR_MODEL_DIMNISION1 as select from scarr
 association [1..1] to sflight as _sf
 on $projection.carrid = _sf.carrid


 {

 key scarr.carrid,
 scarr.carrname,
 scarr.currcode,
 _sf.fldate,
 _sf.price

 }
@AbapCatalog.sqlViewName: 'ZSRCUBE'
@EndUserText.label: 'CUBE ANALYTIC'
@Analytics.dataCategory: #CUBE
define view ZSR_MODEL_CUBE as select from spfli
association [0..*] to ZSR_MODEL_DIMNISION as _ZSR_MODEL_DIMNISION
on $projection.connid = _ZSR_MODEL_DIMNISION.connid
association[1..1] to ZSR_MODEL_DIMNISION1 as _ZSR_MODEL_DIMNISION1
on $projection.carrid = _ZSR_MODEL_DIMNISION1.carrid
{
key spfli.connid,
_ZSR_MODEL_DIMNISION.airpfrom,
_ZSR_MODEL_DIMNISION1.carrid
 GRAPHICS :
 Authorization, Access Control :-
 GIVING ACCESS FOR A PARTICULAR USER TO ACCESS CDS DATA,

WE NEED TO USE AUTHORIZATION AS WELL .
 HERE AUTHORIZATION IS HAPPENING FOR THE A PERSON BY
USING DCL (DATA CONTROL LANGUAGE ) .
 Authorization
 The Authorization in SAP protects transactions, programs, and

services in SAP systems from unauthorized access.
 On the Basis of Authorization concept, the administrator assigns
authorizations to the users that determine which actions a user can
execute in the SAP system, after he or she logged on to the system
and authenticated himself or herself.
 Authorization Object
 Authorization Object is a method of restricting users to access any
particular application created in the system. It will be denying user
for viewing confidential data on screen or denying access to certain
transactions.
 Example
 Suppose we have a Zcdsview in our system that consists of
confidential data. Which cannot be accessed by all users. Only
authorized persons can have access to the data. So, in case these
tables are being used in any program, for display/write purpose,
that program would be executed only by Authorized users. Please
make sure to disable Table Entries, while creating tables, and not to
create any Table Maintenance Generator also. Only this program
would be used to perform read/write operations on the table.
 Authorization Field
 Authorization field contains the value that you have defined. It is
connected to the data elements stored with the ABAP dictionary.
 7 STEPS TO ACHIEVE ACCESS CONTROL :-
 FIND THE FIELD / BUSINESS REQUIREMENT AND MAP TO LOGIC.

 CRAETE/FIND AUTHORIZATION(S) FIELDS.
 CREATE AUTHORIZATION OBJECTS.
 ADD TO EXISITING ROLE OF USER OR CREATE A NEW USER.
CREATE A NEW USER
CREATE A NEW ROLE
ADD ROLE TO USER
 CREATE THE DCL
 ACTIVATE AND TEST ALL THE CHANGES.
 TEST AND VERIFY.
 Steps:
1. Creating Object Class T-Code SU21.
2. Creating Authorization Object Which contains Authorization field.
You can create authorization field in SU20 or while creating
authorization object also you can create.
3. Creating a Role T-Code PFCG.
4. Assigning Authorization object to the role and generating the
profile.
5. Create custom program using Authority-check.
To create Object class and authorization object inside object class.

Go toT-Code SU21from create button, First select Object class.
Object Class: Object classContains one or more Authorization Objects.

All authorization objects are allocated to exactly one class. This has no
functional but allocating character. We will need this object class to
encapsulate the authorization object that we will be creating.
The below screen appears and enter the Object Class name and Save.
Object Class contain many authorization objects and select Authorization Object.
The below screen appears, provide the Object name, text and class name is already created and click
on Field maintenance. You can create authorization field in SU20 also.
Then click on Authorization Field
Provide the authorization field and data element once you click on enter button the domain and
output length will come automatically. select save button and go back.
Add the two-authorization field one is ZCARRID and ACTVT and select save button.
ACTVT:ACTVT is a standard field within SAP Table tact that stores Activity information like create,
change, display.
Select Permitted Activities button.
You can select as many activities and click on save. Here I took display authorization.
The next step is to create a role in T-Code PFCG, inside which we will attach our authorization Object.
Enter the role and click on Single Role button.
What is Role:role is assigned to an users the user menu that is displayed after they log on to the sap
system. Roles also contain the authorizations that users can use to access the transaction, reports,
Web-based applications.
Single Role:is created with the profile generator and allows the automatic generation of an
authorization profile. The role contains the authorization data and the logon menu for the user.
Composite Role: Consists of any number of single roles.
Provide the description and click on save.
Select the Authorization tab and click on the icon next to profile name. Once you click on the icon
system will generate a profile name and a profile text.
What is profile:A profile is the element in the authorization system. It allows a user to access the
system. For authorization check, the system checks on the particular profile which is assigned to user
for the proper authorization.
Click on the Change Authorization data and press continue.

Do not select any template.
You will see a new screen with role name on top left. Here you can add your Authorization object
that was created in SU21. Click on the Manually button.
Add the Authorization object and press enter.
Now you need to add values in your object. For those who would be given authorization.
Click on change of ZCARRID
Press f4 and you can select any number of Airline code. Here I have selected AA and press continue
and click on save button.
Do same for ACTVT and select display and click on save button.
Then generate the profile by clicking on generate icon.
Finally, you come out of the screen pressing back button. And you will see the authorizations tab
with a green symbol, meaning, authorization object has been assigned and the role can be used.
After these steps click on the User tab and provide the User Id and click on User Comparison button.
Click on Complete comparison.

The user master record for all roles adjusted.
What is User master record: The user master record contains all information about the corresponding
user, including authorizations.
The Authorization and User tab with a green symbol, means you have successfully created the
authorization and assigned the role to the user.
Create custom program using Authority-check.
Authority-check:Authority Check is the statement used in an ABAP program to perform an authorization
check against an authorization object. This statement will return sy-subrc is 4 if user has not authorized.
Authorization in CDS View
We all k now how authorization works in ABAP using ABAP statement AUTHORITY-CHECK, In CDS View
has its own authorization concept CDS access controls using a data control language (DCL).
DCL(Data Control Language):DCL is used to define the authorization for the CDS View which controls
access to the data retrieved based on user.
First step, we can create an implementation CDS View (SPFLI) from this table.
@AbapCatalog.sqlViewName:'ZMMAUTH'
@AbapCatalog.compiler.compareFilter:true
@AbapCatalog.preserveKey:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'Authorization Check'
defineviewZMM_Authorizationasselectfrom spfli {
//spfli
key carrid,
connid,
cityfrom,
cityto
}
Creating an Access control with CDS.

Now we have already created Authorization object and Authorization field. We need to connect them
with our CDS View to make it recognize the DCL. To do this, in eclipse, right click on the Core Data
Service folder, click new and select access control.
Now add the below code in the Access Control. Here the Authorization Object and Authorization
field should be the same as the one which you created in the Tcode SU21.
Inside Access Control

Annotations in DCL
@EndUserText.label: 'Access Control'
The translatable short text for role.
@MappingRole: true
Role is implicitly to all users
Define Role Provide a role name here
Grant select on This is the CDS View on which data restriction are to be applied through a DCL.
Where This is the field which is to be restricted.
Aspect pfcg_auth This is the place to include the authorization object and authorization fields on
which it is applied with the ACTVT permitted activities.The possible value of ACTVT for that
authorization object can be seen in TCODE SU21 as shown below. As most CDS views are used for
reading, 03 is used which is for display.
@EndUserText.label:'Access Control'
@MappingRole:true
definerole ZACCESS_CONTROL {
grant
select
on
ZMM_AUTHORIZATION
where
( CARRID )=aspectpfcg_auth(ZSPF_CARRI, ZCARRID, ACTVT ='03');
 AND IF YOU WANT CHECK THAT OUR HANAUSER13 IS ADDED OR

NOT WE CAN CHECK THROUGH “SACM”
 CDS DEVELOPMENT PREVIEW :-

 FIND DDL :-
 HERE WE ARE FINIDING WHERE OUR CDS WILL BE STORED IN DDL.
 THERE IS A STANDARD PROGRAM “RUTDDLSSHOW2”.
 IN THIS PROGRAM THERE IS ONE TABLE “DDDDLSRC” IT WILL HOLD

OUR CDS VIEW NAME.
 IF WE RUN THIS PROGRAM , IT WILL ASK YOUR CDS VIEW NAME
LATER EXCUTE WE WILL GET OUR CODE.
 HOW TO SEE DEPENDENT OF TABLES
 1ST WAY DEPENDENCY ANLAYZERS :-
 FISRT WE HAVE TO OPEN ONE CDS VIEW , DO RIGHT CLICK -> OPEN
WITH -> DEPENDNCY ANALYZER.
 IF WE WANT TO SEE IN SQL GRAPH CLICK ON SQL RELATION
 WAY TO INCREASE THE PERFORMANCE OF CDS VIEW :

 MORE POINTS TO INCREASE :-
1. Code push down: As explained above, code push down can improve performance by
executing filtering, aggregation, and calculation logic within the database layer.
2. Indexes: Creating indexes on the columns used in the filtering and aggregation of the
CDS view can improve query performance.
3. Materialized views: Materializing a CDS view can improve performance by pre-
calculating the result set and storing it in a separate table, allowing for faster access to
the data.
4. Partitioning: Partitioning a CDS view can improve performance by distributing the data
across multiple storage containers, reducing the amount of data that needs to be
loaded into memory.
5. Minimizing data load: Avoid loading unnecessary data into memory by using
appropriate filters in the CDS view definition.
6. Avoiding complex calculations: Complex calculations can impact performance. If
possible, perform calculations outside of the CDS view or use stored procedures to
perform the calculation.
7. Use of appropriate join types: Use inner joins instead of outer joins, as outer joins can be
slower and consume more memory.
 UDERSTANDING OF VDM AND IT’S LAYERS :-
 HERE HOW A VDM WORKS FLOW IN S/4 HANA , SEE WE HAVE 3

VDM LAYER.
 FIRST WE HAVE A DATABASE AND TABLES , IT CONTAINS SOME
TABLES.
 FIRST VDM IS “BASIC_VDM” IT IS LIKE VDM WHICH IS ONLY
INTERACT WITH DB LAYER AND ASLO AVAILABLE FOR ALL
APPLICATION.
 SECOND VDM IS “COMPOSITE_VDM” IT IS LIKE VDM WHICH CAN
BE ONLY INTERACT WITH BASIU VDM NOT WITH DB LAYER , IT IS
USED FOR CONSUME THE DATA BY DOING JOINS AND
ASSOCIATION, WE CAN CREATE MULTIPLE COMPOSITE VDM.
 THIRD VDM IS “CONSUMPATION_VDM” IT IS LIKE VDM WHICH
CAN BE INTERACT WITH COMPOSITE NOT WITH DB LAYER, MAINLY
IT WILL CONSUME THE DATA FROM DIFFERENT PLATFORM LIKE
ODATA, UI5 ETC.
NOTE :- BASIC AND COMPOSITE VIEW ARE THE INTERFACE VIEWS.
 DIFFERNCE BETWEEN ASSOCIATION , CONSUMPATION,

PROJECTION :-
 @ASSOCIATION V/S @COMPOSITION :-

1. Dependence: In Composition, the dependent object does not exist independently
of the parent object, while in Association, the referred object can exist
independently of the referring object.
2. Cardinality: In Association, one class refers to another class as a reference and can
refer to multiple instances of the referred class, but only one of them can be
referred to at any time. In Composition, one class acts as a container for another
class and contains multiple instances of the contained class.
3. Deletion: In Composition, when the container object is deleted, the contained
object is also deleted. In Association, deleting one object does not affect the
other object.
4. Annotation: Association is represented in CDS View by the "@Association"
annotation, while Composition is represented by the "@Composition" annotation.
5. Purpose: The purpose of Association is to relate two objects, while the purpose of
Composition is to create a parent-child relationship between two objects, where
the child object is dependent on the parent object.
 @PROJECTION :-
 In SAP ABAP (Advanced Business Application Programming), the

"@Projection" annotation in CDS (Core Data Services) Views is used to define
the structure of the data that is returned from the CDS View. It specifies the
fields (attributes) that should be included in the result set, and the way in
which the data is organized. The projection determines the structure of the
data that is returned to the client, for example a consuming application, and
can be used to simplify, aggregate, or restrict the data that is returned.
Projection is used to define the structure of the data that is returned from a
CDS View, without modifying the underlying data in the database. The
"@Projection" annotation is applied to a CDS View definition and it defines
the structure of the data that will be returned when the view is queried.
 HOW VDM WILL WORK IN S/4 HANA :
 CDS VIEW PERFORMACE WITH SOM STANDARD ANNOTAIONS

INFORMATION :-
 BY UING PRESENTION LAYER WE DISPLAY IN FIORI UI THROUGH
ODATA WE CAN LINK TO PRESENATION LAYER IN APPLIACTION
LAYER OUR CDS WILL CREATED AND SADL IS THE RESPONSIABLE
FOR THE CREATION OF CDS AND ONCE IT IS ACTIVATED CODE WILL
PUSHDOWN TO DB LAYER THERE SQL PROCESSOR WILL MAKE
QUERY PLAN HOW QUERY WILL GO ON.
 THERE ARE 2 FACTORS FOR CDS PERFORMANCE :-
 DESIGN TIME DEPENDENCY :- HERE WE GET TO KNOW HOW
MUCH TABLE INVOVLED .
 RUNTIME DEPENDENCY AND EXECUATION PERFORMANEC FOR
ALLTABLES
 ST05 FOR CHECKING ACTIVE TRACE -> RUN CDS -> DECTIAVE ->
AND DISPLAY TRACE -> WE WILL GET TO SEE THE DURATION
PERFORMANCE -> LATER SELECT AND CLICK ON EXECUTE PLAN ->
CHECK RUNTIME WITH GRAPH.
 WHAT ARE THE ANNOTAION TO IMPROVE OUR PERFORM OF CDS :-

 WE ARE USING THREE IMPROTANT ANNOTATIONS :-
1)SERVICEQUALITY :-
 SERIVCE QULAITY IS TO USE WHEN WE WANT TO CHECK

PERFORMANCE KPI .
 IN THAT “A” IS TH HIGHEST KPI QUALITY AND “D” IS THE LOWEST
KPI QUALITY .
 “A” -> WHEN WE HAVE COMPLEX CDS VIEW THAT WE ARE NOT
ABLE TO DO PERFORMANCE OR SOMETHING THAT TIME WE GO
FOR “A”.
2)SIZECATOGRY :-
 HERE DEPENDED ON SIZE DB WILL GIVE SOURCE , IF XXL HAS LOT
OF FIELDS THAT TIME IT WILL TELL TO DB I HAVE THIS MUCH
RECORD LIKE THAT , THAT TIME DB WILL PROVIDE SOURCE.
3)DATACLASS :-
 HOW AND WHERE AND WHEN TO USE THESE THREE ANNOTAIONS
:-
 CHECKING THE CDS VIEW KIP AND IT’S ALL ANNOTAION ARE
IMPLEMENTED OR NOT:-
 WE HAVE ON STANDRD TABLE THERE WE HAVE TO GIVE CDS NAME

AND EXCUTE :-
 BASIC AND COMPOSITE AND CONSUPATION VIEW EXAMPLE :-
 BASIC VIEW 1 :-
@AbapCatalog.sqlViewName: 'ZBASICVIEW'
@EndUserText.label: 'BASIC VIEW'
@VDM.viewType: #BASIC
define view ZSR_BASIC_VIEW1 as select from scarr
{
key scarr.carrid as Airline,
@Semantics.text: true
scarr.carrname as AirName,
scarr.currcode as AirCurrency,
scarr.url as AirlineUrl
 BASIC VIEW 2 AND ASSOCIATION WITH 1ST BASIC VIEW :-
@AbapCatalog.sqlViewName: 'ZBASICVIEW2'
@EndUserText.label: 'BASIC VIEW2'
define view ZSR_BASIC_VIEW2 as select from spfli
association [0..1] to ZSR_BASIC_VIEW1 as _SCARR
on $projection.Airline = _SCARR.Airline
{
//@ObjectModel.foreignKey.association: ‘_Scarr’
key spfli.carrid as Airline,
key spfli.connid as AirConnection,
spfli.countryfr as DepartureCountry,
spfli.countryto as ArrivalCountry,
//@Semantics.quantity.unitOfMeasure: ‘AirDistanceUnit’
@DefaultAggregation:#SUM
spfli.distance as AirDistance,
@Semantics.unitOfMeasure: true
spfli.distid as AirDistanceUnit,
_SCARR
 BASIC VIEW 3 HERE ASSOCTAION WITH BASIC 1 AND BASIC 2 :-
@AbapCatalog.sqlViewName: 'ZBASICVIEW3'
@EndUserText.label: 'BASIC VIEW3'
define view ZSR_BASIC_VIEW3 as select from sflight
association [0..1] to ZSR_BASIC_VIEW1 as _SCARR
on $projection.Airline = _SCARR.Airline
association [0..1] to ZSR_BASIC_VIEW2 as _SPFLI

on $projection.Airline = _SPFLI.Airline
and $projection.AirConnection = _SPFLI.AirConnection
{
key sflight.carrid as Airline,
//@ObjectModel.foreignKey.association: ‘_Spfli’
key sflight.connid as AirConnection,
key sflight.fldate as FlightDate,
//@Semantics.amount.currencyCode: ‘FlightCurrency’
@DefaultAggregation: #MIN
sflight.price as FlightPrice,
sflight.currency as FlightCurrency,
@DefaultAggregation: #SUM
sflight.seatsmax as MaximumAvaSeats,
sflight.seatsocc as NumberOfAvaSeats,
/* Associations */
_SCARR,
_SPFLI
 COMPOSITE VIEW AND ASSOCAIATION WITH BASIC 3 :-
@AbapCatalog.sqlViewName: 'ZCOMPOSITE'
@EndUserText.label: 'COMPOSITE VIEW'
@VDM.viewType: #COMPOSITE
define view ZSR_COMPOSITE_VIEW_FOR_3BASIC as select from ZSR_BASIC_VIEW3
{
key ZSR_BASIC_VIEW3.Airline,
//@ObjectModel.foreignKey.association: ‘_Spfli’
key ZSR_BASIC_VIEW3.AirConnection,
key ZSR_BASIC_VIEW3.FlightDate,
//@Semantics.amount.currencyCode: ‘FlightCurrency’
@DefaultAggregation:#MIN
ZSR_BASIC_VIEW3.FlightPrice,
ZSR_BASIC_VIEW3.FlightCurrency,
ZSR_BASIC_VIEW3.MaximumAvaSeats,
ZSR_BASIC_VIEW3.NumberOfAvaSeats,
/* Associations */
ZSR_BASIC_VIEW3._SCARR,
ZSR_BASIC_VIEW3._SPFLI,
ZSR_BASIC_VIEW3._SCARR.AirName,
ZSR_BASIC_VIEW3._SCARR.AirlineUrl,
ZSR_BASIC_VIEW3._SPFLI.DepartureCountry,
ZSR_BASIC_VIEW3._SPFLI.ArrivalCountry
 CONSUMPATION VIEW AND ASSOCTAION WITH COMPOSITE :-

@AbapCatalog.sqlViewName: 'ZCONS'
@EndUserText.label: 'CONSUMPATION'
@VDM.viewType: #CONSUMPTION
define view ZSR_CONSUMPTION_VIEW_3 as select from ZSR_COMPOSITE_VIEW_FOR_3BASIC
{
key ZSR_COMPOSITE_VIEW_FOR_3BASIC.Airline,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.AirConnection,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.FlightDate,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.FlightPrice,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.FlightCurrency,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.MaximumAvaSeats,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.NumberOfAvaSeats,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.AirName,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.AirlineUrl,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.DepartureCountry,
ZSR_COMPOSITE_VIEW_FOR_3BASIC.ArrivalCountry,
ZSR_COMPOSITE_VIEW_FOR_3BASIC._SCARR,
ZSR_COMPOSITE_VIEW_FOR_3BASIC._SPFLI
}
 TABLE FUCNTION :-
 Table functions are useful in CDS views because they allow you to define complex data
models that can be used to provide a unified view of data from multiple tables. They can
also be used to perform calculations on data in the database, which can save time and
reduce the amount of data that needs to be transferred between the database and the
application.
 PRERQUSITIES :-
 PROCESS TO ACHIEVE THE TABLE FUNCTION :-
 WE FIRST WE HAVE TO CREATE CDS VIEW WITH BY SELECTING

“TABLE FUN WITH PARAMETER”.
 HERE WE HAVE CREATED TABLE FUN WITH CLASS AND METHOD.

 @EndUserText.label: 'TABLE_FUNCTION'
 define table function ZSR_TABLE_FUN
 with parameters P_material:matnr

 // RETURN WILL MULTIPLE RECORDS//
 returns {
 client : abap.clnt;
 // fecthing the data from the field with data element//
 material_num : matnr;
 CREATED : ernam;
 DATE : laeda;
 CHANGED : aenam;

 }


 implemented by method zcl_material=>get_material;
 LATER WE HAVE TO CREATE THE CLASS AND METHOD IN ABAP
CLASS.
CLASS zcl_material DEFINITION PUBLIC.

PUBLIC SECTION.
INTERFACES if_amdp_marker_hdb.
"HERE WE ARE METHIONING THE TAB FUN FOR THE METHOD "
CLASS-METHODS GET_MATERIAL FOR TABLE FUNCTION ZSR_TABLE_FUN.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_material IMPLEMENTATION.
METHOD get_material BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT

OPTIONS READ-ONLY USING MARA.
RETURN SELECT MANDT AS CLIENT, MATNR AS MATERIAL_NUM, ERNAM AS CREATED, LAEDA AS

DATE, AENAM AS CHANGED FROM MARA
WHERE matnr = :P_material;
ENDMETHOD.
ENDCLASS.
 TABLE FUNCTION WITH JOINS .
 TABLE FUN :-
@EndUserText.label: 'JOINS'
define table function ZSR_TABLE_FUN_JOINS
with parameters P_MATERIAL:matnr,
@Environment.systemField: #CLIENT
clnt:abap.clnt
returns {
client : abap.clnt;
MATERIAL : matnr;
DATE : ersda;
NAME : ernam;
PLANT : werks_d;
STATUS : pstat_d;
}
implemented by method ZCL_TAB_FUN_JOINS=>GET_MATERIAL_DATA;
 CLASS :-
CLASS zcl_tab_fun_joins DEFINITION PUBLIC.

PUBLIC SECTION.
CLASS-METHODS : GET_MATERIAL_DATA FOR TABLE FUNCTION ZSR_TABLE_FUN_JOINS .
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_tab_fun_joins IMPLEMENTATION.
METHOD get_material_data BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT

OPTIONS READ-ONLY USING MARA MARC.
RETURN select ma.mandt as client,

ma.matnr as material,
ma.ersda as date,
ma.ernam as name,
mc.werks as plant,
mc.pstat as status
from mara as ma inner join
marc as mc
on ma.mandt = mc.mandt and ma.matnr = mc.matnr
where ma.mandt = :clnt and ma.matnr = :P_MATERIAL;
ENDMETHOD.
ENDCLASS.
 JOINS WITH ALL FIELDS .
CLASS zcl_tab_fun_joins DEFINITION PUBLIC.

PUBLIC SECTION.
CLASS-METHODS : GET_MATERIAL_DATA FOR TABLE FUNCTION ZSR_TABLE_FUN_JOINS .
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_tab_fun_joins IMPLEMENTATION.
METHOD get_material_data BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT

OPTIONS READ-ONLY USING MARA MARC.
RETURN select ma.mandt as client,

ma.matnr as material,
ma.ersda as date,
ma.ernam as name,
mc.werks as plant,
mc.pstat as status
from mara as ma inner join
marc as mc
on ma.mandt = mc.mandt and ma.matnr = mc.matnr
where ma.mandt = :clnt;
ENDMETHOD.
ENDCLASS.
 SOME INTERVIEW QUESTIONS :-
 HOW TO ACHIEVE PARAMTERSIED CDS VIEW ?
@AbapCatalog.sqlViewName: 'ZPARA2'
@EndUserText.label: 'PARAMETER'
define view ZSR_PARAMETRISED_CDS
with parameters P_CARRID : s_carr_id
as select from scarr as SC
{
key SC.carrid as AIRLINE,
SC.mandt as Mandt,
SC.carrid as Carrid,
SC.carrname as Carrname,
SC.currcode as Currcode,
SC.url as Url,
SC.flag as Flag
where SC.carrid = $parameters.P_CARRID
 HOW TO PASS DEFAULT VALUE FOR PARAMETER IN CDS VIEW ?
 We can only give session variables user, client, lang, system_date.
 HOW TO EXPOSE THE CDS DATA IN OPEN SQL :-
 CDS VIEW :-
@AbapCatalog.sqlViewName: 'ZPARA2'
@EndUserText.label: 'PARAMETER'
define view ZSR_PARAMETRISED_CDS
with parameters
as select from scarr as SC
{
key SC.carrid as AIRLINE,
SC.mandt as Mandt,
SC.carrid as Carrid,
SC.carrname as Carrname,
SC.currcode as Currcode,
SC.url as Url,
SC.flag as Flag
where SC.carrid = $parameters.P_CARRID
 REPORT PROGRAM :-
REPORT ZSR_EXPOSING_CDS_OPEN_SQL.
*data : lt TYPE TABLE OF ZSR_ASSOCIATION_ONE_TO_MANY.
select \_spfli-
connid as air_code FROM ZSR_ASSOCIATION_ONE_TO_MANY into TABLE @data(lt)
.
*select \__spfli-
connid FROM ZSR_ASSOCIATION_ONE_TO_MANY into TABLE @data(lt).
BREAK-POINT.
 What is the use of @semantics annotation ?
 Semantic annotation is the process of adding metadata or tags to content, such as text or
images, to provide additional context and meaning. Semantic annotation is used to make
it easier for machines to understand and interpret the content, and to improve the
accuracy of search results.
 What is the use of @enivronment annotation ?
 FOR ACCESSING DEFAULT VALUES LIKE SYSTEM

VARIBLE.

Full End To End Information On S/4 Hana Database

Uploaded by

Copyright:

Available Formats

Full End To End Information On S/4 Hana Database

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full End To End Information On S/4 Hana Database

Uploaded by

Copyright:

Available Formats

 FULL END TO END INFORMATION ON S/4 HANA DATABASE :-

 S/4 HANA DATBASE FOOTPRINT :-

 NORMAL R/3 DATABASE V/S HANA DATABASE SYSTEM .

1. In-Memory Computing: S/4HANA is built on an in-memory computing platform, which

 ROW STORAGE DISADAVNTGE:-

 HERE WE ARE ROW STORING , DATA WILL BE STORED IN ROW , IF

 HERE WE HAVE TO CREATE SECONDARY INDEX FOR SPEED UP

 THEN IF WANT SPEED UP THE READING PROCESS THAT STORE THE

 WE CAN’T DO AGGREATE FOR LARGE AMOUNT OF DATA.

 COLUMN STORAGE ADVANTGES TO OVERCOME THE

 IT WON’T ALLOW OR STORE DUPLICATES VALUES, IT WILL STORE

 WE CAN DO AGGREGATE FUNCTION WITH LARGE AMOUNT OF

 HERE READ PROCESS WILL BE FASTER , DON’T NEED TO READ

 NO NEED TO CREATE INDEX BECAUSE EVERY EACH COLUMN ARE

 IF WE MAKE CHANGES THE DATA , DATA WON’T BE SAVED IN

 WHILE READING DATA IF WE HAVE 2 SAME DATA WITH SAME

 CDS BASIC THINGS :-

Introduction to ABAP CDS Views - Go Coding

1. When we create View in HANA, it is sent to quality via a HTC (HANA

1. When we create a CDS view we create a CDS Data Definition.

 CDS CODE PUSH DOWN :-

 HOW TO USE CDS VIEW WITH OTHER ANNOTATIONS DIFFERENT

1) CODE TO DATA PARADIGM :-

3) SQL QUERY GENERATE :-

 IN CDS IF QUERY GENERTES IT WILL MOVE TO DB LAYER NOT OUR

10) BULILT- IN-FUNCTION :-

 WE CAN USE BUILT IN FUN WITH CDS LIKE UNION, INTERSCTION

 WE CAN CREATE PARAMETER WITH CDS VIEW.

 WE CAN USE SYSTEM VARIBLE LIKE $SESSION.USER TO KNOW

 DIFFERNCE BETWEEN CDS VIEW AND DDIC VIEW :-

 VDM A ND IT’S TYPES :-

There are two types of VDM in CDS:

 VDM AND IT’S SIZE :-

 Properties for Basic View:

 Properties of Composite View:

4) PRIVATE VIEW TYPE :-

 In SAP, a Core Data Services (CDS) view is a way to define and

 CDS is created for the purpose of its consumer:

FIORI Application (@UI Annotation).

 Note: S/4 HANA Embedded analytics and FIORI cannot consume

 CDS PRACTICLES PEOGRAMMS :-

 FIRST WE HAVE TO CREATE PROJECT AFTER 2 ANNOTATIONS GET

 1) CDS SQL VIEW , 2) CDS ENTITY .

 We can see in sap application our DDL .

LOOP AT LT INTO DATA(LS).

 INNER JOIN BETWEEN SALES ORDER INVOICE HEDER AND

 CDS VIEW WITH SELECT OPTION :-

 WE CAN’T WRITE SELECT-OPTION DIRECTLY IN CDS BUT WE CAN

DATA : LS TYPE MARA.

SELECT-OPTIONS:S_MATNR FOR LS-MATNR.

SELECT * FROM MARA INTO TABLE @DATA(LT) WHERE MATNR IN @S_MATNR.

LOOP AT LT INTO LS.

 BUFFERING IN CDS VIEW :-

 @AbapCatalog.buffering.status – #ACTIVE , #NOT_ALLOWED,

 @AbapCatalog.buffering.type- #FULL , #GENERIC , #NONE , #SINGLE

 @AbapCatalog.buffering.numberOfKeyFields – Relevant if the buffering

 PROGRAM WITH PARAMETER :-

where carrid = $parameters.FLIGHT_CODE

 WITH TWO PARAMETERS :-