笔者最近的工作和 SAP 某云产品的扩展性设计相关，因此借这个机会，把我过去工作中积累的 SAP 产品扩展技术相关的知识做一个梳理和回顾。

文章目录

SAP 产品标准

SAP Field Extensibility 简述

SAP Side-by-Side Extensibility 简述

SAP In-App Extensibility 介绍

SAP Business Addin 增强概念在多种 SAP 产品中的应用

ABAP 类面向切片编程方式(Aspect Oriented Programming)

SAP Commerce 扩展方式简述

SAP Fiori UI 扩展方式简述

展望未来

下面是文章正文。

SAP 产品在发布到市场上之前，都必须经历一系列严格的产品标准(Product Standards)相关测试。

这些产品标准包含但不局限于：

• 功能正确性(Functional Correctness)

• 性能(Performance)

• 安全性(Security)

• 全球化(Globalization)

• 业务配置性(Business Configuration)

• 可扩展性(Extensibility)

• 生命周期管理(Software Lifecyle)

• 可访问性设计(Accessibility)

其中 SAP 产品的可扩展性(Extensibility), 又可细分为字段级别的可扩展性(Field Extensibility)和流程级别(Process Extensibility)的可扩展性。当然二者有时也没有明确的区分界限，比如客户实际应用场景中，一旦创建了新的扩展字段后，通常也期望该字段参与到业务流程中去，即所谓端到端的扩展场景(End-to-End Extension Scenario).

Jerry 之前写过一篇文章介绍了 SAP 产品字段级别可扩展性(Field Extensibility)的设计原理：SAP产品的Field Extensibility，本文则介绍 SAP 产品流程级别的可扩展性。

SAP 产品的两种扩展方式：In-App 和 Side-by-Side Extensibility

以 Jerry 工作的 SAP C/4HANA 套件为例，在SAP帮助文档里，我们可以首先选择以 In-App Extensibility 还是以 Side-by-Side 的方式来扩展:

选定扩展类型后，再从下拉菜单里选择具体的产品名称，即得到该产品针对选定的扩展类型，SAP 所推荐的扩展方式。

所谓 In-App Extensibility，指通过 SAP 扩展工具创建出的 Enhancement(增强)，同被增强的 SAP 标准产品运行在同一服务器上。更准确地说，增强实现同被增强的 SAP 应用运行于同一会话(Session)内。

与之相对的是 Side-by-Side Extensibility，增强实现同被增强的 SAP 应用通常运行在不同的服务器上。以 Jerry 之前文章 基于SAP Kyma的订单编排增强介绍 里提及的场景为例，SAP Commerce 将 Order.Created 事件注册到 SAP Cloud Platform Extension Factory(Kyma)上，二次开发人员在 SAP 云平台上创建 Lambda Function，订阅这个事件，实现发送邮件的逻辑。运行时每当 SAP Commerce 有订单创建，Order.Created 事件发布到 SAP 云平台上，Lambda Function 被触发，自动发送邮件。

通过 Side-by-Side Extensibility，可以实现咨询公司 Gartner 早在 2014 年就提出的双模 IT(Bimodel)概念，即一方面通过 SAP S/4HANA 作为数字化核心，以支撑企业稳定可靠运作；另一方面，通过 SAP 云平台所架构的数字化创新平台，借助包括人工智能、区块链、大数据分析等前沿科技，对 S/4HANA 进行 Side-by-Side 扩展，帮助客户实现快速的产品/服务乃至商业模式的创新。

关于 Side-by-Side Extensibility，Jerry 之前的文章曾做过简单介绍：

还在用 ABAP 进行 SAP 产品的二次开发？来了解下这种全新的二次开发理念吧

本文余下部分着重回顾 SAP In-App 这种扩展方式。

