SAP CRM系統訂單模型的設計與實現

i042416發表於2019-01-22

模型

SAP成都研究院的一個部門領導讓我給他的團隊做一個SAP CRM One Order框架的培訓，這是我準備的培訓內容。

在Jerry之前的文章基於SAP Kyma的訂單編排增強介紹，我表達了自己對SAP應用的理解：模型以及基於模型的增刪改查。只是同我們大學專業課學習時完成的家庭作業相比，SAP模型的複雜程度增加了好幾個數量級。

和傳統的增刪改查相比，以訂單編排領域為例，SAP訂單模型的" 增 "，還需要考慮實際業務流程中各種型別的前置和後序訂單，即SAP使用的術語文件流(Document Flow) 。

而" 改 ", 除了訂單自身狀態的遷移外，還包括訂單模型提供的各種可執行邏輯。這些邏輯既包括訂單模型本身欄位的更改，也可以包括訂單與第三方系統的互動。在很多上下文裡，我們稱這些邏輯為Action。

如下圖右下角所示：

既然訂單模型複雜度如此之高，那麼引入一種精良的能支援企業級訂單編排應用的高質量建模方式，就顯得至關重要。

隨便看些例子，SAP CRM總共支援多少種標準的訂單型別？下圖中BUS2000開頭的就是不同的訂單型別，我沒有具體數過，但是幾十種總是有的。

而SAP Cloud for Customer，雖然位於CRM名稱空間下面的Business Object的數量比SAP CRM要少一些，但是基本的用於實現銷售自動化流程的訂單模型仍然一應俱全。

我們先來看SAP CRM的訂單模型。有沒有可能用一套模型來描述SAP CRM支援的幾十種訂單型別呢？有，那就是SAP CRM One Order模型，其自描述的名稱就體現了該模型的特色。

Jerry曾經試圖搞清楚" One Order "這個稱呼，是來自SAP官方，還是僅僅被SAP開發人員內部使用。

用搜尋引擎根據關鍵字One Order搜尋，得到的結果幾乎全是Jerry寫的部落格，囧。不過進系統根據ONE ORDER為關鍵字還是能搜尋出大把的程式碼。

我的文章 Jerry的WebClient UI 42篇原創文章合集裡有這張架構圖：

其中One Order框架從架構上講，位於上圖紅色區域內，包括資料庫表，ABAP結構體以及操作它們的API程式碼。

SAP One Order框架有多成功？搜尋引擎輸入關鍵字" SAP CRM ONE ORDER ", 第一條搜尋結果即Jerry寫的一篇部落格。其中第一段話就給大家做了詳細的闡述：

儘管它如此成功，但當Jerry剛剛接觸One Order的時候，吃驚地發現，竟然沒有一個比較直觀的圖形化介面，能夠顯示出這個模型的全貌。不過瑕不掩瑜，對於一個誕生於20年前的框架來說，我們不應該用20年後的標準來苛求它。

我們想象一下，不同型別的訂單，有什麼共同點？無非每種訂單都有抬頭結構，行專案。有的結構，從業務上說可以同時出現在訂單的抬頭和行專案，比如參與訂單的業務夥伴明細(Involved parties), 組織架構(Organization Unit)等等。有的欄位只有行專案才能出現，比如賣出的產品資訊(Product, Scheduled Line)。

SAP One Order建模的原理，類似我們小時候玩的積木。

組成One Order模型最小粒度的單元，就是一個個扮演積木作用的結構體，在事務碼CRMC_OBJECTS裡檢視。

下圖是這些結構體的列表，如果SAP標準的結構體不能滿足需要，客戶仍然可以自行建立新的結構體。

然後我們用搭積木的方式，將業務上具有關聯關係的若干結構體組合起來，共同分配給某個訂單型別，比如描述服務流程的訂單型別BUS2000116，就由下列這些結構體組成：

有了模型之後，剩下的就是實現基於這些模型的增刪改查操作，即ABAP程式設計。

One Order API的程式碼實現原理，實際上就是設計模式裡的模板 (Template)模式和觀察-釋出者模式的結合體。

我們學習模板模式的時候，有一個經典的例子，上帝通過模板模式主宰芸芸眾生的生老病死。

我們每個人被父母例項化出來之後，只能被動地實現上帝在模板裡定義好的四個方法：生，老，病，死，而不能夠更改這個模板本身，比如調換這四個方法的順序。即使是賈伯斯，也沒有辦法給自己新增一個"永生"的方法。聽起來很殘酷，但這是事實。

那麼，One Order框架裡，作為One Order應用的上帝，定義了哪些模板方法？

事務碼CRMV_EVENT，指定BUS2000116, 執行：

得到下圖列表。紅色的第一列，就是前文提到的組成One Order模型的積木。藍色的第二列，是這些積木對發生在自己身上的感興趣的事件列表。從圖中可以看到這些事件名稱都是自描述的，比如AFTER_CREATE, BEFORE_CHANGE, BEFORE_DELETE等等。

第三列黑色的ABAP函式，就是這些事件的監聽函式。

這些監聽函式的字尾EC代表Event Callback。

藉助上述框架，One Order應用的開發人員的開發工作就變得無比輕鬆：

1. 通過搭積木的方式，定義出自己應用需要的One Order模型

2. 實現模型裡需要關注的事件對應的監聽函式。

至於這些監聽函式什麼時候被呼叫到？應用開發人員完全不用操心。

由此我們能發現，One Order框架的實現，把程式設計複雜度從應用開發人員身上轉移到了框架實現身上。

One Order框架內部的實現比較複雜，一篇文章的篇幅無法講述清楚。況且通常情況下，One Order框架的使用者只需要瞭解CRM_ORDER_READ, CRM_ORDER_MAINTAIN等API的用法即可。

如果想了解更多細節，可以參考我的SAP社群部落格：

1. Buffer logic in One Order header extension Read

https://blogs.sap.com/2017/03/22/buffer-logic-in-one-order-header-extension-read/

2. Logic of FILL_OW function module in One Order

https://blogs.sap.com/2017/03/22/logic-of-fill_ow-function-module-in-one-order/

3. Logic of CHANGE_OW function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-change_ow-function-module-in-one-order/

4. Logic of CREATE_OW function module in One Order

https://blogs.sap.com/2017/03/24/logic-of-create_ow-function-module-in-one-order/

5. Logic of SAVE_EC function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-save_ec-function-module-in-one-order/

6. CHANGED_AT, HEAD_CHANGED_AT and CRM_CHANGED_AT in order header table

https://blogs.sap.com/2017/04/27/changed_at-head_changed_at-and-crm_changed_at-in-order-header-table/

One Order的API之一，為消費者提供修改操作的CRM_ORDER_MAINTAIN, 所有SAP標準支援的結構體都作為輸入引數之一出現在引數列表裡:

這種設計方法雖然讓引數列表顯得有點冗長,但是從另一方面看，也起到了自描述的效果, 確保API的使用者即使不閱讀文件,僅憑瀏覽這些引數本身,就能大概瞭解該API到底支援One Order哪些資料的修改。

這也符合那份著名的來自Google的API設計最佳實踐文件裡提到的，好的API應該滿足的條件之一：易學易用，自描述，不易造成誤解。

在我的另一篇文章 Hello World, S/4HANA for Customer Management 1.0 我曾經提到，SAP CRM的部分功能遷移到SAP S/4HANA後，部分實現做了一些改造，其中就包括One Order的改造。

Jerry是負責One Order改造設計的三位人員之一，詳細的改造原理和實現我已經分享到SAP社群了，這裡只簡述一些核心概念。

為什麼要改造？因為SAP CRM搬到了S/4HANA上，而S/4HANA的一個強大之處，在我同事Zhang Sean的文章 S/4HANA業務角色概覽之訂單到收款篇裡也提到了，那就是S/4HANA在SAP歷史上第一次實現了OLTP和OLAP的完美結合，即一套系統的唯一資料來源，可以同時滿足Transaction事務型應用和Analytics分析報表型應用的需要。

而SAP CRM One Order沒有改造之前的模型是無法和S/4HANA的上述特性匹配的。

改造之前，每個組成One Order模型最小粒度的結構體，都有自己獨立的一張專屬資料庫表，命名規範一般是CRMD_加上結構體名。

