如何进行SAP Cloud for Customer Extensibility的设计与实现，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
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中的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包含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记录这个修改。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注编程网行业资讯频道，感谢您对编程网的支持。