在讨论 SAP 产品扩展时，我们有必要区分这组概念的差异：Enhancement(增强)和 Modification(修改). 后者是直接对 SAP 产品的源代码进行修改，在 SAP 产品升级或者 Patch 导入系统时，这些本地修改会被覆盖，故 SAP 不推荐通过 Modification 的方式进行二次开发。而 SAP 增强技术则不会存在当产品升级时被覆盖的问题，因此将 SAP 增强技术描述为一种具备 Upgrade Safe 或者 Modification Free 特性的技术.

SAP Business Addin 增强概念在多种 SAP 产品中的应用

以 ABAP 作为技术栈的 On-Premises 产品，其增强技术源远流长。尽管具体技术实现有差异，但思路都一致：SAP 事先在标准程序里预留一些 Hook，二次开发人员可以实现这些 Hook，将自己的业务逻辑代码编写在里面。 这些 Hook 所在 SAP 标准程序里的位置，称之为增强点(Enhancement Point). 当标准程序执行到这些 Hook 时，系统如果检测到有 Partners 实现了这些 Hook，就调用之，从而实现了业务流程的扩展。

这些增强方式技术上没有太多噱头，但却体现了德国制造一贯的作风：严谨实用，低调高效。可以说 SAP 早期基于 ABAP 技术栈的产品能在全世界取得成功，称霸 ERP 软件领域，这些增强技术功不可没。

从时间线来说，国内很多 SAP 中文博客将 ABAP 增强技术划分为三代：User Exit，Function Enhancement 和 Business Addin. 前两种方式广泛用于早期的 SAP 产品中，现在已很少提及。Business Addin(有时简称 BAdI)，从诞生至今一直是 SAP ABAP On-Premises 产品增强技术的主力军，并且在 ABAP Cloud 产品如 SAP Cloud for Customer 和 S/4HANA Cloud 中也能看到其身影。

Business Addin 技术又分为使用 CL_EXITHANDLER 进行增强管理和调用的传统方式(Classical BAdI)和使用 ABAP 关键字 GET BADI 和 CALL BADI 实现这两种方式。二者区别在于前者是在 ABAP 应用层面管理和调用增强，而后者两个关键字的实现位于 ABAP Kernel 中，性能优于传统方式。

换言之，在传统 BAdI 增强方式里，对于 SAP 预留的增强点里，运行时到底包含哪些有效增强实现的逻辑，是编写在 ABAP 层的 CL_EXITHANDLER 里，所有 ABAP 开发人员都能调试这些 ABAP 代码：

而 GET BADI 和 CALL BADI 实现在 ABAP Kernel 层，只有 SAP 内部人员才能看到这些关键字的 C 语言实现代码。

GET BADI 关键字执行完毕后，满足 Filter 条件且状态为 Active 的增强实现实例被 ABAP Kernel 填充到内表 IMPS 里：

正因为 ABAP 新式增强其强大的扩展功能，在基于 ABAP 的 Cloud 产品里也出现了它的身影。

在 SAP Cloud for Customer 里，二次开发人员无法直接用 SAPGUI 编写 ABAP 增强代码，却仍旧能用 SAP Cloud Application Studio 创建增强：

下图下拉菜单显示的就是 CustomerQuote 这个 BO 预留的增强点：

在 Studio 里用 ABAP 脚本语言编写增强实现，保存激活后，会在 ABAP 后台自动生成 BAdI 增强体和根据 ABAP 脚本语言编译成的 ABAP 原生代码。

到了 S/4HANA Cloud，SAP 仍然不想放弃给二次开发人员提供编写 ABAP BAdI 增强实现的功能，只不过编写工具从 SAPGUI 和 SAP Cloud Application Studio 迁移到了浏览器中。

客户在 S/4HANA Cloud 的 Fiori Launchpad 里，进入 Custom Logic 这个 tile：

新建一个 Enhancement Implementation：

选定 Business Context 后，同样能从 Enhancement Option 即可用增强点列表里，选择合适的增强点创建增强实现：

同 SAP Cloud for Customer 编写的 ABAP 脚本不同，在 SAP S/4HANA Cloud Custom Logic 里，编写的是原生的 ABAP 代码：

