儘管有一萬個捨不得，2018年還是無可挽回地離我們遠去了。

唯有SAP成都研究院的同事和我去年在網路上留下的這些痕跡，能證明2018年我們曾經很認真地去度過每一天：

今天寫的這篇文章也是因為工作需要。本文會首先介紹SAP傳統產品裡的訂單編排增強技術，再來了解一下同樣的增強需求，SAP Kyma是如何完成的。

基於SAP傳統ABAP技術的訂單編排增強技術
基於SAP Kyma的訂單編排增強技術

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

1. 單個訂單透過業務流程或者工作流驅動的狀態遷移，比如從初始的Created狀態，經過一系列操作，最後進入Closed狀態；

2. 多種型別的訂單協同工作，完成一個完整的端到端業務流程。典型的例子有銷售自動化(Sales Force Automation)裡的從Lead, Opportunity, Quotation到Contract，Order這些不同型別的訂單協同。

SAP系統裡訂單狀態的遷移到底有多複雜？複雜度絕對遠超初學者的想象。

以SAP CRM為例，在我使用的SAP CRM 714系統裡，訂單狀態總共有906種，這不得不讓人佩服SAP CRM當初的設計者考慮問題的周全。

即便已經設計了這九百零幾種狀態，SAP仍然考慮到了客戶可能的狀態擴充套件需求，因此採用了一種經典的 User Status (使用者自定義狀態)和 System Status (SAP標準狀態)的兩層狀態設計，讓使用者能夠隨便定義的User Status透過扮演中間層角色的 Business Transaction ，對映到能夠被SAP標準程式所感知的System Status。

上圖左邊的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定義的區間內。

除了複雜的狀態處理和跳轉外，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 Kyma如何完成類似的需求。在使用Kyma之前，大家得對Kyma是什麼，SAP為什麼要開發出Kyma這兩個問題比較清楚才行。我之前的文章站在巨人肩膀上的牛頓：Kubernetes和SAP Kyma 已經介紹了這兩個問題的答案，所以本文不再重複，直接上例項了。

我們假設需要對SAP Hybris Commerce的下單流程做增強，在標準的Fraud(欺詐)檢查里加入我們在Kyma裡實現的自定義檢查流程。

如下圖所示，其中淺藍色的矩形框代表我們用Kyma實現的自定義Fraud檢查邏輯。

具體增強了哪些檢查邏輯呢？從下的訂單裡拿到下訂單的客戶ID，然後在Kyma裡呼叫SAP Marketing Cloud和SAP雲平臺上提供的服務對這個客戶做校驗，Kyma拿到校驗結果後，再傳回Commerce。

下面是具體步驟。

1. 首先登入Commerce的back office頁面，定義一個新的action，ID為EXTERNAL_KYMA_FRAUD_CHECK。做過ABAP開發的朋友們不難理解這個action，可以類比成ABAP裡的action profile，用於儲存和維護Partner的增強。

2. 進到Kyma的console頁面：

選擇一個stage進去，點選Lambdas進入編輯頁面：

image.gif

新建一個Lambda function，取名fraudcheck2。我們所有的增強邏輯就寫在這個函式里。

這個函式自動建立的標籤(Labels)，Kubernetes老司機們一定覺得很親切。這些標籤其實和大家現實工作中使用雲筆記裡的標籤，以及圖片管理軟體裡的標籤作用相同，就是一種鍵值對(Key Value Pair), 可以允許使用者將Kubernetes物件進行靈活分組，並提供高效的檢索。

這個標籤的概念不是Kyma發明的，而是Kubernetes的標準功能。

Function Trigger裡可以指定這些Lambda函式在哪些事件觸發後執行，思路和前文介紹的SAP CRM函式註冊一致。選擇第一步定義了新的action後對應的event：

關於Lambda函式具體的實現，做過nodejs開發的朋友們一定不會覺得陌生。

首先第18行，19行從event這個輸入引數物件裡取得發生事件的訂單Code，然後第26行消費OCC(Omni Commerce Channel)Restul API獲得訂單明細，從明細裡獲得訂單的客戶ID，再呼叫第30行的程式碼根據客戶ID拿到客戶明細，然後使用第37行和第40行的程式碼分別檢查該客戶的郵箱地址是否有效，以及該客戶是否第一次下單。