SAP Cloud for Customer Extensibility的设计与实现

时间 2019-11-19

标签 sap cloud customer extensibility 设计实现栏目云服务繁體版

原文原文链接

今天的文章来自Jerry的同事，SAP成都研究院C4C开发团队的开发人员徐欢(Xu Boris)。徐欢就坐我左手边的位置，所以我工做中但凡遇到C4C的技术问题，一扭头就能够请教他了，很是方便。下图是他办公室的桌面。前端

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 多个客户故障。ide

目前做为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内所有用户生效。flex

Key User Tool很是容易使用。若是想经过Adaptation的方式加强UI，登陆C4C ,在顶部菜单栏选择Adapt -> Edit Master Layout（相应的，若是选择Personalization方式，则经过下图Adapt旁边的Personalize菜单项开始）。ui

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

填写字段描述，类型等信息以后保存便可。debug

你们把上图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里名叫$PERS的Layer中。运行时，包含了Personanization的UI页面准备渲染时，C4C前端框架才会临时把这些位于$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 $Load读取UI源代码，从下图中咱们看到$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字段的属性作了修改的事件。

而ChangeRegistry.js, 做为响应用户在Key User Tool里操做的入口，将不一样类型的UI修改分发给对应的处理器进行处理。

下图显示的是当"PropertyChange"这个类型的UI修改发生时，该修改被ChangeRegistry.js投递给处理器PropertyChange.js。

PropertyChange.js会根据传入的事件参数进行解析，判断出当前发生更改的字段的Property是mandatory，因而进入_mandatoryChanged进行处理，建立CT记录这个修改。

但愿这篇文章能让你们对C4C的Extensibility设计有一个粗浅的了解，感谢阅读。

更多阅读

要获取更多Jerry的原创技术文章，请关注公众号"汪子熙"或者扫描下面二维码: