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

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

如何批次呼叫BO action

不好的例子:

第一行和第四行有兩個迴圈，然後在第二次迴圈裡呼叫一個比較耗時的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的執行已經放到迴圈外部了。

如何批次執行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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼: