数据库详细说明

1、基于工作流引擎的信息系统通用框架设计1.1.1框架模型SysUser表是记录系统所有用户信息的地方，包括系统的认证，其中IfOnLeave表示用户是否处在休假，IfLogging表示相关的用户是否登录到系统。这两个信息在工作流引擎中 将被作为任务分配的提示信息。UserInFunc/RoleInFunc表是用来表示系统用户 /角色和系统模块之间的关系，记录不同的用户/角色拥有哪些不同的模块，以及对该模块的操作权限。Department和Team分别表示部门和团队， 部门通常表示纵向的行政隶属关系， 而团队 通常表示横向的合作关系。 Department和Team分别通过相应的 SuperDep

2、tID和SuperTeamID 关联使得在部门之间和团队之间分别形成树状的上下级关系。机构模型中的部门、团队、人员以及相互间的关系为大型企业尤其是从事技术工作的 企业的机构建模提供了有力的支持，同时也为现代企业流行的管理模式一一“矩阵管理”提供了支持。当然，对于小型机构而言，完全可以考虑只定义 Department或者Team其中之一。 由于Department和Team之间在ER图中并无联系，因此缺少其中一个并不会破坏机构模型 的完整性。1.1.2信息模型信息模型的核心是控制节点表ControlNode，其他相关的表结构主要有业务过程Process、活动节点表 Activity、任务指派规则

3、表 AssignRule、任务状态表 TaskStatus任务列 表ToDoTaskList以及已完成的任务列表HaveDoneTasks。1、活动类型每个业务过程由若干业务活动组成，不同的业务活动通过各不相同的ActID来唯一标识，ActType则指明相应活动的类型。同一个业务活动在工作流运行时可能具有多个实例(instanee)。我们将活动的实例称为任务，将属于同一业务过程的任务称为属于同一批次的任务。有的业务活动可能针对具体的业务环节，即在前台(后台)对应实际的应用逻辑；有 的业务活动则不针对具体的业务环节。活动类型分类见表1:表1活动名中文名说明INITIAL初始化活动业务过程的第一个

4、活动，不针对具体业务环节。NORMAL常规交互活动一般的人机交互活动类型DUMMY哑活动不针对具体业务环节，它可以作为某些活动的虚拟后继活动，还 可以使用它来构造更为复杂的业务规则。COMPLETION终结活动表明相应业务过程的终结，不针对具体业务环节。2、控制类型控制节点表ControlNode中的CtrNodeType表示控制节点的类型，按照前文的分析，控 制节点的类型见表 2：表2控制类型名中文名说明DIRECT无条件转移不做任何动作，直接激活下一个节点。AND_BRANCH与分支控制流经此处的任务将进行与分支，通过查找TaskStatus表来决定下一动 作。AND_MERGE与合并控制

5、流经此处的任务将进行与合并同步，通过查找TaskStatus表来决定下 一动作。OR_BRANCH或分支控制流经此处的任务将进行或分支，通过查找TaskStatus表来决定下一动 作。OR_MERGE或合并控制流经此处的任务将进行或合并同步，通过查找TaskStatus表来决定下 一动作。VOTE_MERGE投票合并控制通过查找TaskStatus表来决定投票结果。上面所定义的6中控制类型的节点，若不能满足业务要求，可以自定义其他的控制节 点类型。3、任务状态任务状态表TaskStatus实际就是一个保存一个流程实例的所有活动节点的状态图集。该表在一个流程实例产生之时一并产生所有活动节点的初始

6、状态。生成以后则由控制节点来动态修改其状态。任何活动节点实例的状态可能如表3：表3任务状态名中文名说明SLEEPING睡眠状态流程实例创建时统一设置所有活动节点为该状态，等待唤醒。WAITING就绪状态前趋控制节点将活动唤醒，等待人工处理。PROCESSING处理状态表示正在进行人工处理，等待处理结果。DONE_PASSED处理结束通过状态表示人工处理结束，移交给控制节点继续下一步处理。DONE_VETOED处理结束未通过状 态表示人工处理结束，处理意见为“否决”，同时移交给控制节点 继续下一步处理。表TaskStatus实际上是一个流程实例的状态图，在流程创建初期一并创建。一个活动可以同时具

