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.

A CDS view looks like a database view and carries far more information than one. That extra information is why it sits under Fiori, OData and analytics in S/4HANA.

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

    define view entity I_SalesOrder as select from vbak
      association [0..1] to I_Customer as _Customer
        on $projection.CustomerId = _Customer.CustomerId
    {
      key vbeln as SalesOrder,
          kunnr as CustomerId,
          @Semantics.amount.currencyCode: 'Currency'
          netwr as NetAmount,
          waerk as Currency,
          _Customer
    }

Annotations are the difference from a SQL view. @Semantics.amount.currencyCode tells every consumer that this amount belongs with that currency field — so a Fiori list formats it correctly and an analytical tool refuses to sum amounts in different currencies.

@Semantics.amount.currencyCode

A plain database view is a set of columns. A CDS view carries what the columns mean.

Associations replace repeated joins. The association is declared once, and consumers navigate it:

    select from I_SalesOrder { SalesOrder, _Customer.CustomerName }

The join is generated only if the field is actually used. Declare ten associations and select from one, and nine joins never run — which is not true of a view with ten joins written in.

The layered virtual data model. SAP's convention:

    I_*   interface / basic   a clean projection over tables.
                              Reusable, stable, no business logic.
    C_*   consumption         what an app or an OData service queries
    P_*   private             internal, not for reuse

The rule that matters: do not consume I_ views directly from an app. Go through a consumption view.

The reason is change. The interface layer is meant to be reused by many consumers and to evolve; a consumption view is owned by one app and can be tailored to it. Bind an app directly to the interface layer and every consumer is coupled to every other one's requirements.

Extending a view without modifying it. The CDS equivalent of an append structure:

    extend view entity I_SalesOrder with ZSalesOrderExt
      { zz_project_code }

Your fields live in your own object, so an upgrade replacing SAP's view does not collide with them. This is the upgrade-safe way to add fields, and it is the same principle as everywhere else in SAP.

Code pushdown is the performance argument. A CDS view with grouping and aggregation runs inside HANA. The application server receives the aggregated rows.

    old way   select 4 million rows into an internal table, loop, sum
    CDS       HANA aggregates; ABAP receives 40 rows

That is a difference in memory, network and time, and it is the whole point of "code to data" rather than data to code.

What the interviewer is probing.1. "Why are CDS views preferred over database views or ABAP selects?" Probing: the architectural reason. Stalls: "They are newer." Moves up: they push logic to the database, carry semantic annotations that drive Fiori and analytics, and are transportable repository objects.

2. "What is the layered CDS model?" Probing: the design pattern. Stalls: "One view." *Moves up:* basic interface views over tables, composite views for reusable logic, and consumption views exposing a specific application — which keeps reuse possible.

3. "What is an association versus a join?" Probing: the key concept. Stalls: "The same." Moves up: an association is evaluated only if the consumer uses its fields, so it does not cost anything when unused — a join always executes.

4. "What do annotations actually do?" Probing: the mechanism. Stalls: "Documentation." Moves up: they drive generated behaviour — OData exposure, Fiori elements layout, analytics semantics and authorisation checks.