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

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

现象观察

BRFplus中定义的decision table如下
SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第1张图片

可以看到整个Workflow还是相当简单的,据此反推出工作流程图:
SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第2张图片
其中,User Action只有05,为Finalize Processing;31为Non-User Action,就是很熟悉Activation过程。00为sumbit,S3为Approver所在节点,其他的DD、AC、NA、CP都是后台的操作,不需要人为干预。

现在具体观察到当前Change Request的workflow log。
SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第3张图片
这里很容易就可以观察到Dead Loop现象,按照上面的流程图来说,正常流程应该只需要一个Processor就可以把整个流程成功走完,其他操作都为后台处理,但是该Change Request却无限循环。

问题分析

造成这种现象只有一种情况,就是S3-DD-AC之间的循环,也就是说在AC处返回了非31的code,导致流程指回S3,而不是继续向下直到Complete。
SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第4张图片

  1. 进行后台Workflow Log界面查看Technical Details
    SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第5张图片
  2. Log Details分析
    按照Workflow Log来说,最新的Loop 22 对应的是S3,Loop 22 对应的是AC。
    Container中包含的变量值也正式了我们的想法。如下图,Loop 22中的Route Finder Task就可以看到,前一步为AC,根据返回Action Code = 33 (<>31)决定了下一步回到了S3。
    SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第6张图片
    向上展开Loop 21,发现Check Activation Error中出现了一条Error Message:Error because of Snapshot Difference
    SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第7张图片
    而这恰恰和Action Code = 33相对应。
    SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第8张图片

至此可以分析出如下结论:
造成该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)。
SAP MDG —— Rule-Based Workflow(2) 死循环背后的问题_第9张图片

你可能感兴趣的:(SAP-MDG-HOWTO,SAP-MDG-PROCESS,SAP,MDG,Workflow,Deadloop,BRFplus)