web工作流管理系统开发6-10.doc

之六 表单权限与流程的权限控制
在设计工作流系统的时候，常常会碰到这样的情况：
          同一张表单需要在流程的多个环节中处理，且各环节的处理情况不一致，有的节点可写，有的节点之可读。
  例如，同一张报销单：员工填写报销单时，只能填写报销单主体信息和明细部分，其它信息不可见；
          经理审批时，只能填写审核结果和审核意见，报销单主体和明细部分只能查看；
          财务审批时，报销单主体明细和经理审核信息都只能查看，只能设是否置领取费用的相关信息

          这样就是同一张表单在流程的三个环节中流转，且各环节对表单的信息控制权限不一样。
处理过程： 
     1、在设计电子表单的时候，设置一张表单，包含报销单的所有的信息。并同时设置相关部分相关角色的权限。
         员工－－有填写报销单主体和明细信息的权限；
         经理－－有审核结果和审核意见的可写权限，报销单主体和明细信息只读的权限，财务的是否领取费用信息不可见；
         财务人员－－有是否领取费用信息的可写权限，其它所有信息只读；
     2、设计流程的流转定义信息
          设置流程的各个环节，以及流程个环节的动作，挂接上电子表单；
          同时设置流程动作的权限；

         员工填写动作－－仅员工角色可执行；
         经理审批动作－－仅经理角色可执行；
         财务审批动作－－仅财务人员可执行；

     3、启动流程，运行表单
         当流程实例运行到填写报销单时候，仅员工角色可执行填写动作，打开表单，读取表单的权限控制，仅报销单主体和明细部分能填写。其它不可见；
         流程实例流转到经理审批环节：经理角色能执行审批动作，打开表单，读取表单的权限控制，仅审批结果和审核意见可写，其它信息只读；
        流转到财务审核环节；财务人员能执行审核动作，打开表单，读取表单的权限控制，仅是否领取费用信息可编辑，其它信息只读；

       这样利用表单的权限控制和流程环节的权限控制相结合达到同一张表单在流程的多个环节中流转的效果。
问题：
      如果有一个环节是员工查看报销单：即员工需要随时查看审核结果，此时只能查看，不再能修改报销单任何信息，且仍然是访问同一张表单。
      利用上面的方法达不到这样的结果。

提示处理方案一：
      员工随时查看审核结果，这种不应该设计为流程的一个环节，不是流程的环节，这种设计是错误的。应该设计一个查询的模块，输入查询条件去查询报销单，无论是进行的流程实例还是历史流程实例都可以查询出来，这样的方式去做到随时访问。
 提示处理方案二：
      如果业务需要，一张表单在第一个环节，同一用户可写，单据流转到后面的环节，即同一用户只可读的情况，则采用如下方法来处理：
 1、在设计电子表单的时候，设置表单控件的可读和可写权限时，选择流程的环节动作，设置控件在流程的每个环节可读、可写、不可见等特性。设置完成后保存设置在表单中；
 2、流程设计的时候，设置流程动作的权限，挂接好表单；
 3、流程实例运行时，执行动作，装入电子表单，表单初始化的时候，装入控件的权限配置信息；校验其控件的权限，初始化控件的属性。达到只读、可写、不可见等特性；

制作过程以后再附；

之七 最新的dtd格式校验修改
eworkflow自定义工作流系统，流程定义文件，采用的是xml格式，在设计之初，使用了dtd文件来约束xml文档的内容。
开发的时候，采用的是resin3来发布，对dtd格式的校验不是很严格。
 后来测试的时候，用tomcat4发布，发现对dtd文件的校验要严格一些，所以去掉了xml流程定义文件里面的dtd文件。
但是后台java代码中仍然做了dtd的校验。因为没有读取到dtd文件，校验也成功了！
 近日有用户在tomcat6发布，发现后台对dtd的校验还是不成功！各发布工具真的太太太不一样了！
 所以新近做的修改，去掉后台类中的dtd校验，改用代码做校验，即检查xml文件中的各个节点定义是否规范。
 最新修改的版本下载： /Files/webreport/eworkflow.rar  （有最新的demo版了，这个删除了）
交流qq: 6460267 (工作流)