关于浏览器里如何实现上图所示的 ABAP 语法高亮，请参考 Jerry 的文章：ABAP开发环境语法高亮的那些事儿。

ABAP 类面向切片编程方式(Aspect Oriented Programming)

相对 Java 编程人员，ABAP 开发人员平时可能不会接触到面向切片编程(Aspect Oriented Programming，简称 AOP)这个概念。

面向切片编程可以看成对面向对象编程思维的一种补充，广泛应用在基于 Spring 框架的 Java 应用中，比如 SAP Commerce.

利用 AOP，可以对组成业务逻辑的各部分进行隔离，降低各部分间的耦合度，以及避免非业务逻辑代码侵入到业务逻辑代码里。

由于 ABAP 语言特性和 Java 的差异，SAP 官方从未提及 ABAP 对 AOP 的支持，所以 Jerry 本文目录里也采用“类 AOP”的字眼来描述。

在 ABAP 里如果想要统计一个方法的运行时间，最常用的办法是在方法实现体的头部开启一个计时器，在实现体末尾关闭计时器。伪代码如下：

下图是 SAP Gateway 处理 OData 请求的框架代码。在处理开始之前打开计时器：

请求处理完毕后关闭定时器：

这样的写法，开关计时器这些基础设施性质的代码就侵入到了 OData 请求处理的业务代码里。

除了性能统计外，权限检查，日志记录，事务处理等任务也几乎是任何应用必须编码实现的非业务逻辑模块代码。

借助 AOP 理念，可以优雅地避免非业务逻辑代码对业务逻辑代码的侵入(有时也称污染)。

使用 AOP 编程范式，业务模块的编写只关注业务逻辑本身，仅此而已。权限检查，日志记录，性能检测这些基础设施级别的关注点，通过不同的 AOP 实现技术，在不修改业务模块源代码的前提下，像切面(Aspect)一样编织(Weave)到业务模块里。

ABAP 缺少 Java 那样对 AOP 的完善支持，ABAP 平台提供的 Pre/Post/Overwrite Exit，可以在一定程度上实现类似 Java AOP 的效果，即某 ABAP 方法的 Pre-Exit 增强，能够自动在该方法调用之前被调用；Post-Exit 增强，自动在该方法调用之后被调用。Pre 和 Post-Exit 增强的存储和生命周期管理，均独立于被增强方法本身。

限于文章篇幅，ABAP 这种类 AOP 技术和 Java AOP 的比较，有机会 Jerry 单独写一篇文章介绍。

在 SAP Business by Design 和 SAP Cloud for Customer 的 Cloud Application Studio 里，以标准 Business Object 节点作为粒度，为二次开发人员暴露了很多增强点，比如在某 BO 节点发生修改之后，保存之前，从数据库加载到应用之后，执行某 Action 之前，都能编写自定义逻辑。

本来 ABAP Pre-Exit 和 Post-Exit 是实现这些自定义逻辑的最佳载体，但是在 Jerry 工作的 2010 年的时候，这些 Exit 无法实现多租户隔离(Multi-tenant isolation)，即租户 A 上创建的 Exit，在其他所有租户上也都可见，因此无法用在诸如 SAP Business by Design，SAP Cloud for Customer 这些需要支持多租户隔离特性的 SAP 云产品上。

关于 SAP Cloud for Customer Extensibility 设计的更多细节，请参考我的同事 Xu Boris 的文章：SAP Cloud for Customer Extensibility的设计与实现。

SAP Commerce 扩展方式简述

SAP Commerce 的服务层是根正苗红的基于 Spring 的实现，因此可以充分发挥 Java Spring AOP 带来的高可扩展性。

关于 Spring AOP 在 SAP Commerce 中的应用，请参考SAP帮助文档.

除了 Spring AOP 之外，SAP Commerce 的高可扩展性还体现在其以 Extension 为基础的模块化架构上。

