在 SAP S/4HANA Cloud 或者采用 ABAP Cloud 开发模型的项目里，我们经常会遇到这样一个场景。某个 RAP Business Object 已经开发完成，底层有 CDS View Entity，中间有 Interface View 和 Transactional View，上层还有 Projection View、Behavior Definition 以及 Service Definition。功能跑得很好，OData V4 服务也能够正常消费，可一旦准备把其中某个 CDS Entity 作为正式扩展点开放出去，并给它增加Extend C0release contract，一系列此前没有出现过的问题就会集中暴露出来。这时会发现，能够执行extend view entity，和能够把一个 CDS Entity 当成长期稳定的扩展 API 对外发布，其实是两件完全不同的事情。SAP 对 CDS Extensibility 的设计思路非常明确。扩展能力不能只是一个语法层面的开关，而应当成为 API Provider 主动设计出来的一份稳定契约。哪些地方允许增加字段，扩展字段采用什么命名规则，可以引用哪些数据源，最多能增加多少字段，扩展能够占用多少字节，是否允许引入新的 Association，甚至是否允许给整个 RAP Business Object 增加新的 Child Node，这些内容都应该由原始模型的提供者提前定义。这就是 Extensibility Enablement 真正解决的问题。从Extend C0 把扩展能力做成稳定契约，深入理解 ABAP CDS Extensibility Enablement 与 C0 发布
在 SAP S/4HANA Cloud 或者采用 ABAP Cloud 开发模型的项目里，我们经常会遇到这样一个场景。某个 RAP Business Object 已经开发完成，底层有 CDS View Entity，中间有 Interface View 和 Transactional View，上层还有 Projection View、Behavior Definition 以及 Service Definition。功能跑得很好，OData V4 服务也能够正常消费，可一旦准备把其中某个 CDS Entity 作为正式扩展点开放出去，并给它增加Extend C0release contract，一系列此前没有出现过的问题就会集中暴露出来。这时会发现，能够执行extend view entity，和能够把一个 CDS Entity 当成长期稳定的扩展 API 对外发布，其实是两件完全不同的事情。SAP 对 CDS Extensibility 的设计思路非常明确。扩展能力不能只是一个语法层面的开关，而应当成为 API Provider 主动设计出来的一份稳定契约。哪些地方允许增加字段，扩展字段采用什么命名规则，可以引用哪些数据源，最多能增加多少字段，扩展能够占用多少字节，是否允许引入新的 Association，甚至是否允许给整个 RAP Business Object 增加新的 Child Node，这些内容都应该由原始模型的提供者提前定义。这就是 Extensibility Enablement 真正解决的问题。从Extend C0 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
