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

創(chuàng)新互聯(lián)公司是一家專注于網站制作、成都網站建設與策劃設計,謝家集網站建設哪家好?創(chuàng)新互聯(lián)公司做網站,專注于網站建設十載,網設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:謝家集等地區(qū)。謝家集做網站價格咨詢:028-86922220

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

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

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

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

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

比如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)能跳轉到的目標狀態(tài)的ID，必須在由該字段的Low和High定義的區(qū)間內。

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

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

1. 很多SAP的客戶，除了購買SAP的On-Premises產品或者訂閱云服務外，還擁有其他業(yè)務系統(tǒng)。這類客戶的訂單編排，在SAP標準業(yè)務流程基礎上往往還存在和這些第三方業(yè)務系統(tǒng)的交互。

2. 即使是同一行業(yè)的客戶群，因為地域和國家，語言的差異，可能業(yè)務流程也存在一定的差異。SAP發(fā)布的標準功能有時無法100%支持這些千差萬別的業(yè)務流程。

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

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

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

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

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

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

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

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

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

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

如果客戶對其中某個業(yè)務步驟需要做增強(需要替換某根水管), 只需要用一個自己實現(xiàn)的函數(shù)去替換SAP標準函數(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è)務功能增強。有些Hook可能存在某些讀寫限制，比如AfterLoading這個Hook，會在SAP BO的標準加載邏輯執(zhí)行完畢后被調用，在這個Hook的實現(xiàn)里，SAP不允許任何對BO節(jié)點標準字段的寫操作，以避免Partners的增強對SAP標準流程可能帶來的影響。有的顧問朋友可能會說，這些Hook不就是SAP Netweaver里傳統(tǒng)的Business AddIn(BAdI)么？沒錯，概念上可以這么理解，需要提醒的就是，這些Hook創(chuàng)建之后，在ABAP后臺并不是以BAdI Implementation的方式存儲，而是以ESF2 Determination的方式存儲，類似下圖這種BOPF里的Determination：

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

網站題目：SAP訂單編排和流程增強的方法是什么-創(chuàng)新互聯(lián)
URL鏈接：http://chinadenli.net/article42/dhjjec.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站收錄、軟件開發(fā)、移動網站建設、網站設計公司、網站改版、定制網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)