淺談企業管理軟件中客戶模型的設計方式

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

感謝閱讀。

ABAP ERP Java XML

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。