Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1294176
  • 博文数量: 932
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 10208
  • 用 户 组: 普通用户
  • 注册时间: 2011-07-08 12:28
文章分类

全部博文(932)

文章存档

2021年(1)

2020年(134)

2019年(792)

2018年(5)

我的朋友

分类: 架构设计与优化

2019-08-25 21:15:06

今天的文章来自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 多个客户故障。

目前作为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里名叫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的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

阅读(597) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~