关键字：驰骋工作流引擎 流程引擎工作模式 流程中间件工作模式  工作流快速开发平台  工作流流设计  业务流程管理   asp.net 开源工作流

bpm工作流系统  java工作流主流框架  自定义工作流引擎



内容：CCBPM的工作模式并不代表其他流程引擎也有此工作模式。


我们把是否集的角度分为：独立工作模式与中间件工作模式。



如果您想把CCBPM作为中间件的模式植入到您的开发架构，我们把这样的模式称为中间件工作模式。

这种模式下您需要按照操作手册做组织结构集成与代码集成就可以了，在您的框架下工作，登录与退出功能页面都是您的，您登录了，就调用我的登录接口，你的系统退出了就调用我的退出接口。

您可以调用CCBPM提供的发起、待办、在途接口获得数据生成菜单页面，当然您也可以使用CCBPM的写好的Start.htm,Todolist.htm,Runing.htm绑定您的菜单上。

驰骋BPM流程引擎独立模式就是独立的登录，退出功能页面，独立的菜单体系结构，使用CCBPM的工作流菜单管理系统，独立的前台用户提供服务。

我们按照是否有二级管理员的角度分为：工作流单机版本，工作流集团模式两个模式。

单机版，适合一个单个应用，有一个管理员，一套组织结构体系，一套流程体系。

集团版，适合一个集团企业应用，具有一个admin一级管理员，多个子公司二级管理员。Admin设计的流程全集团与集团的机关单位可以使用，但是子公司的管理员设计的流程只能在本子公司内部使用。

.net工作流系统开发体会

公司的eworkflow自定义工作流系统，最初是开发了java版的。待java版的功能稳定后，就开始开发.net版的。

java版的eworkflow工作流系统，我们没有依赖于任何框架，如struts,spring等，也没有用hibernate，ibatis等orm映射工具。在支持web方面也有一套自己的mvc框架，都是纯java的代码。因为工作流系统，比较注重的是工作流引擎核心的实现，其他的表现形式，人机交互等都相对不是工作流系统的重要部分，并且业务模块的自定义表单采用的是eform自定义表单，所以在mvc的框架中，我们只需要注重M部分的流程引擎的开发。

 

在用.net实现工作流系统的时候，只需要将java版的后台纯java的代码，用.net的c#来实现。java和c#就象孪生兄弟，长的太象了。都是纯面向对象的，有类，接口，继承，多态等。只是关键字的写法不一样。我们只需一点一点的将java实现的流程引擎代码用c#翻译过来即可，保留所有的java设计思路，设计模式，包名类路径等。为实现同样的功能，c#的语法有的更简单、方便一些。因为java版的eworkflow 没有依赖于任何开源的框架，所以在实现上少了这些开源框架代码的移植。

工作流系统框架图：



 



用c#实现eworkflow工作流系统主要需要修改如下方面的代码。

java版：

基本的语法，类定义，包名等

c#版：

改用c#的语法，关键字等。c#的命名空间比java的package更灵活。

 

java版：

数组，集合等方面的实现

c#版：

翻译成对等的 数组，集合等。

 

java版：

xml的实现采用jdk1.4自带的包

c# ：

xml的实现采用System.xml

在所有涉及xml节点部分的代码全部转换过来。

 

java版：

数据库操作采用jdbc

c#：

数据库的实现比较麻烦。有oledb,sqlclient,oracleclient。

这部分的实现与java版的不同，但仅限于实现方面不同，.net工作流系统的数据库实现采用了工厂模式封装了oledb,sqlclient,oracleClient的不同，对外表现形式和java工作流系统一样，在所有涉及数据库操作的部分代码逻辑还是一样。（.net工作流系统的数据库实现见上一篇文章：如何构建支持多数据库的.net工作流系统 http://www.cnblogs.com/webreport/archive/2010/08/13/1799022.html）

 

java版：

反射部分有反射包

c#：

翻译成c#的反射实现。

 

java版：

流程定义时自定义脚本，采用了beanshell。

c#：

