解决中国特色流程需求分析.docVIP

灵活的临时动态性需求1 回退 需求描述： 回退作为审批流来讲是最常见的需求，对于审批流来说，每一个审批环节都有可能会有审批通过、不通过2种情况，而审批不通过时，一般是回退到上一个环节，但是在某些情况下，有可能跨环节回退，例如，在第5个审批环节，审批不通过时，直接回退到第2或第1个环节。而到底回退到哪个环节是可以让用户根据业务需求进行自定义的，并且在回退环节工作完成之后，其下一步的方向也可以让用户自定义。如，要是由第5个环节回退到第2个环节，那么当第2个环节重新修改业务数据并办理完毕后，流程引擎可以设定是重新按照2-3-4-5的顺序重新执行一遍，也可以设定由第2个节点返回给第5个节点，由第5个节点重新审批。场景及实现思路： 图1 串行流程示意图 场景1 串行流程： 在这个场景中，由于流程是串行的，没有分支的情况，因此处理起来最简单（如图1所示）场景1实现思路： 对于这个场景，在中，最直接的方式，就是在需要回退的各个节点之间建立回退线（如图5所示，如果需要从节点4回退到节点2，则直接在节点4之后加一个分支决策节点，连接两个分支，一个是pass to 节点5，一个是reject to 节点2）。 对于节点2来讲，在该工作流组件中，其参与模式又分为4种：task-assignee（assignee user、assignee expression）、task candidates（candidate-groups、candidate-users）、task assignment handler、task swimlanes。 1. task-assignee任务的办理人的值可以直接指向一个特指的用户的id或者一个关联到业务中某个特指用户的表达式（例如order.owner）。此时，如果assignee 赋予了一个特指用户的id，回退时不用做任何处理。如果assignee赋予了一个业务表达式，在回退时，需要保证业务表达式的运算逻辑能够正确执行。 2. task candidates任务的办理人为几个特定的组的集合，或者用户的集合，在这个场景下，实际上就是我们俗称的“竞办”。这样的任务被称为 groupTask，必须被某一个组或者用户拾取才能进行办理，因此如果回退到这样的节点时，需要把任务回退给当时的拾取人。而拾取人需要到 HistoryTask和HistoryDetailImpl两个实体对应的历史库中取得。 3. task assignment handler任务的办理人通过用户自己编写的代码来实现，此时回退到这样的节点时，也不需要做特殊处理，只要保证自己的代码（AssignmentHandler）在执行回退逻辑时同样能够正确执行即可。 4. task swimlanes任务的办理人为“泳道”，回退到这样的节点时，任务的办理人可以自动取得，同样不需要做任何处理。 以上4种情况，在回退之后的处理，又分为2种情况，一种是，按照原来的路径重新执行，即节点2—节点3—节点4，另一种是，节点2办理完毕后，直接返回给节点4。对于第1种情况，不需要做处理。而对于第2种情况，由于在节点2和节点4之间并没有一个转移存在，因此工作流组件也没有提供原生的支持。那么针对这种情况，解决思路可以是：通过动态创建跳转来实现（具体实现方法，详见3.3.4），实际上回退也可以用动态创建跳转来实现，而就不用画回退线了。 图2 串行流程的回退实现 场景2 M选N分支流程： 对于这个场景，N的取值范围为MN=1，假设回退前流程的执行路径为节点1-节点2-节点4-节点5（见图3），此时回退有两种情况： 1. 由节点5回退到节点1，而节点1在进行业务数据的修改后，直接返回给节点5的处理人进行办理或审批； 2. 由节点5回退到节点1，而节点1在进行业务数据的修改后，重新按照节点1-节点2-节点4-节点5的路径再执行一遍； 图3 分支流程示意图 场景2 实现思路：此场景与场景1不同的是，在回退之后继续审批时，需要考虑分支节点的决策条件，在自动决策时要保证决策逻辑正确执行，在人工决策时，需要记录原来的执行路径（保证重走1-2-4-5）。场景3 同步分裂、与汇聚流程（如图4所示），回退前执行的路径为节点1--节点2--（节点3、节点4）--节点5--节点6，此时回退有4种不同的情况要考虑： 1. 由节点6（或节点5）回退到节点2（或节点1），节点2重新办理完毕后，直接返回给节点6的处理人进行办理或审批； 2. 由节点6（或节点5）回退到节点2（或节点1），节点2重新办理完毕后，重新按照节点2--（节点3、节点4）--节点5--节点6的路径再次执行一遍； 3. 由节点6（或