CDS Views | Technical Training — David Ollero Montes

Interface View: technical access

The Interface layer (ZI_ prefix) models access to the database table and its associations, without UI annotations. It's the reusable layer consumed by any client.

ABAP CDSZI_CONTRACT_MANAGER.ddls

@AbapCatalog.sqlViewName: 'ZIVCONTRMGR'
@AccessControl.authorizationCheck: #CHECK
define root view entity ZI_CONTRACT_MANAGER
  as select from zcontract
{
  key contract_id  as ContractId,
      manager_1    as ContractManager1,
      manager_2    as ContractManager2,
      status       as Status,
      last_changed as LocalLastChangedAt,

      // association to the business partner entity
      association [0..1] to I_BusinessPartner as _Manager
        on $projection.ContractManager1 = _Manager.BusinessPartner
}

Consumption View: the exposed layer

The Consumption layer (ZC_ prefix) adds the @UI annotations that Fiori Elements needs to automatically generate lists, columns and filter fields — without writing an XML view by hand.

ABAP CDSZC_CONTRACT_MANAGER.ddls

@Metadata.allowExtensions: true
@UI.headerInfo: { typeName: 'Contract', typeNamePlural: 'Contracts' }
define root view entity ZC_CONTRACT_MANAGER
  as projection on ZI_CONTRACT_MANAGER
{
  @UI.lineItem: [{ position: 10, importance: #HIGH }]
  @UI.selectionField: [{ position: 10 }]
  key ContractId,

  @UI.lineItem: [{ position: 20 }]
  @UI.fieldGroup: [{ qualifier: 'Manager', position: 10 }]
  ContractManager1,

  Status,
  _Manager
}

The most common annotations

@UI.lineItem — shows the field as a column in the List Report table.
@UI.selectionField — turns it into a filter in the search bar.
@UI.identification — shows it in the Object Page header.
@Consumption.valueHelpDefinition — links a value help (F4) to a specific CDS.
@Semantics — marks fields with special meaning (currency, quantity, email...) so the UI formats them automatically.

Value Help: a CDS as a search-help source

Any CDS view can act as a value help for another field, providing a filterable list of values straight from the database.

ABAP CDSZI_VH_CONTRACT_MANAGER.ddls

@ObjectModel.usageType.serviceQuality: #X
@ObjectModel.usageType.sizeCategory: #S
@ObjectModel.usageType.dataClass: #MASTER
define view entity ZI_VH_CONTRACT_MANAGER
  as select from I_BusinessPartner
{
  key BusinessPartner  as Manager,
      BusinessPartnerFullName as ManagerName
}

Why the Interface/Consumption split matters: it lets you reuse the same data model for several consumers (a Fiori app, a report, an API) without duplicating selection logic — only the annotations of each exposure layer change.

Aggregation with analytical annotations

CDS pushes aggregation to the database too. A view can define analytical measures and dimensions so a Fiori chart or KPI card gets the totals calculated in HANA instead of summing rows in the frontend.

ABAP CDSZI_CONTRACT_AGGREGATION.ddls

@Analytics.query: true
define view entity ZI_CONTRACT_AGGREGATION
  as select from zcontract
{
      @Analytics.dimension: true
      manager_1                            as ContractManager1,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      amount                                as Amount,

      currency                              as Currency
}
group by manager_1, currency

Performance: pushing logic down

The whole point of CDS is to let HANA do the filtering, joining and aggregating instead of ABAP looping over internal tables row by row. A CDS view with associations and calculated fields typically outperforms an equivalent hand-written SELECT + ABAP loop by a wide margin on large datasets.

Rule of thumb: if you find yourself writing LOOP AT ... WHERE or nested loops to join data that could be joined in the view itself, that logic almost always belongs in the CDS view, not in ABAP.