SAP Cloud for Customer Extensibility 的设计与实现

2021 年 11 月 23 日
本文字数：3659 字
阅读完需：约 12 分钟

Jerry 前一篇文章 SAP产品的Field Extensibility 以 SAP CRM 和 SAP S/4HANA 为例，介绍了 SAP 产品 Field Extensibility 的设计原理与实现。现在由徐欢继续 Extensibility 这个话题，向您介绍 SAP Cloud for Customer 的 Extensibility 设计与实现。

SAP C4C 和 SAP S/4HANA 的 Extensibility 有很深的渊源，后者的设计以前者为基础而又有所创新。从时间线上说，我认识的很多德国同事先后都参与了 C4C 和 S/4HANA Extensibility 的框架开发。这两个框架开发团队的很多关键角色，比如架构师和产品经理，甚至都是同一批人。

大家好，我是 Boris，中文名徐欢。2015 年元旦之前一直从事 ERP 客户项目开发与咨询，大约有 6 年的时间。在这之前也从事过几年与 SAP 产品无关的开发工作。由于在加入 SAP 之前参与 ERP 实施项目，我曾经花费大量的时间研究 ERP 核心模块的基本业务流程，曾经参与多个项目从立项到客户上线的实施工作。2015 年，怀着对 SAP 开发团队的憧憬之心加入 SAP BYD/C4C 应用开发项目，参与了多个应用模块和行业解决方案的开发，并在 2 年的时间里以技术支持的角色在 C4C HTML5 UI 框架这个领域内处理了 1000 多个客户故障。

目前作为 SAP C4C 在中国标准开发团队的一员，很高兴能在这里分享我关于 C4C Extensibility 的一些心得。

Jerry 前一篇文章 SAP产品的Field Extensibility 已经介绍过 Enhancement 和 Modification 这两个概念的区别。C4C 用户通过 Key User Tool 这个工具（类似 CRM 的 Application Enhancement Tool，AET）对 C4C 标准 UI 和客户定制开发的 UI 进行增强。增强类型分为 Personalization 和 Adaptation，分别针对同一 tenant 内单个用户生效和同一 tenant 内全部用户生效。

Key User Tool 非常容易使用。如果想通过 Adaptation 的方式增强 UI，登录 C4C ,在顶部菜单栏选择 Adapt -> Edit Master Layout（相应的，如果选择 Personalization 方式，则通过下图 Adapt 旁边的 Personalize 菜单项开始）。

现在将光标悬浮在页面任意位置，如果页面被 C4C 后台设置为“可以增强”，那么能看到一个弹出的工具栏，点击里面的加号图标，就能从下拉菜单中选择“Add Fields”来进行字段的增强了。

填写字段描述，类型等信息之后保存即可。

大家把上图 C4C 扩展字段创建页面和下图出现在 Jerry 前一篇文章的 S/4HANA 扩展字段创建页面做对比，是不是非常相像？

对客户而言，整个过程简单易懂，仅仅几分钟便完成全部操作。背后的支撑是 SAP C4C 提供的 Extensibility 框架, 这正是我要给大家介绍的。首先我们从基本概念说起。

Personalization

用户通过这种方式对 UI 进行的调整，只对当前进行 Personalization 的用户生效，对其他用户不可见。

C4C 后台有一个叫 XREP 的存储系统，设计思路和理念同 Jerry 介绍 S/4HANA Extensibility 时提到的 LREP 一致，只不过在 C4C 里换了一个名字而已，这里的 X 代表 Cross。尽管 C4C 的客户和 Partner 无法像 S/4HANA 那样，登录后台查看 XREP 的全部内容，但仍旧可以通过 UI Designer 里的 Configuration Explorer，查看 XREP 里的部分内容。如下图右边区域所示，XREP 实质上就是一个用 ABAP 实现的分层的文件系统。

从技术上讲，每个 Personalization 施加的 UI 修改，都会生成一个文件，这些文件的 C4C 官方叫法是 Change Transaction，下文简称 CT。Personalization 产生的 CT 存储在 C4C 后台 XREP 里名叫 $P E R S 的 L a y e r 中。运行时，包含了 P e r s o n a n i z a t i o n 的 U I 页面准备渲染时， C 4 C 前端框架才会临时把这些位于$ PERS 中的 CT 合并到对应的 C4C 标准 UI 上。

Adaptation

技术上讲，Adaptation 产生的 CT 文件会存储在该用户所归属的 Layer 里。例如客户做的 UI 修改，会存储到名为 $Cust 的 Layer 中去。而 Partner 做的修改，存储到 Partner 对应的 Solution 独有的 Layer 下面。Partner Solution 是 C4C 一个特有的概念，如下图 Cloud Application Studio 中的一个例子。大家可以把 Partner Solution 类比成 ABAP Package 的一个封装，一个 Partner Solution 里能存放 Cloud Application Studio 支持的各种资源，比如 UI，BO，Web Service，OData 开发等等。每个 Partner Solution 在 XREP 里都有对应的 Layer。

