Explain CDS Views (Core Data Services) in SAP

32 / 65

S/4HANAintermediate

CDS Views (Core Data Services)

SAP's semantically rich, database-agnostic-yet-HANA-optimized view definition layer underlying modern ABAP and Fiori apps.

CDS views are arguably the single most-asked S/4HANA technical topic in interviews today because they sit at the intersection of everything modern: they power Fiori Elements UIs, expose OData services, drive analytics, and represent SAP's push toward code-to-data pushdown - so a candidate's depth on this topic is a reasonable proxy for how current their S/4HANA skills actually are.

A CDS view is like a well-labeled database blueprint rather than a plain floor plan - it doesn't just show you the rooms (columns) and how they connect (joins/associations), it also labels which room is the kitchen versus the bathroom (semantic annotations) so any visitor (consuming app) automatically knows how to behave in each one without being told individually every time.

Key Concepts

A CDS view is defined in ABAP Development Tools (Eclipse) using a declarative DDL-like syntax (DEFINE VIEW ENTITY ... AS SELECT FROM ...), compiled into a database view, and enriched with annotations that add semantic meaning far beyond a plain SQL view - @ObjectModel annotations mark entities as fully computed, @Semantics annotations flag currency/amount/quantity fields so consuming tools automatically know to combine an amount field with its currency unit field, and associations (ASSOCIATION TO ...) declare navigable relationships to other CDS entities without manually writing JOIN syntax at the consuming layer.

DEFINE VIEW ENTITY ... AS SELECT FROM ...@ObjectModel@SemanticsASSOCIATION TO ...

SAP layers CDS views by convention: basic/interface views (I_ prefix) provide a clean, reusable, unfiltered projection over one or more DDIC tables; composite views (C_ prefix) combine and enrich multiple interface views with business logic and associations; and consumption views (C_ for analytics or the OData-exposed layer, often generated as @OData.publish: true or via a service definition/service binding) are what Fiori apps or external consumers actually query. Virtual data model best practice strongly discourages consuming a basic/interface view directly from a Fiori app - always go through the composite/consumption layer so the interface layer can be reused and evolve independently.

I_C_@OData.publish: true

A senior-level answer covers CDS extend views (adding fields to an existing CDS view without modifying its source, the CDS equivalent of an append structure, crucial for upgrade-safe customer extensions), the different CDS view categories one should recognize (basic, composite, consumption, and also value-help/text views for F4 dropdown behavior), and how CDS views support code pushdown for analytics - aggregating and filtering millions of rows inside HANA rather than pulling raw data into the ABAP application server, which is a direct, measurable performance and infrastructure-cost benefit worth calling out explicitly.