本文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成都研究院均存在對應的開發團隊。如果您對這些産品有進一步的問題需要咨詢，歡迎留言。
可以按照客戶的類型是Corporate或Individual來搜尋。在SAP的很多産品裡，這兩種類型的客戶共用同一個技術模型，通過模型上某個類型字段進行區分。本文隻着重介紹Corporate Account。
這個BuilAdress節點是SAP CRM客戶模型的子節點。SAP很多産品都有所謂Business Object(下文簡稱BO)的概念，這些模型從技術上來說是一棵樹，由若幹節點組成，節點與節點之間存在父子關系或者跳轉關系。每個節點由若幹字段組成，這些節點組成的模型，再加上節點上定義的一系列能夠執行的動作(action)就構成了一個BO，實際上是sap對某一業務流程及參與實體的高度抽象的産物。
可以看出CRM Fiori和CRM UI顯示的思路類似，都是把擡頭類型的資訊和各個次元的明細資訊分開顯示。同CRM相比，稍稍不同的是CRM Fiori的客戶明細頁面并不像CRM那樣，各個次元的資料從上到下依次全部顯示在一個頁面上。因為要照顧到使用平闆電腦或者手機通路系統的Fiori使用者，是以CRM Fiori頁面上隻會顯示某一次元的客戶資料。不同次元的資料展示通過下拉菜單來切換。
使用我公衆号文章Jerry和您聊聊Chrome開發者工具提到的技巧找到客戶明細頁面的UI模型位址:
/BYD_COD/SalesOnDemand/Account/UI/COD_Account_TI.TI.uicomponent
在Cloud Application Studio裡打開該UI模型，點選Data Model即可檢視C4C客戶模型的設計明細。
這幾個模型有什麼差別和聯系？借用面向對象程式設計的思路來解釋C4C裡客戶模型的設計：類似面向對象程式設計語言裡的父類一樣，Business Partner這個BO定義了一些最基本最通用的字段，如下圖正中的虛線框所示：Generic Attribute，Addresses和Relationships。其他模型Customer，Employee和Supplier，則在這些通用字段基礎上定義了一些新的字段。對于Customer模型，其差別于Business Partner模型之處就在于需要維護一些和銷售相關的資訊，比如銷售資料，銷售區域和銷售線索。對于Employee，關注點則在于工作位址，工作部門，上司等資訊。
借用面向對象程式設計語言的繼承概念，C4C的Customer和Employee BO繼承了Business Partner BO上定義的通用字段，同時本身又定義了新的字段，這些字段将其自身和其他BO從業務上區分開來。
這些模型在SAP全球客戶多年使用過程中，暴露出一些局限性和不足，例如一個Customer/Vendor隻能維護一套位址資訊；沒有角色的概念，一個業務夥伴沒法維護成既是Customer又是Vendor；沒辦法維護一些和時間相關的屬性。
這些不足到了S/4HANA得到了妥善解決。在S/4HANA裡，所有不同類型的業務夥伴使用統一的Business Partner模型。R/3的Customer和Vendor使用各自的模型和資料庫表，到了S/4HANA，這些模型統一成Business Partner，通過BP Role來區分其角色，底層的資料庫表也統一使用Business Partner的資料庫表。
為了確定大量源自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的客戶明細資料，
Hybris ECP backoffice裡也存在Customer和Employee模型。因為是backoffice的使用場景，是以和前文介紹的SAP CRM和SAP C4C不同，這裡的客戶頁面還包含一些其他次元的資訊維護，比如密碼政策和密碼重置功能。
按照同樣的邏輯再從Principal往上追溯，可以得到完整的類型繼承鍊:
Customer->User->Principal->GenericItems->LocalizableItem->ExtensibleItem->Item。
由此得知Hybris的類型系統，對于Customer和User這些業務模型的關系描述采用的是繼承的思路，而ABAP Dictionary裡的類型模型則采用的是組合的思路。若幹業務上相關的字段被放到一個結構體裡，若幹結構體再組合(include)成一個規模更大的結構體，最終形成一個給外界消費的結構體。
SAP Revenue Cloud是SAP最近釋出的一款雲解決方案。該方案能動态地規劃、創新和調整系統，從雲端自動管理和配置定價，報價，計費和訂購等流程，進而超越報價到收款流程，通過變革實作盈利。
點選Customer tile檢視客戶主資料：
這些資料請求由部署在SCP上基于Java實作的Revenue Cloud微服務負責響應并傳回給UI5前台。
SAP Hybris Engagement Center是SAP新一代全管道呼叫中心SaaS産品。在坐席和客戶的互動場景裡，坐席需要在最短的時間内搜尋出系統裡存在的客戶或完成新客戶的建立工作。
通過expand指令在一個請求裡将客戶模型的擡頭資訊及位址資訊一并取回。觀察HTTP請求的響應結構，得知Engagement Center的客戶模型裡，位址資訊維護在子節點Addresses上。
這篇文章簡要介紹了SAP幾款産品中客戶模型的模組化情況。通過SAP不同産品裡客戶資料模型的比較，我們了解到這些模型的複雜程度随使用場景的不同而有所差別。您也可以按照本文介紹的使用Chrome開發者工具這一方法，自行研究您感興趣的SAP産品裡的模型設計。甚至，您可以用同樣的方法看看Salesforce的客戶模型是怎樣設計的。
感謝閱讀。