怎么進行SAP CRM系統訂單模型的設計與實現

怎么進行SAP CRM系統訂單模型的設計與實現，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

和傳統的增刪改查相比，以訂單編排領域為例，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社區了，這里只簡述一些核心概念。

• https://blogs.sap.com/2018/03/02/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-1/

• https://blogs.sap.com/2018/03/05/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-2/

為什么要改造？因為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系統訂單模型的設計與實現的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！