SAP S4CRM和C4C的技术比较

最新推荐文章于 2023-02-15 17:20:29 发布

weixin_33901843

最新推荐文章于 2023-02-15 17:20:29 发布

阅读量96

点赞数

文章标签： ui java javascript ViewUI

原文链接：https://juejin.im/post/5abf667e5188255583595f4e

版权

如果您对SAP S/4HANA for Customer Management（以下简称S4CRM）和SAP Cloud for Customer（以下简称C4C）不甚熟悉，那我建议您可以先浏览我之前写的这两篇微信公众号文章。

发布了这两篇文章之后，我在后台收到很多朋友的留言，询问S4CRM和C4C相比较的各种问题。因此我写了这篇文章，统一作答。

Jerry受家中长辈影响，从小就是一个三国演义迷，小学还未毕业，罗贯中的三国演义就已读过无数遍了。幼时也曾缠着长辈追问诸葛亮和周瑜谁在智力上更甚一筹，直到初中时我入坑“暗荣”发布的三国志V, 才从游戏中找到了答案。为了写这篇文章，Jerry又一次打开了玩了无数次的三国志V。好吧，周大都督智力值只比诸葛丞相低1点，但是武力值高18点。一代儒将，文武双全，“曲有误，周郎顾”，名不虚传。

大学毕业参加工作后不久，又赶上真三国无双V的发布。

这部毁誉参半的作品在我这个三国迷看来却称得上又一款神作，虽然该作品也有很多我想吐槽的地方，比如周大都督的兵器居然和孙大圣的一样，而赤壁之战周公瑾借此在世界军事史以弱胜强的著名战例中留下浓墨重彩一笔的“火计”，居然分配给了陆逊这个小说中我非常讨厌的家伙，然后补了一个和赵云一样的技能“神速”，囧。不过瑕不掩瑜，我又是玩的不亦乐乎，以至于在很长的几年时间里，我的很多论坛账号的头像都是用的下图这种：

诸葛亮和周瑜这对人物，无论是在三国演义书中，还是在数不清的以三国为题材的电脑游戏里，各自都有大量的粉丝。如果要问谁更优秀，在Jerry看来这个问题本身就很荒谬，两人在蜀和吴担任的角色不同，这根本没有可比性。不过要问Jerry更喜欢哪一个，答案毫无疑问是诸葛丞相，毕竟作为一个土生土长的成都人，而且在武侯区又住了那么多年。

为了避免这篇文章成为三国游戏介绍杂文，让我们言归正传。 Jerry在S/4HANA for Customer Management(以下简称S4CRM)和Cloud for Customer(以下简称C4C)开发团队都工作过，这篇文章给出这两款产品一些技术层面的比较。

下图是我原创的表格。

注：表格中S4CRM指2018年2月28日发布的1.0版本。

部署方式

这一差异显而易见，本地部署和云端部署的区别导致了表格里其他比较项目的差异。

SAP标准UI开发方式

S4CRM和C4C的UI虽然看起来都是Fiori风格，但实现技术不同。

S4CRM的标准UI采用的仍然是SAP CRM WebClient UI技术，只不过SAP WebClient UI团队的开发同事们巧妙地设计了一系列CSS，并且对WebClient UI的框架做了一些调整(所谓的”Visual Harmonization”), 使得其视觉效果和体验接近于原生的Fiori应用。

如果看到一个界面风格和原生Fiori应用很类似的UI，您不能判定该UI到底是基于WebClient UI还是SAP UI5，可以打开Chrome开发者工具，倘若能找到下图红色区域所示的CRM Application Frame和带有/bc/bsp的ICF路径，则该UI是基于WebClient UI开发的。

如果在Sources标签页内能看到加载了下图所示的UI5库文件，说明该UI是基于SAP UI5开发的。

当然也可以安装我的博客Chrome Development Tool tips used in my daily work提到的UI5 Inspector:

安装之后在Chrome开发者工具会多出一个名为UI5的标签页，如果一个UI基于SAP UI5，则该标签页会显示对应信息，否则显示空白。

而C4C的标准UI则是基于SAP UI Designer和SAP UI5协作而成的。C4C标准UI也符合著名的“二八定律”，即80%的标准UI布局类似，只是呈现的业务数据有差异。例如下图红色区域我们称之为工作中心（Work Center），蓝色区域为工作中心视图（Work Center View），绿色区域称为Object Work List。

C4C里不同的应用尽管功能各异，但用户都是通过工作中心-工作中心视图-OWL这个统一的方式去访问。为了避免开发此类布局基本类似的UI模型造成的重复劳动，我们使用UI Designer，以所见即所得的方式开发UI模型。

例如Tickets这个视图里的OWL基于的UI模型名称可以通过Chrome开发者工具找到: /BYD_COD/ServiceOnDemand/AgentQueue/SEOD_Ticket_SADL_OWL

该模型在UIDesigner里打开如下图所示。我们首先从UI控件工具箱里拖拽出一个表格控件放到该模型UI区域，再指定该表格需要显示哪些列，并维护每列需要显示Ticket这个Business Object上哪些字段的内容。

在UI Designer里开发的UI模型保存之后，在ABAP后台以XML的格式存储。运行时这些UI模型的内容被读到C4C前台，通过C4C UI框架翻译成SAP UI5控件渲染给终端用户。

对于UI Designer技术上不能支持的剩下20%的需求，我们仍然会采用原生的SAP UI5开发。比如下图这种地图和C4C标准UI的集成，就是成都SAP研究院的C4C开发团队通过SAP UI5实现的。

Partner UI开发方式

对S4CRM来说，因为是本地部署，Partner可以直接登录后台进行开发，所以理论上来说，只要SAP标准开发能实现的功能，Partner也能做。

