From: Wang, Jerry
Sent: Wednesday, 30 December, 2015 1:57 PM

Subject: user status的優化思路

老的實現直接call one order util API，傳入order guid，輸出對應的所有user status。這個API里面又嵌了兩個function module，都只支持一次處理一個order。

現在AG3上有9萬條數據，我準備直接找DB table，然后用這九萬條數據做測試。如果新舊solution返回的結果一致，就認為優化后的代碼在功能上沒有任何問題。

如下圖，老的實現，get_status_info這個方法不支持批量處理，因此我仿照老方法的邏輯，重新實現了一個方法。

下圖這個方法是one order team提供的API，它的邏輯是：

如果transaction type沒有assign 任何status profile（如下右圖所示），則按照一些很復雜的邏輯計算出system status并返回，就是下邊左邊流程圖的右邊那個分支。
否則，返回status profile里assign的user status

根據過去我support客戶和處理incident的經驗來看，沒有哪個客戶使用了沒有assign 任何status profile的transaction type。要么直接用系統標準的，要么用Z的。

我個人的想法是我們不需要考慮system profile那個分支，如果代碼里確實發現某個order對應的transaction type沒有assign system profile，對于該order而言就不返回任何task信息。如果客戶抱怨，直接告訴他至少要給transaction type assign一個status profile就行了。

如果我們還是必須support system status那個分支，我需要花費額外的effort把上圖右邊那個分支，尤其是紅色那個方塊內的邏輯搞清楚。

對于DocumentNextUserStatuses這個node，我優化的實現里只返回UserStatus，即下面郵件流程圖左邊那個分支。

不給transaction type維護status profile的情形太罕見了，實際項目中應該不可能出現，我們沒必要為了一個理論上的可能性花費不必要的effort。

總結

以上是生活随笔為你收集整理的关于SAP CRM One Order状态(Status)和Status Profile的处理逻辑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。