我的同事 Yang Joey 曾经在他的文章SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的独特之处提到过，C4C 的 UI 界面的源代码，是以 XML 格式存储在 ABAP Netweaver 后台的 XREP 里的。XREP 提供了许多访问这些 XML 文件的 API，比如读取，解析，激活等等。同 S/4HANA LREP 一样，C4C XREP 有不同的 Layer，分别存储 SAP 标准 UI，Partner 创建的 UI，以及用户所创建的资源。通过 Layer 实现了资源的区分隔离，使得操作者对 UI 的更改不需要修改最底层 SAP 标准的 UI 文件。运行时，上层的更改覆盖对应的底层文件的表现。关于不同层之间合并(Merge)的更多细节，请参考 Jerry 文章SAP产品的Field Extensibility里 S/4HANA 章节里对 LREP 的介绍。

运行时，C4C 框架从 XREP Layer $L o a d 读取 U I 源代码，从下图中我们看到$ Load 包含 SAP 标准 UI，以及 Partner 和客户进行 UI 更改产生的 CT。在 Adaptation 模式下产生的 CT 会被立即合并到对应的 UI 去，CT 合并之后 $Load 中的 UI 文件会被重新生成，以便在下次加载时前台框架总是基于最新合并后的 UI 源代码进行渲染。

我们现在以 Adaptation 的方式修改一个标准字段的属性，然后观察伴随着这个修改动作，自动生成的 CT 到底是什么样子的。我们将 Employee UI 上 Manager 这个标准字段的 Mandatory 属性打上勾，意思是如果该字段未维护，则对 Employee 做的修改无法成功保存。

因为用户和 Partner 无法登陆 C4C 后台，所以我们需要用另一种方式查看生成的 CT 明细。在地址栏的 url 里增加 debugMode=true 的参数进入调试模式。

然后重新加载该页面，按住 Ctrl + 鼠标左键点击“Manager”字段，出现一个弹出窗口。下图红色下划线标注的就是这个 CT 在 XREP 中的存储路径。路径里有个片段"AddCondition", 提示了这个 CT 的类型。点击超链接"Get CTs"查看 CT 明细。

这个 CT 的 XML 内容如下：

里面包含的一些重要信息：

UsedAnchor：这个属性是 C4C Extensibility 设计区分于 SAP CRM 和 S/4HANA 的最重要标志之一，马上详细介绍。上图的 UsedAnchor 类型为 SectionGroupAnchor，xrepPath 为该 Anchor 在 XREP 中的路径。
TargetFile：说明这个 CT 会被合并到哪个 C4C UI 上。上图例子里的值为 COD_Employee.TI, 指的是 Employee 的明细页面，即 Employee 明细页面上发生了 UI Adaptation 操作。
AddCondition：说明这个 UI 修改的具体类型。上图例子指修改的属性名称为"Mandatory", 默认值为 true。

现在来细说 UsedAnchor。Jerry 的文章SAP产品的Field Extensibility 曾经提到，在 SAP CRM 和 S/4HANA 的后台，都有一个统一的 Extensibility 注册表。每个应用的开发人员，如果希望自己应用的 UI 能够支持 Extensibility，那么需要将框架需要的信息注册进去。同样，C4C Extensibility 也需要这种注册表的逻辑，通过上面例子里提到的 Anchor 实现。

Anchor 的中文意思是“锚点”，这个字用在 C4C Extensibility 注册这个上下文非常合适。每个 Anchor 指向了一个可以通过 C4C Key User Tool 进行增强的 UI 区域。我们用 UI Designer 中打开刚才修改了 Manager 字段 Mandatory 属性的 Employee 明细页面，发现 Manager 字段位于一个 Section Group 中。选中该 Group，从页面右边的 Extensibility 属性中能发现维护有一个 Anchor。该 Anchor 即我们之前研究的 CT 的 XML 内容里 UsedAnchor 字段的值。

如果一个 Section Group 的 Extensibility 属性处维护有 Anchor，意思是 SAP C4C 声明该 Section Group 可以被 Key User Tool 增强。反之，不可增强。在 Adaptation 模式下将鼠标放至这些不可增强的 UI 上，只会被高亮，但没有任何工具栏显示。

除了 Key User Tool 外，C4C 的 Partner 还有另外一个途径对 UI 做增强，即使用 Cloud Application Studio 的 Extensibility Explorer。选中一个 UI Section Group，如果该 Group 的 Extensibility 字段维护了 Anchor，那么可以看到下图红色高亮的操作选项，按照向导即可对该 UI 做增强。

最后，这些自动创建的 CT，到底是在何时何处，由谁创建的？

**CT **创建

CT 创建的触发是在 UI 端 JavaScript 代码中完成，然后投递到 C4C 后台的。在 C4C UI 端 JavaScript 的目录 sap/client/flex/changes 文件夹下，存放着不同类型的 UI 修改对应的处理器(Handler)。比如 AddConditionHandler.js 这个文件，负责响应用户在 Key User Tool 里对 UI 字段的属性做了修改的事件。