有的朋友抱怨WebClient UI和其他开源UI框架相比显得比较笨重，有的特效不易实现。其实，我的个人看法是，WebClient UI底层是基于SAP BSP的，而BSP又支持原生HTML和Javascript的开发，因此BSP其实也是灵活和开放的。

例如您可以参考我的这篇文章使用WebClient UI实现下面的效果：

Display count down in WebClient UI

以及在BSP里使用Vue:

对于C4C的Partner来说，只能使用UI Designer进行UI开发。C4C标准的UI5开发那条途径没有对Partner开放。不过存在一个轻量级的替代方案：使用C4C HTML mashup扩展C4C标准UI。

下面是SAP Community上的一篇博文，介绍了如何调用微软新闻API，取回最新的新闻并显示在C4C的客户明细页面里。

SAP后台开发方式

S4CRM和C4C后台都是基于ABAP Netweaver，因此对于SAP标准开发人员来说，进行这两个产品的后台开发使用的工具相同：SAPGUI或者ABAP Development Tools。关于更多ABAP Development Tools的介绍，请参考我的微信公众号文章那些年我用过的SAP IDE 。

S4CRM的Service Request的实现是基于One Order这个技术框架，Jerry是该开发框架的一员，而C4C的Service Request则基于ESF（Enterprise Service Framework）框架，Jerry在C4C项目中对该框架也有所了解，因此这里可以多说一句。One Order和ESF这两个框架其实现都有着Java Spring里依赖注入和控制反转的影子，即SAP应用开发人员只需要专注于将具体的业务逻辑实现在框架规定的技术模型里——One Order里称为回调(Callback), ESF里称为Determination，而无需操心这些模式何时调用——这些模型实例的初始化，执行上下文的准备，以及模型与模型之间的依赖，模型与框架的协同工作(orchestration)等等工作都由ESF框架本身完成，这极大程度地降低了应用开发的编程复杂度，提高了应用程序的健壮性。

下图是S4CRM里One Order的部分回调截图，红色区域即为具体的回调函数。

下图是S/4HANA里的BO Determination的一个例子。因为C4C的后台对Partner不可见，因此不允许在社交媒体上发布任何关于C4C后台的截图，这里我采用S/4HANA的截图代替，因为二者技术原理类似。

Partner 后台开发方式

对S4CRM来说，SAP开发人员和Partner采用的开发工具和开发方式相同。

对C4C Partner来说，只允许使用SAP Cloud Application Studio进行后台的二次开发。这是因为C4C基于云的部署模式，多个客户以不同租户（tenant）的方式，共享同一物理服务器。直接用SAPGUI和ABAP Development Tools创建的后台模型均为所有租户可见。因此，SAP提供了新的开发工具Cloud Application Studio供Partner进行后台二次开发。使用该工具创建的后台模型由所谓的PDI(Partner Development Infrastructure)统一管理，确保其租户隔离性(Tenant Isolation)。

我在SAP Community上也写过很多关于Cloud Application Studio的文章，您可以通过这个链接获得。

与其他系统集成的技术手段

S4CRM不存在C4C里开箱即用的Web Service和OData Service，需要Partner自行将function module通过事务码SOAMANAGER暴露成Web Service。具体步骤参考我的博客: Step by step to create, consume and trace web service in ABAP system

另一方面，虽然S4CRM不需要再借助CRM中间件进行S4CRM和S/4HANA的数据同步，但是仍然可以使用CRM中间件里的一个模块，XIF(External Interface) Adapter来和第三方系统交互。XIF Adapter在整个交互场景中扮演的角色如下：

具体例子参考我的博客：Step by step to send IDoc data into external receiver via XIF adapter

有趣的是，传统的SAP CRM和C4C也是可以通过PI(Process Integration)和XIF Adapter进行集成的, 请参考我的博客: Replicate CRM Opportunity to SAP Cloud for Customer using PI and XIF Adapter

和S4CRM相比，作为一款云解决方案，C4C同其他系统的交互手段要丰富得多。下图是C4C提供的标准集成场景一览：

SAP Help里描述的这些OData Service也是开箱即用的：

C4C所有的集成方式都记录在一位印度美女同事Sapna Ramaiah的博客里，阅读量超过4万：

SAP Hybris Cloud for Customer – All About Integration

Key User Extensibility

S4CRM没有继续使用源自SAP CRM的AET(Application Extension Tool), 而是采用了S/4HANA的扩展工具S/4HANA Key User Tool。该工具的一个特色就是支持在浏览器里书写ABAP代码，其原理在我的微信公众号文章那些年我用过的SAP IDE里有过介绍。

C4C里的Key User Tool无论从使用方式还是从功能上来说都和S/4HANA Key User Tool非常类似，这在我看来一点也不奇怪。这篇介绍S/4HANA Key User Tool的博客的作者，Thomas Schneider，曾经是大名鼎鼎的SAP PDI的首席架构师：

The Key User Extensibility Tools of S/4 HANA

Thomas博士1996年进入SAP工作至今，出版过多部SAP技术著作。我去德国Walldorf总部出差时，曾看到不少同事桌上都摆着他的一两本书。

C4C的Key User Tool给我留下深刻印象的一个强大功能是提供了灵活的规则(Rule)编辑功能来控制UI上某个元素的显示/隐藏。这种规则甚至可以通过脚本代码来定义。

因为对这个功能的实现很好奇，我做过一些研究并把结果写在了这篇博客里：

How to change UI element visibility dynamically via Rule Editor – and how it works under the hood

而S/4HANA Key User Tool也毫不逊色，甚至支持直接在浏览器里编写ABAP代码：

具体原理在我的公众号文章那些年我用过的SAP IDE里介绍。