怎么進行SAP CRM系統(tǒng)訂單模型的設(shè)計與實現(xiàn)，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、成都小程序開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了古藺免費建站歡迎大家使用！

和傳統(tǒng)的增刪改查相比，以訂單編排領(lǐng)域為例，SAP訂單模型的"增"，還需要考慮實際業(yè)務(wù)流程中各種類型的前置和后序訂單，即SAP使用的術(shù)語 文檔流(Document Flow)。

而"改", 除了訂單自身狀態(tài)的遷移外，還包括訂單模型提供的各種可執(zhí)行邏輯。這些邏輯既包括訂單模型本身字段的更改，也可以包括訂單與第三方系統(tǒng)的交互。在很多上下文里，我們稱這些邏輯為Action。

如下圖右下角所示：

既然訂單模型復(fù)雜度如此之高，那么引入一種精良的能支持企業(yè)級訂單編排應(yīng)用的高質(zhì)量建模方式，就顯得至關(guān)重要。

隨便看些例子，SAP CRM總共支持多少種標準的訂單類型？下圖中BUS2000開頭的就是不同的訂單類型，我沒有具體數(shù)過，但是幾十種總是有的。

而SAP Cloud for Customer，雖然位于CRM命名空間下面的Business Object的數(shù)量比SAP CRM要少一些，但是基本的用于實現(xiàn)銷售自動化流程的訂單模型仍然一應(yīng)俱全。

我們先來看SAP CRM的訂單模型。有沒有可能用一套模型來描述SAP CRM支持的幾十種訂單類型呢？有，那就是SAP CRM One Order模型，其自描述的名稱就體現(xiàn)了該模型的特色。

Jerry曾經(jīng)試圖搞清楚"One Order"這個稱呼，是來自SAP官方，還是僅僅被SAP開發(fā)人員內(nèi)部使用。

用搜索引擎根據(jù)關(guān)鍵字One Order搜索，得到的結(jié)果幾乎全是Jerry寫的博客，囧。不過進系統(tǒng)根據(jù)ONE ORDER為關(guān)鍵字還是能搜索出大把的代碼。

我的文章  Jerry的WebClient UI 42篇原創(chuàng)文章合集 里有這張架構(gòu)圖：

其中One Order框架從架構(gòu)上講，位于上圖紅色區(qū)域內(nèi)，包括數(shù)據(jù)庫表，ABAP結(jié)構(gòu)體以及操作它們的API代碼。

SAP One Order框架有多成功？搜索引擎輸入關(guān)鍵字"SAP CRM ONE ORDER", 第一條搜索結(jié)果即Jerry寫的一篇博客。其中第一段話就給大家做了詳細的闡述：

盡管它如此成功，但當Jerry剛剛接觸One Order的時候，吃驚地發(fā)現(xiàn)，竟然沒有一個比較直觀的圖形化界面，能夠顯示出這個模型的全貌。不過瑕不掩瑜，對于一個誕生于20年前的框架來說，我們不應(yīng)該用20年后的標準來苛求它。

我們想象一下，不同類型的訂單，有什么共同點？無非每種訂單都有抬頭結(jié)構(gòu)，行項目。有的結(jié)構(gòu)，從業(yè)務(wù)上說可以同時出現(xiàn)在訂單的抬頭和行項目，比如參與訂單的業(yè)務(wù)伙伴明細(Involved parties), 組織架構(gòu)(Organization Unit)等等。有的字段只有行項目才能出現(xiàn)，比如賣出的產(chǎn)品信息(Product, Scheduled Line)。

SAP One Order建模的原理，類似我們小時候玩的積木。

組成One Order模型最小粒度的單元，就是一個個扮演積木作用的結(jié)構(gòu)體，在事務(wù)碼CRMC_OBJECTS里查看。

下圖是這些結(jié)構(gòu)體的列表，如果SAP標準的結(jié)構(gòu)體不能滿足需要，客戶仍然可以自行創(chuàng)建新的結(jié)構(gòu)體。

然后我們用搭積木的方式，將業(yè)務(wù)上具有關(guān)聯(lián)關(guān)系的若干結(jié)構(gòu)體組合起來，共同分配給某個訂單類型，比如描述服務(wù)流程的訂單類型BUS2000116，就由下列這些結(jié)構(gòu)體組成：

有了模型之后，剩下的就是實現(xiàn)基于這些模型的增刪改查操作，即ABAP編程。

One Order API的代碼實現(xiàn)原理，實際上就是設(shè)計模式里的模板(Template)模式和觀察-發(fā)布者模式的結(jié)合體。

我們學(xué)習(xí)模板模式的時候，有一個經(jīng)典的例子，上帝通過模板模式主宰蕓蕓眾生的生老病死。

我們每個人被父母實例化出來之后，只能被動地實現(xiàn)上帝在模板里定義好的四個方法：生，老，病，死，而不能夠更改這個模板本身，比如調(diào)換這四個方法的順序。即使是喬布斯，也沒有辦法給自己添加一個"永生"的方法。聽起來很殘酷，但這是事實。

那么，One Order框架里，作為One Order應(yīng)用的上帝，定義了哪些模板方法？

