CDS access control (DCL)

In the Clean Core model, authorization moves *into* the data model. Instead of scattering AUTHORITY-CHECK statements through ABAP, you declare a Data Control Language (DCL) role — a separate object linked to a CDS view — that constrains which rows a user may read. The view becomes self-protecting: any consumer, whether Open SQL, OData or analytics, inherits the row-level filter automatically.

A DCL role reads `define role ... { grant select on <view> where ( field ) = aspect pfcg_auth( ... ) }`. The `aspect pfcg_auth` clause maps a view field to a classic PFCG authorization object and its fields, so the user's existing authorizations decide which rows pass. For example, granting select where `( companycode ) = aspect pfcg_auth( s_tcode, bukrs, actvt = '03' )` lets a user read only the company codes their authorization permits, with activity 03 (display).

The toggle that wires it together is the view annotation `@AccessControl.authorizationCheck`. Set to `#CHECK`, the view *requires* a matching DCL role — activation succeeds, but the first access errors at runtime if no role exists. Set to `#NOT_REQUIRED`, DCL is skipped entirely, which is appropriate for views you want readable from internal RAP queries that are not end-user-facing. Choosing the wrong value is a classic trap: `#CHECK` with no DCL compiles cleanly and fails only when someone reads the view.

ABAP@EndUserText.label: 'Auth for Orders'
@MappingRole: true
define role ZI_OrderHeader_DCL {
  grant select on ZI_OrderHeader
    where ( CompanyCode ) = aspect pfcg_auth ( S_TCODE,
                                               BUKRS,
                                               ACTVT = '03' );
}

Source notes: clean-core-curriculum §6.5