共計(jì) 4777 個(gè)字符，預(yù)計(jì)需要花費(fèi) 12 分鐘才能閱讀完成。
基于 SAP Kyma 的訂單編排增強(qiáng)是怎樣的，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。
盡管有一萬個(gè)舍不得，2018 年還是無可挽回地離我們遠(yuǎn)去了。
唯有 SAP 成都研究院的同事和我去年在網(wǎng)絡(luò)上留下的這些痕跡，能證明 2018 年我們?cè)?jīng)很認(rèn)真地去度過每一天：
SAP 成都研究院 2018 年總共 87 篇技術(shù)文章合集
一個(gè) SAP 開發(fā)人員的 2018 年終總結(jié)
今天寫的這篇文章也是因?yàn)楣ぷ餍枰Ｊ紫冉榻B SAP 傳統(tǒng)產(chǎn)品里的訂單編排增強(qiáng)技術(shù)，再來了解一下同樣的增強(qiáng)需求，SAP Kyma 是如何完成的。
SAP 產(chǎn)品里的訂單處理流程，無論是 On-Premises 解決方案還是云產(chǎn)品，我認(rèn)為歸根到底可以概括成四個(gè)字：訂單編排，包含兩個(gè)層次的內(nèi)容：
1. 單個(gè)訂單通過業(yè)務(wù)流程或者工作流驅(qū)動(dòng)的狀態(tài)遷移，比如從初始的 Created 狀態(tài)，經(jīng)過一系列操作，最后進(jìn)入 Closed 狀態(tài)；
2. 多種類型的訂單協(xié)同工作，完成一個(gè)完整的端到端業(yè)務(wù)流程。典型的例子有銷售自動(dòng)化 (Sales Force Automation) 里的從 Lead, Opportunity, Quotation 到 Contract，Order 這些不同類型的訂單協(xié)同。
SAP 系統(tǒng)里訂單狀態(tài)的遷移到底有多復(fù)雜？復(fù)雜度絕對(duì)遠(yuǎn)超初學(xué)者的想象。
以 SAP CRM 為例，在我使用的 SAP CRM 714 系統(tǒng)里，訂單狀態(tài)總共有 906 種，這不得不讓人佩服 SAP CRM 當(dāng)初的設(shè)計(jì)者考慮問題的周全。
即便已經(jīng)設(shè)計(jì)了這九百零幾種狀態(tài)，SAP 仍然考慮到了客戶可能的狀態(tài)擴(kuò)展需求，因此采用了一種經(jīng)典的 User Status(用戶自定義狀態(tài))和 System Status(SAP 標(biāo)準(zhǔn)狀態(tài))的兩層狀態(tài)設(shè)計(jì)，讓用戶能夠隨便定義的 User Status 通過扮演中間層角色的 Business Transaction，映射到能夠被 SAP 標(biāo)準(zhǔn)程序所感知的 System Status。
上圖左邊的 Open, In process，Released 和 Completed 就是用戶自定義訂單狀態(tài)，SAP 允許客戶給每個(gè)狀態(tài)分配一個(gè) Low 和 High 的值，通過這兩個(gè)值巧妙地提供了一種用非圖形化方式進(jìn)行狀態(tài)跳轉(zhuǎn)的功能。
比如 In process 狀態(tài)的 Low 為 20，意味著 In process 狀態(tài)不可能重新回到 Open 狀態(tài)，因?yàn)?Open 狀態(tài)的 ID 10 小于 In process 狀態(tài)的 Low 字段定義的 20——一個(gè)狀態(tài)能跳轉(zhuǎn)到的目標(biāo)狀態(tài)的 ID，必須位于由該字段的 Low 和 High 定義的區(qū)間內(nèi)。
除了復(fù)雜的狀態(tài)處理和跳轉(zhuǎn)外，SAP 訂單編排的復(fù)雜度主要體現(xiàn)在以下方面：
1. 很多 SAP 的客戶，除了購(gòu)買 SAP 的 On-Premises 產(chǎn)品或者訂閱云服務(wù)外，還擁有其他業(yè)務(wù)系統(tǒng)。這類客戶的訂單編排，在 SAP 標(biāo)準(zhǔn)業(yè)務(wù)流程基礎(chǔ)上往往還存在和這些第三方業(yè)務(wù)系統(tǒng)的交互。
2. 即使是同一行業(yè)的客戶群，因?yàn)榈赜蚝蛧?guó)家，語言的差異，可能業(yè)務(wù)流程也存在一定的區(qū)別。SAP 發(fā)布的標(biāo)準(zhǔn)功能有時(shí)無法 100% 支持這些在細(xì)節(jié)上存在千差萬別的業(yè)務(wù)流程。
因此 SAP 系統(tǒng)對(duì)訂單編排增強(qiáng)的支持就非常必要。
當(dāng)然，不同的 SAP 產(chǎn)品，對(duì)訂單增強(qiáng)的實(shí)現(xiàn)方式也各不相同。
在 SAP CRM 里，雖然 SAP 沒有明確提出 Business Object 這個(gè)概念，但訂單應(yīng)用基于的模型實(shí)際上仍然是由不同的節(jié)點(diǎn)組成：
每個(gè)節(jié)點(diǎn)對(duì)應(yīng)一些更底層的模型節(jié)點(diǎn)，其上可以注冊(cè)各種事件處理函數(shù)。下圖是 Service Request 這個(gè) BO 的抬頭節(jié)點(diǎn)的事件處理函數(shù)：
每種事件觸發(fā)時(shí)，注冊(cè)的函數(shù)會(huì)自動(dòng)執(zhí)行。
每個(gè)節(jié)點(diǎn)可以分配一個(gè)或多個(gè)執(zhí)行函數(shù)。當(dāng)然，嚴(yán)謹(jǐn)?shù)牡聡?guó)人在最簡(jiǎn)單的觀察 - 發(fā)布者模式上又添加了幾個(gè)維度的設(shè)置。
下圖第一列紅色的 Execution Time，表示這些分配的函數(shù)到底是事件觸發(fā)后立即執(zhí)行，還是延遲到訂單抬頭或者行項(xiàng)目的通用例程執(zhí)行完后再執(zhí)行(往往用于實(shí)現(xiàn)批量操作，或者待執(zhí)行函數(shù)同通用例程存在依賴關(guān)系，或者出于性能考慮）。
第二列的 Priority，即函數(shù)執(zhí)行優(yōu)先級(jí)，如果若干函數(shù)除了優(yōu)先級(jí)外其他維度維護(hù)的屬性完全一致，則按優(yōu)先級(jí)從高到低依次執(zhí)行。
第三列 Event，就是觀察者 - 發(fā)布者模式里的事件了，下面是 SAP CRM 訂單框架一些標(biāo)準(zhǔn)的事件：
最后一列就是事件監(jiān)聽函數(shù)。
Jerry 傾向于把 CRM 訂單處理系統(tǒng)的運(yùn)作方式理解成類似下圖這種復(fù)雜的水管傳輸系統(tǒng)，訂單業(yè)務(wù)流程依次通過注冊(cè)在不同事件上的監(jiān)聽函數(shù)去執(zhí)行，就像水從這一根根大小粗細(xì)長(zhǎng)短各異的水管流過一樣。
如果客戶對(duì)其中某個(gè)業(yè)務(wù)步驟需要做增強(qiáng)(需要替換某根水管), 只需要用一個(gè)自己實(shí)現(xiàn)的函數(shù)去替換 SAP 標(biāo)準(zhǔn)函數(shù)(自己另外找一根水管替換掉現(xiàn)在正在工作的水管），能替換的前提是自己實(shí)現(xiàn)的函數(shù)的接口同被替換函數(shù)完全一致(自己另外找的水管和以前的水管兩端接口的規(guī)格完全一致）。
而 SAP Cloud for Customer 里的訂單模型，其 Business Object 在目前最新的 1811 版本里仍然是由 ESF2 框架實(shí)現(xiàn)，只是后臺(tái)對(duì) Partners 不可見，但大家可以類比 SAP On-Premises 世界里的 BOPF 框架，兩個(gè)框架的實(shí)現(xiàn)原理類似。
在 Cloud 世界里，想對(duì)訂單處理流程做增強(qiáng)，同之前介紹的 SAP CRM 相比，相對(duì)來說受的限制要多一些。
在 Partner 做增強(qiáng)開發(fā)的 Cloud Application Studio 里，所有能做增強(qiáng)的點(diǎn)以 Hook 的方式顯示如下:
Partners 可以在這些 Hook 里進(jìn)行業(yè)務(wù)功能增強(qiáng)開發(fā)。有些 Hook 可能存在某些讀寫限制，比如 AfterLoading 這個(gè) Hook，會(huì)在 SAP BO 的標(biāo)準(zhǔn)加載邏輯執(zhí)行完畢后被調(diào)用，在這個(gè) Hook 的實(shí)現(xiàn)里，SAP 不允許任何對(duì) BO 節(jié)點(diǎn)標(biāo)準(zhǔn)字段的寫操作，以避免 Partners 的增強(qiáng)對(duì) SAP 標(biāo)準(zhǔn)流程可能帶來的影響。有的顧問朋友可能會(huì)說，這些 Hook 不就是 SAP Netweaver 里傳統(tǒng)的 Business AddIn(BAdI)么？沒錯(cuò)，概念上可以這么理解，需要提醒的就是，這些 Hook 創(chuàng)建之后，在 ABAP 后臺(tái)并不是以 BAdI Implementation 的方式存儲(chǔ)，而是以 ESF2 Determination 的方式存儲(chǔ)，類似下圖這種 BOPF 里的 Determination：
站在巨人肩膀上的牛頓：Kubernetes 和 SAP Kyma
已經(jīng)介紹了這兩個(gè)問題的答案，所以本文不再重復(fù)，直接上實(shí)例了。
我們假設(shè)需要對(duì) SAP Hybris Commerce 的下單流程做增強(qiáng)，在標(biāo)準(zhǔn)的 Fraud(欺詐)檢查里加入我們?cè)?Kyma 里實(shí)現(xiàn)的自定義檢查流程。
如下圖所示，其中淺藍(lán)色的矩形框代表我們用 Kyma 實(shí)現(xiàn)的自定義 Fraud 檢查邏輯。
具體增強(qiáng)了哪些檢查邏輯呢？從下的訂單里拿到下訂單的客戶 ID，然后在 Kyma 里調(diào)用 SAP Marketing Cloud 和 SAP 云平臺(tái)上提供的服務(wù)對(duì)這個(gè)客戶做校驗(yàn)，Kyma 拿到校驗(yàn)結(jié)果后，再傳回 Commerce。
下面是具體步驟。
1. 首先登錄 Commerce 的 back office 頁面，定義一個(gè)新的 action，ID 為 EXTERNAL_KYMA_FRAUD_CHECK。做過 ABAP 開發(fā)的朋友們不難理解這個(gè) action，可以類比成 ABAP 里的 action profile，用于存儲(chǔ)和維護(hù) Partner 的增強(qiáng)。
2. 進(jìn)到 Kyma 的 console 頁面：
選擇一個(gè) stage 進(jìn)去，點(diǎn)擊 Lambdas 進(jìn)入編輯頁面：
image.gif
新建一個(gè) Lambda function，取名 fraudcheck2。我們所有的增強(qiáng)邏輯就寫在這個(gè)函數(shù)里。
這個(gè)函數(shù)自動(dòng)創(chuàng)建的標(biāo)簽(Labels)，Kubernetes 老司機(jī)們一定覺得很親切。這些標(biāo)簽其實(shí)和大家現(xiàn)實(shí)工作中使用云筆記里的標(biāo)簽，以及圖片管理軟件里的標(biāo)簽作用相同，就是一種鍵值對(duì)(Key Value Pair), 可以允許用戶將 Kubernetes 對(duì)象進(jìn)行靈活分組，并提供高效的檢索。
這個(gè)標(biāo)簽的概念不是 Kyma 發(fā)明的，而是 Kubernetes 的標(biāo)準(zhǔn)功能。
Function Trigger 里可以指定這些 Lambda 函數(shù)在哪些事件觸發(fā)后執(zhí)行，思路和前文介紹的 SAP CRM 函數(shù)注冊(cè)一致。選擇第一步定義了新的 action 后對(duì)應(yīng)的 event：
關(guān)于 Lambda 函數(shù)具體的實(shí)現(xiàn)，做過 nodejs 開發(fā)的朋友們一定不會(huì)覺得陌生。
首先第 18 行，19 行從 event 這個(gè)輸入?yún)?shù)對(duì)象里取得發(fā)生事件的訂單 Code，然后第 26 行消費(fèi) OCC(Omni Commerce Channel)Restul API 獲得訂單明細(xì)，從明細(xì)里獲得訂單的客戶 ID，再調(diào)用第 30 行的代碼根據(jù)客戶 ID 拿到客戶明細(xì)，然后使用第 37 行和第 40 行的代碼分別檢查該客戶的郵箱地址是否有效，以及該客戶是否第一次下單。
注意第 43 行和 46 行的代碼我暫時(shí)注釋掉，稍后才會(huì)啟用。
現(xiàn)在我們來測(cè)試一下。在 Commerce 里下一個(gè)單，記下訂單 ID 2139。
回到 Commerce back office 頁面，查看剛才下的訂單的 Business Process，輸入 2139 進(jìn)行查詢：
這里根據(jù) ID EXTERNAL_KYMA_FRAUD_CHECK 進(jìn)行搜索，找到了剛才第一步新建的基于 Kyma action 對(duì)應(yīng)的流程日志記錄：
我們?cè)偃ゲ榭催@個(gè)訂單的 Fraud 檢查記錄：
點(diǎn)這個(gè) Fraud Reports 查看檢查結(jié)果。這個(gè)標(biāo)簽從左到右依次排開的風(fēng)格很像 Fiori 和 ABAP Webdynpro。
可以看見前文介紹的 Email 有效性檢查和是否是首單的檢查結(jié)果。
Email 檢查結(jié)果：客戶的郵箱地址有效。
首單檢查返回的分?jǐn)?shù)是 100，根據(jù)當(dāng)前 Commerce 配置文件這個(gè)結(jié)果被認(rèn)定為首單。具體配置文件的位置和本文主題無關(guān)，這里不詳述。
現(xiàn)在再回到 Kyma 的 Lambda 函數(shù)編輯器里，將之前注釋掉的從 Marketing Cloud 獲取聯(lián)系人地址的函數(shù)以及調(diào)用 SAP 云平臺(tái)的 Business Partner 服務(wù)的函數(shù)重新啟用：
啟用之后，保存，然后進(jìn)入 Service Catalog。這個(gè)組件也是 Kubernetes 提供的標(biāo)準(zhǔn)組件，Kyma 基于它做了增強(qiáng)，能夠?qū)⒌谌降姆?wù)導(dǎo)入進(jìn)來給 Kyma 的 Lambda 函數(shù)消費(fèi)。
這里能看到已經(jīng)導(dǎo)入了很多第三方服務(wù)。我們其實(shí)可以把這個(gè)界面類比成 SAP 云平臺(tái)的 Service Market Place。
選擇 SAP 云平臺(tái)的 Business Partner Service：
接下來的步驟和我們?cè)?SAP 云平臺(tái)上消費(fèi)一個(gè)服務(wù)類似，首先創(chuàng)建一個(gè)服務(wù)實(shí)例：
然后再基于這個(gè)服務(wù)實(shí)例創(chuàng)建一個(gè)綁定，
image.gif
綁定類型設(shè)置成 Function Binding，綁定的目標(biāo)設(shè)置成之前編輯好的 Lambda 函數(shù)。
現(xiàn)在再下一個(gè)單試試，下單客戶選擇同第一個(gè)訂單相同的客戶：
這一次，這個(gè)第二次下的訂單的 Fraud 檢查報(bào)告，同第一個(gè)訂單相比就多了兩條記錄：
首先看第二條首單檢查的記錄，得分為 0，和我們期望的結(jié)果一致，因?yàn)檫@已經(jīng)不是該客戶第一次下單了：
從 Marketing Cloud 的服務(wù)返回的檢查結(jié)果：
從 SAP 云平臺(tái)的 Business Partner 服務(wù)返回的結(jié)果可以看出，下單的這個(gè)客戶不存在一個(gè)對(duì)應(yīng)的 Business Partner。
這個(gè)例子，在 Commerce 下單流程中通過 Kyma 去訪問 Marketing Cloud 和 SAP 云平臺(tái)上的服務(wù)進(jìn)行額外的 Fraud 檢查，業(yè)務(wù)上來說可能意義不大，更多的是從技術(shù)的角度出發(fā)，介紹了這種基于微服務(wù)架構(gòu)的訂單編排增強(qiáng)方式。
關(guān)于基于 SAP Kyma 的訂單編排增強(qiáng)是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注丸趣 TV 行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
