如何進(jìn)行C4C Cloud Application Studio做ABSL開發(fā)中性能方面的最佳實(shí)踐

如何進(jìn)行C4C Cloud Application Studio做ABSL開發(fā)中性能方面的最佳實(shí)踐，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

如何批量調(diào)用BO action

不好的例子:

第一行和第四行有兩個循環(huán)，然后在第二次循環(huán)里調(diào)用一個比較耗時(shí)的ServiceRequest BO的item 節(jié)點(diǎn)上定義的標(biāo)準(zhǔn)action FinishFulfilmentProcessing。代碼的時(shí)間復(fù)雜度為o(n2)

正確的做法：

優(yōu)化的原理就是，C4C和其他很多基于Netweaver的SAP產(chǎn)品一樣，其BO的核心service都支持批量操作。所謂批量操作，技術(shù)上就是指這些service的輸入?yún)?shù)是一個內(nèi)表，而非單條數(shù)據(jù)。如果您做過CRM開發(fā)，可以類比CRM_ORDER_MAINTAIN這個function module，其所有輸入?yún)?shù)都是內(nèi)表結(jié)構(gòu)。C4C的BO提供的service的接口定義也完全采用了這種支持批量操作的設(shè)計(jì)。

上述不好的例子，編譯出來的ABAP代碼的偽代碼如下：(因?yàn)镃4C的后臺代碼沒有開放給Partner和客戶，我只能提供偽代碼)。可以看出盡管BO的action是執(zhí)行批量操作，但是這種寫法并沒有發(fā)揮批量操作的作用，每次在循環(huán)內(nèi)部作為輸入?yún)?shù)的內(nèi)標(biāo)在第二行被清空，造成每次調(diào)用BO action時(shí)輸入?yún)?shù)只有一條記錄。

而正確的例子，編譯后生成的偽代碼為：

能清楚地看到BO action的執(zhí)行已經(jīng)放到循環(huán)外部了。

如何批量執(zhí)行BO Retrieve

當(dāng)我們在Cloud Studio里通過代碼自動完成功能試圖調(diào)用BO的Retrieve方法時(shí)，IDE會提示我們Retrieve方法有三個重載(Overload), 這表明Retrieve能夠支持傳入不同的參數(shù)。

正確和不建議的做法分別見下圖藍(lán)色和紅色代碼?？梢钥吹剿{(lán)色代碼retrieve接受的輸入?yún)?shù)是一個集合, 包含了兩個ID為3和4的元素，使得41行的調(diào)用能夠一次即可返回2個ServiceRequest的數(shù)據(jù)。

line 43編譯后生成的ABAP代碼的偽代碼：

line 41編譯后生成的ABAP代碼的偽代碼：

通過比較能發(fā)現(xiàn)如果傳入retrieve的參數(shù)是一個ID的集合，那么編譯生成的ABAP代碼會調(diào)用一個接口為內(nèi)表的retrieve方法，批量讀取數(shù)據(jù)。

如何批量執(zhí)行BO Create

對于基礎(chǔ)的Create操作，見下列代碼第54行，只支持基于單個節(jié)點(diǎn)的數(shù)據(jù)創(chuàng)建。

但是對于CreateWithReference的場景，則和第二個例子的Retrieve場景一樣，不僅支持傳入單個數(shù)據(jù)(第56行), 也支持傳入一個集合(第58行)。

這兩種不同的輸入，會導(dǎo)致編譯生成的ABAP代碼分別進(jìn)入CREATE_WITH_REF_1和CREATE_WITH_REF_N的執(zhí)行邏輯，產(chǎn)生性能差異。

看完上述內(nèi)容，你們掌握如何進(jìn)行C4C Cloud Application Studio做ABSL開發(fā)中性能方面的最佳實(shí)踐的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！