SAP Core Data Services (CDS)

The source material provides an introductory overview of SAP Core Data Services (CDS), explaining why SAP developed this technology as a common, higher-level data model to be consumed across various technologies like OData and Business Intelligence. It defines CDS as a set of domain-specific languages (DDL, DQL, DCL) used for creating semantically rich data models that include extra metadata through annotations for applications like Fiori. The discussion also clarifies the distinction between ABAP CDS and HANA CDS, noting that the former is open-source and database-agnostic while the latter is native to the HANA database and developed by native HANA developers. Finally, the text highlights the key advantages of CDS over classical SAP views, such as supporting code pushdown, advanced join types, and the use of parameters and complex expressions.

Here’s a more detailed, “from‑scratch” view of SAP Core Data Services (CDS) — how it works, key building blocks, types of views, and how it's used in the SAP stack. Feel free to ask if you want deeper detail on any part (e.g. annotations, performance tuning, CDS in RAP, etc.).

1. Why CDS? The Motivation

Before CDS, SAP used classical views (in ABAP Dictionary) or SQL views, ABAP programs, and ad-hoc modeling in different layers. But this had drawbacks:

Business logic / calculations often lived in ABAP layer, causing more data traffic and less performance.
Multiple technologies (OData, BI, Fiori, etc.) each had their own way of defining models, leading to duplication or inconsistent models.
The emerging SAP HANA in-memory database allows pushing logic down (code pushdown) into the database — but to exploit it, we needed a unified, semantic modeling layer.

So SAP introduced CDS:

A higher-level, declarative way to define semantic data models centrally.
These models can be consumed by various technologies (OData, ABAP, UI5, analytics) without re-defining the logic everywhere.
Supports annotations, associations, parameters, and richer expressions compared to classical views.
(SAP Community)
It also enables code pushdown: complex logic is executed in the database rather than in the application server, reducing data transfer and improving performance. (SAP Community)

2. ABAP CDS vs HANA CDS — Two “Flavors”

One of the distinctions you already saw is between ABAP CDS and HANA CDS. Here’s a clearer comparison:

Feature / Aspect	ABAP CDS	HANA CDS
Where defined / repository	Defined in the ABAP layer, stored in ABAP repository (via ADT / Eclipse) (SAP Help Portal)	Defined natively in HANA (using HANA tools)
Database independence	More database-agnostic: Translators generate the proper SQL or view layers so ABAP CDS can run on various DBs (though HANA gives best performance) (SAP Help Portal)	Tightly tied to HANA; can use HANA-specific features
Consumption by ABAP	Can be consumed by Open SQL, ABAP code, OData, Fiori, etc. (SAP Community)	Primarily used for native HANA apps / analytics
Use of HANA-specific features	More restricted (to keep portability)	Full access to HANA-specific optimizations, features
Typical use case in S/4HANA / ABAP world	The dominant CDS used in SAP S/4 and embedded analytics	More common in HANA-native scenarios or side-by-side HANA developments

In S/4HANA and the ABAP world, ABAP CDS is what you’ll use almost always for modeling data for applications, analytics, and OData services. (SAP Learning)

3. CDS Architecture & Layers

Let’s look at how CDS fits into the SAP stack and how data flows. The diagrams above help illustrate this.

High-level Layers

Database Layer
- Under the hood, when you activate a CDS view, it generates a SQL view in the database (especially in HANA) that implements the logic. (SAP Learning)
- In HANA, the SQL optimizer executes the view logic (filtering, joins, aggregations) natively.
Application / ABAP Layer
- The ABAP server (AS ABAP) hosts CDS artifacts (in repository), and acts as the execution environment for ABAP programs.
- ABAP CDS views are executed via Open SQL; the query is translated to the generated view in the DB. (SAP Help Portal)
- The Gateway or OData framework can expose CDS views as OData services. (SAP Community)
Presentation / UI Layer
- Fiori / SAP UI5 apps, analytical UIs, BI tools consume data via OData or via the ABAP layer.
- The semantic metadata (annotations) in CDS helps drive UI behavior (labels, semantics, etc.).

Thus the flow is:

[UI / Fiori] ← OData / UI interface → [ABAP / Gateway] → CDS View → Generated SQL View in DB → Tables / Joins in the DB

When you look at a deeper “virtual data model” (VDM) in S/4, you often see basic, composite, and consumption views stacked (we’ll get to that).

4. Key Concepts in CDS

To effectively use CDS, you need to understand these core constructs:

4.1 Annotations

Annotations are metadata you attach to a CDS entity, field, parameter, etc. They start with @.
Annotations help frameworks (UI, OData, analytics) understand how to treat the fields (e.g. labels, grouping, filterable, behavior, etc.).
Example: @AbapCatalog.sqlViewName: 'ZC_MYVIEW' gives the name of the generated SQL view.
Another example: @UI.headerInfo, @AnalyticsDetails etc., guiding UI or analytics behavior. (SAP Community)
You can also use annotations to define input parameters, access control checks, etc.

