Jerry 眼中的 SAP 客户数据模型
本文 Jerry 将介绍八款 SAP 产品中的客户模型。希望您在阅读完本文之后,能对 SAP 客户模型设计的思路有一个最最粗浅的了解。
由于 Jerry 水平和精力所限,本文不会详细阐述这些产品里的客户模型设计细节,而是介绍了一种方法,如果您对这些模型设计感兴趣,可以按照该方法自行深入研究。
SAP CRM
SAP CRM Fiori
SAP Hybris Cloud for Customer
SAP S/4HANA On Premise
SAP S/4HANA On Cloud
SAP Hybris Enterprise Commerce Platform
SAP Hybris Revenue Cloud
SAP Hybris Engagement Center
除 SAP S/4HANA On Cloud 之外,其他七款产品在 SAP 成都研究院均存在对应的开发团队。如果您对这些产品有进一步的问题需要咨询,欢迎留言。
SAP CRM
可以按照客户的类型是 Corporate 或 Individual 来搜索。在 SAP 的很多产品里,这两种类型的客户共用同一个技术模型,通过模型上某个类型字段进行区分。本文只着重介绍 Corporate Account。
下图是 SAP CRM 里某个 Corporate Account 明细页面的抬头区域。
客户明细页面的抬头区域下部由若干可以通过点击小三角符号来展开的区域组成。SAP 的技术文档里称这些区域为 Assignment Block。
如何查看 SAP CRM 的客户模型呢?在上图客户页面按 F2,会显示如下弹出窗口,显示该页面实现的 BSP 应用视图名称为 BP_HEAD/BPHEADOverview。
在 BSP 开发工具里打开该视图,能看到每一个 Assignment Block 的技术明细。
假设我想深究下图名为 Address 的 Assignment block 实现明细,在上图中得知其 BSP 实现为 BP_ADDR/CorpAccountAddresses。在开发工具里打开此视图,找到地址数据是来自模型节点 BuilAddress。
这个 BuilAdress 节点是 SAP CRM 客户模型的子节点。SAP 很多产品都有所谓 Business Object(下文简称 BO)的概念,这些模型从技术上来说是一棵树,由若干节点组成,节点与节点之间存在父子关系或者跳转关系。每个节点由若干字段组成,这些节点组成的模型,再加上节点上定义的一系列能够执行的动作(action)就构成了一个 BO,实际上是 sap 对某一业务流程及参与实体的高度抽象的产物。
CRM 客户模型的底层数据库表:BUT000。用于区分 Corporate 还是 Individual Account 的字段名称: TYPE。
通过模型单元测试工具,能够清楚地看到客户的地址信息是维护在节点 BuilAddress 里的。下图是 CRM Business Object 测试工具截图,左上显示了该模型的节点集合,左下显示了当前选中节点为 BuilAddress,右边区域显示了这个节点所有字段的内容。
SAP CRM Fiori
前一章节介绍里使用 CRM Web Client UI 打开了一个 Corporate 客户。这里用 SAP CRM Fiori 再次打开它。
可以看出 CRM Fiori 和 CRM UI 显示的思路类似,都是把抬头类型的信息和各个维度的明细信息分开显示。同 CRM 相比,稍稍不同的是 CRM Fiori 的客户明细页面并不像 CRM 那样,各个维度的数据从上到下依次全部显示在一个页面上。因为要照顾到使用平板电脑或者手机访问系统的 Fiori 用户,所以 CRM Fiori 页面上只会显示某一维度的客户数据。不同维度的数据展示通过下拉菜单来切换。
例如选中 Marketing Attributes 维度后,在 Chrome 开发者工具里能观察到一个 HTTP 请求,观察其路径发现 CRM_BUPA_ODATA,这其实是 OData 服务的技术名称。
在网关系统根据该服务名称搜索,能查到提供该 OData 服务的后台服务器。
让我们再来重温我的公众号文章SAP Fiori应用的三种部署方式里提到的这张架构图。网关服务器就是下图红色方框的 ABAP Frontend Server,而 OData 服务的实现位于后台服务器,如下图蓝色方框所示。
SAP Hybris Cloud for Customer
工作中心视图 Accounts 和 Individual Customers 分别对应了 SAP CRM 里的 Corporate Account 和 Individual Account。
页面风格和 SAP CRM 稍有不同,但是思路一致:客户的抬头信息显示在页面左部,其他维度的信息显示在页面右部。每个维度的信息通过不同的标签页进行切换。
使用我公众号文章Jerry和您聊聊Chrome开发者工具提到的技巧找到客户明细页面的 UI 模型地址:
/BYD_COD/SalesOnDemand/Account/UI/COD_Account_TI.TI.uicomponent
在 Cloud Application Studio 里打开该 UI 模型,点击 Data Model 即可查看 C4C 客户模型的设计明细。
这里可以看出 C4C 的客户模型仍然是一个 BO,位于命名空间http://sap.com/xi/AP/FO/BusinessPartner/Global。
该命名空间内部还包含一些其他 BO,例如 Customer 和 Employee。
这几个模型有什么区别和联系?借用面向对象程序设计的思路来解释 C4C 里客户模型的设计:类似面向对象编程语言里的父类一样,Business Partner 这个 BO 定义了一些最基本最通用的字段,如下图正中的虚线框所示:Generic Attribute,Addresses 和 Relationships。其他模型 Customer,Employee 和 Supplier,则在这些通用字段基础上定义了一些新的字段。对于 Customer 模型,其区别于 Business Partner 模型之处就在于需要维护一些和销售相关的信息,比如销售数据,销售区域和销售线索。对于 Employee,关注点则在于工作地址,工作部门,领导等信息。
借用面向对象编程语言的继承概念,C4C 的 Customer 和 Employee BO 继承了 Business Partner BO 上定义的通用字段,同时本身又定义了新的字段,这些字段将其自身和其他 BO 从业务上区分开来。
作为一款云解决方案,您可以通过一些非常简易的步骤,在短短几分钟之内通过 OData Service 或者 Web Service,实现您的第三方应用和 C4C 客户模型的各种交互。例如您可以将 C4C 的客户数据暴露出来供第三方应用读取,或者通过第三方应用对 C4C 客户数据进行写操作。
SAP S/4HANA On Premise
在 SAP R/3 里,创建不同角色的业务伙伴需要使用不同的事务码:
这些模型在 SAP 全球客户多年使用过程中,暴露出一些局限性和不足,例如一个 Customer/Vendor 只能维护一套地址信息;没有角色的概念,一个业务伙伴没法维护成既是 Customer 又是 Vendor;没办法维护一些和时间相关的属性。
这些不足到了 S/4HANA 得到了妥善解决。在 S/4HANA 里,所有不同类型的业务伙伴使用统一的 Business Partner 模型。R/3 的 Customer 和 Vendor 使用各自的模型和数据库表,到了 S/4HANA,这些模型统一成 Business Partner,通过 BP Role 来区分其角色,底层的数据库表也统一使用 Business Partner 的数据库表。
客户数据的创建也统一使用事务码 BP 来完成。R/3 那些五花八门的业务伙伴创建的事务码全部标注成 Obsolete。一旦执行,会自动重定向到事务码 BP 去。
为了确保大量源自 R/3 的基于 Customer/Vendor 旧模型的应用能够继续工作,S/4HANA 引入了 Customer Vendor Integration(CVI)的概念,简单地说即每次 S/4HANA 应用使用新的 Business Partner 对应的 API 进行写操作时,数据不仅仅存储到新的 Business Partner 模型的对应的数据库表里,同时仍然会存储一份到旧的数据模型表里,如下图所示:
关于 CVI 的更多介绍,请参考博客:
SAP S/4HANA on Cloud
和 S/4HANA On Premise 使用的客户模型相同,例如下图 ID 为 1010 的客户明细数据,
通过 OData 服务 MD_CUSTOMER_MASTER 从 ABAP 服务器读取。
切换标签页时,会触发该标签页对应的明细数据读取请求。
每个标签页对应客户模型上的一个子节点。通过 Chrome 开发者工具查看请求结果字段即可了解到该子节点上建模了哪些字段。
SAP Hybris Enterprise Commerce Platform
Hybris ECP backoffice 里也存在 Customer 和 Employee 模型。因为是 backoffice 的使用场景,所以和前文介绍的 SAP CRM 和 SAP C4C 不同,这里的客户页面还包含一些其他维度的信息维护,比如密码策略和密码重置功能。
Hybris 的模型定义很有意思,定义在 xml 文件里。在 Hybris 文件夹\bin\platform\ext\core\resources 下面有 core-items.xml:
该 xml 文件定义了 Customer 这个模型是另一个模型 User 的扩展,具体扩展的字段名称为 customerID。
在执行命令 ant build 后,会自动生成一个以 Model 结尾的.java 文件,位于文件夹\bin\platform\bootstrap\gensrc\de\hybris\platform\core\model:
查看 CustomerModel.java,发现 xml 文件第 1757 行定义的 code Customer 出现在了 Java 文件的第 40 行,xml 文件第 1763 行为 Customer 模型定义的新字段 customerID, 出现在 Java 文件的第 43 行。
而 User 模型的实现文件 UserModel.java 和 CustomeModel.java 位于同一个文件夹。打开 UserModel.java, 发现它又是扩展自模型 PrincipalModel。
这个扩展关系也是在 core-items.xml 里定义的。
同理,User 模型较之 Principal 模型,新定义的字段如下图 attributes 标签里所示:
按照同样的逻辑再从 Principal 往上追溯,可以得到完整的类型继承链:
Customer->User->Principal->GenericItems->LocalizableItem->ExtensibleItem->Item。
由此得知 Hybris 的类型系统,对于 Customer 和 User 这些业务模型的关系描述采用的是继承的思路,而 ABAP Dictionary 里的类型模型则采用的是组合的思路。若干业务上相关的字段被放到一个结构体里,若干结构体再组合(include)成一个规模更大的结构体,最终形成一个给外界消费的结构体。
SAP Hybris Revenue Cloud
SAP Revenue Cloud 是 SAP 最近发布的一款云解决方案。该方案能动态地规划、创新和调整系统,从云端自动管理和配置定价,报价,计费和订购等流程,从而超越报价到收款流程,通过变革实现盈利。
点击 Customer tile 查看客户主数据:
客户明细页面是典型的 Master Detail 风格。
从 Chrome 开发者工具里发现明细页面加载时,会有一个请求向后台读取 40 个客户的抬头信息:客户 ID,客户类型和客户名称,显示在左边的 Master List 区域内。
选中 Master List 里某个客户,会触发另一个 HTTP 请求向后台读取选中客户的明细:分别是客户地址,客户联系人和客户市场信息。这三类明细分别是 Revenue Cloud 客户模型的三个子节点,通过 expand 指令读取。
在 Chrome 开发者工具里展开节点即可查看该节点的字段。例如地址节点包含的字段如下:
这些数据请求由部署在 SCP 上基于 Java 实现的 Revenue Cloud 微服务负责响应并返回给 UI5 前台。
SAP Hybris Engagement Center
SAP Hybris Engagement Center 是 SAP 新一代全渠道呼叫中心 SaaS 产品。在坐席和客户的交互场景里,坐席需要在最短的时间内搜索出系统里存在的客户或完成新客户的创建工作。
实际上 Engagement Center 里的 Corporate 客户模型上的字段一个屏幕就能够全部显示出来,如下图所示:
客户明细页面渲染之前,所需要的数据通过如下 HTTP 请求读取:
通过 expand 指令在一个请求里将客户模型的抬头信息及地址信息一并取回。观察 HTTP 请求的响应结构,得知 Engagement Center 的客户模型里,地址信息维护在子节点 Addresses 上。
从响应结构也能看出地址和客户角色都支持维护多个记录,这个观察结果也和 UI 上提供的功能一致。
这篇文章简要介绍了 SAP 几款产品中客户模型的建模情况。通过 SAP 不同产品里客户数据模型的比较,我们了解到这些模型的复杂程度随使用场景的不同而有所区别。您也可以按照本文介绍的使用 Chrome 开发者工具这一方法,自行研究您感兴趣的 SAP 产品里的模型设计。甚至,您可以用同样的方法看看 Salesforce 的客户模型是怎样设计的。
感谢阅读。
版权声明: 本文为 InfoQ 作者【Jerry Wang】的原创文章。
原文链接:【http://xie.infoq.cn/article/582edb296bb34c5a90a3578e0】。文章转载请联系作者。
评论