SAP訂單編排和流程增強的方法是什么

本篇內(nèi)容主要講解“SAP訂單編排和流程增強的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“SAP訂單編排和流程增強的方法是什么”吧!

SAP產(chǎn)品里的訂單處理，無論是On-Premises解決方案還是云產(chǎn)品，我認(rèn)為歸根到底可以概括成四個字：訂單編排，包含兩個層次的內(nèi)容：

1. 單個訂單通過業(yè)務(wù)流程或者工作流驅(qū)動的狀態(tài)遷移；

2. 多種訂單類型協(xié)同工作，完成一個完整的端到端的業(yè)務(wù)員流程。

比如SAP CRM里經(jīng)典的User Status(用戶自定義狀態(tài))和System Status(SAP標(biāo)準(zhǔn)狀態(tài))的設(shè)計，通過引入Business Transaction將兩者關(guān)聯(lián)起來，完美地實現(xiàn)了用戶自定義訂單狀態(tài)被SAP標(biāo)準(zhǔn)程序的感知。

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

比如In process狀態(tài)的Low為20，意味著In process狀態(tài)不可能重新回到Open狀態(tài)，因為Open狀態(tài)的ID 10小于In process狀態(tài)的Low字段定義的20——一個狀態(tài)能跳轉(zhuǎn)到的目標(biāo)狀態(tài)的ID，必須在由該字段的Low和High定義的區(qū)間內(nèi)。

用戶狀態(tài)通過Business Transaction映射到的SAP標(biāo)準(zhǔn)狀態(tài)，在我截圖的系統(tǒng)上一共有906個，這不得不讓人佩服SAP CRM當(dāng)初的設(shè)計者考慮問題的周全。

除了復(fù)雜的狀態(tài)處理和跳轉(zhuǎn)外，SAP訂單編排的復(fù)雜度主要體現(xiàn)在以下方面：

1. 很多SAP的客戶，除了購買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è)務(wù)流程也存在一定的差異。SAP發(fā)布的標(biāo)準(zhǔn)功能有時無法100%支持這些千差萬別的業(yè)務(wù)流程。

因此SAP系統(tǒng)對訂單編排增強的支持就非常必要。

當(dāng)然，不同的SAP產(chǎn)品，對訂單增強的實現(xiàn)方式也各不相同。

在SAP CRM里，雖然SAP沒有明確提出Business Object這個名詞，但訂單應(yīng)用基于的模型實際上仍然是由不同的節(jié)點組成：

每個節(jié)點對應(yīng)一些更底層的模型節(jié)點，上面可以注冊各種事件處理函數(shù)。下圖是Service Request這個BO的抬頭節(jié)點的事件處理函數(shù)：

每個節(jié)點可以分配一個分配一個執(zhí)行函數(shù)，當(dāng)然，嚴(yán)謹(jǐn)?shù)牡聡嗽谧詈唵蔚挠^察-發(fā)布者模式上又添加了幾個維度的設(shè)置。

下圖第一列紅色的Execution Time，表示這些分配的函數(shù)到底是事件觸發(fā)后立即執(zhí)行，還是延遲到訂單抬頭或者行項目的通用例程執(zhí)行完后再執(zhí)行(往往用于實現(xiàn)批量操作，或者待執(zhí)行函數(shù)同通用例程存在依賴關(guān)系，或者出于性能考慮）。

第二列的Priority，即函數(shù)執(zhí)行優(yōu)先級，如果若干函數(shù)除了優(yōu)先級外其他維度維護的屬性完全一致，則按優(yōu)先級從高到低依次執(zhí)行。

第三列Event，就是觀察者-發(fā)布者模式里的事件了，下面是SAP CRM訂單框架一些標(biāo)準(zhǔn)的事件：

最后一列就是事件監(jiān)聽函數(shù)。

Jerry傾向于把CRM訂單處理系統(tǒng)的運作方式理解成類似下圖這種復(fù)雜的水管傳輸系統(tǒng)，訂單業(yè)務(wù)流程依次被注冊在不同事件上的監(jiān)聽函數(shù)執(zhí)行，就像這一根根大小粗細(xì)長短各異的水管一樣。

如果客戶對其中某個業(yè)務(wù)步驟需要做增強(需要替換某根水管), 只需要用一個自己實現(xiàn)的函數(shù)去替換SAP標(biāo)準(zhǔn)函數(shù)(自己另外找一根水管替換掉現(xiàn)在正在工作的水管），能替換的前提是自己實現(xiàn)的函數(shù)的接口同被替換函數(shù)完全一致(自己另外找的水管和以前的水管兩端接口的規(guī)格完全一致）。

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

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

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

Partners可以在這些Hook里進行業(yè)務(wù)功能增強。有些Hook可能存在某些讀寫限制，比如AfterLoading這個Hook，會在SAP BO的標(biāo)準(zhǔn)加載邏輯執(zhí)行完畢后被調(diào)用，在這個Hook的實現(xiàn)里，SAP不允許任何對BO節(jié)點標(biāo)準(zhǔn)字段的寫操作，以避免Partners的增強對SAP標(biāo)準(zhǔn)流程可能帶來的影響。有的顧問朋友可能會說，這些Hook不就是SAP Netweaver里傳統(tǒng)的Business AddIn(BAdI)么？沒錯，概念上可以這么理解，需要提醒的就是，這些Hook創(chuàng)建之后，在ABAP后臺并不是以BAdI Implementation的方式存儲，而是以ESF2 Determination的方式存儲，類似下圖這種BOPF里的Determination：

到此，相信大家對“SAP訂單編排和流程增強的方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！