搜索
三十一回退流的实现在流程建模的时候，定义好了返回的线路，这种严格来说，不是回退流。例如，审核不通过，则返回重新填写，这种只是条件路由。工作流的回退流，是流程实例在流转的过程中，可以回退到运行轨迹的任意步骤，同时还可以辅助一些业务补偿方法，使得回退时候的环境和原来执行时候的环境一样。所以回退流，和流程引擎支持的正常的路由方式是不一样的，甚至是反流程建模的方式，流程建模就是把业务流程的各业务处理过程按一定的流转方式建立起关联。而回退流，是没有规律的，当流转到一定的步骤后，可以回退到任意的步骤。当流程的流转方式为顺序流的时候，处理回退很简单：顺序流：当运行到最后一个步骤时，可以选择回退到前面的任意步骤。而不是按照流程定义的方式，接着往下执行。实现过程：关闭当前执行的步骤－－》转入历史步骤－－》指定回退的步骤为当前可执行的步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类(可选的)条件路由：实现过程：和顺序流的处理类似，当需要回退的时候，关闭当前的可执行步骤－－》送入历史步骤－－》建立回退到的步骤为当前可执行步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类（可选的）分支路由：上一篇文章主要讲了分支和聚合，分支包含静态分支和动态分支，都是同时产生并发的分支线路。静态分支用静态聚合来汇聚，动态分支用动态聚合来汇聚。按正常的流转方式，静态分支和动态分支，按照流程建模时候的路由方式，继续向前流转。但是如果选择回退，回退的处理就和顺序流等不一样，回退到分支上，回退到主干上，处理过程会不同。单层的分支：当流转到分支节点，产生并发的分支时分支－－回退到－－分支，处理过程：关闭当前分支节点－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）其它的分支不受影响。分支－－回退到－－主干，处理过程：关闭所有分支上的当前步骤－－》转入历史步骤－－》回退到的主干节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）。所有分支都被关闭，回退到主干节点上。主干－－》回退到－－分支，处理过程：关闭当前主干上的当前步骤－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）只生成回退到的分支节点为当前可执行步骤，其它并行节点不生成，当此分支执行完成，汇聚的时候，配合其它分支节点的历史步骤的执行情况，来满足汇聚的条件。就如只有此回退到的分支需要重新执行一次，其它的分支不用重新执行。多层的分支：当有分支嵌套的时候，回退的处理又更加复杂单层的分支－－回退到－－本分支，处理过程，同上面单层分支－－分支。其它的分支均不受影响，只在本分支上面回退。单层的分支－－回退到－－上层分支的主干，处理过程：递归出上层分支的所有下级分支节点||关闭这些节点的所有当前步骤||送入历史步骤||生成回退到的上层分支主干的节点为当前步骤||生成指定回退到步骤的任务||辅助执行业务补偿类（可选）任意分支－－回退到－－主干，处理过程：关闭所有的多层分支的当前步骤－－》送入历史步骤－－》回退到的主干节点步骤为当前步骤－－》生成指定步骤的任务－－》辅助执行业务补偿（可选）这种回退处理比较清晰，关闭掉所有并行的一级分支，二级分支等等。上层分支的主干－－回退到－－任意分支步骤：关闭分支主干上的当前步骤－－》送入历史步骤－－》生成回退到的分支节点步骤为当前步骤－－》生成回退步骤的任务－－》辅助业务补偿（可选）其它并发分支线不受影响。主干－－回退到－－任意分支：只生成回退到的分支节点处理过程：关闭主干节点的当前步骤－－》送入历史步骤－－》生成回退到的分支节点为当前步骤－－》生成回退到步骤的任务－－》辅助业务补偿（可选）其它分支线不受影响，取其它分支的历史步骤和当前分支步骤匹配汇聚节点的条件。就如同某分支需要重做，其它分支不需要重新处理。标签:java工作流,自定义工作流,.net工作流三十二设计模式在工作流系统开发中的运用GoF四人组一共介绍了23种面向对象的设置模式，为每一种特定的实现取了一个名字，根据模式的应用目的不同，将他们分为3类，创建型、结构性和行为型。面向对象设计三原则：优先使用组合针对接口编程为变化而设计设计模式不是万能的，熟悉了这些模式，灵活运用它，并且不局限于设计模式，构架出适合自己的设计才是最重要的。在工作流系统的开发中，后台的类是纯面向对象的方式实现的，因此少不了设计模式的运用：单例模式：读取数据库配置文件fcconfig.xml读取工作流相关的配置文件fcworkflow.xml读用户系统的配置文件fcuser.xml这种读取配置文件，返回多个属性值的，用单例模式，确保系统中只有一个实例在运行。获取表的最大id号，用的是静态方法，因为只需要获取一个值。静态方法和单例模式有区别：静态方法在系统运行后，就已经运行了，是一个方法，只有一个返回值。单例模式是在需要获取这个流程实例的时候，才初始化这个类，返回的是一个类的实例。工厂模式：配置多数据库的支持；配置流程的多种存储方式；配置用户系统的多种实现方式....很多实现都能看到工厂模式的影子，大部分的实现都是采用工厂模式＋可配置的参数来实现的。外观模式，代理模式：外观模式是在系统的封装好了功能前面再加一道入口门。在eworkflow中用户系统的对外提供统一的入口，有点类似外观模式。代理模式：资源的延迟访问。为对象提供一个代理来控制对该对象的访问。适配器模式：在流程的表达式分析中，有用到适配器模式，系统提供了一套分析表达式的方法。也可以切换成其它的（用户自定义的）表达式分析器类。装饰器模式：比较常见的是在web请求后，加上拦截器或者是过滤器。复合模式：有多层次嵌套的上下级关系的节点，在实现的时候，采用了复合模式来达到一个递归的调用。就是在父层次的抽象类中，定义了节点有共性的属性。在子层次的类中，用一个集合来记录父层次类的实例个数，再通过遍历这个集合来达到递归出所有嵌套子节点的个数。命令模式：web请求的时候，所有的页面请求方式用命令模式来封装，达到统一的调用。策略模式：所有的节点的前置后置函数，都实现一个接口，接口提供一个方法，这个方法流程引擎中会调用。前置后置函数可以是一些业务函数。所有的条件判断函数，也都是实现了一个统一的接口，接口提供一个判断方法，这个方法在流程引擎中会调用。只要实现这个接口，用户可以自己写业务规则。模版方法：这种在很多父层次的抽象类中，经常有实现。观察者模式：在将自定义表单（eform）和eworkflow工作流的集成中，有类似使用观察者模式。在表单业务数据的提交后，产生事件，通知到工作流系统中，工作流系统接到通知后，将执行流程的动作提交，达到流程递进。....可能上面的归纳不是很准确，但是对接口编程，为变化而设计这种思想贯穿了整个流程开发。还是那句话，设计模式不是万能的，能提炼出共性，符合使用设计模式的，使得复杂的处理更加简单了，就可以使用。标签:java工作流,自定义工作流,web工作流,自定义表单,dotnet工作流引擎,.net工作流三十三撤回的实现工作流系统的回退流，是指流程实例运行到一定阶段后，可以主动的选择回退到曾经运行过的任意轨迹上。回退流的发起方是当前步骤的任务执行人，选择主动的回退，上面有一篇回退流的实现，主要说明了回退流的实现过程。工作流系统的撤回，是指流程实例运行了一定的轨迹后，上一步的任务执行人，选择撤回刚刚提交的任务，使得流程再次流转到此步骤。撤回的发起方是当前步骤的上一步任务的执行人，选择主动撤回。如上图：红色圈为当前运行到的轨迹，当上一步审核步骤的任务执行人，选择主动撤回时，则将回退到审核步骤，再次执行。撤回与回退的两个区别：1.撤回只能撤回到当前步骤的上一步，不能跨多个步骤的撤回。回退是可以任意的回退。2.撤回的发起方是上一步的任务执行人。回退的发起方是当前步骤的可执行人。撤回与回退的相同点：1.撤回和回退都是指回到曾经的轨迹；2.撤回和回退回到曾经运行的轨迹后，再次生成此轨迹的任务，并且辅助业务补偿类，将环境或业务数据恢复成原来的，持久化变量可以忽略，临时变量则需要重新赋值。3.撤回和回退都不是按照流程定义的正常轨迹流转，需要配置有权限的用户去操作。撤回功能的实现：既然撤回与回退都是回到曾经运行的轨迹，只是发起方不一样，所以在实现的时候，只需调用同一流程引擎的实现自由回退的api函数。串行路由，实现撤回，查找当前撤回步骤的下一步是否为当前步骤，是则强行关闭当前的任务，回退到此步骤，重新生成此步骤的任务。条件路由，实现撤回，查找当前撤回步骤的下一步是否为当前步骤，需要查找有条件结果和无条件结果，有则实现回退。分支路由，实现撤回，主要是查找当前撤回步骤的下一步是否为当前步骤，需要略过分支节点来查找，查找到了，则实现回退。撤回的过程与回退流的实现过程一样。分支路由的撤回，分为在分支上面的撤回，与，分支到主干上的撤回分支－－分支的撤回如下图：在分支上面的撤回，则只撤回本分支的任务，其它分支不受影响。分支－－主干的撤回如下图：分支撤回到主干，则将关闭所有的分支，撤回到主干。如果分支上面嵌套分支，也将关闭所有的嵌套分支，回到主干。聚合路由，实现撤回，当一个分支提交了，其它分支还未执行，即未满足聚合的条件时，则实现不了撤回，因为当前步骤还在另一个分支，还未执行到聚合后面的节点。当分支条件均满足后，流转到聚合节点后面的步骤，则可以实现撤回，撤回与回退一样，只撤回此分支的轨迹，其它分支不撤回。撤回与回退的功能均是不按流程定义的轨迹去任意执行，因此在操作的时候不能给所有的用户都分配此功能。撤回与回退在流程引擎中的实现是一样的，撤回只是对回退的一个补充。三十四集成用户系统工作流引擎或工作流系统，应该致力于工作流引擎模型的设计，业务流程的抽象，以及业务流程的流转，这些是工作流系统的重要部分，把这些设计好了，一套工作流系统也就具备雏形了。但是业务流程的流转往往是需要有特定的人，特定的角色等的参与的。在业务流程建模，流程实例的流转，都是离不开应用系统中的用户系统。可以说用户系统是工作流系统的不可缺少的部分，因此工作流系统也必需要涉及到用户系统的设计与实现。工作流系统作为开发部件，集成到用户的应用系统中。有些模块可以直接被应用系统调用，同时流程引擎又封装了很多api函数，开发人员也可以通过类库，api函数等的来集成流程引擎的功能。一般来说，应用系统均会包含有用户系统，组织机构等的维护模块，有独立的设计和实现。工作流系统和应用系统的集成，首先就要面临用户系统的集成：工作流系统本身也需要包含用户系统的设计与实现。集成应用系统后，应用系统也有自己的用户系统。需要将这两套用户系统合二为一，因此在eworkflow流程引擎中，设计了一个映射表，作为中间层。来实现将应用系统的用户系统映射到流程系统中，使得流程系统中业务流程建模，定义，流转中使用的用户角色等都关联到应用系统。一个fcuser.xml映射表的内容如下：根据关键字，来填写相应的表名，在流程引擎中，根据这些关键字来读取相应的value值，作为表名。工作流系统中，所有关于用户系统的数据来源（包括前台后台的界面显示的）均来自这个映射表。因为工作流系统中，只涉及到使用用户系统，例如查找，显示列表等。不涉及到用户系统的维护（用户系统的维护，在应用系统中有独立的完成），因此，映射表中，只需要关联几个常用的字段，例如用户编号，用户id,用户名称；角色id,角色名称。同时还有一个工作组的概念（或者临时的工作组），如果应用系统中没有工作组，就可以不设置关联，eworkflow自动取eworkflow中的工作组表。映射表中所有字段，均按照字符型的来关联，如果和应用系统的字段类型不匹配，则需要修改流程引擎user包中的用户对象类了，就是表的实体类。使得字段类型保持一致。因为流程引擎中用到用户系统字段都相对少，所有在业务流程建模等显示的列表字段都相对简单，如果需要增加多一些的信息，在需要扩展这些