在一个采用 RAP 构建的 SAP S/4HANA 业务对象里，我们经常会看到这样一种 CDS 结构。底层有持久化表，中间有 Interface View 或 Root View Entity，上面又覆盖了一层 Projection View，最外面再通过 Service Definition 和 Service Binding 暴露成 OData V4 服务。刚开始接触 RAP 时，很容易产生一个疑问，既然底层的 CDS View Entity 已经把字段、Association、Composition 甚至 Behavior 都定义好了，为什么还要再建立一层 Projection View。答案藏在 Projection 这个词里。Projection View 并不是为了重新建立一套数据模型，而是为了从已有的数据模型中选择、调整并暴露某个具体消费场景所需要的那一部分能力。SAP 官方把 CDS Projection View 定义为一种特殊的 CDS View Entity，它建立在另一个 View Entity 之上，通常位于 CDS 数据模型最上层，也就是常说的 Consumption Layer。它的工作重点不是重新访问数据库表，而是针对某一个服务、某一类消费者或者某一种分析场景，对已有的数据模型进行适配。这也是理解 Projection View 最关键的一点。它不是数据模型的另一个复制品，而更接近数据模型面对外部消费者时的一张受控窗口。假设我们的 RAP Business Object 在底层维护销售订单，内部模型可能包含销售订单编号、销售组织、客户、信用状态、内部审批状态、技术 UUID、创建时间、修改时间以及几十个只供内部流
从 RAP 消费层到稳定接口，深入理解 ABAP CDS Projection View 的定义机制与 Provider Contract
在一个采用 RAP 构建的 SAP S/4HANA 业务对象里，我们经常会看到这样一种 CDS 结构。底层有持久化表，中间有 Interface View 或 Root View Entity，上面又覆盖了一层 Projection View，最外面再通过 Service Definition 和 Service Binding 暴露成 OData V4 服务。刚开始接触 RAP 时，很容易产生一个疑问，既然底层的 CDS View Entity 已经把字段、Association、Composition 甚至 Behavior 都定义好了，为什么还要再建立一层 Projection View。答案藏在 Projection 这个词里。Projection View 并不是为了重新建立一套数据模型，而是为了从已有的数据模型中选择、调整并暴露某个具体消费场景所需要的那一部分能力。SAP 官方把 CDS Projection View 定义为一种特殊的 CDS View Entity，它建立在另一个 View Entity 之上，通常位于 CDS 数据模型最上层，也就是常说的 Consumption Layer。它的工作重点不是重新访问数据库表，而是针对某一个服务、某一类消费者或者某一种分析场景，对已有的数据模型进行适配。这也是理解 Projection View 最关键的一点。它不是数据模型的另一个复制品，而更接近数据模型面对外部消费者时的一张受控窗口。假设我们的 RAP Business Object 在底层维护销售订单，内部模型可能包含销售订单编号、销售组织、客户、信用状态、内部审批状态、技术 UUID、创建时间、修改时间以及几十个只供内部流