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

• 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的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: