C4C Cloud Application Studio作ABSL開發的一些性能方面的最佳實踐

Stefan Hagen在博文SAP Cloud Application Studio Performance Best Practices裏介紹了在C4C裏使用Cloud Application Studio進行ABSL編程的一些性能方面的最佳實踐。

文章裏提綱挈領地給出了一些guideline。這裏提供一些具體的例子。

如何批量調用BO action

很差的例子:

第一行和第四行有兩個循環，而後在第二次循環裏調用一個比較耗時的ServiceRequest BO的item 節點上定義的標準action FinishFulfilmentProcessing。代碼的時間複雜度爲o(n²)

正確的作法：

優化的原理就是，C4C和其餘不少基於Netweaver的SAP產品同樣，其BO的核心service都支持批量操做。所謂批量操做，技術上就是指這些service的輸入參數是一個內表，而非單條數據。若是您作過CRM開發，能夠類比CRM_ORDER_MAINTAIN這個function module，其全部輸入參數都是內表結構。C4C的BO提供的service的接口定義也徹底採用了這種支持批量操做的設計。

上述很差的例子，編譯出來的ABAP代碼的僞代碼以下：(由於C4C的後臺代碼沒有開放給Partner和客戶，我只能提供僞代碼)。能夠看出儘管BO的action是執行批量操做，可是這種寫法並無發揮批量操做的做用，每次在循環內部做爲輸入參數的內標在第二行被清空，形成每次調用BO action時輸入參數只有一條記錄。

而正確的例子，編譯後生成的僞代碼爲：

能清楚地看到BO action的執行已經放到循環外部了。

如何批量執行BO Retrieve

當咱們在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方法，批量讀取數據。

如何批量執行BO Create

對於基礎的Create操做，見下列代碼第54行，只支持基於單個節點的數據建立。

可是對於CreateWithReference的場景，則和第二個例子的Retrieve場景同樣，不只支持傳入單個數據(第56行), 也支持傳入一個集合(第58行)。

這兩種不一樣的輸入，會致使編譯生成的ABAP代碼分別進入CREATE_WITH_REF_1和CREATE_WITH_REF_N的執行邏輯，產生性能差別。

要獲取更多Jerry的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: