在 SAP S/4HANA 项目里，经常会遇到一个看起来很简单、实际上会直接影响未来升级成本的问题。SAP 已经交付了一套 CDS 数据模型，业务团队又希望增加企业自己的字段，例如销售订单上的渠道分类、财务凭证上的内部分析维度、采购订单上的供应商评级，或者在一个标准业务对象旁边增加新的关联实体。早期 ABAP 开发里，很自然的做法往往是修改标准对象，或者复制一个标准对象到Z命名空间再继续开发。短期来看开发速度很快，到了 SAP S/4HANA 升级、Feature Pack 更新甚至从 On-Premise 向 Private Cloud 迁移时，这些修改就会逐渐变成技术债。标准模型一旦发生变化，SPAU、SPDD、兼容性分析以及大量回归测试都会跟着出现。CDS Extensibility 解决的正是这个问题。SAP 允许由自己交付的 CDS entity，也允许合作伙伴或者客户开发的 CDS entity，预先声明一组稳定的 extension points。扩展方不需要修改原来的 CDS 定义，而是通过独立的 CDS entity extension 增加字段、association，甚至在 RAP 场景中继续扩展 behavior、composition 与 service。SAP 官方将这种方式定位为 upgrade-safe、lifecycle-stable 的扩展机制，它也是 ABAP Cloud 与 Clean Core 开发模型中的重要基础。这里最容易产生的误解，是把 CDS Extensibility 理解成一条语法。看到extend 深入理解 SAP ABAP CDS Extensibility，从可扩展数据模型到 Clean Core 稳定扩展契约
在 SAP S/4HANA 项目里，经常会遇到一个看起来很简单、实际上会直接影响未来升级成本的问题。SAP 已经交付了一套 CDS 数据模型，业务团队又希望增加企业自己的字段，例如销售订单上的渠道分类、财务凭证上的内部分析维度、采购订单上的供应商评级，或者在一个标准业务对象旁边增加新的关联实体。早期 ABAP 开发里，很自然的做法往往是修改标准对象，或者复制一个标准对象到Z命名空间再继续开发。短期来看开发速度很快，到了 SAP S/4HANA 升级、Feature Pack 更新甚至从 On-Premise 向 Private Cloud 迁移时，这些修改就会逐渐变成技术债。标准模型一旦发生变化，SPAU、SPDD、兼容性分析以及大量回归测试都会跟着出现。CDS Extensibility 解决的正是这个问题。SAP 允许由自己交付的 CDS entity，也允许合作伙伴或者客户开发的 CDS entity，预先声明一组稳定的 extension points。扩展方不需要修改原来的 CDS 定义，而是通过独立的 CDS entity extension 增加字段、association，甚至在 RAP 场景中继续扩展 behavior、composition 与 service。SAP 官方将这种方式定位为 upgrade-safe、lifecycle-stable 的扩展机制，它也是 ABAP Cloud 与 Clean Core 开发模型中的重要基础。这里最容易产生的误解，是把 CDS Extensibility 理解成一条语法。看到extend RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
