在 SAP S/4HANA 项目里做 CDS 数据模型时，有一类问题很容易被低估。我们写好了一个 CDS View Entity，通过 Service Definition 暴露成 OData V4，再交给 SAP Fiori elements 做 List Report 或 Object Page。页面能打开，数据也能查出来，看起来整个链路已经跑通。可一旦把系统交给不同组织、不同公司代码、不同销售区域的业务人员，真正棘手的问题才出现。同一个 CDS Entity 返回的十万条销售订单，并不是所有登录用户都应该看到。销售组织 1010 的员工只能读取 1010 的订单，销售组织 2010 的员工只能读取 2010 的订单。审计人员可能需要跨公司读取数据，而普通业务人员不应该获得这样的权限。某些 CDS Entity 还包含 Business Partner、员工、银行账户等敏感信息，其中部分数据已经进入 End of Purpose 阶段，甚至已经处于 blocked 状态。如果把这些规则全部写进 ABAP 程序里的AUTHORITY-CHECK，整个设计很快会变得混乱。SAP CDS 提供了另一套机制，也就是 CDS Access Control。它使用 DCL，也就是 Data Control Language，把数据读取权限直接放到数据模型旁边声明。只要一个 CDS Entity 存在有效的 DCL Access Control，通过 ABAP SQL 读取这个 Entity 时，授权条件就可以被隐式加入查询过程，只返回当前用户允许看到的数据。SAP 官方文档把这种机制描述为 CDS 数据读取过程中的隐式限制，DCL 条件最终会参与数据库查询条件