各级政府机关，围绕各自的行政职能，存在着很多的行政审批业务，这些行政审批业务虽在职能上存在很大差异，但从流程的角度看又存在着很多共性。与企业自动化流程控制相比，政府审批流程多为人工控制，流程的运行规则较为简单，多为串行结构，也存在一些并行分支与选择分支结构。目前，大部分机关部门，其内部审批业务的管理手段，要么是纯人工操作，要么基于不同的业务系统。即使采用工作流技术，各业务系统也是各自独立，从流程定义到用户管理都各行其是，一旦出现业务调整、机构人员变动，需要对各个系统分别进行修改。因此，从成本和效率考虑，构建统一的电子政务系统，统一管理业务和办公资源，还是很有必要的；而且，从政府审批业务的相似性来看，统一管理也存在可行性。
构建统一的政务管理系统，就是要在一个统一的平台上管理机关内部几乎所有的审批和管理业务，并统一管理和分配办公资源。要实现这一目标，就需要构建一个统一的政务系统搭建平台，以工作流引擎为核心，统一管理业务流程的定义、运行和监控。不同部门、不同用户将在这个统一的平台上完成各自不同的业务，并根据权限共享办公资源，从而实现机关业务和机关管理的有效集成。 本文将要讨论的工作流引擎不是一个独立的工作流产品，而是基于电子政务系统的内嵌的工作流模块，只追求实现统一管理部门业务的实用性要求，并不具备良好的通用性和可移植性。
2.1 基于关系结构的轻量级工作流引擎
在WfMC（工作流管理联盟）的工作流管理系统参考模型中，工作流引擎是整个工作流管理系统的核心。工作流引擎是为工作流管理系统在定义时提供支持、同时在运行时提供解释和执行服务的一组数据模型和软件，也就是说，工作流引擎是负责解释和执行工作流模型的后台工具。从前面的分析可以看出，构建统一的电子政务系统搭建平台，实际上就是实现一个统一的工作流管理平台，并在此基础上定义、运行和管理不同的业务流程。要实现这一目标，首先要考虑的就是如何在系统中引入和使用工作流引擎。
本文所研究和开发的背景是实现相关政府机关内部审批业务的统一管理，涉及的审批业务规则相对简单和固定，作者无意开发一个大而全的通用工作流管理系统，而是将工作流的开发融合到政务系统的开发过程中，从实用出发、从审批业务流程的需求出发，设计和实现一个基于特定业务规则的、能有效融合过程信息与业务数据的小型工作流管理平台。因此，从够用、灵活和低成本的原则出发，论文倾向于开发一个基于关系结构的轻量级工作流引擎。所谓轻量级工作流引擎，它不追求工作流引擎功能的完备和复杂，只是实现其中必不可少的功能和特征，即主要考虑对数据模型的定义和解释，活动之间的协调，以及任务的分配和控制等基本功能。
所谓基于关系的工作流引擎指的是工作流引擎中的数据模型（即机构模型和信息模型）全部通过关系结构来表达；控制工作流引擎运作的各种程序逻辑（即控制模型）也是通过常规关系数据库管理系统中所提供的存储过程、包以及DML数据操纵语句等机制来实现；同时，事务的并发控制也通过数据库系统所提供的机制来实现[1]。
从技术角度来说，使用关系结构来表达工作流引擎中的数据模型可以降低工作流引擎开发过程中的技术难度和工作量。具体表现在：（1）与工作流引擎相关的各种控制数据（包括业务活动的状态数据）可以存储在数据库系统中；（2）与此相关的数据的完整性可以由数据库管理系统来维护；（3）利用关系结构可以方便地定义工作流引擎中的各种数据格式和数据结构；（4）可以方便地利用数据库管理系统提供的各种DML语句来操纵工作流引擎所需的各种数据。
从开发应用系统的角度来看，在同一数据库环境下为开发者提供一个基于关系结构的工作流引擎，并且如果这个工作流引擎所提供的功能可以方便地嵌入到应用的开发环境中，则可以降低开发应用的难度。这是因为：（1）应用系统对业务数据的管理通常会采用一个常规的关系数据库系统作为后台的支撑。基于关系结构的工作流引擎可以很容易的实现与业务数据的关联；（2）应用系统的开发者往往会采用一种他们所熟悉的并且适合此数据库系统的前端开发工具来开发具体应用，这些前端开发工具一个显著特征是开发功能强大，但一般不具备工作流机制。因此，采用基于关系结构的工作流引擎可以很容易与应用的开发环境做到无缝的集成。
2.2 工作流元模型分析
2.2.1 机关审批业务的过程路由结构分析
下面以国土资源部门的业务管理需求为例进行分析，其它政府部门大多与此类似。
国土资源审批业务涉及的范围较广，包括土地、矿产、地质环境、大地测绘等几项大的管理职能，而每一项职能又包含很多具体的审批业务。与企业自动化流程相比，国土资源审批业务过程皆需人工参与，流程的运行规则较为简单，但从流程控制的角度看，却也几乎涵盖了WfMC所提出的所有路由结构。以土地违法案件的监察处理过程为例（如图2.1所示），就包含了并行、分支等路由关系：
图2.1 土地违法案件的监察处理过程模型
参考国土资源审批业务的过程控制需求，在工作流建模中要综合考虑顺序路由、并行路由、选择路由等多种路由关系：
（1）顺序执行
顺序（串行）结构是流程运行和控制的基础，其它如并行、分支（包括从主流程到子流程）等结构，都是对顺序结构的进一步控制和扩充。顺序结构是国土资源审批业务的主要过程结构。政府机关的审批环节有着很强的顺序结构特点，只有前一部门（或人员）审核通过才能进入下一个环节审批。
（2）并行处理
国土资源审批业务的并行处理存在两种情况，一种是在业务的进行中需要多个部门的协作配合。如在查处土地违法案件的过程中就需要用地科和地籍科分别提供土地的权属证明材料和土地的登记情况。虽然这种部门合作完全可以顺序地执行，但并行处理的引入可以有效提高业务办理的效率。
并行处理的另一种情况是部门（或领导）对业务的联合审批，即会签（或会审），只有所有部门（或领导）都审批通过，流程才能继续进行。以划拨土地的审批业务为例，在政府行文批准土地使用权之前，需要政府领导、国土部门主要负责人、分管负责人、相关业务科室负责人进行会签，会签通过，才能行文批准土地使用。因此，对会签的处理也是在工作流建模中引入并行路由的重要原因。
（3）选择路由
在国土资源审批业务过程中存在一些选择路由的情况，这种选择大都是人为的结果，而不是由不同过程条件所驱动的自动执行。以图5所示的土地违法案件的监察处理过程为例，就是由监察科审核用地科和地籍科所提供的数据或资料，判断土地使用者是否存在违法用地，进而决定是否对其实施处罚。
（4）流程回退
在机关审批业务的进行中不可避免地存在业务环节的反复。还是以土地违法案件的监察处理过程为例，在接受违法案件举报后的任何环节都有可能需要前面的环节补充资料、修改业务数据错误等，如在监察科审核地籍科所提供的资料时可能还需要地籍科进一步提供相邻地块的登记情况；在监察科复审案件查处结果时可能还需要监察大队进一步现场调查处理，直至可以结案为止。
因此，在工作流引擎控制模型的设计和实现中要考虑后续环节（任务）能够有选择地将流程回退到特定环节重新执行。从这一点来看，国土资源审批工作流的回退处理，与WfMC所提出的循环路由相比，需要更大的灵活性。
2.2.2 过程逻辑的嵌套约束与复杂流程的简化处理
考虑到国土资源审批业务流程相对简单和固定，为降低流程控制的复杂度，特别是降低过程回退处理的难度，实现过程执行的灵活性，本文规定流程的分支节点只能成对出现，而且过程分支逻辑不允许嵌套，只能以类似土地监察案件处理流程的形式出现。从这个角度看，国土资源审批业务的工作流模型整体上仍是顺序执行的结构。
但以上约束有可能会导致系统无法实现对某些复杂业务过程的定义和处理。以划拨土地的审批业务为例，其业务过程就似乎需要嵌套的过程逻辑。
图2.2是划拨土地的审批业务流程图。从图中可以看出，在用地科对用地申请进行初审时，如果决定拒绝申请，需要向办公窗口反馈审核意见；如果决定接受申请，则需要相关科室顺序执行审核处理，并提交部门及政府负责人等会审，会审通过后还需要根据原土地登记情况决定是否需要地籍科注销原土地登记。审批的结果及政府批准文书也需要反馈给办公窗口。因此，在定义划拨土地审批业务流程时，似乎需要在选择路由逻辑中嵌套并行逻辑。这就给流程控制特别是流程的回退处理带来了一定的难度。
图2.2 审批建设用地申请的业务流程图
为了降低流程逻辑的复杂度，需要仔细分析国土资源的业务过程特点，通过对业务过程逻辑进行改造，来简化业务处理流程，消除过程逻辑嵌套。
从划拨土地审批业务过程以及土地违法案件的监察处理过程可以看出，国土资源审批业务的办理特点是“一个窗口进，一个窗口出”，这就为充分利用系统提供的流程回退功能，消除过程逻辑嵌套提供了可能。可以为接受业务申请的窗口首任务节点增加“退回申请”的功能。这样，在用地科初审时，如果决定拒绝申请，可以填写拒绝申请的理由，并将业务过程回退到接受申请的首任务节点。对于回退的过程，接受申请的首任务节点可以选择取消该次申请（系统会删除相关业务数据，删除已创建的任务实例，只保留流程实例以备监控检查），也可以选择补充资料，重新提交申请。
这样，利用系统所提供的流程回退处理的灵活性，通过类似处理，既可以满足国土资源审批业务的复杂过程需求，同时又消除了过程逻辑嵌套，有效降低了流程控制的复杂度。
另外，划拨土地审批业务过程也包含了对选择路由执行“旁路”操作的需求，即用地申请被批准后，流程要么转到地籍科，执行分支任务（针对被申请土地已经登记注册的情形），要么直接跨过选择路由执行下一环节（如图2.3所示）。这也是流程定义与控制要考虑的问题。
图2.3 选择路由中的“旁路”分支
2.2.3 政务系统工作流的过程元模型
根据以上对国土资源审批业务过程的分析，参考WfMC工作流模型，定义如下的工作流元模型，并给出工作流引擎对部分模型元素的约束：
1、任务节点（Task Node）
图2.4是根据图2.2所示的流程图，使用工作流图形定义工具绘制的划拨土地审批业务工作流。
图2.4 划拨土地审批业务工作流
图中的蓝色矩形框代表着不同的任务节点。任务节点，或称人工活动节点，代表需要人工参与的任务，当过程的执行到达某任务节点时，系统将与当前节点相关的任务添加到参与者任务列表中，并进入等待状态。只有用户完成任务并触发过程执行，过程才得以继续。
任务节点是国土资源审批业务的具体执行环节，由具有特定角色的部门员工参与，完成如业务数据编辑、资料审核等人工活动。任务节点将作为流程定义的一部分被保存到数据库中。
2、逻辑节点（Logic Node）
逻辑节点包括标示过程起止逻辑的开始节点、结束节点(图中浅蓝色的小矩形框)，以及标示过程路由的与分支、与连接、或分支、或连接等过程逻辑节点(图中的黄色矩形框)。
（1）开始节点（Start Node）：开始节点是工作流模型的唯一入口，它无前驱节点，而且其后继节点必须是任务节点，而不能是过程逻辑节点。开始节点被记录在流程定义中，当启动流程，由引擎对流程定义实施实例化操作时，与开始节点连接的任务节点同时被实例化，并作为流程的首任务出现在对应角色用户的任务列表中。首任务的完成会激发引擎对其后续任务节点的实例化，以驱动流程的继续进行。
（2）结束节点（End Node）：基于国土资源审批业务过程相对简单的特点，与其它工作流模型定义语言允许多个过程出口不同，为了简化过程的定义和控制，这里的结束节点是工作流模型的唯一出口，即一个流程只能有一个结束节点。结束节点无后继节点，而且其前驱节点必须是任务节点。当过程执行到结束节点时，则标志着整个流程的结束。
开始节点和结束节点将作为流程定义的一部分被保存到数据库中。
（3）与分支（And Split）和与连接（And Join）节点：与分支和与连接的使用是为了方便定义和表达过程中的并行路由。与分支和与连接只能成对出现，也就是说，从一个与分支节点引出的所有并行分支最终要汇聚到一个对应的与连接节点。而且，与分支节点和与连接节点的前驱节点及后继节点只能是任务节点，不允许一个与分支节点紧跟一个与连接节点和一个与连接节点紧跟一个与分支节点等情形出现。
（4）或分支（Or Split）和或连接（Or Join）节点：或分支和或连接的使用是为了方便定义和表达过程中的选择路由。同与分支和与连接节点一样，或分支和或连接节点也只能成对出现，而且，或分支节点的前驱和或连接节点的后继只能是任务节点。和并行路由不同，或分支节点和或连接节点可以直接相连，以起到“旁路”选择路由的作用。
与开始与结束节点不同，过程逻辑节点只作为图形元素出现在工作流图形定义工具中，是为了方便表示任务节点之间的逻辑关系而设立的。过程逻辑节点不会被保存到过程定义中，它们所表达的节点间的逻辑关系将作为相关任务节点的ProcessLogic属性，分别以值“And Split”记录到与分支的前驱任务节点；以值“Or Split”记录到或分支的前驱任务节点；以值“And Join”记录到与连接的后继任务节点，和以值“Or Join”记录到或连接的后继任务节点。而且，在保存过程迁移时，与过程逻辑节点关联的迁移，将被重新指向拥有相应ProcessLogic属性的任务节点。
3、过程迁移（Transition）
本文所研究的工作流模型是由节点和迁移组成的有向图。迁移在工作流图形定义工具中是一个带有箭头的连接线段，表示节点之间的连接关系。迁移线段包含To和From两个图形属性，分别表示迁移所连接的起始节点和迁移所指向的终止节点，并在保存工作流定义的同时，被保存到记录迁移属性的数据库表中。
2.3 工作流定义模型以及与业务数据的关联
电子政务系统的工作流定义模型，包含了保存过程定义、节点定义和迁移定义等过程基本信息的数据库表，其中，节点定义保存了过程的开始节点、结束节点和所有的任务（活动）节点。除此之外，为了实现在流程运行中显示和编辑业务信息，在流程定义时还应该可以选择业务信息数据表进行关联；并在定义任务节点时选择任务可以浏览的字段和可以编辑的字段，以控制任务对业务数据的处理权限，达到数据安全性和数据一致性的目标。
另外，在不同的业务处理环节可能需要上传文档扫描件等附件资料。因此，在任务节点定义时还要选择任务是否可以上传（或浏览）附件，并将附件存储在上传附件表中。上传附件与业务数据和流程实例关联，以实现在流程运行、流程监控和业务信息浏览（查询）时可以查看相关的附件资料。
出于行政复议、法律责任追究等目的，部分政府审批可能还需要纸质文档的保存，包括审批业务相关表格的签字盖章等。因此，特定流程环节可能还需要打印与业务表相关的不同表格，如国土部门土地登记业务中就需要《土地登记申请表》、《土地登记调查表》、《土地登记审批表》等。这样，在定义流程前还要预先定义好要打印的表格，并在任务节点定义时选择任务需要打印的表格。
图2.5是工作流的过程定义模型：
图2.5 工作流过程定义模型
为了实现过程流与业务数据流的有效融合，在流程定义表中包含一个RelatedTableID字段，保存流程-业务关联表中与流程定义相关的业务表编号。在流程业务关联表RelatedTable中包含业务数据表编号字段、业务数据表名称字段TableName、业务数据表中文名字段Alias，以及用于保存业务数据表记录标识字段名的IdentifiedField字段。在审批业务的处理中，各业务环节实际上是对业务数据表的一条记录进行操作，因此各任务环节都需要知道要处理的业务表名称，及其记录的标识字段名称。在定义流程时，通过选择预先定义（或引入）的业务数据表，业务表名称、业务表记录标识字段名等将被关联到流程定义中。
在任务节点的定义表中包含ProcessLogic字段，用于记录节点的过程逻辑类型，字段的取值配合与节点关联的迁移定义（迁移定义的From或To字段指向当前节点），可以决定过程执行的走向。如当ProcessLogic字段的值为“Or Split”时表示流程可以选择以当前节点为起始节点的多个迁移中的一条来继续执行。任务节点的AssignedRole字段记录了具有当前任务处理权限的角色编号，引擎将根据该字段为登录的角色用户创建其有权处理的任务列表。
另外，在任务节点定义中还增加了字段PrintedTableID，记录活动（任务）处理时需要打印的业务表格。
在定义活动（任务）时，通过选择任务要打印的表格，打印表格的编号PrintedTableID将被记录到任务定义中，这样用户在完成任务实例时就可以选择打印业务表格。预先定义的打印表格保存了表格的打印格式及表格每一行要显示的业务表字段名集合，在处理任务实例时系统会自动获取相关字段值，逐行生成打印表，供用户选择打印。
图2.6描述了流程定义与业务数据融合的处理方法：
图2.6 流程定义与业务数据的融合
2.4 工作流实例模型
图2.7 工作流过程实例模型
工作流及其任务节点定义完成后，工作流首任务的角色用户有权启动流程，工作流引擎将根据流程定义及首任务节点定义自动生成流程实例及首任务实例，首任务的完成会激发引擎根据首任务定义以及与之关联的迁移所指向的下一任务编号，自动生成其下一任务的实例，如此顺序执行，直到流程结束。每一个新生成的任务实例，根据其任务定义的关联角色，会出现在角色用户的任务列表中。
图2.7是工作流的过程实例模型。
流程实例的Description字段由用户在启动流程时填写，用于记录流程实例的描述，如正在处理的审批项目名称、提出申请的单位（个人）等，用于在流程监控时，配合开始、结束时间等字段作为查询项使用；IdentityFieldValue字段记录了流程实例所关联的业务表记录编号。当启动流程，生成流程实例时，工作流引擎根据流程定义，自动生成关联业务表的新记录，并将记录编号记录到流程实例中，供后续的任务实例按照任务权限浏览或编辑业务表记录的相关字段；AboutTaskUsers字段记录流程任务名称及完成任务的员工，每一个流程环节完成后，系统会把任务名称及完成该任务的员工姓名添加到该字段，供流程监控使用；IsSuspended字段记录流程实例是否被冻结，被冻结的流程只有在解冻之后才能继续执行；IsCanceled字段记录流程实例是否被取消，取消流程实例的操作，会激发引擎删除关联业务表记录、删除所有任务实例，只保留流程实例供监控。因此取消流程实例操作是不可逆的，用户在监控过程执行时如果选择取消流程实例，需要填写取消原因，而且只有被冻结的流程实例（而且冻结时间超过一定期限）才可以被取消；Message字段用于保存任务实例间的沟通信息，如任务回退的原因、下一步任务需注意的问题等。用户可以随时浏览沟通栏信息，并添加自己的意见、建议等。
任务实例的TaskState字段用于设置任务的完成状态；配合任务实例的PreTaskInstance（前驱任务实例）字段和NextTaskInstance（后继任务实例）字段，为引擎控制流程的执行和回退提供了方便。
上传附件表除了前面提到的与业务数据和流程实例的关联字段之外，还包含一个保存任务实例编号的字段，以便在处理回退的任务时用户可以选择删除与当前任务实例关联的上传附件。
有关工作流模型的数据库设计将在后续章节中详细介绍。
文中所引用的论文：
[1] 何清法，李国杰，等. 基于关系结构的轻量级工作流引擎. 计算机研究与发展，2001，38(2)：129~137
