SAP S/4HANA中的扩展开发方式汇总

1. 背景

可扩展性是ERP软件的一个重要指标。

客户的需求和流程是千差万别的，任何一个ERP软件都不可能在出厂时就满足客户100%的需求。因而在标准功能的基础上，再进行定制化的开发会是ERP项目实施的一个重要内容。

如下图所示，对于SAP标准软件提供的功能而言，其可能仅满足了客户的一部分需求，对于标准功能未涵盖的部分，客户则需要通过扩展开发的方式实现。

在过去SAP ECC项目的实施中，客户和实施顾问主要是通过经典ABAP 扩展（Classic ABAP Extensibility）的方式来进行二次开发的（e.g. SE80），通过这种方式，开发人员可以使用、修改所有的SAP标准程序，其提供了极大的灵活性和便利性。

但这种方式带来的问题也很明显，SAP系统在升级时，客户自定义的扩展开发是可能被影响和覆盖的。

在云转型的浪潮下，这种增强模型的缺陷也日益凸显。因而，随着SAP S/4HANA的推出，SAP也推出了新的扩展模型（upgrade-stable cloud extensibility model），通过使用SAP官方发布的API和增强点，对SAP的标准程序和客户增强程序进行隔离，进而保证核心系统的稳定升级。

也就是SAP官方资料中常常提及的Clean Core战略，也即：“扩展程序应与SAP标准程序严格分开；在扩展开发中，仅可以使用SAP发布的接口和对象”。

在这样的大原则下，就可以确保ERP核心系统的稳定升级，也即SAP的官方升级不会对客户的定制化功能和流程造成影响。

那么，经典增强（Classic Extensibility）技术，在S/4HANA上还能用吗？

• 对于SAP S/4HANA Public Cloud，经典增强技术将不再可用；
• 对于SAP S/4HANA Private Cloud和SAP S/4HANA On-Premise版本，用户仍然是可以使用经典增强技术的，但SAP官方不推荐。

2. S/4 HANA的扩展模型

经典增强技术在S/4HANA上不再被推荐，取而代之的下面这3种建议的增强模型：关键用户扩展（Key-user Extensibility）; 栈上开发者扩展On-Stack Developer Extensibility(Embedded Steampunk); 并行式扩展Side-by-side Extension on SAP BTP。

2.1 关键用户扩展（Key-user Extensibility）

关键用户扩展，常称之为Key-user Extensibility或In-App Extensibility，可以让业务专家向SAP S/4HANA添加扩展，而无需深入了解底层SAP应用程序的实现细节。这种扩展方式常用于是所谓的最后一公里扩展，可以使用低代码/无代码工具扩展SAP S/4HANA用户界面、进程或表单。

关键用户通常没有或只有有限的编码技能，因此不需要具有版本控制、依赖处理、重构或调试等功能的完全集成的开发环境。

使用关键用户可扩展的特点是，与Developer Extensibility相比，简单的扩展可以更快地实现，因为可以节省业务专家（负责规范扩展，随后负责测试和批准）和开发人员（负责开发和开发人员测试）之间的沟通交流成本。

通过Key-user Tools，可以快速实现以下功能：

• 调整屏幕布局，如移动字段和字段组，隐藏字段，更改标签等。
• 向业务对象添加自定义字段。然后，自定义字段在整个应用程序堆栈中可用（从UI到数据库表或用于开发人员扩展）。
• 添加自定义业务对象来处理自定义数据，只需很少的编码工作。
• 添加自定义逻辑来使用cloud BAdIs验证自定义字段。
• 向流程组添加自定义字段（例如，从销售报价和销售订单到交付和发票），以提供一致的端到端可扩展性。
• 添加自定义核心数据服务（CDS）视图并创建新的分析应用程序（报告、kpi等）。
• 复制和适应打印和电子邮件表格模板。

关键用户做出的扩展内容，也会保存到传输请求中（transport request），进而可以将增强从D系统传输到Q系统和D系统。

下面是通过Key-user Tools来实现屏幕布局调整的一个例子。

2.2 栈上开发者扩展On-Stack Developer Extensibility(Embedded Steampunk)

栈上开发人员扩展性，适用于需要更接近或耦合与SAP S/4HANA系统数据、事务或应用程序的开发场景。

扩展项目的需求超出了关键用户扩展的范围，因此需要完全访问开发功能，如调试、重构支持、版本控制等。

与并行扩展相比，栈上扩展是在与底层SAP S/4HANA云系统相同的软件栈上开发和运行的。这允许扩展通过SAP扩展点、本地SAP api或SQL查询访问SAP S/4HANA逻辑和数据。

典型的栈上场景是对SAP数据进行频繁或复杂SQL访问的扩展（例如，连接客户和SAP数据的SQL查询），这无法通过远程数据访问或数据复制轻松实现。另一个典型的栈上模式是扩展，它将自定义数据存储在与扩展的SAP S/4HANA应用程序相同的逻辑工作单元LUW中。

Developer Extensibility方式可以允许ABAP开发人员使用ADT连接到SAP S/4HANA Cloud系统。

但是，在SAP S/4HANA Cloud ABAP环境下，将使用新的ABAP云开发模型开发扩展（ABAP Cloud），这将确保SAP的标准对象不被修改，并且在扩展中仅能使用SAP发布的API和扩展点。

2.3 并行式扩展（Side-by-side Extension on SAP BTP）

并行式扩展可以让用户在SAP BTP上构建扩展功能。自定义开发的扩展程序与SAP S/4HANA系统并行运行。

对于与SAP S/4HANA数据、事务或应用程序松耦合的场景，该模型是首选选项。

在SAP BTP上构建并行扩展一般有三个选项：

• 利用SAP BTP上推荐的应用程序编程模型，也即RAP或CAP
• 使用低代码和无代码工具（例如，SAP Fiori元素、工作流、业务规则）
• 当然也使用开源组件、外部框架或任何其他语言来进行扩展开发

也即，在Side-by-side场景中，对于传统的ABAP开发人员，可以使用SAP BTP上的ABAP开发环境作为开发平台，也即继续使用ABAP语言开发云原生的应用程序。

而对于JAVA和Node.js等技术栈的开发人员，可以使用SAP CAP（Cloud Application Programming Mode）框架来进行扩展开发。

与栈上开发者扩展性模型相比，Side-by-side Extension的主要区别是访问SAP S/4HANA Cloud的业务对象时，只能使用发布在SAP business Accelerator Hub （https://api.sap.com/）中的远程API。

3. 对比

在具体的应用场景中，客户需要评估具体的增强场景，然后选取合适的增加方式。

下图是SAP官方给出的一个决策树。

4. 小结

本文总结了SAP S/4HANA中的各种扩展开发方式，并列举了其各自的特点。