4.2 Associations

Associations are like semantic relationships (akin to foreign key relationships), used to link CDS entities.
They let you navigate (“path expressions”) instead of writing explicit joins everywhere.
E.g. you can write something like employee.address.zipcode using associations under the hood.
This simplifies code and makes models more intuitive. (SAP Community)

4.3 Parameters & Input Parameters

CDS views can have input parameters, so the consumer can pass in values (e.g. a company code, date, etc.).
These parameters are used in the where clause or logic inside CDS.
Annotations can also define parameter behavior (e.g. default values). (SAP Community)

4.4 Table Functions, Projection Views, etc.

Projection View — A CDS view derived from another CDS view(s), often used to adapt a view for a certain use case. (SAP Help Portal)
Table Function — A CDS entity backed by an AMDP (ABAP Managed Database Procedure) for more complex logic not easily expressed in CDS. Returns a tabular result. (SAP Help Portal)
Hierarchies, Custom Entities, Abstract Entities — other advanced constructs in CDS. (SAP Help Portal)

4.5 Access Control (DCL)

CDS supports declarative access control using DCL (Data Control Language).
You define CDS roles and restrict access to fields/rows based on conditions.
When a CDS view has a CDS role, the access logic is evaluated automatically. (SAP Help Portal)

5. Virtual Data Model (VDM) — Basic / Composite / Consumption Views

In many SAP S/4 systems, the CDS modeling strategy uses a layered approach:

Basic Views (or “Base Views”)
- Directly reflect base tables (or simple join of base tables).
- They expose atomic elements (fields) and associations.
- They don’t usually include end-consumption logic (filtering, UI-specific stuff).
Composite Views
- Combine basic views, apply more complex logic, and form more business-level models (e.g. linking several base views).
- Use associations, path expressions, etc.
Consumption Views
- The final layer used by UIs, OData, reports, etc.
- They may restrict or expose only certain fields, apply annotations specific to UI, and often are published as OData services.
- You annotate them for UI behavior, OData exposure, etc.

This layered approach helps in reusability and separating domain logic from UI logic.

In many diagrams you see arrows from basic → composite → consumption, and from consumption to OData / UI / analytic tools. The diagram from Bilink Solutions (above) shows that clearly.

6. Example CDS View (Simple)

Here’s a simplified sample of a CDS view:

@AbapCatalog.sqlViewName: 'ZC_MYVIEW'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'My CDS View'

DEFINE VIEW ZC_MyView
  WITH PARAMETERS
    p_companycode : bukrs
  AS SELECT FROM sbook AS sb
  INNER JOIN scarr AS sc ON sb~carrid = sc~carrid
{
  key sb~carrid        AS CarrierID,
  key sb~connid        AS ConnectionID,
  sb~fldate            AS FlightDate,
  sb~seatsmax          AS SeatsMax,
  sc~carrname          AS CarrierName
}
WHERE sb~carrid = :p_companycode

Here @AbapCatalog.sqlViewName defines the name of underlying SQL view.
WITH PARAMETERS p_companycode allows filtering input.
Then from base tables sbook and scarr we select fields and join.
You could add further annotations for UI, filters, etc.

7. Lifecycle, Activation & Query Execution

When you activate the CDS definition, SAP generates underlying SQL views or database objects (depending on DB) that implement the logic.
At runtime, if an ABAP program or OData request calls the CDS view:
1. The consumer issues a request (for example via Open SQL or via OData to a service defined over CDS).
2. The ABAP/CDS framework translates the request into a SQL query over the generated SQL view.
3. The database executes the query (filters, aggregations, joins, etc.) and returns results.
4. The ABAP / UI layer receives the result and presents it.

Because much logic is executed in the database, you get better performance (especially with HANA).

8. Advantages of CDS Over Classical Views

You already listed many, but to restate and expand:

Code pushdown — logic in DB, not in ABAP loops.
Rich expressions — functions, aggregations, case statements, window functions etc.
Associations / path expressions — simpler navigation between entities instead of verbose joins.
Annotations / metadata — drive UI, OData, analytics without separate mapping.
Reusability & modularity — you can layer views (basic, composite, consumption).
Extensibility — standard or SAP-provided CDS views can be extended.
Access control built in — with DCL and CDS roles.
Parameter support — input parameters etc.
Support for complex joins / unions, advanced join types etc.

9. When & Where to Use CDS

In S/4HANA and modern ABAP development (especially with Fiori/UIs), CDS is the default way to model data for consumption.
Use CDS views as the data foundation for OData services for SAP UI5 / Fiori.
Use composite / consumption CDS views for analytics and reporting.
Use table functions (CDS + AMDP) when you need logic not easily expressed in CDS.
Use DCL to secure sensitive data access at the view level.

If you like, I can send you a step‑by‑step tutorial (with sample code) starting from zero to build a CDS model, annotate it for Fiori, and expose it as OData. Would you prefer that?

Search This Blog

SAP Learnings