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

為蘇州等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及蘇州網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、蘇州網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

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

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

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

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

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

比如In process狀態(tài)的Low為20，意味著In process狀態(tài)不可能重新回到Open狀態(tài)，因?yàn)镺pen狀態(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)。

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

除了復(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ǔ)言的差異，可能業(yè)務(wù)流程也存在一定的差異。SAP發(fā)布的標(biāo)準(zhǔn)功能有時(shí)無(wú)法100%支持這些千差萬(wàn)別的業(yè)務(wù)流程。

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

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

在SAP CRM里，雖然SAP沒(méi)有明確提出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ù)：

每個(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)聽(tīng)函數(shù)。

Jerry傾向于把CRM訂單處理系統(tǒng)的運(yùn)作方式理解成類似下圖這種復(fù)雜的水管傳輸系統(tǒng)，訂單業(yè)務(wù)流程依次被注冊(cè)在不同事件上的監(jiān)聽(tīng)函數(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不可見(jiàn)，但大家可以類比SAP On-Premises世界里的BOPF框架，兩個(gè)框架的實(shí)現(xiàn)原理類似。

在Cloud的世界里，想對(duì)訂單處理流程做增強(qiáng)，同之前介紹的SAP CRM相比，相對(duì)來(lái)說(shuō)受的限制要多一些。

在Partner做增強(qiáng)的Cloud Application Studio里，所有能做增強(qiáng)的點(diǎn)以Hook的方式顯示如下:

Partners可以在這些Hook里進(jìn)行業(yè)務(wù)功能增強(qiáng)。有些Hook可能存在某些讀寫(xiě)限制，比如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)字段的寫(xiě)操作，以避免Partners的增強(qiáng)對(duì)SAP標(biāo)準(zhǔn)流程可能帶來(lái)的影響。有的顧問(wèn)朋友可能會(huì)說(shuō)，這些Hook不就是SAP Netweaver里傳統(tǒng)的Business AddIn(BAdI)么？沒(méi)錯(cuò)，概念上可以這么理解，需要提醒的就是，這些Hook創(chuàng)建之后，在ABAP后臺(tái)并不是以BAdI Implementation的方式存儲(chǔ)，而是以ESF2 Determination的方式存儲(chǔ)，類似下圖這種BOPF里的Determination：

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