7、有多个实例，即任务，这些实例可以是属于统一批次的，也可能属于不同批次，表TaskStatus中SerialNo （流水号）来标识任务所属的批次，所有属于同一批次的任务具有相 同的流水号。不同的任务之间则通过唯一的SerialNo进行标识。4、任务队列和已完成任务队列任务队列ToDoTaskList用于记录那些已经创建但尚未完成的任务。根据控制算法，在表TaskStatus中将后继节点状态设置为 WAITING，同时向ToDoTaskList表中添加一条信息， 系统的用户在登录后，可以通过查询这个任务队列，看到该任务。在用户处理过程中时，将它设为PROCESSING状态，防止其他用户对正在处理的

8、任务又进行处理，造成结果不一致。已完成任务队列 HaveDoneTasks用于记录那些已经正常结束的任务，CompletionFlag表示相应任务的结束标记。UserID表示执行此任务的实际人员，GrantorID若不为空，则表示此次任务的执行过程是经过授权的，GrantorID指明相应的授权人员。1.1.3任务指派任务指派是指依照某种规则将任务分配给具体人员来执行。只有常规交互活动才涉及 到任务指派的问题；其他活动要么在前台不具备实际的应用逻辑，要么由工作流引擎自动调用，因此与任务指派无关。在前文中已经提到了许多表和字段将联合用于工作流引擎的任务指派，其核心表结构为AssignRule,每一

9、个常规交互活动在AssignRule表都对应一条记录。BasedOn指明任务指派的基准，它可以取值见表4之一：表4指派规则说明DEPT_BASED基于部门进行任务指派，DeptID用于指定执行此活动的部门。TEAM_BASED基于团队进行任务指派，TeamID用于指定执行此活动的团队。ROLE_BASED基于角色进行任务指派，RoleID用于指定执行此活动的角色。USER_DEFINED基于自定义的方式进行任务指派，ExeFuncID指明相应的自定义执行程序。任务指派的基准确定了可以执行相应任务的群体，具体指派到哪些实际人员还取决于任务指派方法Method，Method可以取值见表5：表5任务

10、指派方法说明ALL任务将分配给由BasedOn指定的群体中的所有人员。LEAST_WORKING_LIST任务将分配给指定群体中的工作量最少的人员，工作量的多少可以通过ToDoTaskList的统计数据得到。FCFA先来先分配，即将任务队列中最早创建的任务分配给相应群体中最先提岀 执行任务请求的个体，任务的创建时间由DateCreated指示。PRIORITY基于优先数分配，只适合于ROLE_BASED任务指派基准。在表UserlnRole 中有个字段PriorityNo用于指定相应人员的优先级。本例中指列出了四种指派方法，用户可以根据具体需要来添加新的任务指派方法。1.2控制模型控制模型将信

11、息模型、机构模型和框架模型有机的结合在一起，它根据其中定义的业务规则来流转业务 流程，控制模型是工 作引擎的控制中心。图2是基于工作 引擎的信息系统通 用框架的结构图。调度中心 调度中心接受 从个性化界面（外部 接口）发送过来流程 控制的请求（如业务 初始化、获取任务以 及结束任务等），根 据不同的请求类型I信息模型机构模型框架模型个性化用户界面日志信息调用相应的处理模块完成与本次请求相关的操作并将结果返回。该操作是基于DBMS的并发机制和锁机制来实现工作流引擎的控制模型， 不需要诸如请求队列等形式的数据结构。 从而实现了多个外部请求之间的独立性。状态图管理调度中心在收到活动节点状态变化触发之

12、后，根据其后继控制节点的类型，调用不同的算法，计算并设置 控制节点后继节点的 状态，来生成状态图。 所涉及到状态图中活 动节点的各种状态见 表3,他们之间的转换 关系见图3。任务管理任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据 的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动 （如果存在的话）创建新的实例；同时，其他不同的外部请求也将触发“任务管理”实施任 务状态的切换。任务指派任务指派处理只是针对 NORMAL活动，通常情况下，在任务状态由“SLEEPING ”切换到“ WAITING ”过程中完成任务的指派工作，即处于就绪状态的任务在通常情况下都确定了 其执行者（FCFA除外）。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人 员，通常情况下这是一个包含多个人员的集合；然后根据任务指派方法确定由这个群体中的哪些个体来执行任务，执行任务的个体标识记录在相应任务记录的UserID字段中。在前面已经对任务指派方法进行了解释