DCL Authorization and Access Control

Explanation

DCL, or Data Control Language, is used to define access control for CDS views. It helps restrict data at row level based on authorization conditions. In enterprise systems, CDS views may expose sensitive financial, HR, customer or pricing data. Without proper authorization, a Fiori app or OData service can expose more data than intended. CDS access control is especially important for consumption views used in UI and analytics. Developers must know whether access control is required, how it is applied and how to test it with different users.

Code example

// CDS view with authorization check enabled.@AccessControl.authorizationCheck: #CHECK@EndUserText.label: 'Sales Order Secure View'define view entity ZC_SalesOrderSecure as select from ZI_SalesOrderBasic{ key SalesOrder, SalesOrganization, CreatedOn} // Example DCL concept:// Define role ZR_SalesOrderSecure {// grant select on ZC_SalesOrderSecure// where SalesOrganization = aspect pfcg_auth( ... );// } // Purpose:// DCL restricts rows returned to the consumer.// This is critical when CDS is exposed to Fiori/OData/analytics.

Real project scenario

A sales analytics CDS initially showed all sales organizations to every user. Adding DCL restricted data based on authorized sales organization and fixed a security issue before go-live.

Common mistakes

- Exposing CDS without access control review. - Assuming frontend authorization is enough. - Using #NOT_REQUIRED without security approval. - Not testing with restricted users.

Best practices

- Review security requirement for every consumption view. - Use DCL where row-level control is required. - Test with realistic restricted users. - Avoid exposing sensitive fields unnecessarily.

Interview angle

Senior candidates should explain DCL, @AccessControl.authorizationCheck and row-level security.