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。