工作流回退模式设计分析.docVIP

工作流回退模式设计分析 回退（Rollback WorkItem） 回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。 - 参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将任务回退给以前某个节点的执行者重新办理。 常见回退 回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的）。 串行 ??? 这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。 分支 ??? 从“当前A”节点返回到其主干。 并发 ??? “当前A”和“当前B”分别是并行分支上的正在活动的节点，这时由“当前A”节点提出回退到其主干节点请求，这时引擎需要停止兄弟并行支路上的活动节点，对已执行过的节点要进行回滚，并进行可能的补充（可选）。 同一执行线回退 对于同一执行线之间的节点回退，系统将回退两节点形成的距形区域之间所有节点，并进行可能的补偿。 ??? 在这种情况下， ??? 从分支回到分支的处理方法是把“分支回退到主干”+“从主干回退到分支”组合起来处理，先用“分支回退到主干”方法处理前段，再按“从主干回退到分支”处理后段。 从子流程回退到主流程 分两段来处理，第一段是先从子流程当前节点“活动41”回退到子流程的启动节点“活动4”。第二段是从子流程的启动节点“活动4”按上述的方法回退到“活动1” 从主流程回退到子流程 这种情况比较复杂，处理方法是分三段处理，第一段是从当前节点“活动5”回退到子流程的启动节点“活动4”。第二段恢复子流程在执行状态。第三段是从子流程的结束节点回退到“活动42”节点。 会签节点回退 对于多人（或者多部门）会签的节点回退，提供不同的回退策略： 任意人回退即回退，剩余工作项手工终止 首个签办人回退 指定人员列表回退 流程定义期定义该策略。 回退节点的参与者选择 默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。 在节点任务竞争参与的情况下，提供另一种策略，即让人员重新竞争。 回退的条件判断 业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口，返回回退路径，由客户自定义代码进行匹配处理。 ? 关于实现 很多工作流引擎通过流程定义时绘出回退线来显式的支持回退，虽然可以帮助设计人员更比较清晰管理回退，但在业务复杂的情况下会造成流程图的异常烦琐，根本无法阅读，流程也难以维护。相比而言隐式实现更易于维护和理解，也是本人推荐实现方式。 问题讨论 本文未提到的回退场景，请各位集思广益。 关于虚拟回退的问题 可以把回退分为引擎级回退和业务级的回退，引擎级的回退，可以回退到任何节点，但要求所有支路全部回滚，保证流程状态不混乱。业务级（模拟）的回退，只允许回退上一步，通过添加新节点来模拟退回。 用模拟回退的方式实现： 现在问题是，如果在执行“收集整理_副本”节点时，执行人再要求回退，该如何处理？ 关于流程回退通知 引擎级回退，要求所在分支也强制回退，如何通知各分支，不至于刚发现收到待办工作，等想办理时却发现该工作已被取消，如果不知道是什么原因被回退了，就会很郁闷。 关于拒收问题 拒收和回退看起来是很相近的两个业务，到现在我还觉得他们有着同样的处理方式。在你们接触到的业务中，有遇到哪些拒收的情况？ 反馈： 1）流程还提供回退条件判断接口，让业务系统自行决定是否可回退，如果业务系统未实现该接口，则按默认策略判断。 2）为业务系统提供回退情况查询，比如指定要回退的目标节点后，返回该回退的类型：同步或异步，受影响的支路。 3）多步会签，用动态创建分支去实现。 4）提供流程历史意见和流程流转跟踪。 5）提供拒收事件，由业务系统实现拒收。 6）回退产生一个事件，由该事件的实现人来处理回退的通知。