Jerry 第一次学习 SAP Commerce 时，曾经被其 Extension 这个单词的字面意思所迷惑。其实在 SAP Commerce 上下文里，Extension 和 ABAP 里的 Extension 含义有所不同——后者多指二次开发人员基于 SAP 标准程序做的增强，而前者是 Commerce 里一个更加宽泛的概念：

An extension is an encapsulated piece of software that extends SAP Commerce functionality by either modifying existing features, or introduction new features.

SAP Commerce 的业务层，平台层和基础设施层的很多标准功能，均通过 Extension 作为载体来实现。一个 Extension 就是 SAP Commerce 里一个最小粒度的功能模块，从开发角度上看就是一个导入到 IDE 后的 Java 工程文件夹：

按照SAP帮助文档上的步骤，二次开发人员可以创建新的 Extension，实现了自己的自定义业务逻辑后，再按照向导将其合并到 SAP Commerce 中去，从而实现功能扩展需求。

在 SAP Commerce config 文件夹下的 localextensions.xml, 声明了运行时会加载的 Extension 列表。由此看出，SAP Commerce 里无论标准 Extension 还是二次开发人员自建的 Extension，在加载时都处于同等地位，这是我觉得 SAP Commerce 在 Extensibility 上不同于 ABAP 产品的一个有趣之处。

SAP Fiori UI 扩展方式简述

本文描述的 SAP Fiori UI，仅限于基于 SAP UI5 框架实现的前台页面。采用 React，Vue，Angular 等技术实现的 Fiori UI 不在本文讨论范围内，您可以通过 Jerry 这些文章了解更多细节：

• SAP Fiori + Vue = ？
  

• Fiori Fundamentals和SAP UI5 Web Components
  

• 用React开发SAP Fiori应用
  

基于 SAP UI5 框架实现的 Fiori UI，从实现方式又可以分为前端开发人员手动编写的 UI，以及通过框架比如 SAP Fiori Elements 自动生成的 UI 两种。

前者的典型例子是 SAP CRM Fiori 的标准应用，Jerry 之前工作过的 SAP 成都研究院 CRM 开发团队曾经负责过这几个 Fiori 应用的开发和维护：

这些 Fiori 标准应用的 XML 视图和 Controller 的 JavaScript 代码均是我们人工编写的，我们在 XML 视图里，预留了 Partners 能够插入自定义 UI 元素的 Extension Point：

二次开发人员通过下图所示的 UI5 View Extension，将自定义 UI 元素插入 Fiori UI 的 SAP 标准 XML 视图预留的 Extension Point 里：

而 JavaScript 实现的 SAP Fiori UI 标准控制器里，我们也为二次开发人员预留了进行流程逻辑增强的所谓 Extension Hook：如下图第 933 行所示：

上图的 Hook 在 Partners 的 UI 控制器里实现代码如下：

我当时担任 SAP CRM Fiori 客户项目 Dev Angel 时，曾经建议项目的二次开发人员，用这种方式完成了很多端到端级别的增强开发，我把其中一些案例写在了 SAP 社区的博客系列里.

无论 XML 视图里的 Extension Point，还是 JavaScript 控制器里的 Extension Hook，设计理念同前文介绍的 ABAP Business Addin 如出一辙。

这种理念也延续到了基于 SAP Fiori Elements 自动生成的 UI 里：

关于如何使用 Extension Point 对 SAP Fiori Elements UI 进行扩展，请参考SAP帮助文档.

展望未来

随着 SAP Cloud Platform Extension Factory 的问世，越来越多的客户选择将自定义逻辑实现在基于 Serverless 架构的 Lambda Function 里，通过 Side-by-Side 的方式对 SAP 云产品进行扩展。而微服务架构下的 SAP 云产品，如何对这些基于 Lambda Function 实现的客户增强进行统一管理和调用，是一个令人浮想联翩的话题，Jerry 将来有机会的话会继续介绍。

感谢阅读。