.net方面没有类似的软件，自己开发了一个支持自定义脚本功能，脚本语法是c#（和java版的一样，java版的beanshell脚本语法是java），实现动态编译和加载。



还有很多细节方面的修改，散布在各处。总之，java版的eworkflow工作流系统和.net工作流系统也象孪生兄弟一样，功能是一样的，只是实现方式不同。

.net工作流系统之扩展性

最近为用户做工作流实施时，都无一例外的提出工作流系统的扩展性问题。


事件一：eworkflow工作流系统预置了一些系统的条件，前置后置函数等。如果这些不能满足业务需要，用户需要定制自己的业务规则，业务过程，该如何做？

解决方案：eworkflow系统预置了很多系统的条件类，前置后置函数类。简单一些的业务规则，可以直接用自定义脚本，写个表达式的方式来实现。

 如条件类的：判断用户是否有某个角色  cn.com.fcsoft.workflow.util.UserHasRoleCondition  
             判断是否是竞争型任务的签收人 cn.com.fcsoft.workflow.util.CompetitionTaskCondition
             ....

             
    事件类：将指定步骤的执行人保存到mostRecentCaller变量中 cn.com.fcsoft.workflow.util.MostRecentCaller
        ...

        

 打开我们的任意一个条件类 ，可以看到，条件类必须实现Condition接口，实现passesCondition()方法

 

 

 /// <summary> 判断调用者caller是否属于role参数所指的角色

 /// caller: userid  role: roleid

 /// </summary>

 public class UserHasRoleCondition : Condition

 {

  //~ Methods 

  

  public virtual bool passesCondition(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps)

  ....

  

 流程的上下文、相关的业务参数、数据库连接、当前操作员id等，均可以在passesCondition的三个参数中获得。

 

 因此在需要扩展业务规则的时候，可以扩展这种条件类，只需要在用户的应用系统中引用eworkflow.dll（java版的就是引入eworkflow.jar），新建业务规则类，实现Condition接口，在passesCondition方法中写业务规则就可以了，所有和流程相关的信息，节点定义的属性，业务参数，均可以从passesCondition方法的三个参数中获得。

  将写好的条件类注册到 WF_DSN_CLASS表中，在流程定义的时候，从节点的属性页中选择出这些扩展的业务规则，挂接到流程的节点上。在流程实例运行到此节点的时候，就会执行这些节点上定义的业务规则类，作出规则判断。

  

  下面是一个判断 当前操作员用户，是否属于某个区域的业务规则的判断

  
  

    

 

 -----------------------------------------条件和事件的分隔线-----------------------------------------------



  打开任意一个事件函数类，可以看到，事件函数类的，必须实现FunctionProvider接口，实现execute()方法

   public class MostRecentCaller : FunctionProvider

 {

  //~ Methods 

  

  public virtual void  execute(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps)

  

  和条件类的接口一样，流程的上下文、相关的业务参数、数据库连接、当前操作员id等，均可以在execute的三个参数中获得。集成开发文档中会有这三个参数的详细描述。

  

  在需要扩展业务事件，业务过程的时候，只需要在用户的应用系统中引用eworkflow项目或者eworkflow.dll(（java版的就是引入eworkflow.jar），新建这种事件类，实现FunctionProvider接口，在execute()方法中写业务实现，所有和流程相关的信息，节点定义的属性，业务参数，均可以从execute方法的三个参数中获得。

  将写好的类注册到 WF_DSN_CLASS 表中，在流程定义的时候，从节点的属性页中选择出这些扩展的业务事件类，挂接到流程上。这样流程实例运行的时候，流转到相应的节点，就会执行节点上定义的这些业务事件。

  

  例如将当前操作员信息保存到流程的上下文中：

  



 

事件二：我们的eworkflow工作流系统的 待办任务列表 只有流程相关的信息，业务信息部分较少，集成到用户系统时，用户希望能自定义一些业务列信息。

解决方案：

 eworkflow工作流系统的任务表中，任务名称，是支持表达式的，在表达式中可以引入业务信息。例如任务名称为：审核 业务部 李明 的报销单。  业务部 李明 这两个信息均来自表达式，获取的是报销单中的记录信息。

 
 如果这样还是不能满足用户的需要，用户需要扩展列出多列业务表中的记录值。那就只能通过调用流程的获取待办任务列表的api函数来做了。

 具体过程如下：

 先通过调用工作流的api函数，获取待办任务列表

 

 ArrayList getCurrentTasks(System.String type, System.String wfId, System.String stepId);

 

 得到的是一个list，list的每一条是对应一条任务表的一个 IDictionary对象（java版的就是map对象），任务表的字段名为key，记录值为value。

 任务表中会记录任务信息关联的流程实例id, 通过流程实例id获得 和业务表的关联，找到业务表的记录，然后取出业务表中的多列信息，和任务信息 一起返回到页面显示，这样就获得了一个 包含多列具体业务信息的待办任务列表了。

.net工作流系统集成自定义表单

工作流系统一般都包含工作流引擎，工作流引擎是对业务流程的抽象，是实现流程自动化的微内核，利用工作流引擎的基本元素能搭建出各种各样的流程，但仅限于流程，不涉及到业务实现。

流程的每个节点上可以挂接需要处理的业务模块，例如一个简单的报销流程，如下图：在填写报销单的流程节点上，就可以挂接上 填写报销单 这样一个业务模块；到审批的节点上，挂接 审批报销单模块。

   
   

工作流引擎是不负责这些具体业务模块的实现的，否则就不是对业务流程的抽象了。

这些具体业务模块的实现，可以是开发人员做好的一些业务模块，也可以是用一些表单工具做的自定义业务表单。

无论是定制的业务模块，还是利用表单工具做的自定义表单，都需要在这些模块中集成流程。

好的工作流引擎都应该是封装好的，对外仅提供调用的api函数。这样才能方便的将流程与业务模块集成在一起。

 

工作流引擎对外提供的api应该包含：

流程的初始化函数：给定一个具体的业务流程名称，启动流程，获得一个流程实例id.

流程的执行函数  ：给定一个具体的流程实例id, 执行他的任务，使得流程递进，达到流程的流转。

获得与修改流程实例的状态：获得与修改一个具体流程实例的状态。指流程实例的 激活，挂起，与 完成 等状态。

获得流程定义任意节点的信息：获得指定流程指定节点的任务信息，包括流程定义的属性，自定义信息等等。

。。。。。。。

 

在业务模块中，嵌入流程引擎的api函数的调用，启动一个流程，或 通过给定的流程实例id，去执行它的当前任务，将当前任务提交，使得流程流转。当然，业务模块的业务数据提交和流程的流转应该保持在一个事务中，达到流程的长事务一致性。

 

下面以eworkflow.net+eform.net为例，说明.net工作流系统与自定义表单系统的集成。

还是以报销流程为例，先将业务流程转换成eworkflow的流程。（流程图如上图中简单报销流程）

再设计好业务表，这里我们设计了两张表，报销主表和明细表。




从上面的流程中可以看出，需要有报销单填写模块，和审核模块。

用eform画好 报销单，如下：



注：eworkflow .net工作流系统中已经集成好了eform .net自定义表单系统了。表单属性中 选择 工作流工具栏



工作流工具栏也是用eform设计的一个页面，此页面中已经做好了和流程的集成。在表单提交到后台保存的之后，再执行流程的相应动作，达到流程的递进。



用eform画好 报销单的审核 如下：（同样在表单属性中，选择 工作流工具栏）




画好的页面保存在workflow\example_dj\目录中。



在流程设计器中，打开报销流程，在相应节点上挂接好 业务表单。

 



 

这样报销流程就设计好了，可以启动执行了。

有更细一些的控制，就在流程设计器中打开报销流程，修改流程节点的属性，或修改流程的流转。



在eform自定义表单系统的代码中已经有通用的模块集成了eworkflow .net工作流系统了，所以不需要再写代码调用流程api了。