标签：组合 不同类 应用 菜单 返回 UI uil frontend business
本文Jerry将介绍八款SAP产品中的客户模型。希望您在阅读完本文之后，能对SAP客户模型设计的思路有一个最最粗浅的了解。
由于Jerry水平和精力所限，本文不会详细阐述这些产品里的客户模型设计细节，而是介绍了一种方法，如果您对这些模型设计感兴趣，可以按照该方法自行深入研究。
除SAP S/4HANA On Cloud之外，其他七款产品在SAP成都研究院均存在对应的开发团队。如果您对这些产品有进一步的问题需要咨询，欢迎留言。
可以按照客户的类型是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，右边区域显示了这个节点所有字段的内容。
前一章节介绍里使用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服务的实现位于后台服务器，如下图蓝色方框所示。
工作中心视图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 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的更多介绍，请参考博客：
和S/4HANA On Premise使用的客户模型相同，例如下图ID为1010的客户明细数据，
通过OData服务MD_CUSTOMER_MASTER从ABAP服务器读取。
切换标签页时，会触发该标签页对应的明细数据读取请求。
每个标签页对应客户模型上的一个子节点。通过Chrome开发者工具查看请求结果字段即可了解到该子节点上建模了哪些字段。
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 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新一代全渠道呼叫中心SaaS产品。在坐席和客户的交互场景里，坐席需要在最短的时间内搜索出系统里存在的客户或完成新客户的创建工作。
实际上Engagement Center里的Corporate客户模型上的字段一个屏幕就能够全部显示出来，如下图所示：
客户明细页面渲染之前，所需要的数据通过如下HTTP请求读取：
通过expand指令在一个请求里将客户模型的抬头信息及地址信息一并取回。观察HTTP请求的响应结构，得知Engagement Center的客户模型里，地址信息维护在子节点Addresses上。
从响应结构也能看出地址和客户角色都支持维护多个记录，这个观察结果也和UI上提供的功能一致。
这篇文章简要介绍了SAP几款产品中客户模型的建模情况。通过SAP不同产品里客户数据模型的比较，我们了解到这些模型的复杂程度随使用场景的不同而有所区别。您也可以按照本文介绍的使用Chrome开发者工具这一方法，自行研究您感兴趣的SAP产品里的模型设计。甚至，您可以用同样的方法看看Salesforce的客户模型是怎样设计的。
感谢阅读。
要获取更多Jerry的原创技术文章，请关注公众号"汪子熙"或者扫描下面二维码:
标签：组合 不同类 应用 菜单 返回 UI uil frontend business
原文地址：https://www.cnblogs.com/sap-jerry/p/8969509.html
