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。