笔者过去的文章，曾经介绍过 SAP 产品 Field Extensibility 的设计和实现原理。
SAP 产品的 Field Extensibility(字段级扩展)
企业管理软件领域对标准功能的可扩展性支持，从技术实现层面，可以分为字段级扩展(Field Extensibilty)和流程级扩展(Process Extensibility)两个类别。
笔者过去在 SAP Business By Design 和 SAP Business Suite CRM 开发团队工作时，对这两个领域有过深入研究。
字段级扩展包括但不限于对底层数据模型，以及各个中间交互层之间传输对象(Transfer Object)的扩展。从最终用户的视角出发，即用户能使用 SAP 提供的工具，在软件界面上添加标准功能缺失的字段，这些字段往往是客户业务流程中必需的字段。
当客户发现 SAP 标准软件的功能，即使通过配置，也无法完全适配其企业流程的一些特殊业务需求时，可以考虑流程级扩展。流程级扩展技术实现多种多样，比如 ABAP 平台提供的各种 Exits，BAdI Enhancement，工作流和一些 BPM 解决方案。
在实际项目实施中，这两种类别的扩展方式往往交织在一起。比如在销售订单这个 Business Object 上创建一个扩展字段，同时希望该扩展字段维护的输入值，自动传输到销售订单对应的发票单据的同名扩展字段值去。这个过程就既包含了两个 BO 模型的字段级扩展，又包含了 BO 之间扩展字段值拷贝的流程级扩展。
SAP 官网针对 SAP S/4HANA 这个旗舰级产品，给出了另一个维度的 Extensibility 分类，总共包含五种扩展方式。
https://help.sap.com/docs/ABAP_PLATFORM_NEW/b5670aaaa2364a29935f40b16499972d/82dc267d4b0b4b309b40c22f700fe5c2.html
下面是这些扩展方式的逐一介绍。
Classic Extensibility - 经典扩展方式
过去几十年间 SAP 最传统最成功的二次开发方式，也是国内 SAP 从业者最熟悉的扩展方式，适用于基于 ABAP 技术栈的 SAP On-Premise 产品。
这种方式的优点是客户和合作伙伴可以重用 SAP 系统里所有 ABAP 对象，这给开发人员提供了极大的灵活性和选择权。
不足之处在于，如果开发人员没有遵循所谓`升级安全`的最佳实践来进行二次开发，则 SAP 标准系统升级时，可能会导致正常运行的扩展开发代码出现问题。
因此对于一个包含了大量二次开发代码的 SAP 系统来说，升级是一件需要提前和仔细规划的重要事项。升级过程中需要预估足够的可能会重构代码的工作量，升级后需要安排回归测试确保二次开发代码仍然继续工作。
这些高昂的代价通常是很多 On-Premise 客户推迟升级的原因之一。
Key User Extensibility - 关键用户扩展方式
关键用户通过 SAP 提供的专门工具，进行自定义应用程序及其 UI、Report、Email 模板，工作流模版，表单模版等应用界面载体的创建。
Key User Extensibility 也可以看作是一种低代码解决方案，因为关键用户不需要具备太多的传统编程知识，无需深入 SAP 产品底层的编码实现细节。
关键用户通常对业务流程和配置有深入的了解，同时也熟悉 SAP 产品里的模型和工具使用方法。
同第一种经典扩展方式相比，Key User Extensibility 具有较低的学习曲线，同时不用担心通过 Key User 工具创建的扩展，在系统升级后会出问题，因为扩展的兼容性已经由工具本身来保证。
不过 Key User 扩展方式也有使用前提，即期望被扩展的应用，已经被 SAP 标记为 Extensible(可扩展)。
从 Key User 视角来看，在浏览器里打开 Key User 工具，通过工具提供的向导创建出扩展字段，这个丝滑的过程不过是几分钟的事情。但是为了让这个屏幕支持通过工具扩展，这背后通常需要 SAP 多个产品开发部门做出努力和交付。
笔者在 SAP CRM 开发团队工作时，就曾经完成过一个开发任务：让一个 CRM 应用能够通过浏览器运行 Key User Tool 的方式被扩展。当用户对屏幕增强后，SAP 需要针对客户在 Key User Tool 里指定的增强信息，在底层存储模型和各个中间交互层，生成相应的对象和控制逻辑，并让所有这一切协同工作(Orchestration).
当时我写了两篇博客来介绍里面的一些设计原理，发布在 SAP 社区上：
step by step to enable your Genil component with AET - Part One：
https://community.sap.com/t5/crm-and-cx-blogs-by-sap/step-by-step-to-enable-your-genil-component-with-aet-part-one/ba-p/13005059
step by step to enable your Genil component with AET - Part Two：
https://community.sap.com/t5/crm-and-cx-blogs-by-sap/step-by-step-to-enable-your-genil-component-with-aet-part-two/ba-p/13005414
Developer Extensibility - 开发者扩展方式
开发者扩展同本文开头提到的经典扩展方式最大的区别，就在于其只能使用 SAP 标记为 Released 的那一部分开发对象。
我们使用 ABAP Development Tool 登录 SAP BTP ABAP 编程环境，就可以在 Project Explorer 下的 Released Objects 文件夹里，查看这些可用对象的全部列表。
开启 Developer Extensibility 的第一步，就是使用 ABAP 报表 RSMAINTAIN_SWCOMPONENTS 创建一个新的 Software Component，并且将其基于的 ABAP 版本标注为 `ABAP for Cloud`：
基于 Software Component 可以创建 ABAP 开发包，后者用于存储 ABAP 开发对象。
在 ABAP Cloud 的世界里，每个 ABAP 对象多了一个新属性：ABAP Language Version.
该属性有三个可选值：
Standard ABAP
ABAP for Key User
ABAP for Cloud Development
本公众号后续会详细介绍这三种版本的 ABAP 的区别。
Developer Extensibility 是针对 Key User 扩展模型局限性的一种强有力的补充。因为在二次开发中仅能使用 SAP Released 的 ABAP 对象，所以这种扩展方式也不用担心升级问题。
Side-by-Side Extensibility - 并行可扩展方式
该扩展方式依托于 SAP BTP，区别于前三种扩展方式最大的特色，就是这种方式构建出的是与 SAP S/4HANA 无缝集成但却松散耦合(Loose Coupling)的扩展。
Side-by-Side Extensibility 通过 SAP 发布的 Stable API 和 Business Event 与 SAP S/4HANA 交互，但在技术和生命周期管理层面，均独立于 SAP S/4HANA 这个核心系统。
这种扩展方法使得客户和合作伙伴在不直接增强 SAP S/4HANA 核心系统的情况下实现定制化功能，从而保持核心系统的稳定性和持续可升级性。
因其开发方式完全独立于 SAP S/4HANA 核心系统并行开展，估得名 Side-by-Side Extensibility.
采用 Side-by-Side Extensibility 扩展方式的收益：
保持 SAP S/4HANA 的 Clean Core：通过在核心系统之外进行扩展，避免了对标准 SAP S/4HANA 系统的直接增强，减少了系统升级和维护的复杂性。 灵活性和可扩展性：开发人员可以根据实际情况，选择多种编程语言如 ABAP、Java、JavaScript、Python 等在 SAP BTP 上构建扩展，满足不同的业务需求。 独立的生命周期管理：扩展应用程序的开发、部署和更新完全独立于 SAP S/4HANA 进行，与核心系统接触了耦合关系。 充分利用云平台优势：SAP BTP 提供了丰富的服务和工具，避免重复造轮子，也减少了寻找第三方解决方案的技术复杂性和实施工作量。
Cloud-Ready Extensibility Options: All in One
在具有一定复杂度的实施项目中，几乎不太可能仅使用单一的扩展方式——因此有了第五个扩展概念：云端就绪的多合一扩展方案。
如下图所示，这种方案混合了 Key User 扩展，Developer 扩展和 SAP BTP 上的 Side-by-Side 扩展。分散部署的 Side-by-Side 解决方案通过 Remote API 同 SAP S/4HANA 系统上的其他扩展进行通信。
这些不同的扩展方案，各自的使用场合是什么？
SAP 官网帮助文档上有一张图。这里简单做一个总结。
Classic Extensibility 适用于需要进行高复杂度的定制开发场景，扩展开发与 SAP 标准功能之间不存在可供使用的稳定接口。这种情况下只能使用 Classic Extensibility 的紧耦合开发方式。
Key User Extensibility 通常用于解决`最后一公里`需求，即扩展最终用户使用的程序界面，模版，表单，报表等。需求简单明确，复杂度较低。这种扩展方式底层使用的 ABAP 版本为 ABAP for Key User.
Developer Extensibility 用于实现 Key User Extensibility 因为功能局限而无法实现的需求，虽仍属于紧耦合扩展方式，但因为仅能使用 SAP Released Objects 这部分稳定的 ABAP 对象（包含 BAdIs，类，接口，CDS Views，RAP 里的 Behavior Definitions 和 Authorization Objects），所以升级安全。底层使用的 ABAP 语言版本为 ABAP for Cloud Development.
Side-by-Side Extensibility 松耦合解决方案，开发者可以选择自己熟悉的技术栈，通过 BAPIs, IDOCs, OData 和 SOAP API 同 SAP S/4HANA 核心系统集成。部署和生命周期管理同 SAP S/4HANA 完全独立。
本公众号后续会对除了 Classic Extensibility 之外的其他扩展方式进一步介绍。
