筆者在 SAP 領域工作多年，對 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模型，其自描述的名稱就體現了該模型的特色。
下面是 SAP CRM 應用的架構圖：
其中 One Order框架從架構上講，位於上圖紅色區域內，包括資料庫表，ABAP結構體以及操作它們的API程式碼。
筆者剛剛接觸 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的用法即可。
One Order的API之一，為消費者提供修改操作的CRM_ORDER_MAINTAIN, 所有SAP標準支援的結構體都作為輸入引數之一出現在引數列表裡:
這種設計方法雖然讓引數列表顯得有點冗長,但是從另一方面看，也起到了自描述的效果, 確保API的使用者即使不閱讀文件,僅憑瀏覽這些引數本身,就能大概瞭解該API到底支援One Order哪些資料的修改。
這也符合那份著名的來自 Google 的API設計最佳實踐文件裡提到的，好的API應該滿足的條件之一：易學易用，自描述，不易造成誤解。
SAP CRM 的部分功能遷移到 SAP S/4HANA後，部分實現做了一些改造，其中就包括One Order的改造。
為什麼要改造？因為SAP CRM搬到了S/4HANA上，而S/4HANA的一個強大之處，即 S/4HANA在 SAP 歷史上第一次實現了 OLTP 和 OLAP 的完美結合，即一套系統的唯一資料來源，可以同時滿足Transaction事務型應用和Analytics分析報表型應用的需要。
而SAP CRM One Order沒有改造之前的模型是無法和S/4HANA的上述特性匹配的。
改造之前，每個組成One Order模型最小粒度的結構體，都有自己獨立的一張專屬資料庫表，命名規範一般是CRMD_加上結構體名。
這套底層儲存模型如果原封不動地搬到S/4HANA裡，在執行報表統計等應用時會出現效能問題——為了取出報表結果，後臺需要在很多個結構體的儲存表中做各種資料庫表的內外連線操作。當參與連線操作的資料庫表尺寸增長到一定數量級後，整個應用的效能表現不佳。筆者也參與了效能評測，最後我們決定對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不可見，但我們仍然可以從合法渠道獲得一些其訂單模型的設計資訊。
從SAP社群上這位SAP員工的回覆，我們得知ESF2和BOPF有很多相似之處，設計理念類似，但ESF2主要用於部署在雲端的產品，比如SAP Cloud for Customer上Business Object的開發，而後者主要服務於On Premises解決方案比如S/4HANA。
同之前介紹的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 系統裡訂單模型的演進歷史和設計原理，以及消費該訂單模型的 API，接著介紹了這種模型遷移到 S/4HANA 系統時面臨的挑戰，以及筆者所在專案團隊給出的遷移重構方案。最後將另一款雲端 CRM 系統的訂單模型進行類比，希望對工作於客戶關係管理領域的讀者能有所幫助。