事務(wù)碼CRMV_EVENT，指定BUS2000116, 執(zhí)行：

得到下圖列表。紅色的第一列，就是前文提到的組成One Order模型的積木。藍色的第二列，是這些積木對發(fā)生在自己身上的感興趣的事件列表。從圖中可以看到這些事件名稱都是自描述的，比如AFTER_CREATE, BEFORE_CHANGE, BEFORE_DELETE等等。

第三列黑色的ABAP函數(shù)，就是這些事件的監(jiān)聽函數(shù)。

這些監(jiān)聽函數(shù)的后綴EC代表Event Callback。

借助上述框架，One Order應(yīng)用的開發(fā)人員的開發(fā)工作就變得無比輕松：

1. 通過搭積木的方式，定義出自己應(yīng)用需要的One Order模型

2. 實現(xiàn)模型里需要關(guān)注的事件對應(yīng)的監(jiān)聽函數(shù)。

至于這些監(jiān)聽函數(shù)什么時候被調(diào)用到？應(yīng)用開發(fā)人員完全不用操心。

由此我們能發(fā)現(xiàn)，One Order框架的實現(xiàn)，把編程復(fù)雜度從應(yīng)用開發(fā)人員身上轉(zhuǎn)移到了框架實現(xiàn)身上。

One Order框架內(nèi)部的實現(xiàn)比較復(fù)雜，一篇文章的篇幅無法講述清楚。況且通常情況下，One Order框架的使用者只需要了解CRM_ORDER_READ, CRM_ORDER_MAINTAIN等API的用法即可。

如果想了解更多細節(jié)，可以參考我的SAP社區(qū)博客：

1. Buffer logic in One Order header extension Read

https://blogs.sap.com/2017/03/22/buffer-logic-in-one-order-header-extension-read/

2. Logic of FILL_OW function module in One Order

https://blogs.sap.com/2017/03/22/logic-of-fill_ow-function-module-in-one-order/

3. Logic of CHANGE_OW function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-change_ow-function-module-in-one-order/

4. Logic of CREATE_OW function module in One Order

https://blogs.sap.com/2017/03/24/logic-of-create_ow-function-module-in-one-order/

5. Logic of SAVE_EC function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-save_ec-function-module-in-one-order/

6. CHANGED_AT, HEAD_CHANGED_AT and CRM_CHANGED_AT in order header table

https://blogs.sap.com/2017/04/27/changed_at-head_changed_at-and-crm_changed_at-in-order-header-table/

One Order的API之一，為消費者提供修改操作的CRM_ORDER_MAINTAIN, 所有SAP標準支持的結(jié)構(gòu)體都作為輸入?yún)?shù)之一出現(xiàn)在參數(shù)列表里:

這種設(shè)計方法雖然讓參數(shù)列表顯得有點冗長,但是從另一方面看，也起到了自描述的效果, 確保API的使用者即使不閱讀文檔,僅憑瀏覽這些參數(shù)本身,就能大概了解該API到底支持One Order哪些數(shù)據(jù)的修改。

這也符合那份著名的來自Google的API設(shè)計最佳實踐文檔里提到的，好的API應(yīng)該滿足的條件之一：易學(xué)易用，自描述，不易造成誤解。

在我的另一篇文章  Hello World, S/4HANA for Customer Management 1.0  我曾經(jīng)提到，SAP CRM的部分功能遷移到SAP S/4HANA后，部分實現(xiàn)做了一些改造，其中就包括One Order的改造。

Jerry是負責(zé)One Order改造設(shè)計的三位人員之一，詳細的改造原理和實現(xiàn)我已經(jīng)分享到SAP社區(qū)了，這里只簡述一些核心概念。

• https://blogs.sap.com/2018/03/02/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-1/

• https://blogs.sap.com/2018/03/05/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-2/

為什么要改造？因為SAP CRM搬到了S/4HANA上，而S/4HANA的一個強大之處，在我同事Zhang Sean的文章  S/4HANA業(yè)務(wù)角色概覽之訂單到收款篇  里也提到了，那就是S/4HANA在SAP歷史上第一次實現(xiàn)了OLTP和OLAP的完美結(jié)合，即一套系統(tǒng)的唯一數(shù)據(jù)源，可以同時滿足Transaction事務(wù)型應(yīng)用和Analytics分析報表型應(yīng)用的需要。

而SAP CRM One Order沒有改造之前的模型是無法和S/4HANA的上述特性匹配的。

改造之前，每個組成One Order模型最小粒度的結(jié)構(gòu)體，都有自己獨立的一張專屬數(shù)據(jù)庫表，命名規(guī)范一般是CRMD_加上結(jié)構(gòu)體名。

這套底層存儲模型如果原封不動地搬到S/4HANA里，在運行報表統(tǒng)計等應(yīng)用時會出現(xiàn)性能問題——為了取出報表結(jié)果，后臺需要在很多個結(jié)構(gòu)體的存儲表中做各種數(shù)據(jù)庫表的內(nèi)外連接操作。當參與連接操作的數(shù)據(jù)庫表尺寸增長到一定數(shù)量級后，整個應(yīng)用的性能表現(xiàn)不佳。Jerry也參與了性能評測，最后我們決定對One Order的底層數(shù)據(jù)模型做改造。

因為留給我們從調(diào)研到改造的原型開發(fā)，再到正式開發(fā)一共只有八個月的時間，因此我們選擇了一種代價最小，對One Order框架改動最小的方式。

首先我們拋棄了之前每個結(jié)構(gòu)體擁有一張專屬數(shù)據(jù)庫表的做法，在S/4HANA里，每種訂單類型只擁有兩張表，一張存儲抬頭級別的數(shù)據(jù)，另一張存放行項目數(shù)據(jù)。之前散落在不同結(jié)構(gòu)體表中的字段，如今統(tǒng)一維護在這兩張表里。由于所有的字段都平鋪在這兩張表里，我們內(nèi)部形象地稱其為平坦表(Flattened Table)。

存儲模型大大簡化之后，我們基于這兩張表再創(chuàng)建CDS view，讓上層的報表應(yīng)用消費。這樣改造后簡化的模型，能滿足S/4HANA中OLAP應(yīng)用的需求。

針對S/4HANA OLTP應(yīng)用的改造，用一句話概括，就是我們采用設(shè)計模式里的適配器模式(Adapter), 在API與簡化后的數(shù)據(jù)庫表之間引入一個微型的中間件，扮演Adapter的角色。

當消費者通過One Order API進行讀操作時，中間件負責(zé)把存儲在簡化后的數(shù)據(jù)表中的數(shù)據(jù)進行還原，再填充到One Order API上層的緩存中。對后者來說，它對底層存儲模型發(fā)生的變化毫不知情，因為Adapter封裝了底層數(shù)據(jù)讀取的邏輯并做了格式轉(zhuǎn)換，所以O(shè)ne Order API上層不需要做任何改動，也完全能夠像在SAP CRM里一樣正常運行。

而當消費者調(diào)用One Order API進行寫操作時，在存儲于各個結(jié)構(gòu)體對應(yīng)的緩存中的數(shù)據(jù)持久化到數(shù)據(jù)庫之前，同樣是Adapter負責(zé)把這些分散在不同緩存結(jié)構(gòu)中的數(shù)據(jù)做一個合并，合并后的結(jié)構(gòu)體再寫入平坦表。

講完了CRM One Order訂單模型的設(shè)計，我們再來簡單看看SAP Cloud for Customer的訂單模型設(shè)計。

雖然SAP Cloud for Customer的后臺對客戶和Partners不可見，但我們?nèi)匀豢梢詮暮戏ㄇ阔@得一些其訂單模型的設(shè)計信息。

https://archive.sap.com/discussions/thread/3602400

從SAP社區(qū)上這位SAP員工的回復(fù)，我們得知ESF2和BOPF有很多相似之處，設(shè)計理念類似，但ESF2主要用于部署在云端的產(chǎn)品，比如SAP Cloud for Customer上Business Object的開發(fā)，而后者主要服務(wù)于On Premises解決方案比如S/4HANA。

因為Jerry不能夠把C4C后臺ESF2的界面給大家看，所以我選擇了展示S/4HANA的Business Object開發(fā)框架BOPF，因為前面說了，二者很多方面都非常相似。

同之前介紹的SAP CRM One Order框架一樣，通過BOPF實現(xiàn)的訂單模型，同樣由若干個結(jié)構(gòu)體通過搭積木的方式組成，這些結(jié)構(gòu)體如上圖紅色高亮區(qū)域所示，每個結(jié)構(gòu)體也有自己的專屬存儲數(shù)據(jù)庫表。而SAP CRM One Order里每個結(jié)構(gòu)體的事件監(jiān)聽函數(shù)，采取的是ABAP傳統(tǒng)的面向過程的函數(shù)實現(xiàn)，而BOPF則采取了實現(xiàn)指定接口的ABAP類，二者原理相同，只是實現(xiàn)細節(jié)有差異。

SAP C4C的訂單模型，雖然和SAP CRM傳統(tǒng)的One Order模型一樣，每個結(jié)構(gòu)體擁有一張專屬的數(shù)據(jù)庫表，但是在運行報表程序時并不會出現(xiàn)性能問題，這是怎么做到的？

答案是采用了TREX，一個專為只讀報表應(yīng)用優(yōu)化過的存儲倉庫。換句話說，SAP C4C的事務(wù)處理和報表處理使用的是兩套不同的存儲系統(tǒng)，這一點和S/4HANA不同。

SAP Cloud for Customer的訂單模型，在Cloud Application Studio里對客戶和Partners是可見的，大家感興趣的可以自行去查看。

看完上述內(nèi)容，你們掌握怎么進行SAP CRM系統(tǒng)訂單模型的設(shè)計與實現(xiàn)的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)站名稱：怎么進行SAPCRM系統(tǒng)訂單模型的設(shè)計與實現(xiàn)-創(chuàng)新互聯(lián)
地址分享：http://jinyejixie.com/article36/deppsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、微信小程序、云服務(wù)器、標簽優(yōu)化、網(wǎng)站維護、網(wǎng)站收錄

廣告

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