本文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，位於名稱空間。

該名稱空間內部還包含一些其他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的客戶模型是怎樣設計的。

感謝閱讀。

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

Jerry眼中的SAP客戶資料模型