Up to now, you have been reading from tables directly. SELECT from VBAK, SELECT from KNA1, join, process, display. That works — for reports. But modern SAP development does not work that way.

In S/4HANA, RAP, Fiori, and OData, data is not read from tables. It is read from CDS Views — Core Data Services Views. These are semantic data models that live in the database, describe business meaning, and can be consumed by both ABAP code and external systems like Fiori apps.

This is the chapter where you cross from classic ABAP into the modern world. From here on, everything you build — RAP business objects, Fiori apps, analytics — sits on top of CDS Views.

🎯 What You Will Learn in This Chapter

• What CDS Views are and why they matter in S/4HANA
• The difference between CDS Views and SE11 Views
• How to create a CDS View in Eclipse ADT
• The main annotation families and what they control
• What Associations are and how they differ from JOINs
• How to create Parameterized CDS Views
• What Access Control (DCL) is and how it enforces row-level security
• How to consume CDS Views in ABAP with Open SQL
• The difference between classic CDS View and modern CDS View Entity

📘 What is a CDS View?

CDS stands for Core Data Services. A CDS View is a data model definition written in SQL-like syntax that is compiled and executed directly on the SAP HANA database.

Think of it as a supercharged SQL view. It does everything a normal view does — selects, joins, filters — but adds:

• Calculations — arithmetic, string operations, case expressions
• Aggregations — SUM, AVG, COUNT, MIN, MAX
• Annotations — metadata that controls authorization, UI rendering, OData exposure
• Associations — declared relationships to other views
• Parameters — input values that filter the result at query time
• Semantics — built-in meaning for amounts, currencies, units, dates

⚖️ CDS View vs SE11 View — Why the Change?

You already learned about SE11 Views in Chapter 5. Why do we need something else?

🛠 Creating Your First CDS View

CDS Views are created in Eclipse ADT, not in SAP GUI.

A minimal CDS View

@AbapCatalog.sqlViewName: 'ZITRAVEL'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Travel Interface View'

define view ZI_Travel
  as select from /dmo/travel as Travel
{
  key Travel.travel_id       as TravelId,
      Travel.agency_id       as AgencyId,
      Travel.customer_id     as CustomerId,
      Travel.begin_date      as BeginDate,
      Travel.end_date        as EndDate,
      Travel.booking_fee     as BookingFee,
      Travel.total_price     as TotalPrice,
      Travel.currency_code   as CurrencyCode,
      Travel.status          as Status
}

A modern CDS View Entity (ABAP 7.55+)

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Travel Interface View'

define view entity ZI_Travel
  as select from /dmo/travel as Travel
{
  key Travel.travel_id       as TravelId,
      Travel.agency_id       as AgencyId,
      Travel.customer_id     as CustomerId,
      Travel.begin_date      as BeginDate,
      Travel.end_date        as EndDate,
      Travel.booking_fee     as BookingFee,
      Travel.total_price     as TotalPrice,
      Travel.currency_code   as CurrencyCode,
      Travel.status          as Status
}

🏷️ Annotations — The Metadata Layer

Annotations are declarations prefixed with @ that add meaning and behavior to a CDS View. They are what turns a plain data model into a semantic, service-ready definition.

The main annotation families

Practical example — a consumption view

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Travel Consumption View'
@UI.headerInfo: { typeName: 'Travel', typeNamePlural: 'Travels' }
@Metadata.allowExtensions: true

define view entity ZC_Travel
  as select from ZI_Travel
{
  @UI.lineItem: [{ position: 10 }]
  @UI.identification: [{ position: 10 }]
  key TravelId,

  @UI.lineItem: [{ position: 20 }]
  @UI.selectionField: [{ position: 20 }]
      AgencyId,

  @UI.lineItem: [{ position: 30 }]
      CustomerId,

  @UI.lineItem: [{ position: 40 }]
      BeginDate,

  @UI.lineItem: [{ position: 50 }]
      EndDate,

  @UI.lineItem: [{ position: 60 }]
  @Semantics.amount.currencyCode: 'CurrencyCode'
      TotalPrice,

      @Semantics.currencyCode: true
      CurrencyCode
}

🔗 Associations — Lazy Joins

An Association is a declared relationship between two CDS Views or between a CDS View and a table. It is like a JOIN — but better.

JOIN vs Association

Defining an Association

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Travel with Customer'

define view entity ZI_TravelWithCustomer
  as select from /dmo/travel as Travel
  association [0..1] to /dmo/customer as _Customer
    on Travel.customer_id = _Customer.customer_id
{
  key Travel.travel_id       as TravelId,
      Travel.customer_id     as CustomerId,
      Travel.total_price     as TotalPrice,

      // Expose the association
      _Customer
}

Using the Association in a path expression

@EndUserText.label: 'Travel with customer name'

define view entity ZI_TravelWithName
  as select from ZI_TravelWithCustomer
{
  key TravelId,
      CustomerId,

      // Path expression — navigates the association
      _Customer.first_name   as CustomerFirstName,
      _Customer.last_name    as CustomerLastName,

      TotalPrice
}

🎛️ Parameterized CDS Views

A CDS View can accept input parameters that are supplied at query time. This lets one view serve many scenarios — different dates, currencies, or scopes — without duplicating the model.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Travel by date range'

define view entity ZI_TravelByDate
  with parameters
    P_FromDate : abap.dats,
    P_ToDate   : abap.dats
  as select from /dmo/travel as Travel
{
  key Travel.travel_id       as TravelId,
      Travel.customer_id     as CustomerId,
      Travel.begin_date      as BeginDate,
      Travel.end_date        as EndDate
}
where Travel.begin_date >= :P_FromDate
  and Travel.end_date   <= :P_ToDate

🔒 Access Control (DCL) — Row-Level Security

A CDS View can be protected by a DCL (Data Control Language) file that defines row-level authorization. This means different users see different rows of the same view, based on their authorization roles.

The annotation that turns it on

@AccessControl.authorizationCheck: #CHECK

A simple DCL file

@EndUserText.label: 'Authorization for ZI_Travel'
@MappingRole: true

define role ZI_Travel {
  grant select on ZI_Travel

  where ( Travel.agency_id ) =
        aspect pfcg_auth ( S_AGENCY, ACTVT = '03' );
}

What this means: a user only sees rows where the agency_id matches what they are authorized for in their role (transaction PFCG).

📥 Consuming CDS Views in ABAP

Once a CDS View is created and activated, you consume it in ABAP just like a table:

" Read from a CDS View like a table
SELECT * FROM ZI_Travel
  INTO TABLE @DATA(lt_travel)
  WHERE CustomerId = @lv_customer_id.

LOOP AT lt_travel INTO DATA(ls_travel).
  WRITE: / ls_travel-TravelId, ls_travel-TotalPrice.
ENDLOOP.

" For parameterized views, use a WITH clause
SELECT * FROM ZI_TravelByDate(
    P_FromDate = @lv_from,
    P_ToDate   = @lv_to
  ) INTO TABLE @DATA(lt_travel_range).

📝 Chapter Summary

• CDS Views are semantic data models defined in ABAP and executed on the HANA database.
• They replace SE11 Views for modern development — supporting calculations, annotations, associations, parameters, and DCL.
• Two syntaxes: define view (classic) and define view entity (modern, recommended).
• Annotations add meaning and behavior: @AccessControl, @UI, @Semantics, @OData, etc.
• Associations are lazy joins — declared once, executed only when used via path expressions.
• Parameters make views reusable across scenarios.
• DCL enforces row-level authorization once, for all consumers.
• Consume CDS Views in ABAP with SELECT ... FROM ZI_..., just like a table.
• Everything modern — RAP, Fiori, OData, Analytics — sits on top of CDS Views.