SAP MDG —— Rule-Based Workflow（2） 死循环背后的问题

最近用户提上来很多关于MDG使用过程中，rule-based workflow出现死循环的问题。
今天就其中的一起Change Request进行了分析，借此总结一些思路与方法。

现象观察

BRFplus中定义的decision table如下

可以看到整个Workflow还是相当简单的，据此反推出工作流程图：

其中，User Action只有05，为Finalize Processing；31为Non-User Action，就是很熟悉Activation过程。00为sumbit，S3为Approver所在节点，其他的DD、AC、NA、CP都是后台的操作，不需要人为干预。

现在具体观察到当前Change Request的workflow log。

这里很容易就可以观察到Dead Loop现象，按照上面的流程图来说，正常流程应该只需要一个Processor就可以把整个流程成功走完，其他操作都为后台处理，但是该Change Request却无限循环。

问题分析

造成这种现象只有一种情况，就是S3-DD-AC之间的循环，也就是说在AC处返回了非31的code，导致流程指回S3，而不是继续向下直到Complete。

1. 进行后台Workflow Log界面查看Technical Details
   
2. Log Details分析
   按照Workflow Log来说，最新的Loop 22 对应的是S3，Loop 22 对应的是AC。
   Container中包含的变量值也正式了我们的想法。如下图，Loop 22中的Route Finder Task就可以看到，前一步为AC，根据返回Action Code = 33 （<>31）决定了下一步回到了S3。
   
   向上展开Loop 21，发现Check Activation Error中出现了一条Error Message：Error because of Snapshot Difference
   
   而这恰恰和Action Code = 33相对应。
   

至此可以分析出如下结论：
造成该Change Request死循环的原因来自Activation 失败，失败的具体原因则与Snapshot有关。Error Message为Snapshot Difference。

问题解决

那么到底Snapshot是什么，它与Activation又有什么关系呢？查阅官方资料可以得出，snapshot的作用是，当activation执行的时候，会去检查staging table和active table上数据有没有差异，以防在workflow的过程中有人修改了数据 。确保了数据的一致性。

因此可以推断，在该workflow的执行过程中，存储在Active Area中的主数据被某些途径直接进行了修改，例如background job或者是interface。导致审批结束执行Snapshot检查的时候，数据出现了不一致错误。

幸运的是，SAP官方给出了一种解决方案，Note 2063542中提到，可以执行Report USMD_CREQUEST_SNAPSHOT_REFRESH 来实时更新Snapshot数据。除了修复之外，我们也可以运行Report USMD_CREQUEST_SNAPSHOT_COMPARE 来分析到底是哪些数据造成了Snapshot的不一致（Note 2059700）。