您好,登錄后才能下訂單哦!
如何進行C4C Cloud Application Studio做ABSL開發中性能方面的最佳實踐,相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
不好的例子:
第一行和第四行有兩個循環,然后在第二次循環里調用一個比較耗時的ServiceRequest BO的item 節點上定義的標準action FinishFulfilmentProcessing。代碼的時間復雜度為o(n2)
正確的做法:
優化的原理就是,C4C和其他很多基于Netweaver的SAP產品一樣,其BO的核心service都支持批量操作。所謂批量操作,技術上就是指這些service的輸入參數是一個內表,而非單條數據。如果您做過CRM開發,可以類比CRM_ORDER_MAINTAIN這個function module,其所有輸入參數都是內表結構。C4C的BO提供的service的接口定義也完全采用了這種支持批量操作的設計。
上述不好的例子,編譯出來的ABAP代碼的偽代碼如下:(因為C4C的后臺代碼沒有開放給Partner和客戶,我只能提供偽代碼)。可以看出盡管BO的action是執行批量操作,但是這種寫法并沒有發揮批量操作的作用,每次在循環內部作為輸入參數的內標在第二行被清空,造成每次調用BO action時輸入參數只有一條記錄。
而正確的例子,編譯后生成的偽代碼為:
能清楚地看到BO action的執行已經放到循環外部了。
當我們在Cloud Studio里通過代碼自動完成功能試圖調用BO的Retrieve方法時,IDE會提示我們Retrieve方法有三個重載(Overload), 這表明Retrieve能夠支持傳入不同的參數。
正確和不建議的做法分別見下圖藍色和紅色代碼。可以看到藍色代碼retrieve接受的輸入參數是一個集合, 包含了兩個ID為3和4的元素,使得41行的調用能夠一次即可返回2個ServiceRequest的數據。
line 43編譯后生成的ABAP代碼的偽代碼:
line 41編譯后生成的ABAP代碼的偽代碼:
通過比較能發現如果傳入retrieve的參數是一個ID的集合,那么編譯生成的ABAP代碼會調用一個接口為內表的retrieve方法,批量讀取數據。
對于基礎的Create操作,見下列代碼第54行,只支持基于單個節點的數據創建。
但是對于CreateWithReference的場景,則和第二個例子的Retrieve場景一樣,不僅支持傳入單個數據(第56行), 也支持傳入一個集合(第58行)。
這兩種不同的輸入,會導致編譯生成的ABAP代碼分別進入CREATE_WITH_REF_1和CREATE_WITH_REF_N的執行邏輯,產生性能差異。
看完上述內容,你們掌握如何進行C4C Cloud Application Studio做ABSL開發中性能方面的最佳實踐的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。