由於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的更多介紹，請參考博客：

• Business Partner approach: Customer Vendor Integration to Business Partners (CVI)
• Business Partner – Customer-Vendor Integration S/4 HANA

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的客戶模型是怎樣設計的。

感謝閱讀。

要獲取更多Jerry的原創技術文章，請關註公眾號"汪子熙"或者掃描下面二維碼:

Jerry眼中的SAP客戶數據模型