SAP訂單編排和流程加強概述

SAP產品裏的訂單處理，不管是On-Premises解決方案仍是雲產品，我認爲歸根到底能夠歸納成四個字：訂單編排，包含兩個層次的內容：

1. 單個訂單經過業務流程或者工做流驅動的狀態遷移；

2. 多種訂單類型協同工做，完成一個完整的端到端的業務員流程。

好比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 CRM當初的設計者考慮問題的周全。

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

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

2. 即便是同一行業的客戶羣，由於地域和國家，語言的差別，可能業務流程也存在必定的差別。SAP發佈的標準功能有時沒法100%支持這些千差萬別的業務流程。

所以SAP系統對訂單編排加強的支持就很是必要。

固然，不一樣的SAP產品，對訂單加強的實現方式也各不相同。

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

每一個節點對應一些更底層的模型節點，上面能夠註冊各類事件處理函數。下圖是Service Request這個BO的擡頭節點的事件處理函數：

每一個節點能夠分配一個分配一個執行函數，固然，嚴謹的德國人在最簡單的觀察-發佈者模式上又添加了幾個維度的設置。

下圖第一列紅色的Execution Time，表示這些分配的函數究竟是事件觸發後當即執行，仍是延遲到訂單擡頭或者行項目的通用例程執行完後再執行(每每用於實現批量操做，或者待執行函數同通用例程存在依賴關係，或者出於性能考慮）。

第二列的Priority，即函數執行優先級，若是若干函數除了優先級外其餘維度維護的屬性徹底一致，則按優先級從高到低依次執行。

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

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

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

若是客戶對其中某個業務步驟須要作加強(須要替換某根水管), 只須要用一個本身實現的函數去替換SAP標準函數(本身另外找一根水管替換掉如今正在工做的水管），能替換的前提是本身實現的函數的接口同被替換函數徹底一致(本身另外找的水管和之前的水管兩端接口的規格徹底一致）。

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

在Cloud的世界裏，想對訂單處理流程作加強，同以前介紹的SAP CRM相比，相對來講受的限制要多一些。

在Partner作加強的Cloud Application Studio裏，全部能作加強的點以Hook的方式顯示以下:

Partners能夠在這些Hook裏進行業務功能加強。有些Hook可能存在某些讀寫限制，好比AfterLoading這個Hook，會在SAP BO的標準加載邏輯執行完畢後被調用，在這個Hook的實現裏，SAP不容許任何對BO節點標準字段的寫操做，以免Partners的加強對SAP標準流程可能帶來的影響。有的顧問朋友可能會說，這些Hook不就是SAP Netweaver裏傳統的Business AddIn(BAdI)麼？沒錯，概念上能夠這麼理解，須要提醒的就是，這些Hook建立以後，在ABAP後臺並非以BAdI Implementation的方式存儲，而是以ESF2 Determination的方式存儲，相似下圖這種BOPF裏的Determination：

SAP C/4HANA裏的五朵雲之一，Commerce Cloud，則能夠經過SAP Kyma來作擴展，咱們下次介紹。

要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":