声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中所示截图来源SAP软件，相应著作权归SAP所有。
最近用户提上来很多关于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。
进行后台Workflow Log界面查看Technical Details
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）。
注：本微信公众号获得CSDN博主小狼Solar授权，转载SAP MDG相关的文章，该系列文章仅代表小狼个人的观点，仅用于SAP MDG学习和参考。
版权归原作者所有,如有侵权请联系删除。
免责声明：本文所用视频、图片、文字如涉及作品版权问题，请第一时间告知，我们将根据您提供的证明材料确认版权并按国家标准支付稿酬或立即删除内容！本文内容为原作者观点，并不代表本公众号赞同其观点和对其真实性负责。
分享是一种精神
