DCLs are written using the DEFINE ROLE syntax and stored as authorization objects in the ABAP Dictionary.
They work in combination with authorization checks performed automatically at runtime by the ABAP system — when the CDS view is queried through ABAP, OData, or analytical tools.

Purpose of DCL

• To control access to data at the CDS view level (not in ABAP code).

• To ensure data security and compliance with organizational policies.

• To centralize authorization logic so it’s reusable and not hardcoded in multiple reports or services.

In simple terms:

DCL defines who can access what data in a CDS view.

How DCL Works

1. A CDS view is defined with an authorization check annotation:

   @AccessControl.authorizationCheck: #CHECK
   define view ZCDS_Employee as select from zemployee { … }

   2. A DCL (authorization rule) is created using DEFINE ROLE.

   It specifies the conditions under which a user can access the data At runtime, when a user executes the CDS view (via report, OData, or Fiori app),
   the system automatically filters data according to the DCL rule.

PFCG Authorization Object Link

The function aspect pfcg_auth('AUTH_OBJECT', 'FIELD') links the DCL to a PFCG (Profile Generator) authorization object.
This ensures integration between CDS-level security and SAP’s standard role-based security.

Example authorization object definition:

• Authorization object: ZEMP_AUTH_OBJ

• Field: DEPT

• Values assigned in user role (e.g., user only has DEPT = ‘HR’)

Then when user runs the view:

• They will only see rows where department = 'HR'.