基於SAP Kyma的訂單編排加強介紹

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

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

• SAP成都研究院2018年總共87篇技術文章合集
• 一個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進入編輯頁面：

新建一個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行的代碼分別檢查該客戶的郵箱地址是否有效，以及該客戶是否第一次下單。

注意第43行和46行的代碼我暫時註釋掉，稍後纔會啓用。

如今咱們來測試一下。在Commerce裏下一個單，記下訂單ID 2139。

回到Commerce back office頁面，查看剛纔下的訂單的Business Process，輸入2139進行查詢：

這裏根據ID EXTERNAL_KYMA_FRAUD_CHECK進行搜索，找到了剛纔第一步新建的基於Kyma action對應的流程日誌記錄：

咱們再去查看這個訂單的Fraud檢查記錄：

點這個Fraud Reports查看檢查結果。這個標籤從左到右依次排開的風格很像Fiori和ABAP Webdynpro。

能夠看見前文介紹的Email有效性檢查和是不是首單的檢查結果。

Email檢查結果：客戶的郵箱地址有效。

首單檢查返回的分數是100，根據當前Commerce配置文件這個結果被認定爲首單。具體配置文件的位置和本文主題無關，這裏不詳述。

如今再回到Kyma的Lambda函數編輯器裏，將以前註釋掉的從Marketing Cloud獲取聯繫人地址的函數以及調用SAP雲平臺的Business Partner服務的函數從新啓用：

啓用以後，保存，而後進入Service Catalog。這個組件也是Kubernetes提供的標準組件，Kyma基於它作了加強，可以將第三方的服務導入進來給Kyma的Lambda函數消費。

這裏能看到已經導入了不少第三方服務。咱們其實能夠把這個界面類比成SAP雲平臺的Service Market Place。

選擇SAP雲平臺的Business Partner Service：

接下來的步驟和咱們在SAP雲平臺上消費一個服務相似，首先建立一個服務實例：

而後再基於這個服務實例建立一個綁定，

綁定類型設置成Function Binding，綁定的目標設置成以前編輯好的Lambda函數。

如今再下一個單試試，下單客戶選擇同第一個訂單相同的客戶：

這一次，這個第二次下的訂單的Fraud檢查報告，同第一個訂單相比就多了兩條記錄：

首先看第二條首單檢查的記錄，得分爲0，和咱們指望的結果一致，由於這已經不是該客戶第一次下單了：

從Marketing Cloud的服務返回的檢查結果：

從SAP雲平臺的Business Partner服務返回的結果能夠看出，下單的這個客戶不存在一個對應的Business Partner。

本文這個例子，在Commerce下單流程中經過Kyma去訪問Marketing Cloud和SAP雲平臺上的服務進行額外的Fraud檢查，業務上來講可能意義不大，更多的是從技術的角度出發，介紹了這種基於微服務架構的訂單編排加強方式。

祝你們新年快樂! 

相關閱讀

• 站在巨人肩膀上的牛頓：Kubernetes和SAP Kyma
• 在Kubernetes上運行SAP UI5應用(上）
• 在Kubernetes上運行SAP UI5應用(下)

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