web工作流管理系统开发3135.docx
《web工作流管理系统开发3135.docx》由会员分享，可在线阅读，更多相关《web工作流管理系统开发3135.docx（18页珍藏版）》请在冰点文库上搜索。
web工作流管理系统开发3135
三十一回退流的实现
在流程建模的时候，定义好了返回的线路，这种严格来说，不是回退流。
例如，审核不通过，则返回重新填写，这种只是条件路由。
工作流的回退流，是流程实例在流转的过程中，可以回退到运行轨迹的任意步骤，同时还可以辅助一些业务补偿方法，使得回退时候的环境和原来执行时候的环境一样。
所以回退流，和流程引擎支持的正常的路由方式是不一样的，甚至是反流程建模的方式，流程建模就是把业务流程的各业务处理过程按一定的流转方式建立起关联。
而回退流，是没有规律的，当流转到一定的步骤后，可以回退到任意的步骤。
当流程的流转方式为顺序流的时候，处理回退很简单：
顺序流：
当运行到最后一个步骤时，可以选择回退到前面的任意步骤。
而不是按照流程定义的方式，接着往下执行。
实现过程：
关闭当前执行的步骤－－》转入历史步骤－－》指定回退的步骤为当前可执行的步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类（可选的）
条件路由：
实现过程：
和顺序流的处理类似，当需要回退的时候，关闭当前的可执行步骤－－》送入历史步骤－－》建立回退到的步骤为当前可执行步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类（可选的）
分支路由：
上一篇文章主要讲了分支和聚合，分支包含静态分支和动态分支，都是同时产生并发的分支线路。
静态分支用静态聚合来汇聚，动态分支用动态聚合来汇聚。
按正常的流转方式，静态分支和动态分支，按照流程建模时候的路由方式，继续向前流转。
但是如果选择回退，回退的处理就和顺序流等不一样，回退到分支上，回退到主干上，处理过程会不同。
单层的分支：
当流转到分支节点，产生并发的分支时
分支－－回退到－－分支，处理过程：
关闭当前分支节点－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）
其它的分支不受影响。
分支－－回退到－－主干，处理过程：
关闭所有分支上的当前步骤－－》转入历史步骤－－》回退到的主干节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）。
所有分支都被关闭，回退到主干节点上。
主干－－》回退到－－分支，处理过程：
关闭当前主干上的当前步骤－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）
只生成回退到的分支节点为当前可执行步骤，其它并行节点不生成，当此分支执行完成，汇聚的时候，配合其它分支节点的历史步骤的执行情况，来满足汇聚的条件。
就如只有此回退到的分支需要重新执行一次，其它的分支不用重新执行。
多层的分支：
当有分支嵌套的时候，回退的处理又更加复杂
单层的分支－－回退到－－本分支，处理过程，同上面单层分支－－分支。
其它的分支均不受影响，只在本分支上面回退。
单层的分支－－回退到－－上层分支的主干，处理过程：
递归出上层分支的所有下级分支节点
||
关闭这些节点的所有当前步骤
||
送入历史步骤
||
生成回退到的上层分支主干的节点为当前步骤
||
生成指定回退到步骤的任务
||
辅助执行业务补偿类（可选）
任意分支－－回退到－－主干，处理过程：
关闭所有的多层分支的当前步骤－－》送入历史步骤－－》回退到的主干节点步骤为当前步骤－－》生成指定步骤的任务－－》辅助执行业务补偿（可选）
这种回退处理比较清晰，关闭掉所有并行的一级分支，二级分支等等。
上层分支的主干－－回退到－－任意分支步骤：
关闭分支主干上的当前步骤－－》送入历史步骤－－》生成回退到的分支节点步骤为当前步骤－－》生成回退步骤的任务－－》辅助业务补偿（可选）
其它并发分支线不受影响。
主干－－回退到－－任意分支：
只生成回退到的分支节点
处理过程：
关闭主干节点的当前步骤－－》送入历史步骤－－》生成回退到的分支节点为当前步骤－－》生成回退到步骤的任务－－》辅助业务补偿（可选）
其它分支线不受影响，取其它分支的历史步骤和当前分支步骤匹配汇聚节点的条件。
就如同某分支需要重做，其它分支不需要重新处理。
标签:
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包中的用户对象类了，就是表的实体类。
使得字段类型保持一致。
因为流程引擎中用到用户系统字段都相对少，所有在业务流程建模等显示的列表字段都相对简单，如果需要增加多一些的信息，在需要扩展这些列表的功能。
在工作流系统中，所有列表显示等的页面，均是用eform自定义表单来实现的，通过表单设计器，可以快速的修改这些页面的显示。
工作流系统中的用户系统，也有一个设计和使用的过程，当设计和应用系统的用户系统的设计相差太大，也可以通过简化＋扩展业务类的方式来实现，因为工作流系统中涉及到用户系统的部分，就是在业务流程流转中的权限会涉及到，每个节点的使用权限。
可以通过扩展条件类，前置后置函数等来达到。
c#条件类的接口
publicinterfaceCondition
{
boolpassesCondition（System.Collections.IDictionarytransientVars,System.Collections.IDictionaryargs,PropertySetps）;
}
c#函数类的接口
publicinterfaceFunctionProvider
{
void execute（System.Collections.IDictionarytransientVars,System.Collections.IDictionaryargs,PropertySetps）;
}
java条件类的接口
publicinterfaceCondition{
publicbooleanpassesCondition（MaptransientVars,Mapargs,PropertySetps）throwsWorkflowException;
}
java函数类的接口
publicinterfaceFunctionProvider{
publicvoidexecute（MaptransientVars,Mapargs,PropertySetps）throwsWorkflowException;
}
当工作流系统未集成到应用系统时，也可以通过修改这张映射表，读到用户系统表，就可以使eworkflow工作流单独能运行。
三十五自由流的实现
工作流系统在给业务流程建模的时候，按照流程引擎的设计，将业务流程定义出来。
这个业务流程的每个流程实例，就按照流程建模时定义好的线路流转。
自由流是指流程实例在运行时，不按照预先定义好的线路流转，而是自由的跳转，由流程实例的操作人员来选择下一个到达的节点。
通常这种都是不正常的流转，和回退流一样，破坏了流程的正常定义。
但是自由流又很有“特色”，符合一定的业务需求。
例如，当一份申请单提交审核后，需要部门经理，总经理，都审核过，才能流转到业务部门来处理，但总经理出差在外，申请单又急需处理，部门经理在线下已经征得总经理的同意后，就可以选择跳过总经理的审核，直接送到业务部门。
通常自由流是指向前的跳转，回退流是回退到曾经运行过的轨迹。
向前跳转会略过一些节点，不运行，直接到达新的节点。
回退流是回到原来的轨迹，再重新执行，对应重做（撤回）的功能。
自由流对应忽略某些步骤，直接达到后面的步骤。
因此在实现上，自由流和回退流的实现是有区别的。
顺序流的自由流的实现
当运行到填写步骤时，由于某种原因，直接略过审核步骤，跳转到查看步骤。
或者填写人想作废掉这次的填写，直接就跳到结束步骤，结束本流程（当然需要填写人有自由跳转的权限）。
实现过程：
关闭当前步骤（当前任务）－－》转入历史步骤（历史任务）－－》指定跳转到的步骤为当前步骤－－》生成新步骤的任务
条件路由
实现过程：
和顺序流一样，当自由跳转时，关闭当前步骤任务，生成跳转到的节点的步骤和任务。
循环路由：
和顺序流处理过程一样。
分支路由：
分支路由在eworkflow中分为静态分支和动态分支，但是发生自由跳转时，静态分支和动态分支的处理过程是一样的。
分支路由的自由跳转，就比顺序流要复杂很多。
单层的分支：
主干－－－分支
当由主干节点跳转到分支节点上时，这种跳转是没有意义的。
因为分支节点产生并行的分支，几个分支后的线路是同时并行的。
当自由跳转到一个分支的节点上后，另外的分支不能产生，流程会变的没有意义。
因此当发生主干跳转到分支的情况时候，eworkflow是直接关闭当前节点，生成分支上的节点。
但是这样流程可能会变得没有意义，主要看流程建模时候的模型。
主干－－－主干
当由主干节点跳转到主干节点，这种是正常的自由流，实现过程；关闭当前主干步骤（任务）－－》转入历史步骤（历史任务）－－》跳转到指定的主干步骤－－》生成新的主干步骤任务。
多层的分支：
由于分支节点和聚合节点可以嵌套，因此就有多层的分支节点，分支主干，分支的分支之间的跳转问题。
总的原则是，分支主干跳转到分支主干，其它的分支不受影响。
在实现的时候，需要递归的查找出各个分支的所有下级分支。
主干－－主干
最外层的主干节点上的跳转，这种是正常的自由流，实现过程：
关闭当前主干步骤（任务）－－》转入历史步骤（任务）－－》生成最外层的主干步骤－－》生成新的主干步骤任务。
分支主干－－分支主干
分支主干跳转到本分支的主干，是正常的自由流，关闭本分支主干，生成本分支主干的新节点，其它分支均不受影响。
实现过程：
关闭本分支主干步骤（任务）－－》转入历史步骤（任务）－－》生成本分支跳转到的节点的步骤（任务）其它分支均不受影响。
分支主干－－分支的分支
分支主干跳转到本分支的分支，这种是没有意义的，和主干跳入分支是一样的，不是正常的自由流。
分支主干－－主干
分支主干跳入最外层的主干，是正常的自由流，实现过程：
结束所有分支的步骤（任务）－－》转入历史步骤（任务）－－》生成最外层跳转到的节点的步骤（任务）
分支的分支－－分支主干
分支的分支跳转到分支主干，这种是正常的自由流，结束本分支下的所有子分支（包含嵌套的多级分支）生成分支主干的步骤任务，其它分支主干不受影响。
实现过程：
递归查找出所有分支主干的下级分支节点－－》结束查找到的所有分支当前步骤（任务）－－》生成新的分支主干步骤（任务）其它分支主干的当前步骤任务均不变化。
分支的分支－－主干
分支的分支跳转到最外层的主干，这种是正常的自由流，结束所有分支，包含嵌套的分支的分支等等。
生成最外层的主干步骤。
实现过程：
结束所有的当前步骤（任务）－－》生成新的最外层的主干步骤（任务）
其它还会有分支1的分支－－分支2的分支：
这种的跳转显然是没有意义的。
升级会员 