SAP CRM Transaction進行中的權限控制

當試圖打開一個Opportunity時，

系統會進行如下一系列的權限檢查：

1. 檢查Authorization object CRM_ORD_OP:

此處會檢查目前user的partner function和partner function category的設定情況：

如果檢查失敗，會抛出error message：

2. 進行第二輪針對CRM_ORD_LP的檢查：

3. 如果再失敗，進行第三輪對CRM_OPP的權限檢查：

45代表Allow:

4. 如果再失敗，進行第四輪對CRM_ORD_RS的權限檢查：

如果都失敗，将看到如下錯誤資訊：

可以用一張圖概括：

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行，隻支援基于單個節點的資料建立。