怎么進(jìn)行SAP CRM系統(tǒng)訂單模型的設(shè)計(jì)與實(shí)現(xiàn)

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

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

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

如下圖右下角所示：

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

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

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

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

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

用搜索引擎根據(jù)關(guān)鍵字One Order搜索，得到的結(jié)果幾乎全是Jerry寫的博客，囧。不過進(jìn)系統(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寫的一篇博客。其中第一段話就給大家做了詳細(xì)的闡述：

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

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

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

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

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

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

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

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

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

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

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

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

得到下圖列表。紅色的第一列，就是前文提到的組成One Order模型的積木。藍(lán)色的第二列，是這些積木對發(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. 實(shí)現(xiàn)模型里需要關(guān)注的事件對應(yīng)的監(jiān)聽函數(shù)。

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

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

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

如果想了解更多細(xì)節(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之一，為消費(fèi)者提供修改操作的CRM_ORDER_MAINTAIN, 所有SAP標(biāo)準(zhǔn)支持的結(jié)構(gòu)體都作為輸入?yún)?shù)之一出現(xiàn)在參數(shù)列表里:

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

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

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

Jerry是負(fù)責(zé)One Order改造設(shè)計(jì)的三位人員之一，詳細(xì)的改造原理和實(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/

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

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

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

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

因?yàn)榱艚o我們從調(diào)研到改造的原型開發(fā)，再到正式開發(fā)一共只有八個(gè)月的時(shí)間，因此我們選擇了一種代價(jià)最小，對One Order框架改動(dòng)最小的方式。

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

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

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

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

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

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

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

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

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

因?yàn)镴erry不能夠把C4C后臺(tái)ESF2的界面給大家看，所以我選擇了展示S/4HANA的Business Object開發(fā)框架BOPF，因?yàn)榍懊嬲f了，二者很多方面都非常相似。

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

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

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

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

看完上述內(nèi)容，你們掌握怎么進(jìn)行SAP CRM系統(tǒng)訂單模型的設(shè)計(jì)與實(shí)現(xiàn)的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！