DCL and Analytical Annotations

Explanation

DCL (Data Control Language) applies row-level authorisation checks to CDS views based on authorisation objects. @Analytics.dataCategory marks a view as CUBE/DIMENSION/FACT; @Aggregation.default sets aggregation behaviour. Together they power embedded analytics and KPIs without extra coding.

Code example

@EndUserText.label: 'Sales by Company Code'@Analytics.query: truedefine view entity ZQ_SalesByBukrs as select from ZI_SalesHeader {  bukrs,  @Aggregation.default: #SUM  netwr} group by bukrs

Real project scenario

A CFO KPI tile was delivered in a day using an analytical CDS view + a smart chart Fiori tile — no ALV, no ABAP.

Common mistakes

Skipping DCL and relying on ABAP checks in RAP; over-aggregation hiding drill-down; naming clashes between annotations and fields.

Best practices

Enforce authorisation with DCL; keep analytics annotations in consumption layer; measure impact with SAT before wide rollout.

Interview angle

What is the difference between #NOT_ALLOWED and #NOT_REQUIRED in @Analytics.aggregation?