关于SAP CRM One Order状态(Status)和Status Profile的处理逻辑

版权声明：本文为博主汪子熙原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1440083

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。