之八 开源osworkflow之任务管理
前言：
osworkflow的任务管理很简单，没有专门的任务表，也没有待办，已办，发出，处理任务等等。
只有很简单的查询用户可处理的动作和已经处理过的历史步骤。(注意这里只是可处理的动作和已经处理过的历史步骤，都不是任务)
这显然距任务管理差很多很多。
改造方案：
      增加任务表，记录任务的相关属性，可执行人，任务处理人，任务发出时间，完成时间等。
      流程定义模版文件中增加任务节点，定义任务的名称，从流程上下文中获取任务的内容和相关属性，定义任务的可执行人。
      将产生任务记录和处理关闭任务的过程嵌入到工作流引擎的动作执行函数中。
      当流程到达步骤后，根据流程定义模版文件中定义的任务节点，产生任务记录；
      当动作执行时，检查任务是否可以执行完成，关闭任务。
      因为单独出一张任务表，所以可以增加对任务的管理，查询得出待办任务列表，已办任务列表，做代理待办，催办，逾期未办等等的处理。
      可以做到的任务管理：任务发起，待办，已办，催办，督办收回等等。

任务表结构：

流程定义节点：
例如:

          内容：${remark}
          部门经理
          5110
          "role">ROL_0000003

增加生成任务的类MakeTask：

增加descriptor中的任务定义类，并在相应的检查校验中增加对任务节点的校验：

总结：
      通过增加任务，将任务的生成与处理嵌入到流程引擎中，任务的产生与完成跟流程的运行密切相关，在流程运行时会生成相应的任务，实例递进时完成相应的任务。同时任务记录单独抽出生成一张表，又可以很容易的做待办，已办，催办等等和任务相关的管理。
      原来osworkflow是从流程引擎的核心表中去查太麻烦了也很不灵活，功能太过简单，也不利于扩展。
之九 eworkflow自定义流程最新版本下载
web工作流管理系统，eworkflow自定义流程最新版本下载

流程代码下载：/Files/webreport/eworkflow11.rar     （有最新的demo版了，这个删除了）

oracle数据库备份文件下载：/Files/webreport/eworkflow_oracle.rar  下载后解压
sqlserver数据库备份文件下载：/Files/webreport/eformtest11.rar  下载后解压
标签: java工作流, 流程设计器, 自定义工作流, web工作流, 工作流, 工作流引擎

之十 数据库连接及事务设定
为了方便设置数据库连接和事务的一致，将所有数据库连接信息统一设置在fcconfig.xml文件中；
 fcconfig.xml的内容：

  sword="eboracle" />

 /ebsys
 用户.ID,用户.名称,部门.ID,部门.名称系统.单位名称

其中节点中可以设置多个数据源连接
e表、eform或工作流系统默认均是取第一个的连接串信息。

这样设置的好处有两方面：

1、通过修改这个文件可以将开发库，测试库，运行的正式库分开；比如，开发用一套库，测试用一套库，正式运行的时候设置jndi的数据库连接；
2、可以在同一套系统中同时使用多数据源：比如，操作请求中指定数据源的name，就可以使用指定的数据源，不指定的使用默认的数据源，达到一套系统使用多数据源。

代码实现过程：
一次性读出fcconfig.xml文件的配置信息；
      可以用单例模式一次读出；
      也可以通过servlet的init()一次读出（工作流中采用的是这种方法）；

在需要建立数据库连接的时候，根据传入的datasourcename ，建立数据库连接；不传入datasourcename则取第一个；

数据库事务的一致性设定：
      工作流系统eworkflow中业务系统自定义模块用eform自定义表单来实现，流程的递进有单独的工作流引擎；
当流程实例运行时，必须要求业务数据的保存和流程的递进 保持在一个事务中，即当一个提交的环节失败后，业务数据和流程都回滚；
     这就必须要求，eform表单的提交和工作流实例的递进保持在同一个事务中：

实现过程：
      单独设置一个Environment.java类：
      此类负责调用ConnectionConfig.java，创建数据库连接，每获得一个conn后，开启事务。并提供提交关闭方法和事务回滚方法；
       在流程实例的递进提交前，建立Environment的实例，将Environment 的实例传递到eform引擎和工作流eworkflow引擎中，在需要数据库连接的时候，从Environment实例中获得一个，开启事务；如果有异常 抛出则调用Environment实例的回滚；

        当业务数据保存和流程的保存都完成后，再调用Environment实例的提交关闭；提交数据和将数据库连接关闭。

   这样就达到了流程数据与业务数据保持一致。