筆者在 SAP 成都研究院工作多年，從事過多款 SAP 產品的標準開發工作。這些產品裡無一例外地都存在著訂單(Order) 這種資料模型。

訂單模型從資料結構上來說是一棵樹，根節點就是我們通常俗稱的訂單抬頭(Header Level) 結構，主要包含訂單 ID，建立時間，建立者，訂單描述資訊，訂單涉及到的業務合作伙伴(Business Partner)等欄位。

根節點透過所謂的 Association 和 Composition，關聯到其他葉節點，最典型的葉節點就是訂單行專案(Line Item) 結構。行專案包含訂單設計到的產品明細，比如產品 ID，產品數量，產品單價，計稅方式，定價資訊等等。訂單根節點和訂單行專案的對應關係為 `1:N`.

SAP 產品裡的訂單處理，無論是 On-Premises 解決方案還是雲產品，筆者認為歸根到底可以概括成四個字：訂單編排。這個概念包含兩個層次的內容：

1. 單個訂單透過業務流程或者工作流驅動的狀態遷移；換言之，SAP 產品的應用邏輯，實際上透過訂單模型的狀態遷移來體現。
2. 多種訂單型別協同工作，完成一個完整的端到端的業務流程。

![](https://img-blog.csdnimg.cn/img_convert/ccad123d853a36b88ac0367b72c1f2c8.png)

比如 SAP CRM 裡經典的 User Status(使用者自定義狀態)和 System Status(SAP 標準狀態)的設計，透過引入 Business Transaction 將兩者關聯起來，完美地實現了使用者自定義訂單狀態被 SAP 標準程式的感知。

下圖左邊的 Open, In process， Released 和 Completed 就是使用者自定義訂單狀態，SAP 允許客戶給每個狀態分配一個 Low 和 High 的值，透過這種方式巧妙地提供了一種用非圖形化方式進行狀態跳轉的定義。

比如 `In process` 狀態的 Low 為 20，意味著 In process 狀態不可能重新回到 Open 狀態，因為 Open 狀態的 ID 10 小於 In process 狀態的 Low 欄位定義的 20——一個狀態能跳轉到的目標狀態的 ID，必須在由該欄位的 Low 和 High 定義的區間內。

使用者狀態透過 Business Transaction 對映到的 SAP 標準狀態，在我截圖的系統上一共有 906 個，這既體現了 SAP 軟體的高度複雜性，也不得不讓人佩服 SAP CRM 當初的設計者考慮問題的周全。

![](https://img-blog.csdnimg.cn/img_convert/82061eccd3c43603735e78b43872b498.png)

除了複雜的狀態處理和跳轉外，SAP 訂單編排的複雜度主要體現在以下方面：

1. 很多 SAP 的客戶，除了購買 SAP On-Premises 產品或者訂閱雲服務外，還擁有其他業務系統。這類客戶的訂單編排，在 SAP 標準業務流程基礎上往往還存在和這些第三方業務系統的互動。

2. 即使是同一行業的客戶群，因為地域和國家，語言的差異，可能業務流程也存在一定的差異。SAP 釋出的標準功能有時無法 100% 支援這些千差萬別的業務流程。

因此 SAP 系統對訂單編排增強的支援就非常必要。

![](https://img-blog.csdnimg.cn/img_convert/4f8de922256586ee708544725b268a63.png)

當然，不同的 SAP 產品，對訂單增強的實現方式也各不相同。

在 SAP CRM 裡，雖然 SAP 沒有明確提出 Business Object 這個名詞，但訂單應用基於的模型實際上仍然是由不同的節點組成：

![](https://img-blog.csdnimg.cn/img_convert/35e8dda65207d0473a9ca5126ade2a63.png)

每個節點對應一些更底層的模型節點，上面可以註冊各種事件處理函式。下圖是 Service Request 這個 Business Object 的抬頭節點的事件處理函式：

![](https://img-blog.csdnimg.cn/img_convert/fd983897e9ad99158ec1ddbd6a98385c.png)

每個節點可以分配一個分配一個執行函式，當然，嚴謹的德國人在最簡單的觀察-釋出者模式上又新增了幾個維度的設定。

下圖第一列紅色的 Execution Time，表示這些分配的函式到底是事件觸發後立即執行，還是延遲到訂單抬頭或者行專案的通用例程執行完後再執行(往往用於實現批次操作，或者待執行函式同通用例程存在依賴關係，或者出於效能考慮）。

第二列的 Priority，即函式執行優先順序，如果若干函式除了優先順序外其他維度維護的屬性完全一致，則按優先順序從高到低依次執行。

![](https://img-blog.csdnimg.cn/img_convert/2520da1d209d50a56bf204c1e8925636.png)

第三列 Event，就是觀察者-釋出者模式裡的事件了，下面是 SAP CRM 訂單框架一些標準的事件：

![](https://img-blog.csdnimg.cn/img_convert/0d0fe24b8a3d388a3925163fe7b09b1a.png)

最後一列就是事件監聽函式。

筆者傾向於把 CRM 訂單處理系統的運作方式理解成類似下圖這種複雜的水管傳輸系統，訂單業務流程依次被註冊在不同事件上的監聽函式執行，就像這一根根大小粗細長短各異的水管一樣。

如果客戶對其中某個業務步驟需要做增強(需要替換某根水管), 只需要用一個自己實現的函式去替換 SAP 標準函式(自己另外找一根水管替換掉現在正在工作的水管），能替換的前提是自己實現的函式的介面同被替換函式完全一致(自己另外找的水管和以前的水管兩端介面的規格完全一致）。

![](https://img-blog.csdnimg.cn/img_convert/0a38a7c9f54b3c5e98cc64b9558c0b99.png)

而 SAP Cloud for Customer 裡的訂單模型，其 Business Object 在目前最新的 1811 版本里仍然是由 ESF2 框架實現，只是後臺對 Partners 不可見，但大家可以類比 SAP On-Premises 世界裡的 BOPF 框架，兩個框架的實現原理類似。

![](https://img-blog.csdnimg.cn/img_convert/9035c596a86a9a897c0ce59c573af74b.png)

在 Cloud 的世界裡，想對訂單處理流程做增強，同之前介紹的 SAP CRM 相比，相對來說受的限制要多一些。

在 Partner 做增強的 Cloud Application Studio 裡，所有能做增強的點以 Hook 的方式顯示如下:

![](https://img-blog.csdnimg.cn/img_convert/f99a83d86120f15748a014c422580b4c.png)

Partners 可以在這些 Hook 裡進行業務功能增強。有些 Hook 可能存在某些讀寫限制，比如 AfterLoading 這個 Hook，會在 SAP BO 的標準載入邏輯執行完畢後被呼叫，在這個 Hook 的實現裡，SAP 不允許任何對 BO 節點標準欄位的寫操作，以避免 Partners 的增強對 SAP 標準流程可能帶來的影響。

有的顧問朋友可能會說，這些 Hook 不就是 SAP Netweaver 裡傳統的 Business AddIn(BAdI) 麼？沒錯，概念上可以這麼理解，需要提醒的就是，這些 Hook 建立之後，在 ABA P後臺並不是以 BAdI Implementation 的方式儲存，而是以 ESF2 Determination 的方式儲存，類似下圖這種 BOPF 裡的Determination：

![](https://img-blog.csdnimg.cn/img_convert/da2ee12b7d32ba4963b4e1fa186af2f2.png)

# 總結

本文首先給出了 SAP 產品裡訂單模型的統一實現思路，接著選擇 SAP CRM 和 SAP Cloud for Customer 這兩款具有代表性的客戶關係管理解決方案，著重介紹了其訂單編排邏輯的設計原理與實現細節。

SAP 訂單模型的編排方式概述

相關文章