轻量级工作流引擎的设计及实现.doc

资源描述

轻量级工作流引擎的设计与实现目录目录 1 摘要 3 Abstract 4 第一章引言 5 1.1 轻量级工作流引擎的概念 5 1.2 工作流管理系统的分类及本文的侧重点 5 1.2.1 面向文档的与面向过程的 5 1.2.2 结构化的与即席的 6 1.2.3 基于邮件和基于数据库 6 1.2.4 任务推动的与目标拉动的 6 1.2.5 本文的侧重点 6 第二章工作流管理系统参考模型简介 7 第三章系统分析与设计 9 3.1 工作流模型的设计 9 3.1.1 工作流模型的对象 9 3.1.1.1 从一个简单的业务实例看业务的需求 9 3.1.1.2 工作流对象的具体分析和说明 11 3.1.2 对象之间的逻辑关系 13 3.1.2.1 对对象进行分类以及各个分类中对象之间的关系 13 3.1.2.2 各个模型之间的逻辑关系 15 3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换 16 3.1.4 任务分派 19 3.1.5 转换条件的满足 19 3.2 系统结构 21 3.3 系统模块的划分 22 3.4 数据库设计 22 3.5 类的设计 26 3.5.1 实体类的设计 26 3.5.1.1 数据库访问类 26 3.5.1.2 值对象类 31 3.5.2 业务类的设计 35 3.5.3 接口类的设计 37 第四章系统实现 37 4.1 关键问题的解决方案 37 4.1.1 启动工作流实例 37 4.1.2 推进工作流实例的进程 38 4.1.3 类型为文档的附件的处理 39 4.2 一个简单工作流管理系统的实现 39 4.2.1 系统应用框架 39 4.2.2 J2EE相关技术的应用 40 4.2.2.1 J2EE核心模式和类的实现 41 4.2.2.2 JavaBean技术与类的实现 41 4.2.2.3 JBOSS应用服务器和工作流引擎的实现 41 4.2.2.4 Jsp/Servlet技术和系统界面的实现 43 4.2.3 具体编码实现 43 第五章系统的不足 44 第六章总结 44 参考文献 45 轻量级工作流引擎的设计与实现摘要工作流管理技术由于良好的企事业业务适应性得到了广泛的应用，基于工作流管理技术的工作流管理系统已经为各企事业单位带来传统信息系统所没有的效益。工作流是一种反映业务流程的计算机化的模型，是为了在先进计算机环境下实现经营过程集成和经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流管理系统是支持企业经营过程高效执行并监控其执行过程的计算机软件系统。工作流引擎是工作流管理系统的核心。它为管理系统提供一系列通用的服务，以实现各种管理系统的具体应用。针对目前企事业的一般业务，我们运用了轻量级工作流引擎的概念，主要探讨轻量级工作流引擎的具体设计和具体实现。实践证明，轻量级的工作流引擎可以满足企事业一般的需求，而且明显缩短了开发周期。关键字:轻量级，工作流引擎，工作流模型，工作流实例，业务规则 Abstract Because of the good adaptabilities to the enterprises’ business, the workflow management technology now has already been used extensively. The workflow management system which bases on the workflow management technology has also already brought the benefit that the traditional information system couldn’t bring. The workflow is a computerize model which reflects the business process, and it is also a business model which can be carried out by the workflow management system, setting up with the purpose of accomplishing the integration and automation of the management process under the advanced computer circumstances. The workflow management system is a computer software system that can support the enterprises management process to carry out in a high efficiency and dominate the management process. The workflow engine is the core of the workflow management system. The workflow engine offers series of common services for the management systems with the purpose of bringing all kinds of management systems to be applied concretely. In connection with the common business of the present enterprises, we put the definition of the lightweight workflow engine to use, and research the concrete design and accomplishment of the lightweight workflow engine chiefly. The practice has proved that the lightweight workflow engine can meet the common demands of the enterprises, and can shorten the development periods visibly. Keywords：Lightweight, workflow engine, workflow model, workflow instance, business rule 第一章引言 1.1 轻量级工作流引擎的概念轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。 1.2 工作流管理系统的分类及本文的侧重点根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。 1.2.1 面向文档的与面向过程的前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。 1.2.2 结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。 1.2.3 基于邮件和基于数据库前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。 1.2.4 任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。 1.2.5 本文的侧重点本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心――工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。第二章工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范，定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。 WFMC给出的工作流参考模型如下图：接口2 接口3 接口4 接口1 接口5 过程定义工具工作流API与交换格式工作流执行服务工作流机（工作流引擎）工作流管理工具其它工作流执行服务工作流机工作流客户应用工作流机直接调用的应用图2.1 工作流参考模型从图中可以看出，参考模型包含了五类接口，分别是： ⑴ 接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。 ⑵ 接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。 ⑶ 接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。 ⑷ 接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的控制和状态描述，对活动的管理，对资料进行处理。 ⑸ 接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作流引擎）提供这五个接口，提供其实现的所有功能。第三章系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。 3.1 工作流模型的设计对工作流模型的设计是工作流引擎设计的重要组成部分。 3.1.1 工作流模型的对象企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成工作流模型对象。 3.1.1.1 从一个简单的业务实例看业务的需求目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步骤： ⑴ 申请人需要出差，并且他（她）具有出差的权利； ⑵ 申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况； ⑶ 申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来； ⑷ 申请人确认申请无误后提交申请，等待申请的结果； ⑸ 根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理； ⑹ 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果； ⑺ 申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则根据审批结果对该申请进行修改，重新提交申请； ⑻ 申请事务结束。这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对象： ⑴ 申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业务的权利； ⑵ 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该业务进行处理的权利； ⑶ 出差表格：它是该业务规定的格式化资料，并且是必须的 ⑷ 出差具体说明：它是该业务附加的资料，可以不要的 ⑸ 申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用 ⑹ 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则 ⑺ 申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 ⑻ 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化 ⑼ 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本对象： ⑴ 用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。 ⑵ 角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。 ⑶ 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进行处理。 ⑷ 需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。 ⑸ 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。 ⑹ 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一个一个的环节组成。 ⑺ 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。 ⑻ 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。 ⑼ 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。 3.1.1.2 工作流对象的具体分析和说明通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。 ⑴ 用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体； ⑵ 角色：以技能为前提，能够完成某项功能的人员的总称； ⑶ 部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的； ⑷ 职位：以行政责任为前提，代表了管理上的等级关系； ⑸ 工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构； ⑹ 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个过程； ⑺ 流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式； ⑻ 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的细化； ⑼ 环节实例：对应于一个环节的具体应用，是环节实例化的表现形式； ⑽ 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型； ⑾ 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类： ● 表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例； ● 文档类型：只是以文件形式保存附件信息，可以是work文档，也可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上 ⑿ 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的结束； ⒀ 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现了参与人员和系统交互的典型特征； ⒁ 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： ● 自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。 ● 与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理，其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。 ● 或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整个活动就可以完成。 ● 投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。 ⒂ 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规则去完成等等； ⒃ 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编辑和查看文本文件信息等等； ⒄ 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来，以便对其进行管理。 3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。 3.1.2.1 对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类： ⑴ 组织模型组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用下图表示：设置负责组成组成资格组成部门职位用户工作组角色图3.1 组织模型结构从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。 ⑵ 工作流定义模型工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下图：图3.2 工作流定义模型结构包含包含包含包含遵循包含工作流定义附件信息主信息业务规则环节流程包含流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息和附件信息，共同构成工作流定义模型。 ⑶ 工作流实例模型工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如下图：记录记录细化细化影响影响影响影响记录记录转换条件环节实例信息流程实例信息工作项信息工作流实例信息日志信息日志信息细化图3.3 工作流实例模型结构转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息à流程实例信息à环节实例信息à工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。 ⑷ 外部支持模型外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。 3.1.2.2 各个模型之间的逻辑关系不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如下图所示：调用依赖使用使用角色和工作组用户定义工作流实例模型外部支持模型工作流定义模型组织模型图3.4 模型之间的关系组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。 3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的转换。 ⑴ 工作流实例状态图创建管理员管理员管理员 Running （运行） Completed （结束）正常情况 Suspended (挂起) terminated (终止) Initial （初始化）图3.5 工作流实例状态图提交 ⑵ 流程实例状态图管理员管理员管理员 Running （运行） Completed （结束）正常情况 Suspended (挂起) terminated (终止) 图3.6 流程实例状态图 ⑶ 环节实例状态图处理中接受完成正常处理没有完成异常处理回退处理提交给下一环节图3.5 环节实例状态图 ⑷ 工作项状态转换图等待操作完成通过没有完成不通过无操作，超时操作下一工作项回退处理已查看初始化未审批未查看图3.5 工作项状态图接受 3.1.4 任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可以得到以下准则： ⑴ 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项； ⑵ 基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项； ⑶ 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项； ⑷ 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项； ⑸ 基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强的适应性，以及使系统在任务分派时有较大的灵活性。 3.1.5 转换条件的满足工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下： ⑴ 工作流实例的转换条件工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。 ⑵ 流程实例的转换条件流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。 ⑶ 环节实例的转换条件环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规则的规定。 ● 如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常结束状态； ● 如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结束状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常结束状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态； ● 如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常结束状态； ● 如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。 ⑷ 工作项的转换条件工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的规则统称为人工型规则。 ● 如果业务规则是自动型，同属该规则的工作项的状态就只有正常处理后的正常结束状态，当然如果对该工作项还没被处理则处于处理中状态，可这不对环节实例等产生影响； ● 如果业务规则是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该工作项则使到该工作项处于非正常结束状态。 3.2 系统结构本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分析和详细的设计，在这里我们就提出一个系统结构，如下图所示：工作流定义器工作流解析器实例调度中心任务管理器任务分派器启动控制器工作流定义数据工作流实例数据日志数据工作流定义接口工作流实例接口组织定义数据组织定义接口组织定义器状态转换器组织管理器图3.6 工作流引擎系统结构图

展开阅读全文