這套底層儲存模型如果原封不動地搬到S/4HANA裡，在執行報表統計等應用時會出現效能問題——為了取出報表結果，後臺需要在很多個結構體的儲存表中做各種資料庫表的內外連線操作。當參與連線操作的資料庫表尺寸增長到一定數量級後，整個應用的效能表現不佳。Jerry也參與了效能評測，最後我們決定對One Order的底層資料模型做改造。

因為留給我們從調研到改造的原型開發，再到正式開發一共只有八個月的時間，因此我們選擇了一種代價最小，對One Order框架改動最小的方式。

首先我們拋棄了之前每個結構體擁有一張專屬資料庫表的做法，在S/4HANA裡，每種訂單型別只擁有兩張表，一張儲存抬頭級別的資料，另一張存放行專案資料。之前散落在不同結構體表中的欄位，如今統一維護在這兩張表裡。由於所有的欄位都平鋪在這兩張表裡，我們內部形象地稱其為平坦表 (Flattened Table)。

儲存模型大大簡化之後，我們基於這兩張表再建立CDS view，讓上層的報表應用消費。這樣改造後簡化的模型，能滿足S/4HANA中OLAP應用的需求。

針對S/4HANA OLTP應用的改造，用一句話概括，就是我們採用設計模式裡的介面卡模式 (Adapter), 在API與簡化後的資料庫表之間引入一個微型的中介軟體，扮演Adapter的角色。

當消費者通過One Order API進行讀操作時，中介軟體負責把儲存在簡化後的資料表中的資料進行還原，再填充到One Order API上層的快取中。對後者來說，它對底層儲存模型發生的變化毫不知情，因為Adapter封裝了底層資料讀取的邏輯並做了格式轉換，所以One Order API上層不需要做任何改動，也完全能夠像在SAP CRM裡一樣正常執行。

而當消費者呼叫One Order API進行寫操作時，在儲存於各個結構體對應的快取中的資料持久化到資料庫之前，同樣是Adapter負責把這些分散在不同快取結構中的資料做一個合併，合併後的結構體再寫入平坦表。

講完了CRM One Order訂單模型的設計，我們再來簡單看看SAP Cloud for Customer的訂單模型設計。

雖然SAP Cloud for Customer的後臺對客戶和Partners不可見，但我們仍然可以從合法渠道獲得一些其訂單模型的設計資訊。

https://archive.sap.com/discussions/thread/3602400

從SAP社群上這位SAP員工的回覆，我們得知ESF2和BOPF有很多相似之處，設計理念類似，但ESF2主要用於部署在雲端的產品，比如SAP Cloud for Customer上Business Object的開發，而後者主要服務於On Premises解決方案比如S/4HANA。

因為Jerry不能夠把C4C後臺ESF2的介面給大家看，所以我選擇了展示S/4HANA的Business Object開發框架BOPF，因為前面說了，二者很多方面都非常相似。

同之前介紹的SAP CRM One Order框架一樣，通過BOPF實現的訂單模型，同樣由若干個結構體通過搭積木的方式組成，這些結構體如上圖紅色高亮區域所示，每個結構體也有自己的專屬儲存資料庫表。而SAP CRM One Order裡每個結構體的事件監聽函式，採取的是ABAP傳統的程式導向的函式實現，而BOPF則採取了實現指定介面的ABAP類，二者原理相同，只是實現細節有差異。

SAP C4C的訂單模型，雖然和SAP CRM傳統的One Order模型一樣，每個結構體擁有一張專屬的資料庫表，但是在執行報表程式時並不會出現效能問題，這是怎麼做到的？

答案是採用了 TREX ，一個專為只讀報表應用優化過的儲存倉庫。換句話說，SAP C4C的事務處理和報表處理使用的是兩套不同的儲存系統，這一點和S/4HANA不同。

SAP Cloud for Customer的訂單模型，在Cloud Application Studio裡對客戶和Partners是可見的，大家感興趣的可以自行去檢視。

希望這篇文章能讓大家對SAP CRM兩款產品中的訂單模型設計有最基礎的認識，感謝閱讀。

SAP CRM系統訂單模型的設計與實現

相關文章