第一篇：工作流技术研究
工作流技术研究（1）(2008-09-10 19:29:14)
标签：工作流管理系统 工作流参考模型 杂谈 分类：工作流
工作流技术从起源到现在已有三十年的发展历史,为了规范工作流技术的管理,1993年成立了工作流管理联盟(WfMC)。WfMC统一了工作流的定义,制定了工作流产品结构和工作流参考模型等一系列的标准。本文针对工作流及其参考模型作简单的介绍。
首先，先了解一下工作流的相关定义。
一、工作流相关定义
定义1 工作流（Workflow）：工作流的概念定义很多，其中被广泛引用的是工作流管理联盟关于工作流的定义，该组织为工作流管理系统的相关术语、体系结构及应用编程接口等方而制定了一系列的业界标准。工作流管理联盟给出的工作流定义是：全部或者部分，由计算机支持或自动处理的业务过程，它已根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。工作流是指整个或部分经营过程在计算机支持下的全自动化或半自动化。工作流是企业中各种流的载体，它带动了信息流、物料流、资金流的流动，并决定了它们的流速和流量。通过工作流，考察信息、物料、资金等随过程的变化情况，从而可以方便地对一些关键指标进行跟踪和计算。其文
档、信息或任务可以遵循一组程序上的规则从一个参与者传送到另一个参与者。
定义2 工作流管理：工作流管理（Workflow Management, WFM）是人与计算机共同工作的自动化协调、控制和通讯，在计算机化的业务过程上，通过在网络上运行软件，使所有命令的执行都处于受控状态。在工作流管理下，工作量可以被监督，分派工作到不同的用户达成平衡。
定义3 工作流管理系统（WFMS—Workflow Management System）：工作流管理系统是这样的一个系统，详细定义、管理并执行工作流，系统通过运行一些软件来执行工作流，它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义，与工作流的参与者（包括人或软件）相互作用，并根据需要调用其他的软件工具或应用。这些软件的执行顺序由工作流逻辑的计算机表示形式（计算机化的业务规则——过程定义）驱动。总体来说，实际企业中运作的工作流管理系统，是一个人与计算机结合的系统。
它的基本功能体现在几个方面：
? 定义工作流，包括具体的活动、规则等。
? 遵循定义创建和运行实际的工作流。
? 监察、控制、管理运行中的业务，例如任务、工作量与进度的检察等。
定义4工作流机：为工作流实例提供运行时期的执行环境的软件服务器或引擎。工作流机能处理：
? 解释过程定义
? 控制过程实例—创建、激活、挂起、终止等
? 为过程的活动导航，可能要包含顺序或者平行的操作、最后时间期限、对工作流相关数据进行解释
? 参与者签名和退出
? 确定任务项目，实现用户意图；提供接口，支持用户交互
? 维护工作流控制数据和工作流相关数据，在应用程序间或者用户间传递工作流相关数据
? 提供调用外部程序的接口，连接所有工作流相关数据
? 提供控制、管理和审查功能
工作流机可以控制过程集、子过程、或通过对象类型的范围、及其属性定义好运行范围的实例。在一个由多个工作流机构成的工作流执行服务器中，要把过程进行划分，分配给工作流机。可以按照过程类型来划分，某个工作流机负责控制相应类型过程；按照功能进行划分，某个工作流机负责控制过程的一些部分，这些部分所需要的用户或者资源，都在此工作流机的控制范围内。也可以按照其他的一些机制来划分。
定义5 业务过程（business process）：就是活动的集合，这些活动均关联于特定的托付事项（commitment），为过程的产出增值。相对于“工作流”，业务过程是一个更一般化的统称，而工作流这个词，则已经不能仅从字面含义或原理上去理解，它已经被赋予了更深一层的特定含义——专指基于信息技术规划、运作、管理的业务过程。
定义6 自动与协调：“自动”（automate）是工作流的一个特征，但这主要是指它自动进行的特征，而不是说没有人的参与。工作流实际上是一个人与计算机协调的混合过程，在一个实际的工作流中，通常总有些步骤是人完成的。协调是工作流管理的一个目标或者特征，这包括了人与人、人与计算机，计算机软件之间等多种层面的含义。
定义7 监察与控制：监察（Monitoring）与控制（Contorl）是工作流系统的重要功能与特征。这不仅包括对正在发生的业务过程（工作流），还包括它的定义或改
变（比如BPR的过程）。这是工作流系统带给我们的明显好处之一。定义8 标准化：工作流的概念被明确提出并得到重视的同时，人们就认识到了“标准化”在其中的重要性，有关工作流的标准开发和推广，基本是与“工作流”的开发和推广同步进行的。在这方面目前的权威性机构，是“工作流管理联盟”（Workflow Management Coalition, WfMC）。它成立于1993年8月，目前已拥有 130 余个成员，成员包括工作流产品的供应者、应用者，有关大学和研究机构和个人，是一个国际性的非赢利组织。定义9 工作流与重规划：从逻辑上，对工作流的关注和研究可以看作是对业务过程重规划（BPR）的一种深化。BPR的观点，要求我们将眼光投向实际业务进行的过程，但这个过程应当是什么样的，怎样分析、构造？工作流就是一个具体的、操作性的答案，它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造，变成解析的、技术的、可控制和预测的工程化过程，如此，才真正体现出
re-engineering 中 engineering 的意义。
工作流与 BPR 的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（Workflow And
Reengineering International Association, WARIA）。
工作流管理系统是一个真正的“人—机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到计算机针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务
分派和任务的完成状态，可以被最大程度地计算机化和受到控制。
现在的典型工作流产品是客户—服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化
工具，依照业务过程实例的情况定义相应工作的安排。
二、目标领域
使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。
工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。不用将过程用文字的形式写在纸上，工作流系统使你通过
流程定义建模实现过程的自动化（如使用基于Web的应用）。
工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用
（不重复发明轮子）和应用软件的可维护性。
三、工作流参考模型
WfMC定义的工作流参考模型包括若干基本部件和5个基本接口（部件之间的箭头表示部件之间的接口），如图1所示。工作流执行服务器周围的接口是 WAPI（Workflow APIs），通过这些接口可以访问工作流系统的服务，这些接口还控制工作流控制软件与其他系统组件间的交互。在5个接口中的许多功能，都是被2个或更多个接口同时拥有的，因此WAPI可以看作是统一的服务接口，可以交叉使用这5个接口来支持工作流管理功能，而不是单独的使用其中某个接口。
首先，我们粗况的了解一下参考模型中的基本部件，然后再对这些基本部件进行简单分析。
（1）过程定义：负责给出工作流程的定义，并以一定的数据格式提供给工作流引擎解释。
（2）工作流执行服务：工作流管理系统的核心，提供了过程实例执行的运行环境。工作流执行服务借助于一个或多个工作流引擎，激活并解释工作流流程定义，用来创建、管理、执行工作流实例。并同外部的应用程序进行交互，完成工作流过程实例的创建执行与管理职能。
（3）管理和监视工具：负责监控工作流的执行，对工作流管理系统中过程实例的状态进行监控与管理，如用户管理、角色管理、审计管理、资源控制等。
（4）工作流客户应用：执行者访问工作流的界面，活动参与者通过这样的应用程序参加工作流活动，获取自己的任务。
（5）工作流引擎：过程定义的解释器，它是工作流执行服务的核心。
（6）被调应用程序：工作流执行服务在过程实例的运行过程中，调用的、用以对应用数据进行处理的程序。在过程定义中包含这种应用程序的详细信息如类型、地
址信息等。
（7）其他工作流执行服务：在大型的工作流管理系统中，工作流可能需要多个工作流引擎共同完成，甚至需要其他异质的工作流执行服务来辅助完成，这涉及到工
作流管理系统之间的互联。
其中过程定义通常包括一些独立的活动步骤，相关的计算机和用户通过一系列的活动步骤操作或制定规则以管理流程的步骤。
参考模型中定义的五类工作流接口。
（1）接口1（工作流定义转换）：工作流服务和工作流建模工具间的接口，包括工作流模型的解释和读写操作。
（2）接口2（客户端应用程序接口）：工作流服务和客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方法。
（3）接口3（应用程序调用接口）：工作流引擎和直接调用的应用程序之间的直接接口。
（4）接口4（工作流机协作接口）：工作流管理系统之间的互操作接口。
（5）接口5（管理和监视接口）：工作流服务和工作流管理工具之间的接口。
在实际的应用中，很多商用和开源的工作流系统都没有严格遵照这个标准，或者说没有统一。一个原因是WfMC的标准对于很多细节没有明确说明，在实现时各个系统出现了各自的实现。另一个原因是，工作流系统与业务系统关系密切，受业务系统的限制或约束太大，因此支持不同业务的工作流在细节上差异很大，标准不易统一，做
一个通用的工作流系统难度比较大。
3.1过程定义
1过程定义工具（Process Definition Tools）
过程定义是用来创建一个计算机可以处理的形式的过程描述。可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。有许多不同的工具可以用来分析、建模、描述业务过程；这样的工具有很大的不同从非正式的（铅笔和纸）到成熟的、十分专业。工作流模型不关心这些工具的特性，也不关心在过程建立时期他们是如何交互的。在以前指出过，这些工具可以作为工作流产品的一部分来提供，或者一个单独的产品，例如BPR工具集。
有的工作流产品提供了其自己的过程定义工具，从而过程定义一般是保留在工作流产品范围内的，并且可能或者不能被读/写信息的编程接口所访问。而使用单独的过程定义和执行服务器产品，过程定义能够在不同的产品间进行转换，并可以被其他产品访问。
设计活动和最后的过程模型输出，称为过程定义。在运行时期过程定义可以被工作流机解释。
过程分析工具、建模工具和定义工具，都要有在一个组织结构中模拟过程的能力（尽管这不是工作流参考模型规定必须有的）。如果组织模型集成到了这些工具中，那么过程定义将包含组织相关对象。这些都是与系统相关的控制数据，例如角色：活动者间的关系，可能会在过程执行期间被引用。工作流定义转换（接口 1）
在建模或定义工具与运行时期工作流管理软件间的接口，被称为过程定义导入/导出接口。这个接口的特点是：转换格式和API调用，从而支持过程定义信息间的互相转换。这个接口也支持已完成的过程定义间的互相转换，或过程定义的一部分。例如，过程定义的改变或者活动中属性的改变。
使用标准的过程定义格式有很多好处：
首先，把建立阶段与运行时期环境进行了分离，可以使用一个建模工具来产生过程定义，这个过程定义可以作为很多个不同工作流运行时期产品的输入。从而用户
可以单独地选择建模工具和工作流运行时期产品。
其次，可以为几个工作流机输出过程定义，这几个工作流机合作来构成分布式的工作流执行服务器。
WFMC在此部分作了以下两个方面的工作：
（1）提出了一个元模型，可以用来表示过程定义中的对象、对象间的关系和属性。这个元模型为不同的产品间的过程定义相互转换奠定了基础，并形成了一套转换
格式。
（2）工作流系统间或工作流系统与过程定义产品间的API调用，提供了公共的方法来访问工作流过程定义。访问可能是读、读/写或者只写操作，并且操作标准对
象集合（在元模型中定义的对象集合），或者产品自己的对象集合。
3基本元模型（A Basic Meta-Model）
WFMC开发了一个过程定义的元模型。元模型中定义了基本的对象类型集，来满足简单的过程定义相互转换。或者有开发者具体扩展，或者在增加的功能中定义另
外的一致性级别来增加更多的对象类型。
需要为下边的类型定义特殊的属
性：
工作流类型定义（Workflow Type Definition）
? 工作流过程名
? 版本号
? 过程开始/结束条件
? 安全、审查、控制数据
活动（Activity）
? 活动名
? 活动类型
? 进入动作和离开动作
? 其他约束
转移条件（Transition Conditions）
? 执行条件
工作流相关数据（Workflow relevant data）
? 数据名与路径
? 数据类型
角色（Role）
? 名称与组织实体
? 应用程序调用（Invoked Application）
? 类型和名称
? 执行参数
? 本地或者访问路径
在分布式工作流服务器中，可能要在过程定义时，为每个工作流机分配活动，可以作为活动的一个附加属性。过程定义能影响安全性与管理。定义的交换格式，要支持符号命名方案，这些符号可以映射到工作流执行服务器中的实际名称与地址。这种映射可以使用动态地址定位机制来实现（例如，目录服务器），也可以使用其他的外部过程定义机制实现。也有其他的一些行业在相关的方面作研究，例如过程建模和CASE转换工具；WFMC提出的方法也适用与其他行业，预
先定义适当的转换格式。
4访问过程定义的 API（APIs to access Process Definitions）
用来支持访问过程定义数据的API命令集。希望规范中包含下边列出的通用类型功能。命令集应该提供命令操作表，和操作的对象、属性，包括：
建立会话（Session Establishment）
? 连接/断开参与系统间的会话
工作流定义操作（Workflow Definition Operationis）
? 从过程定义库或者其他资源中，获得工作流过程的名称列表
? 选择工作流过程定义，为更多的对象级操作提供会话句柄
? 读/写上层工作流过程定义对象
工作流定义对象操作（Workflow Definition Object Operations）
? 创建、恢复、删除工作流定义中的对象
? 恢复、设置、删除对象的属性
3.2工作流执行服务
1什么是工作流执行服务器
由一个或多个工作流机构成的软件服务器，用来创建、管理、执行工作流实例。应用程序可能会通过WAPI来与这个服务交互。
在模型中，过程与活动控制逻辑间有一个逻辑上的分离，活动控制逻辑构成工作流执行服务器；过程与应用工具间、与终端用户任务间也有一个逻辑上的分离，应用工具和任务建立起对每个相关活动的处理。这种逻辑上的分离，为制定更多的行业标准提供了机会，也为在工作流程序中集成用户具体的应用工具提供了机会。
使用下边两个接口中的一个，就可以使工作流机访问外部资源：
客户端应用程序接口（The client application interface），通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务。然后由任务表处理器负责，从任务表中选择、推进任务项。由任务表处理器或者终端用户来控制应用工具的活动。
应用程序调用接口（The invoked application interface），允许工作流机直接激活一个应用工具，来执行一个活动。典型的是调用以后台服务为主的应用程序，没有用户接口；当执行活动要用到的工具，需要与终端用户交互，通常是使用客户端应用程序接口来调用那个工具，这样可以为用户安排任务时间表提供更多的灵活性。
在分布式的工作流执行服务器中，每个工作流机控制过程执行的一部分，并与这部分过程中的活动所要用到的用户、应用工具进行交互。在分布式的执行服务器中有公共的名称空间与管理范围的，从而过程定义、用户/应用程序的名称在一致的标准下被处理。分布式工作流系统，在工作流机间采用特殊的协议和信息转换格式，来同步工作流机的操作、过程交换和活动控制信息。也许工作流相关数据也要在工作流机间进行传递。在单一的工作流执行服务器中，这些操作都是由开发商自己定义的。
在工作流机间需要一个标准的交换格式，来实现异种产品间的调用。使用接口4，执行服务器可以把活动或者子过程转移到另外一个（异种）执行服务器中执行。在工作流参考模型中，这被称作“工作流机交互（Workflow Engine Interchange）”。
2过程和活动状态变迁（Process and Activity Transitions）
工作流执行服务可以看作是一个状态变迁机器，过程或者活动的实例在响应外部事件、工作流机负责的控制判断后，其状态发生改变。
下图描述了过程实例的基本状态变迁方案：
在上图中，发生状态转移（用箭头表示）来响应WAPI的命令；过程定义中的转移条件满足，也可能发生状态转移。
初始化（Initiated）—过程实例被创建，包括与过程状态相关的日期、工作流相关数据，但是过程还没有满足条件，不能执行。
运行（Running）—过程实例已经执行，过程中的活动如果条件满足就可以执行。
激活（Active）—过程中的一个或者多个活动已经被执行。
挂起（Suspended）—过程实例被静止，并且过程中的活动不能执行，直到过程返回到运行状态。
结束（Completed）— 过程实例满足结束条件；所有的完成后操作都将被执行（例如记录日志、或者统计信息），并且销毁过程实例。
终止（Terminated）— 过程实例在正常结束前被停止；所有的完成后操作都将被执行（例如记录错误信息、或者恢复数据），并且销毁过程实例。
活动是不能被中断的，例如工作流执行服务器一旦开始了一个活动，就不能挂起或者终止这个活动。这就意味着，只有在所有运行中的活动结束后，并且过程返回到运行状态，才能对过程执行挂起、重启、终止等命令。另外，可能需要把几个活动放在一起作为“原子单元”，这些原子单元要执行就全部被执行完，如果中途出现异常则返回到开始点，重新执行。可中断活动的处理办法和原子活动单元的重新启动能力，需要进一步的考虑，这超出了WFMC的初期工作范围。
忽略那些额外的复杂事物，活动实例的基本状态和转移如下图：
一个活动的基本状态有：
初始化—过程实例中的活动已经被创建，但是还没有激活（例如，活动的进入条件没有满足），并且没有任务需要处理。
激活 —创建好的任务，分配这个活动来处理。
挂起—活动实例被静止，并直到活动返回到初始化状态，才能为其分配任务。
结束 —活动实例执行完成。
当然，一个产品也可以实现一些其他的状态类型，或者使用不同基本状态和转移来代表上图中的状态和转移。参考模型没有指定工作流系统的内部行为，但是状态
转移阐明了，API命令集的影响范围的基本观点。工作流应用编程接口与数据交换（Workflow Application programming Interface & Interchange）
WAPI可以被看作是一套由工作流执行服务器支持的API调用和数据交换集合，这个集合在在工作流执行服务器的边界处，负责与其他资源交互。尽管结构中涉及到了WAPI中的5个接口，但是每一个接口中的许多功能都是公共的（即，同时被2个或者多个接口共同拥有）。
WAPI的主要功能由API调用组成。同时在WFMC也定义了接口间的，数据转换格式，例如过程定义。工作流控制，工作流相关数据和工作流应用数据
工作流执行服务器维护内部控制数据，来确定过程实例或活动实例的状态，并支持其他内部状态信息。这种内部控制数据不能被访问，也不能进行转换。但是有些信息内容是要对外提供的，来响应某些特殊操作（例如，查询过程状态等）。同种工作流执行服务器可能在工作流机间交换这些信息，通过使用具体的内部对话。
工作流控制数据—由工作流管理系统和（或）工作流机管理的内部数据。
工作流管理系统使用工作流相关数据来判断转移条件是否满足，并选择下一个要执行的活动。这些数据能被工作流应用程序访问，这些数据也需要通过工作流执行软件在活动间传递。当在同种环境下进行操作时，如果过程的执行要在2个或者多个工作流中进行，那么这些数据就要在工作流机间进行传递；这个过程可能需要名称映射
或者数据转化。
工作流相关数据—工作流管理系统用来判断过程中状态转移是否可以执行的数据。过程实例中的每个活动中可能都需要进行数据操作。因此，工作流模型必须能够在所有的处理活动间的“情形数据”交换。在一些环境中，可能需要情形数据在不同的工具数据格式间进行转换，例如，把文档从一种格式转成另外一种格式。（有的系统中，数据转换是工作流执行服务器来完成的；有的系统中直接把数据转换定义成过程中的一个活动来执行）
工作流应用程序数据—应用程序的具体数据，并且不能被工作流管理系统访问。
工作流应用程序数据不能被工作流执行软件所使用，只与应用程序或者用户任务的执行相关。就像工作流相关数据一样，在同种执行服务器中应用程序数据会在工
作流机间进行传递，来保证活动的正常执行。
应用程序与其需要用到的工作流相关或应用程序数据间的关系，会在工作流定义中说明。在一些情况下，可能是隐含关系（例如，在一些系统中情形数据会作为活动导航的一部分，传递到下一个活动中），然而在其他情况下（例如访问共享对象存储），就需要明确定义对象的名字和应用程序的访问路径。在参考模型中，把前一种情况
称为“直接数据交换”，后一种称为“间接数据交换”。数据交换（Data Interchange）
工作流相关数据和应用程序数据的交换，都需要访问WAPI，来支持在3个运行时期功能中的协同工作：
? 任务表处理器（Interface 2）
? 应用程序调用（Interface 3）
? 工作流机交换（Interface 4）
本节讲述数据交换的基本原理；提出了API命令集，包括从工作流机中接收/返回工作流相关数据的具体调用；并为直接数据交换和间接数据交换定义了，与上述
API命令集不同的命令集。
由Email驱动的工作流系统是一种典型的应用程序数据的直接交换，这样的系统中，应用程序数据物理地在活动间进行传递。这种情况下，不需要明确定义活动与应用程序数据间的关系；应用程序数据作为标准工作流活动导航的一部分进行传递，并且在应用程序调用时在本地直接与程序相关。需要在活动间提供数据格式转换时，应用程序需要定义与之相关的数据类型，可以作为一个属性来定义（这个属性信息可能存放在软件执行环境中，或者能被整个工作流执行服务器访问，例如地址目录）。这样，使用同种工作流应用程序构造的系统，就能够根据每个应用程序所定义的数据类型进行数据转换。需要采用一些协议来传递和保存数据类型信息，例如使用 X.400 对象标识符，或者Internet mail MIME机制。
一些类型的工作流系统（例如，使用共享文档存储实现的），在活动间不能从物理上传递应用程序数据。在这些系统中，应用程序要使用适当的访问路径才能进行数据访问。这样，必须要有统一的访问路径命名方案，必须是有效的访问权限，并且由激活的过程实例来控制访问权限。在这种情况下，如果需要，在建模时，数据格式转换
也可以作为一个活动。
同种系统中可能使用私有的对象命名协定和访问权限，但是异种系统需要一个公共的方案。在异种系统中，在过程定义时必须包含对应用程序数据对象存储的访问
路径，或者在活动间的导航必须包含访问路径的传递。
同种工作流产品进行协调工作，其必须采用相同的应用程序数据交换方法，或者通过一个网关机制进行协作，网关机制通过适当的协议，可以在两种不同的数据交换方法间进行映射，也可以处理对象命名与数据类型转换的不同。以后还需要对这部分进行细化，但有可能制定一个交换标准，来包含上述的两种情况。
工作流应用程序或相关数据交换的方法，都是通过3个接口来处理的；下边列出了这3个接口：
客户端应用程序接口—工作流相关数据可以包含在任务中。工作流相关数据也可以通过共享的对象存储形式来间接传递。
应用程序调用接口—依靠应用程序调用接口进行数据转换，可能需要在调用服务中把数据包含在具体应用程序协议中。激活的工作流应用程序可以使用，读/写工作
流相关数据的API，或者用这些API来构造通用应用程序代理。
工作流机协作接口—与客户端应用程序接口相似，尽管在不同的系统中支持不同的应用程序数据交换方法，但是网关功能的使用，需要在两种方法间进行映射，也
要处理名称问题。
3.3工作流客户应用：
1工作流客户端应用程序（Workflow Client Applications）
任务表处理器是在需要调用人类资源的活动时用来与终端用户进行交互的软件。任务表处理器可以作为工作流产品的一部分提供给用户，也可以由用户自己开发。在其他情况中，工作流可能要与普通的办公系统进行集成，例如Email，来为终端用户提供一个统一的任务管理系统。这就要求在工作流执行服务器与工作流客户端应用程序
间有一个非常灵活的通信机制，来构建各种可能遇到的运行系统。在工作流模型中，通过客户端应用程序与工作流机间的定义良好的接口进行交互。在这个接口中包含任务表—由工作流机分配给用户的任务序列。最简单的情况是，工作流机访问任务表，来把任务分配给用户；任务表处理器访问任务表，向任务表中添加任务项。有许多不同的产品来实现任务表的交互。
任务表中任务项的激活（例如，启动应用程序，连接工作流相关数据），可能是由工作流客户端应用程序或者终端用户控制的。在工作流客户端应用程序与工作流执行服务器间定义了一系列的方法，用来向任务表中添加任务项、从任务表中删除完成的活动、激活临时挂起的活动，等。
任务表处理器也可以调用应用程序，或者直接调用，或者由终端用户调用。通常希望，任务表处理器的应用程序调用范围能够受到运行环境的限制，尽管这样会给
模型带来通用性的限制，但这种情况是一直存在的。
与任务表相关的部分活动的数据，是任务表处理器用来调用应用程序所必须的信息。当应用程序数据是强类型时，在任务表处理器中要存放一个联接，用来实现程序的调用。在其他情况中，在任务表处理器与工作流机间要进行完全的应用程序名称和地址信息的交换；这时，工作流客户端应用程序也可能实现一些应用程序调用接口（接
口3）中的功能，来获得必要的信息。
任务表中可能要包含一个过程中的几个不同实例的相关任务，或者包含几个不同过程中的一个共同活动项。一个任务表处理器可能要与几个不同的工作流机、几个不同的工作流执行服务器进行交互。（按照每个产品的实现，为每个过程单独维护一个物理上分开的任务表，或者任务表处理器把几个不同的任务表联合到一起，呈现给终端
用户）
因此，客户端工作流应用程序与工作流机间的接口必须十分灵活，来满足下边的几方面功能的实现多样性：
? 过程和活动表示符
? 资源名和地址
? 数据引用和数据结构
? 可选择的通讯机制 工作流客户端应用程序接口（接口 2）
满足上述需求的方法，在标准API集后，可以为从工作流应用程序到工作流机和任务表的访问提供一致的形式，而不管产品的实现特性。
API与其参数可以映射到几个不同的通信机制上，来适应各种不同的工作流实现模型。
WFMC在其文档中，分开发布API规范；下边是对客户端应用程序API使用的一个概述，分成几个不同的功能。提供了对单独或者多个过程活动实例的操作命令，就像任务表一样。
建立会话（Session Establishment）
? 连接/断开参与系统间的会话
工作流定义操作（Workflow Definition Operations）
? 对工作流过程定义名称或者属性的恢复/查询功能
过程控制功能（Process Control Functions）
? 创建/开始/结束一个过程实例
? 挂起/唤醒一个过程实例
? 在过程实例或活动实例中强制一个状态发生改变
? 查询过程实例或活动实例的属性
过程状态功能（Process Status Functions）
? 打开/关闭过程实例或活动实例的查询，设置过滤标准
? 获取过程实例或活动实例的详细信息
? 获取具体过程或活动的详细信息
任务表/任务项处理功能（Worklist/Workitem Handling Functions）
? 打开/关闭任务表查询，设置过滤标准
? 获取任务表中的项目
? 通知选择/重分配/结束一个任务项
? 查询任务项属性
过程管理功能（Process Supervisory Functions）
? 改变过程定义或者它的实例的运行状态
? 改变某种类型的所有过程实例或活动实例的状态
? 为某种类型的所有过程实例或活动实例的属性赋值
? 终止所有过程实例
数据处理功能（Data Handling Functions）
? 恢复/返回工作流相关或应用程序数据
应用程序调用（Application Invocation）
? 上边对功能的概括，为支持任务表处理器对应用程序调用提供了基础。应用程序调用功能的一些命令是与客户端应用程序环境相关的。
? 有些产品可以只实现全部WAPI的一部分；以后会给出进一步的考虑，定义一致性级别，来满足市场中不同的产品间的，不同的协作需要。
3.4被调应用程序：
1应用程序调用（Invoked Applications）
所有的WFM产品都没有足够的逻辑单元，知道如何调用所有的应用程序，这些应用程序存在异种的产品环境中。这就需要，能够处理在所有平台下和网络环境中进行调用的逻辑，并需要能使用公共格式和编码进行应用数据或相关数据传递的方法。
然而，许多工作流系统能够使用了更多受限制的应用程序，特别是那些采用强制数据类型和直接与应用程序相连的系统。在其他情况中，应用程序对操作的调用，可能是通过标准的交换机制来实现的，例如OSI TP协议或者X.400。一些实现使用了“应用程序代理（Application Agent）”，把这些在在标准接口之后的各种方法包含在工作流执行服务器中。也有可能开发“Workflow enabled”应用工具，这种工具使用标准的API集来与工作流执行服务器进行通信，来接收应用程序数据、信号和响应活动事件等。这些API可以被应用工具直接调用；也可以被应用程序代理过过程调用，作为与其他应用程序（不包含任何工作流技术的程序）交互的前端。应用程序调用接口（接口 3）
下边是接口3的结构，“工作流”类型的应用程序或应用程序代理，可以直接使用这个结构。
在简单的情况中，工作流机在本地处理应用程序调用，使用过程定义中的信息来确定，活动的性质、将要调用的应用程序的类型和所需的数据。被调用的应用程序可能存储在工作流机中，或者与工作流机一同存储在相同的平台下，或者存放在一个独立的网络访问的平台中；过程定义中有足够的应用程序类型和寻址信息（工作流机的特殊需求），来实现应用程序调用。在这种情况下，应用程序命名与寻址的协定是处于工作流机与过程定义之间的。
应用程序调用API的详细语法、语义作为WFMC规范的一部分给出。操作覆盖了一些不同的基本接口，包括上表中的一部分，其中一些操作是同步的，一些是异步的。API的操作可以是单线程的，也可以是多线程的，后者使用活动ID来区分线程。下边是应用程序调用可以使用的一些命令概括：
创建会话（Session Establishment）
? 连接/断开应用程序会话
活动管理功能（Activity Management Functions）
? 开始活动
? 挂起/恢复/放弃活动
? 活动完成通知
? 信号事件
? 查询活动属性
数据处理功能（Data Handling Functions）
? 提供工作流相关数据
? 提供应用程序数据或数据地址
更复杂的情况，异种工作流机间的协同工作，可能需要在工作流机间传递应用程序调用信息，或者作为运行时期数据交换的一部分，或者通过在过程定义阶段后导
入过程定义来实现。
3.5其他工作流执行服务：
WFMC的一个主要目标是，为不同开发商的工作流系统产品，相互间能够进行无逢传递任务项，定义标准。
工作流产品的特性变化多样。在WFMC的协同工作标准中，没有强迫开发商必须提供一个只面向用户需求的产品或者只考虑协同工作。
WFMC把焦点聚集到，开发多种不同的协同工作框架，这些框架可以操作一系列标准的协调工作，从简单的任务传递到整个工作流系统的协同工作（包括过程定义转换、工作流相关数据交换、通用的界面等）。简单的协同工作，WFMC的协同工作定义将在最初就能支持；而复杂的协同工作，还需要进一步的研究。
尽管可以开发一个非常复杂的协同工作框架，由许多个工作流机构成个执行服务器，但是这种框架不会在近期实现，因为这需要所有的工作流机都可以解释一个公共的过程定义和共享公共的工作流控制数据集，事实上是维护异种工作流机间的一个共享过程视图。现阶段更现实的目标是，能够在运行时期传递过程的某些部分，来支持不
同的执行服务器运行。
WFMC定义了4个协同工作模型：链锁式，子过程嵌套，P2P（Peer-to-Peer），相似同步，包含多种协同工作能力级别
3.6管理和监视工具：
WFMC规范的最后关注的是为管理和监视功能开发公共的接口标准，这样一个开发商的产品就可以用来管理其他工作流机的运行。通过公共的接口，几个不同的工
作流执行服务器可以共享，管理和监视功能。
尽管，过程状态命令在接口定义中已经描述了，但一致认为，在某些行业中需要，进行全部状态监视和提取信息的功能。WFMC提出的接口，是要让用户能够得到工作流运行状态的完整视图，无论是什么样的工作流系统；同时，也希望能提供一套全面的功能集，进行系统管理，包括安全性、控制和权限。
接口中包含WAPI集中的一些具体命令，来操作管理和监视功能。另外，进一步的讨论，期望能够确定在什么范围内，这个接口可以使用现有的协议（如CMIP、SNMP），来设置、恢复管理状态和统计信息（定义在开放MIB中——Management Information Base）
“工作流” 已经成为了一个事实存在的概念和名词，可是到了2007年依然找不到没有能够明确的定义,在互连网上，我们随便在GOOGLE或百度上搜索，找到关于工作流的内容及定义可以说是百家争鸣，是标准、是引擎、是技术、解决方案、是思想、是架构。。到底是什么？
工作流到底是什么呢，对于从事做计算机软件设计的人而言，它是一项技术、是我们为我们的客户提供解决方案框架的一部分；对于从事企业信息化管理的人而言，它是一种思想，是我们降低用户的IT运维成本的一种方法；对于从事软件开发的人而言，它是一个架构，是我们如何利用成熟稳定的接口和组件低成本的开发出适应用户流程变化的应用程序。总而言之，工作流通过技术的手段，融入管理思想、为管理提供“人、事、物、流程、时间、条件”等多维管理能力，帮助用户实现管理目标。
既然今天谈的是“工作流”技术，那文章的重点就是占在技术的角度来讨论工作流，我们可以从以下几个方面来探讨工作流。
1、为什么要使用工作流技术
对于这个问题我们可以从软件企业的解决方案策略、用户运维的成本上及企业信息化规划等几个角度来考虑这个问题。
首先从解决方案提供者的角度来说，我们的CIO/CTO面临的一个很大的压力是在于我们为用户提供的解决方案滞后于我们的用户的商业策略，我们用户总是在变化中发展，商业策略面临着市场、竞争对手的压力而改变，而我们提供的解决方案却不能够快速适应这样的变化。工作流技术使这样的一种解决方案成为可能，同时工作流技术也为用户企业实现企业战略执行提供了实现的平台。
从IT运维的角度来说，目前很多IT公司面临了一种CTO（总体拥有成本）成本比例的变化趋势。因为大部分IT企业或IT部门的IT基础架构的现状，使我们用户运行维护的成本在逐步的升高，研发新能力的成本在逐步压缩，但我们的IT投资始终会变缓，特别是IT运行维护的成本在总体拥有成本中的比例。意味着IT企业和IT部门利益的空间将越来越小，其实我们身边的很多案例里就有很多IT企业被某些项目拖累致倒闭的现象。工作流技术可以脱离开发环境而设计业务流程的特性让企业IT运行维护成本大大的降低，从而提高了IT企业和IT部门的利益空间。
从企业信息规划的角度来说，可以回顾前些年的ERP、进销存、CRM等系统，大部分是管事的，系统主要是记录数据及其关联关系等，是静态为主的，但随着社会的发展与竞争格局的变化，企业的策略越来越需要能随需而动，生产管理活动也始终是“人”参与的活动，很多时候人需要激励、参与、满足、约束、被管理等等才能很好达到管理目标。因此新一代管理系统中协同性、灵活性、扩展性需求相当重要，工作流是提供协同性、灵活性、扩展性的最佳工具。
2、工作流用在哪里
毫五疑问，工作流技术是软件技术，用在软件设计领域，工作流分为业务型工作流和状态型工作流，业务型工作流大部分是要用在管理软件设计领域，为管理软件提供灵活性、扩展性、协同性等特质。帮助企业实现战略管理目标。
常用的工作流应用场景：
企业办公自动化系统
IT服务管理系统
客户服务管理系统
物流揽收调度系统
设备运维管理系统
质量考核监督系统
采购系统。。
3、如何使用工作流及哪些人使用
很多时候工作流是一个看不见摸不着的东西，存在于我们的业务管理系统软件中，至于如何使用、哪些人使用可以从几个方面说明。
工作流引擎是系统功能，是软件本身去使用的，工作流架构是包含工作流引擎使用、接口调用、业务系统应用框架的，是开发人员使用的，开发人员在工作流架构上设计开发包含工作流技术的不同业务领域的软件系统。
工作流平台一般是包含流程设计工具的，由企业流程管理用户去使用，通过工作流平台提供的流程管理工具将企业的战略和制度转化为执行语言。
软件系统普通用户使用的则仅仅是包含企业战略执行语言的业务管理系统。
4、工作流技术的选型
关于工作流技术的选型，对于从事IT工作的人员来说是一个需要非常慎重选择，在这里做些简单的阐述，工作流技术分为两种。一种是业务流程型的，比如我们的一些事件处理、服务流程、物流揽收调度、合同审批、设计审核等，需要工作流引擎根据各种表单的内容来人机交互来自动管理这个过程；另一种是状态机型的，根据一件事情的状态变化而自动进行处理，如工业控制，电路控制管理等。常用于一些工业自动化控制系统等。
我们经常听到有人说工作流引擎可以很快的就配置出一个业务系统出来，自定义表单，自定义流程，自定义报表等等，很快就给用户提供一个完整的业务系统，其实这样的想法是非常理想的，我们在开发我们的业务系统的时候我们会发现我们的业务系统不仅仅是功能的实现，它将面临着各个方面的需求，包括性能，并发处理能力、易用性、一致性及个性化等等，当工作流引擎只能满足60%的需求时，我们的团队将为另外的40%需求付出多少成本。因此在工作流的选型上很重要的一点就是它对于二次开发的支持，及接口的友好特性，同时它能支持我们在工作流基础上设计思路上的延续性。
因此工作流技术的选型不但要考虑工作流引擎本身功能的完整性和稳定性，工作流架构的扩展性、易用性及适应能力，还需要考虑工作流涉及开发人员、企业管理实施人员、企业用户的习惯和易用性等。纯粹的工作流的产品意义并不大，关键是否能很好的帮助企业实现管理目标。
5、工作流技术的应用
E8.Net工作流平台融入了新一代管理软件关注的重点思想，所有功能模块应用将权限体系、工作流引擎体系、表示逻辑体系、管理控制逻辑体系、扩展及个性化接口体系充分结合，从架构的设计上优化企业个性化业务系统实施成本，并通过流程管理工具，为企业实施个性化的企业流程，通过记录、监督、跟踪、回访、分析企业日常事务，持续改善企业管理流程，E8.Net工作流平台开源的开发架构设计过程中充分分析了管理行为中人的特性，基于E8开发的企业流程应用系统提供了事中监督、事后回访、全程跟踪的体系架构，E8工作流引擎功能设计中也充分考虑了流程和环节模型特性、环节行为人群体特性和中国特色，流转过程中基于权限体系提供了人为因素中“主动/被动”异常的解决思路，解决快速实施企业业务流程需求的同时，又提供了人性“非理想”状态下的异常解决方案和防范控制解决方案。
工作流技术在协同办公中的实现
http://www.xiexiebang.com 2008年10月28日 17:04 比特网ChinaByte
一、协同办公(OA)系统简介
协同办公(OA)系统是一套兼具企业信息门户、知识管理、工作流管理、人力资源管理、客户与合作伙伴管理、项目管理、财务管理、资产管理功能的协同商务平台，协同办公(OA)系统是一个数字化的企业应用环境，真正让公司所有的信息都在一个平台上管理，解决信息孤岛问题。协同办公系统本身具有的网状结构，为企业打通所有的信息节点，让企业管理者轻松穿梭在客户、员工、文档等所有的信息节点上，因为协同办公系统为您提供了一张信息网，只要您找到这张信息网中的某个节点，您就可以轻松的以这个节点为中心把企业的整个信息网都提取出来。
同时，协同办公(OA)系统可以与后台的ERP软件集成在一起，将所有利益相关者、企业部门、不同应用系统的信息整合到统一的渠道，并提供统一的界面给用户操作和提取信息，从而实现业务处理和信息获取与共享的一体化，达到内部协同和外部协同，为每一个用户提供一个完全的个性化门户，用户在这个个性化的门户中管理日常的所有事务。
二、工作流管理简介
由于工作流预先定义的特性，已设定的请求可以很容易的遵守相应的规则和实际操作情况。企业可以确信所有的请求都是根据规则和手续来输入和批准的，从而保证企业运作的规范化和透明化。上海泛微软件公司的协同办公(OA)系统中实现的工作流e-Workflow管理可以对内部以及外部业务处理采取电子化管理方式管理，工作流管理是提高组织效率的有效工具。
e-Workflow提供强大的自定义功能，支持企业复杂的工作流设置。企业可对工作流的组成因素包括流程完成需要的阶段、每个阶段的负责人、流转条件，直至相对底层的表单和字段进行自定义，使得工作流的定义完全与企业的政策和实际运营相符合，而不必进行复杂的二次开发。
e-Workflow同时也提供了可定制的浏览和报告的功能，用户可以对工作流的关键信息进行任意的定义以获得特定的报表。e-Workflow的特性可以使用户获得非常灵活和丰富的统计报告以对相关的决策作出支持。
三、工作流管理实现基本功能
1定义任意形式的工作流程
e-Workflow强大的自定义功能可以满足企业对复杂工作流程的定义，包括文档流程和表单流程e-Workflow 与 e-HRM结合对于人员在组织结构中的地位和角色将是工作流设计的基础。
2工作流执行
可设定的对工作流的执行包括提交、批准、退回、拒绝、代理、重新打开、归档等，e-Workflow会根据路由的判定条件和当前节点的执行操作设置工作流的下一目标节点。
固定流程和自由流程的结合
原则上是固定流程，应该一步步走下去，但是在某个节点，加入一个自由流程审批人可以选定下一步的审批人，然后再按照预定的流程走下去。
如：申请者-部门经理-出纳-财务经理，对于大一点的公司，有多个出纳，哪个出纳在岗，就让哪个出纳审，那么就可以把出纳那步设成自由流程，当部门经理审批完后，会自动列出所有的出纳，部门经理选择其中的一个出纳然后提交。
4表单数据自动生成
表单的有些数据，不希望由人工输入获得，e-Workflow可以根据被计算字段、原始数据和计算方法自动得出目标字段数据，并可以此作为下一路由选择的判断条件。
5跟踪和回溯
e-Workflow保留工作流流转过程中的所有信息以供查询。对于文档型的审批，可以保持痕迹。这样审批人能够一目了然知道原稿和审批稿的区别。监控和管理
对于某个模板产生的单据，可以设定监督人和管理人，这样既使他没有审批权，也可以看到该单据，同时发送催办信息。当某个单据因为某种原因需要临时更改流程时，监督和管理人可以修改流程，以避免单据的积压提高工作效率
7自动提醒
对于请求的不同状况，例如新的请求到达、待处理请求、超时未处理请求、客户联系计划、请求递交被处理状况等，系统都设定了多种提醒功能以确保请求的处理不致延误。
8流程自动激活
e-Workflow的一个强大之处就是在于它可以让系统在运作的过程中自动触发请求，并且还可以根据前一个请求的实际状况对下一个触发的请求进行智能选择。
9自动更新数据库
e-Workflow在信息流转的过程中，会自动更新系统原有的相关数据库，这是 e-Workflow 另一个重要的特性体现，通过数据自动更新，避免了二次手工录入带来的工作效率低下和失误的情况，真正实现企业管理和运营的电子化。
10分支选择流
根据上一步的选择，选择不同的分支进行流程执行。如：如果上一步是总经理审批的，会选择一个分支进行流转。如上一步是副总审批的选择另外一个分支进行流转。
11条件流转
以请款单为例：金额小于3000元，审批流程是：普通员工-部门经理。如果金额大于3000元的审批流程是：普通员工-部门经理-总经理，那么在流程定义的时候，需要根据单据的填写值进行判断，系统自动选择流程。
12传阅、归档等的并发流
如有一个流程：申请者-副总经理的一张单子，申请者需要提交副总审批的一张单子，不需要部门经理审批，但是需要让部门经理知晓，称为传阅的并发流。同理有归档或者其它的并发流。这种并发流的特点是一个流程的执行过程中，会产生另外的的流程，互不影响。
13流程门户定义
通过与企业信息门户的结合，e-Workflow实现流程定义的门户化，根据不同的信息门户设定不同的流程。
四、小结
工作流技术的出现和迅速发展为企业先进制造战略的实施提供了重要的技术支持。本文提出了分布式工作流建模工具的设计框架，以 SOA设计模式，通过三层结构的方式很好的实现了工作流建模工具、逻辑、数据、视图的分离，使得系统在可扩展性、可靠性与实用性方面都大大提高。以此为原型开发的泛微e-Workflow工作流管理系统很好的配合了工作流引擎的设计。在实际中的初步应用表明该系统通过分析企业不同类的经营过程，采用有向图的方法对现实的企业活动进行形式化描述，并严格定义组成有向图的各类元素的行为特征，从而明确建立企业经营过程到工作流模型的映射机制.使其与企业现有应用结合形成一个完整的过程体系。责任编辑：胡艳丽 工作流管理技术介绍
2009-11-25 作者：葛志春 来源：希赛网
摘 要：本文主要对工作流技术的起源，工作流的概念，研究的技术的内容及工作流管理系统作了深入的介绍；并对工作流技术在国内外的应用现状及不足作了深入的分析。
关键词：工作流、表单
1、工作流技术应用背景
传统的计算机管理信息系统的主要功能有三个：即信息处理、事务处理与决策支持。信息传递和信息处理构成了企业和行政管理部门的业务工作内容之一，也是计算机信息系统的主要功能之一，它是企业和行政管理部门进行事务处理和决策支持的基础。
当PC机没有作为信息处理工具而出现的时候，纸张是进行日常业务活动不可取代的载体。这种传统的纸张为载体的信息传递与处理方式的效率很低，需要花费相当的人力、物力来完成信息的处理、组织、存储以及查询检索，同时这种方式降低了对客户需求的响应速度，给企业和行政管理部门的生产经营都带来了及不利的影响。在计算机得到了广泛普及、计算机应用水平日益提高的情况下，企业与行政管理单位的工作人员希望能够以一种无纸化的、计算机使能的工作环境来开展日常业务工作。一些企业和行政管理部门因此建立了相应的文件、表单传递系统（Forms-routing applications）用来实现日常表单处理的电子化与自动化。这种简单的文件、电子表单系统可以看作是工作流应用的雏形。
企业的经营过程是由一系列相关的任务组成的；这些任务按照企业的管理规章与业务流程串行或并行的执行，最终完成企业的经营目标。自从进入工业化时代以来，有关过程的组织管理与流程的优化工作就一直在进行，它是企业管理的主要研究内容之一。只不过在没有引入计算机信息系统的支持以前，这些工作是由人工来完成的。随着市场经济的发展，市场竞争的日益激烈，企业要求其业务过程能够进行快速重组；业务过程的不断变化也相应要求信息系统能够快速重组。这样，单靠人工对企业过程进行重组和传统的面向功能的信息化计算机系统已经不能适应现代企业的发展。因此，企业希望有一种能够实现企业快速业务流程重组和业务过程自动化的软件系统。在计算机网络技术和分布式数据库技术迅速发展、多机协同工作技术日臻成熟的基础上于20世纪80年代中期开始提出了工作流的概念。工作流技术的提出与发展为企业更好的实现这些经营目标提供了先进的手段。
随着经营业务的展开企业的物理位置逐渐分散、部门间的协作日益频繁；决策过程的分散性也日益明显，对日常业务活动详细信息的需求也日益提高。因此，企业又要求信息系统必须具有分布性、异构性、自治性。在这种大规模的分布式应用环境下高效地运转相关的任务，并且对执行的任务进行密切监控已成为一种发展趋势。在这种技术背景下，工作流管理系统也有最初的创建无纸化办公环境，转而成为同化企业复杂信息环境、实现业务流程自动化的必要工具。这样的一个转变，把工作流技术带入了一个崭新的发展阶段，使得人们从更深的层次、更广的领域上对工作流展开了研究。
1993年工作流技术的标准化组织工作流管理联盟（Workflow Manangement Coalition 简称：WfMC）.的成立标志着工作流技术在计算机应用领域之中被明确的划分出了自己的一席之地，相应的概念与术语也得到了人们的承认。在全球范围内，对工作流的技术研究以及相关的产品开发了进入了更为繁荣的阶段。
2、工作流定义
工作流是从英文单词Workflow翻译而来的。Work表示工作或任务；Flow则表示流动、流程或者流量。Flow反映了一种变化及变化的过程，本身意义比较抽象，但是当它与某一个具体过程相联系时就有了具体的含义，如电流、水流、气流。在经营管理与生产组织中Flow也有重要的意义，如表示物料传输过程的物料流、表示资金流动的资金流、反映信息处理和传递过程的信息流，同样还有价值流、决策流、控制流等概念。依此，用活动及活动之间变化的过程表示的业务流程就是工作流。
十几年来，不同的研究者和产品供应商从不同的角度给出了工作流的定义，但到目前为止，对于工作流仍没有统一的定义。下面列举了一些有代表性的定义，可以使我们对工作流的一些基本特征有一定的理解。
WfMC的定义：工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则，文档、信息或任务能够在不同的执行者之间传递、执行。
Forrester Report的定义：日常的业务处理或协同工作能按预先定义好的规则和过程进行流动，并且这一流动过程能被跟踪和监控。
Giga Group的定义：工作流是经营过程中可运转的部分，包括任务的顺序以及由谁来执行它，支持任务的信息流、评价与控制任务的跟踪、报告机制。
IBM Almaden Research Center的定义：工作流是经营过程中的一种计算机化的表示模型，定义了完成整个过程所需用的各种参数。这些参数包括对过程中每一个单独步骤的定义、步骤间的执行顺序、条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。
Amit Sheth 的定义：工作流是涉及到多任务协调执行的活动，这些任务分别由不同的处理实体完成。一项任务定义了需要做的某些工作，它可以以各种形式来进行定义，包括在文件或电子邮件中的文本描述、一张表格、一条信息以及一个计算机程序。用来执行任务的处理实体可以是人，也可以是计算机系统（如：邮递员、一个应用程序、一个数据库管理系统）。
以上这些定义，虽然表述方式略有不同，但是基本上都说明了这样一个问题，即工作流是业务过程的一个计算机实现，而工作流管理系统则是这一实现的软件环境。使用工作流作为业务过程的实现技术首先要求工作流系统能够反映业务过程的如下几个问题：即业务过程是什么（有哪些活动、任务组成，也就是结构上的定义）、怎么做（活动间的执行条件、规则以及所交互的信息，也就是控制流与信息流的定义）、有谁来做（人或计算机程序，也就是组织角色的定义）、做的怎样（通过工作流管理系统对执行过程进行监控）。因此，可以说工作流是一种反映业务流程的计算机化的模型，它是为了在先进计算机环境支持下实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务系统。
3、工作流技术研究的主要内容
工作流技术，在初期主要由工作流产品供应商推动其发展。随着工作流产品在实际应用中不断取得良好的效果而得到了人们日益的重视，并且到了迅速发展。相对于工作流产品的繁荣，工作流相关理论研究则显得滞后。在过去很长一段时间里，有关工作流技术方面的研究主要有商品化的工作流产品供应商所领导。本着把工作流产品推向市场的目的，这些供应商大多把研究的注意力放在工作流管理产品的开发实施方面。目前在工作流设计方法学，工作流概念模型等方面还没有形成一套比较成熟的理论和方法。在工作流理论与实施技术方面，研究的主要内容包括：
工作流管理系统体系结构；
工作流模型与工作流定义语言；
工作流的事务特性；
研究如何实现高级事务处理技术与工作流管理技术的结合，用定义良好的模型语义与恢复机制来提高工作流系统的正确性与可靠性，从而能够更好的支持复杂的业务过程；
工作流实现技术：包括面向对象技术、异构分布式计算技术、图形化用户界面、消息通信、数据库、WEB等在内的与工作流系统的设计实现有关的各项技术及方法；
工作流的仿真与分析方法；
基于工作流的应用集成与互操作技术；
研究异构应用系统的集成以及不同工作流系统之间的互操作问题；
工作流与经营过程的重组：研究如何通过工作流系统的实施支持快速的实现经营过程重组；
工作流技术的其他应用：研究如何将工作流技术在不同的领域进行运用，包括在CIMS中的应用。
上述主要研究课题可以归纳为三个方面（如图1）：第一方面是工作流的理论基础，包括工作流管理系统的体系、模型与定义语言（工作流的建模方法、工作流模型的形式化表示、工作流定义语言）等的研究。这一部分是工作目前相对来说比较薄弱，还有许多问题需要进一步研究。第二方面是工作流的实现技术，包括工作流的事务特性、各种先进软件技术的应用、工作流仿真。这方面研究工作的目标是提高工作流管理系统的性能，尤其是提高工作流管理系统可靠性及其在处理大规模复杂的且具有并行业务的流程方面的能力。第三方面是工作流技术的应用，包括工作流实施技术在不同应用领域的应用（如在企业经营过程重组、并行过程、敏捷制造）方法、应用软件集成等。这几方面研究的目标是发挥工作流管理系统的优势，为解决具体应用领域内的问题提供有向实现手段。
图1：工作流技术研究内容
4、研究工作流的意义
工作流技术的应用将给组织单位带来巨大的效益。首先，采用工作流管理将使组织单位改变传统的按照功能来配置人员的组织结构，变成按照要实现的主要业务流程来配置组织结构，这样可以大大缩短主要业务过程的处理时间，提高对市场的响应能力。其次，组织结构的改变将大大减少在组织内部不必要的的物料、信息的传递时间。当然，整个组织结构的调整首先需要调整传统的以部门为单位的做法，变成以项目来组织生产和人员的工作方法，如：一个人可能同时从属于多个项目。应用工作流管理系统主要可以取得如下好处：
1）提高管理的规范化程度；
2）更好地与上下游单位形成快速响应市场的供应链网络；
3）降低业务过程的整个处理时间，如在办公自动化环境中，通过更好的规划工作流程，并行执行相互独立的活动，减少文档的传递时间；
4）降低管理成本，如避免不必要的重复的工作，提高工作人员的工作效率；
5）改进工作质量，如自动完成某个任务所需要的相关信息。在客户服务中，能够快速方便的访问所有相关数据和工作流程，从而大大提高客户服务质量；
6）在工作人员之间更好的均衡负荷，如在工作人员缺勤的情况下，自动柔性分配替代人员；
7）通过在工作流模型中加入可预计的故障的处理策略来提高系统的柔性；
8）通过对已经完成的工作流实例的分析，找出存在的不足，进而不断改进工作流程；
9）使工作内容更加丰富，并且提高工作人员的业务能力，减少工作人员进行单调乏味并且十分耗时的文档查找工作。
采用工作流管理系统可以在最大程度上集成组织的现有信息资源，实现资源的充分利用。由于工作流管理系统具有较好的柔性和开发性，因此，可以保证信息系统能够顺利的扩展以满足不断变化的市场环境。另外，工作流管理系统在工作流模型的基础上进行业务过程进行，这就意味着信息系统已经从过去没有一个具体的可量化指标的管理信息系统，发展到了一个建立在工作流模型上（并且是可以利用BPR或者其他仿真工具进行优化后的模型），按照预先定义好的规则进行执行，并且对于执行的结果随时进行监控和评价的规范化阶段。这种由过程建模—〉模型分析—〉过程优化—〉执行结果—〉统计分析—〉改进业务过程—〉优化运作的实施方法为成功地实施信息系统奠定了坚实的基础。
5、工作流管理系统
工作流技术是当今一项飞速发展的技术，它最基本的特性就是它能够结合人工和机器的行为，特别是能够与应用程序和工具进行交互，从而完成业务过程的自动化处理。
工作流是业务的自动化处理过程，在这个过程中，根据预定义的规则将文档、信息在过程参与者中传递，最终完成业务的处理。工作流管理系统（WFMS）是通过管理一序列工作行为以及与活动步骤、相关人员、资源设备来提供业务处理程序上的自动控制，它是通过计算机软件来定义、管理和执行工作流，计算机的执行顺序是由工作流逻辑的计算机描述来驱动的。
工作流管理系统主要具备以下三个功能特征，如图2：
工作流定义功能，主要是对业务处理过程的计算机定义，提供了一种或多种分析、建模、系统定义技术，将一个现实世界的业务处理过程转换成计算机可处理的定义；最终的定义叫作过程模型、过程模版或过程定义，可以表现为文本、图形或自然语言符号。
运行控制功能，对过程的定义进行解释，创建并控制过程的运行实例，调度过程的各种行为步骤，调用适当的人工和IT应用程序资源；工作流管理系统的核心部件就是工作流管理控制软件（工作流引擎）。
运行交互接口，提供与人员或IT应用程序工具进行交互接口来处理各种活动步骤，交互接口对于活动间的控制传递是必须的，如确定过程的状态，调用应用程序工具，传递应用程序数据等。
图2WFMS的三个特征
6、工作流管理系统的分类
根据所实现的业务过程，工作流管理系统可分为四类：
1)管理型工作流（administrative workflow）：在这类工作流中活动可以预定义并且有一套简单的任务协调规则，例如，大学里的课程选修，完成论文后的学位申请等。
2)设定型工作流（ad hoc workflow）：与管理型工作流相似，但一般用来处理异常或发生机会比较小的情况，有时甚至是只出现一次的情况，这与参与的用户有关。
3)协作型工作流（collaborative workflow）：参与者和协作的次数较多。在一个步骤上可能反复发生几次直到得到某种结果，甚至可能返回到前一阶段。
4)生产型工作流（production workflow）：实现重要的业务过程的工作流，特别是与业务组织的功能直接相关的工作流。与管理型工作流相比，生产型工作流一般应用在大规模、复杂的和异构的环境下，整个过程会涉及许多人员和不同的组织。
根据底层实现技术，可将工作流产品分为三类：
1）以通讯为中心：以电子邮件为底层的通讯机制。这种类型的工作流管理系统适合于协作型工作流和不确定型工作流，而不适于生产型工作流。
2）以文档为中心：基于文档路由，它同外界应用的交互能力有限。许多基于表的管理型工作流可以用以文档为中心的工作流实现。
3）以过程为中心：这种工作流系统对应生产型工作流。它们一般建立在数据库之上，有自己专用的通信机制并且提供了同外部进行交互的接口。
根据不同工作流系统所采用的任务项传递机制的不同，市场上的工作流产品又可以划分为四类：
1）基于文件的工作流系统：以共享文件的方式来完成任务项传递。这种类型产品开发得最早、发展最成熟、其产品品种较多。代表产品有FileNet的Visual WorkFlo、IBM的FlowMark、InConcert的InConcert。
2）基于消息的工作流系统：通过用户的电子邮件系统来传递文档信息。这种类型的产品一般都提供与一种或多种电子邮件系统的集成接口。代表产品有Novell与FileNet合作开发的Ensemble、JetForm公司的InTempo、Keyfile公司的Keyflow。
3）基于Web的工作流系统：通过WWW来实现任务的协作。这一类产品起步较晚（在95年以后），但是发展迅速，其市场前景十分看好。许多供应商纷纷改进原有产品或开发新产品以增加对Web的支持。代表产品有Action Technologies公司的ActionWorks Metro、Ultimus公司的Ultimus。
4）群件与套件系统：虽然这一类产品与上面介绍的三种产品在任务传递方式上有很大程度的重叠，但是在这里却有必要把它们单独划分成一类，因为这一类产品都需要依赖于自己系统的应用基础结构，包括消息传递、目录服务、安全管理、数据库与文档管理服务等，它们本身就构成了一个完整的应用开发环境。代表产品有IBM/Lotus公司的Lotus Notes、Microsoft公司的Office与Exchange、Novell公司的GroupWise。
7、工作流管理系统的实施
工作流管理系统不同于ERP和普通的企业管理信息系统，ERP与普通的企业管理信息系统是事务处理系统，其主要目的是满足企业业务操作功能，提高企业事务处理的效率和水平。从企业整体的业务流程和企业经营目标上看，事务处理系统一般局限于解决某个或者某些领域的问题；事务处理系统的另外一个局限性是它一般局限于解决组织内部的具体操作问题，面向组织内部功能，而不是面向市场和面向客户的系统。工作流管理系统的着眼点是面向市场、面向客户，其目标是在整个企业的业务层提高企业的业务处理水平、强化企业的市场意识、提高对市场的应变能力。
由于工作流管理系统与普通事务处理系统存在显著的差别，工作流管理系统在实施方法上也不同于普通的事务处理系统。要实施工作流管理系统首先要在战略层次上对经营目标进行分析，确定战略目标和组织要求。工作流管理系统实施的层次结构，如图3。
图3 WFMS实施的层次结构
在完成了战略目标分析和工作流实施战略后，工作流管理系统才能够进入真正的实施阶段。工作流管理系统在实际系统中的应用一般分为3个阶段，如图4，即模型建立阶段、模型实例化阶段和模型行阶段。模型建立阶段通过利用工作流建模工具完成经营过程模型的建立，将实际经营过程转化为计算机可处理的工作流模型。模型的实例化阶段完成为每个过程设定运行所需的参数，并分配每个活动执行所需要的资源（包括资源、人员、应用）。模型执行阶段完成经营过程的执行，在这个过程中重要的任务是完成人机交互和应用的执行，并对过程与活动的执行情况进行监控与跟踪。
图4 WFMS 实施的三个步骤
8、国内外应用现状与不足
8.1 应用现状
目前工作流技术的研究正日益受到人们的重视，许多大学和研究机构都开展了很多研究项目，取得了重多的研究成果，对工作流技术的发展做出了贡献。
由于工作流应用环境大多是在复杂的分布异构环境中，如企业内部网或因特网，因此应用最新的分布对象处理技术和Web技术，实现工作流管理成为当前研究的重点。有影响的工作流原型系统有：
1）美国佐治亚大学研制的Meteor系统：该系统是一个支持多范型的工作流管理系统，主要用于处理医疗保健应用。多范型是指该系统能够支持分布异构环境下的企业内和企业间的各种工作流。这些工作流可以是数据库管理系统和分布式事务处理系统中的事务，也可以是EDI等特殊应用。Meteor系统可以在Web或CORBA环境下运行。
2)美国普度大学开发的CORBAflow系统：该系统提出了基于CORBA的体系结构，支持跨平台的异构分布系统集成，支持弹性ACID性质；扩展了IDL语言以定义事务性工作流中的补偿事务。
3)土耳其中东大学开发的METUFlow系统：该系统提出了一种基于CORBA环境的工作流服务，包括基于ACTA扩展事务模型的工作流模型、块结构化定义语言、工作流调度管理和并发控制机制等。
工作流的许多概念来自于办公自动化、文档管理、计算机支持协同工作(CSCW)等领域。至今约有300个称为工作流工具的商品化软件，但只有数十个是真正的WFMS软件。一些著名的WFMS产品有：
1）IBM公司的FlowMark系统［9］该系统由对象数据库管理系统ObjectStore支持。主要组件包括服务器、建立客户器、运行客户器和程序执行客户器。服务器负责与数据库交互及协调工作流执行；建立客户器提供用于设计工作流的图形接口；运行客户器提供工作表方式的用户接口；程序执行客户器提供API调用方式的应用接口。
2）Action公司的ActionWorkflow系统该系统由微软的SQL服务器或Lotus Notes支持，包含三个基本组件：①管理系统内核用于集成和管理工作流事务；②分析器提供设计工作流的专门工具；③应用建立器用于将工作流定义转化成可执行的过程。此外，还提供辅助工具，如报表器用于查询工作流的进展状态。
3）Sigma图象系统公司的OmniDesk系统它使用提供ODBC接口的数据库。其中，路径管理器用于工作流管理和负载平衡；路径建立器用于定义路径逻辑；表格建立器用于创建工作流接口。虽然OmniDesk系统主要是为图象文档管理设计的，但是也可以管理其他类型的工作流。
4）Wang公司的OPEN/workflow系统该系统建立在自含的数据库引擎之上。系统分为数据库服务、图形过程建立器、集成工具箱、报表工具。数据库服务提供基本的完整性、安全性、并发控制、恢复和管理功能；图形过程建立器用于定义过程；集成工具箱提供应用之间交互需要的API调用和通信服务；报表工具如查询建立器和报表建立器用于访问有关过程执行的信息。
8.2 工作流应用技术的不足
实际上，大多数产品的开发由于没有清楚地理解用户的需求，而不能满足用户的迫切需要。许多工作流系统主要是解决共享和协作(某些问题仍未很好解决，如异构平台环境、多媒体数据)，而像性能、可伸缩性、可靠性对于复杂应用系统来说至关重要的问题，现有工作流软件并没有考虑。主要原因是，这些系统的建立不是基于在线事务处理(OLTP)技术和数据库技术，只是使用数据库做底层存储，因而在这些领域缺乏技术成熟性和系统健壮性。
另外，由于已有的绝大多数WFMS产品和原型系统的设计是面向普通的办公室应用，因此存在以下不足：
1）工作流模型只能描述如办公自动化中电子邮件或文档等简单的工作流，而不能描述工程设计等复杂过程处理。
2）经营业务流程往往是复杂的异构环境，现有产品不能提供很好的互操作性。例如，在异构环境中，IBM的FlowMark不提供API接口以支持一个工作流的输出，作为下一个工作流的输入。
3）一个工作流可能涉及到多个单位和车间，或多个工厂和企业，例如，在虚拟制造应用中，可能包含成百上千个用户，覆盖广域网络中的数十个场地，上百台计算机系统。大多数现有工作流软件只是设计为一种协作工具，适用于小群体之间业务的工作流，在体系结构上存在缺陷，缺乏可伸缩性。
4）现代组织应用要求系统具备非常高的可用性和健壮性。现有工作流软件只适合于小团体和轻负载，缺乏有效的后备机制，不具备强的故障恢复能力。
为了进一步研究开发支持应用集成的CIMS工作流管理技术，我们认为，需要解决以下关键技术：
1）面向CIMS的工作流建模技术包括工作流模型和定义语言。如何采用弹性事务模型、分层事务模型和工程数据模型相结合的方法，设计出一种适合于CIMS工程应用的工作流模型。
2）基于CIMS信息集成平台的工作流管理系统体系结构CORBA软件总线提供了良好的平台透明性和分布透明性，以及分布对象操作能力，如何充分利用CORBA软件总线和信息集成平台，实现一个高效的工作流管理系统。 3）面向分布对象的工作流管理和执行技术CORBA软件总线系统提供了对象引用、启动和联编机制。工作流管理与执行机制需在此基础上完成作为对象任务的创建、调度、执行、提交或取消，保证工作流的正确性和可靠性。还需要考虑在CORBA软件总线上增加新的公共服务，如持久性对象仓储服务、故障恢复服务等。
4）面向CIMS目标产品的集成技术工作流管理系统是一种中间件技术，适合于任何计算机分布处理系统，在CIMS应用集成涉及的有关系统中，如PDM、MRPII等，都需要这方面的集成技术。
参考文献
[1] 林惠萍、范玉顺、吴澄，“支持企业经营过程重组的工作流仿真技术研究”，http://www.simflow.net
[2] 范玉顺，《工作流管理技术基础》，清华大学出版社，2001.4
[3] 陶冶、范玉顺、罗海滨，“分布式工作流系统的可靠性研究”，http://www.simflow.net
[4] 罗海滨、范玉顺、吴澄，“工作流技术综述”，http://www.simflow.net
[5] 范玉顺、吴澄，“基于工作流的CIMS应用集成支持系统研究”，http://www.simflow.net
[6] 刘佚名、范玉顺，“基于工作流的企业过程的建模和仿真技术研究”，http://www.simflow.net
[7] 范玉顺、吴澄，“基于协调理论的工作流建模方法”，http://www.simflow.net
[8] 陶冶、范玉顺、罗海滨，“提高分布式工作流管理系统的可扩展性”，http://www.simflow.net
[9] 鲍震宁、范玉顺，“企业组织模型结构和建模方法研究”，http://www.simflow.net
[10] 罗海滨、范玉顺、吴澄，“一种面向企业用户的工作流模型”，http://www.simflow.net
第二篇：浅谈JBPM工作流
浅谈JBPM工作流
摘要：本文介绍了工作流的定义，并着重对JBPM工作流的核心组件、体系结构、流程调度等进行了详尽的介绍，以期完成对基于JBPM工作流技术的软件系统研发工作的理论探讨。
关键词：工作流；JBPM；组件；流程调度
工作流研究起源于20世纪70年代，早期的工作流源起办公自动化。1962年，工作流开始使用Petri网来作为流程建模的描述手段，Petri被认为是所有流程定义语言之母。到80年代适，商用工作流(FileNet等)开始基于图像处理和文档管理，直到1993年，工作流管理联盟的成立标志着工作流技术比较成熟了。
JBPM于2002年发起，到现在已经有发布了5.0版本。与JBPM3相比，JBPM4引入了流程虚拟机(PVM)同时增加了业务流程管理系统(BPMS)的特性，它不只是一个工作流系统，而是开始走向BPMS。而JBPM5完全抛弃了JBPM4的代码，所有代码都来自原先的Drools Flow。因此，本文选择了纯JPBM工作流引擎JBPM3。
1.1 工作流的定义
工作流管理联盟(Workflow Management Coalition,WfMC)，给出了工作流定义为：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。除了WfMC以外，Georgakopotllo、IBM Almeden研究中心等也从不同的角度对工作流进行了定义。这些定义都是非形式化语言描述，说明工作流是使用计算机实现的经营过程，而工作流管理系统是实现这个过程的一套软件。
本文中笔者做如下定义：“工作流是一种反映业务流程的计算机化的模型，是为了实现某个经营过程利用计算机在多个参与者之间，按照预定规则自动流转的可由工作流管理系统执行的业务模型。”
1.2 JBPM简介
JBPM是一个基于Java EE的轻量级工作流管理系统，是一个灵活的、可扩展的并能实现工作流的企业级开发框架，提供了流程定义、部署、执行和管理等功能。它具只有很小的依赖性，可以作为Java库与使用任何数据库部署在任何应用服务器上。
JBPM的核心工作流和BPM功能被封装成一个Java库，其中包含了Jbpm-Server、Jbpm-Designer、Jbpm-DB、Jbpm核心组件和Jbpm-Bpel五个部分。Jbpm-Server是一个预先配置好的Jboss应用服务器，Jbpm-Designer是一个基于Eclipse的流程图形化设计插件，Jbpm-DB包括了JBPM所有兼容数据库的JDBC驱动程序和数据库初始化脚本，Jbpm核心组件是一个用来管理流程定义和支持流程实例执行的运行时环境，Jbpm-Bpel是一个独立扩展包，使JBPM可以支持BPEL(一种扩展的XML脚本语言)。
JBPM使用JPDL流程定义语言来表示业务流程，使用Jbpm-Designer图形流程设计器来设计业务流程。Jbpm-Designer使业务分析员和技术开发人员都可以对业务流程进行设计和调整，使得业务流程建模和实际业务执行转换非常容易。
JBPM的核心组件是一个Java库，负责解析流程定义文件和控制运行时流程实例的执行。除了XML解析和持久化依赖的库以外，唯一与之直接相关的库是commons logging，项目中任意Java软件都可以访问JBPM提供的API。JBPM内部使用Hibernate实现其持久化，Hibernate使JBPM能在当前所有的数据库上使用。
JBPM控制台Web应用程序作为流程实例的控制接口，负责流程执行时的任务生成，管理并监视控制台检查或操作运行的流程实例。
1.3 JBPM的体系结构
JBPM工作流实现了三个工作流管理系统的基本功能。
过程定义：JBPM使用JPDL使用户通过可视化方式定义业务流程，流程定义文件被流程解析程序解析后提供给工作流引擎使用。
运行控制：核心是JBPM工作流引擎，管理执行流程的上下文环境，包含了当前执行流程的全部信息。它解析流程定义，控制流程定义实例的创建、流转和销毁，检查流程实例的状态并提供监控程序。
人机交互：当流程需要用户或者外部工具参与时，JBPM提供相应的应用程序接口或通过继承ActionHandler的方法来实现。ActionHandler方法提供了统一的扩展接口，使得扩展更加容易。
1.3.1.1JBPM的流程定义
JBPM本身就是基于模型的组件，流程实例都是依赖流程定义而执行的。但它并不像使用JPDL的流程定义图形化工具那么简单，从上世纪七十年代开始，人们便开始探索流程的形式化描述。JBPM的流程定义采用了动态图的模型语义来描述任意一个流程定义，JPDL主要使用7种流转控制活动来实现流程的形式化描述。
流转控制活动是组成一个业务流程定义最基本的活动，利用这些活动可以构建任意的流程定义，实现各种基本流程流转控制。JPDL的流程控制活动主要包括：
1、start(开始活动)：指明流程的实例用哪里开始，它作为流程的入口。每个流程定义都有且只能有一个start活动(在group中的开始活动除外)，且start活动必须有一个流出转移。
2、state(状态活动)：业务流程需要某些特定的操作后才能继续执行，在这个操作之前流程处于等待状态。当流程运行到state活动时，自动进入等待状态，知道外来的信号触发。
3、decision(判断活动)：根据条件在多个流程转移做出决定性的判断，选择最先匹配的一个条件转移执行。
4、fork-join(分支、聚合活动)：在需要并发执行流程时，fork活动可以使流程出现并行的分支，join活动可以使并行分支聚合成一条流程。
5、end(结束活动)：当流程实例流转到end活动时，实例将被结束。但到达end活动的实例中仍然活跃的流程活动(如fork-join并发流转引起的流程分支)将会被保留继续执行。JPDL允许有多个end活动。
6、task(人工任务活动)：用来处理需要人机交互的活动。可以分配任务给指定用户、实现任务分配处理器、任务泳道、任务提醒等功能。
7、sub-process(子流程活动)：允许在流程定义中调用其他的流程定义。
流程的形式化描述就是有向图，其本质就是节点和有向弧。JBPM的节点Node就是流程控制活动，它的有向弧就是节点的转移Transition(转出或者转入)，使用节点和转移就可以绘制任意一个业务流程。
1.3.1.2JBPM流程调度
流程调度就是流程实例从一个节点运行到另一个节点所依赖的一套机制，图2-13是JBPM流程调度的思维导图。JBPM启动一个流程时候，首先创建一个流程实例，并为这个实例创建一个Root Token，此时这个Root Token在Start节点上。当Token在Start节点上时，就可以将流程下流转，通过Token的signal方法(实际执行的是node的leave操作)，将Token(实际只有ExecutionContext对象)放入要转向的Transtion对象中，再由Transtion对象将Token交给下一个节点，这样便完成了流程调度。
参考文献：
[1]高洁.深入浅出JBPM.人民邮电出版社，2009.7
[2]胡奇.jBPM4工作流应用开发指南,2010.10
[3]胡长城.开源工作流平台jBPM:过程组件模型与PVM.程序员,2008(05)
作者简介：刘永中，男，（1985-），四川省花园式人，西南交通大学信息科学与技术学院08级硕士。
注：本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文
第三篇：java 工作流
Willow 由Huihoo Power开发详细可到其中文主页查看。
更多Willow信息
OpenWFE OpenWFE是一个开放源码的Java工作流引擎。它是一个完整的业务处理管理套件：一个引擎，一个工作列表，一个Web界面和一个反应器（存放自动代理）。它可以可以跟你的程序很好的给合。
更多OpenWFE信息
jBpm jBpm是一个灵活可扩展的工作流管理系统。作为 jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。
更多jBpm信息
OpenEbXML OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
更多OpenEbXML信息
Werkflow Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
更多Werkflow信息
OSWorkflow OSWorkflow是一个灵活的工作流引擎，设计成可嵌入到企业应用程序中。它提供了许多的持久化API支持包括：EJB,Hibernate,JDBC和其它。OSWorkflow还可以与Spring集成。
更多OSWorkflow信息
wfmOpen WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility）(工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
更多wfmOpen信息
OFBiz OFBiz是一个非常著名的开源项目，提供了创建基于最新J2EE/XML规范和技术标准，构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统的框架。OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。更多OFBiz信息
ObjectWeb Bonita Bonita 是一个符合WfMC规范、灵活的协同工作流系统。对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。更多ObjectWeb Bonita信息
Bigbross Bossa 速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。更多Bigbross Bossa信息
XFlow XFlow运行于EJB和servlet容器中。
更多XFlow信息
Taverna Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
更多Taverna信息
Enhydra Shark Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS(一个开源OR映射工具)。
更多Enhydra Shark信息
PowerFolder PowerFolder是一个容易使用，容易安装基于J2EE的工作流服务器，包括开发人员使用的基于web的studio。
更多PowerFolder信息
Open Business Engine Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
更多Open Business Engine信息
OpenWFE OpenWFE是一个开放源码的Java工作流引擎。它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
更多OpenWFE信息
Freefluo Freefluo 是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
更多Freefluo信息
Twiste Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
更多Twiste信息
Con:cern con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。
更多Con:cern信息
JFlower JFlower是一个用Java开发的工作流引擎，可以通过Java插件来扩展。服务器可以
解析XML文档来执行任务，检查条件。会话数据保存在一个数据库中，所以服务器是完全可伸缩的。
更多JFlower信息
JFolder JFolder(formerly PowerFolder)是一个工作流服务器和开发环境,它可以配置在任何J2EE服务器与数据库。
更多JFolder信息
JAWE 基于Java的图形化工作流编辑器。图形化工作流编辑器。使用JAVA语言开发，开放源码。严格遵循WFMC规范。XPDL（XML Process Definition Language）WFMC的 XML 过程描述语言。工作流定义文件保存在本地的XML文件中
更多JAWE信息
Zebra Zebra是一个工作流引擎。原先的设计是为了填补商业开源工作流引擎的空白。它有一些不同于其它工作流系统的特点：
*所有工作流模型都可以在workflow patterns中描述
*一个易于使用的GUI designer
*一个持久层中间件
*OO设计
*一个基于Turbine的Web应用程序
更多Zebra信息
ActiveBPEL ActiveBPEL引擎是一个健壮的运行时环境,它能执行依据BPEL4WS或just BPEL1.1与WS-BPEL2.0规范编写的业务流程。
更多ActiveBPEL信息
YAWL YAWL(Yet Another Workflow Language)一个开源工作流语言/处理系统.它基于现有的工作流处理系统与工作流语言的一个精确分析.不像传统的系统,它提供对大部分工作流模式的直接支持.YAWL支持控制流透视图,数据透视图并且能与WSDL标准的web服务相结合.更多YAWL信息
MOBE MidOffice BPEL Editor(MOBE)是一个开源平台能够让执行,监控,调整,结束每个定义的过程和谐地结合起来.这个平台的实现使用到J2EE技术与公共的标准如:BPEL,XML与SOAP.更多MOBE信息
RUNA WFE RUNA WFE是一个基于JBOSS-JBPM引擎的开源工作流工作平台它是一个跨平台适用于商业流程处理的最终用户解决方案,很容易与所有SQL数据库管理系统相结合.更多RUNA WFE信息
micro-workflow micro-workflow框架适用于那些要在他们程序中分离控制与逻辑方面的开发者,所以这个框架可以使他们的流程相互独立。这样有利于代码重复使用与代码的完整性。更多micro-workflow信息
bexee bexee是一个BPEL执行引擎并且是BPEL标准的一个开源实现.更多bexee信息
PXE PXE-Process eXecution Engine是一个模块化的商业流程执行引擎.支持用WS-BPEL2.0或用BPEL4WS1.1规范描述的商业流程.
第四篇：JBPM工作流文档
JBPM工作流简介 工作流概念简介
“工作流”干预过程、业务程序的自动化处理，文档、信息或者任务按照定义好的规则在参与者间传递，来完成整个业务目标或者对整个业务目标的完成做贡献。同时，“工作流”可能由手工组织，实际上，多数“工作流 ”都在IT系统中进行组织的，从而对过程自动化提供计算机支持，WFMC把工作定位在这个方向上。
“工作流”定义：全部或者部分，由计算机支持或自动处理的业务过程。工作流经常与“过程重组（BPR—Business Process Re-engineering）”联系在一起。BPR 是关于企业（组织）核心业务过程的评估、分析、模拟、定义以及其后的操作实现。尽管，不是所有的BPR都是采用工作流实现的，但工作流技术是最佳的方法，主要因为，工作流技术提供了业务过程逻辑与IT操作支持的分离，从而以后可以修改过程规则来重定义业务过程。相反，工作流技术并不只在BPR中采用，例如用于现有的业务过程中。
“工作流管理系统（WFMS—Workflow Management System）”通过管理工作活动序列，调用与各种活动步骤相关的人员、IT资源，对业务过程提供自动化处理。
“工作流管理系统”定义：工作流管理系统是这样的一个系统，详细定义、管理并执行“workflows”，系统通过运行一些软件来执行workflows，这些软件的执行顺序由工作流逻辑的计算机表示形式（计算机化的业务规则——过程定义）驱动。每个业务过程都有一个生命周期，从几分钟到几天（甚至数月），由过程的复杂性与组成活动的持续时间来决定。有多种方法实现工作流管理系统，使用多种IT和通讯组件，运行环境可以从一个小的本地工作组到企业间。因此，WFMC参考模型从各种角度考虑工作流管理系统，希望提供各种不同的实现技术、运行环境。
尽管实现的方法多种多样，但所有的WFMS都表现出某种共同的特性，这为不同产品间的集成、协同工作提供了基础。参考模型描述了工作流系统的一个公共模型，并且指出参考模型如何能使其与其他各种不同的实现方法相关联。JBPM相关功能简介
JBPM是当前优秀的开源工作流引擎。本文档是关于JBPM与Spring框架集成分析文档。包括：基本概念、设计要点、常见问题解答、参考资源等。
jBPM（JBoss Business Process Management业务流程管理），它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。jPDL是构建于jBPM框架上的流程语言之一。在jPDL中提供了任务（tasks）、待处理状态（wait states）、计时器（timers）、自动处理（automated actions）„等术语，并通过图型化的流程定义，很直观地描述业务流程。
jPDL可以部署于Java语言的任何应用环境下，JavaSE Application(Swing/SWT)、JavaEE Application(Application Server)。
目前jPDL的最新版本是3.2.2，您可以在以下地址：http://labs.jboss.com/jbossjbpm/jpdl_downloads/ 获得官方下载包。下载包分为两种，一种是标准包(jbpm-jpdl-3.2.2.zip)只有20M左右；一种是套件包(jbpm-jpdl-suite-3.2.2.zip)将近80M。两者最大的区别是套装包自带一个已经配置好的jboss服务，下载解压缩后，可直接运行。
jbpm-jpdl.jar是一个典型的jar文件，它涵盖对流程定义和运行时流程实例上下文环境的操作API。在最简化的业务流程样例中，jPDL将流程定义存储与XML格式的定义文件中，在运行时载入内存，在内存里记录完整的业务实例和执行过程的环境变量，并完成全部操作。显然，在实际应用中，流程信息必须被持久化的存储于数据库中。jPDL使用了Hibernate作为其对象持久化的API。
jbpm-identity.jar是jPDL的一个轻量级扩展包，简单实现了组Group、用户User、许可权Permission等用户身份认证和鉴权机制。（实际项目中，没有什么用，不过还是加上吧）
JBPM数据库创建表语句：
jbpm.jpdl.oracle.sql
JBPM工作流程模板与实例相关表的说明：
JBPM工作流程模板与实例相关表.xls
JBPM数据库表字段说明：
JBPM数据库表字段说明.doc
2.1与SSH整合
1、创建公文流转相关的实体类，并创建数据库表
2、根据对用例的分析，初步建立公文流转相关的接口
3、实现接口 切记：要用高版本的hibernate3.jar 3.1 创建数据库表
拷贝相关的依赖包到WEB-INF/lib下面(bsh.jar、jcr-1.0.jar、jbpm-identity.jar、jbpm-jpdl.jar)修改hibernate.cfg.xml，添加JBPM的映射配置，以及缓存属性的配置
从JBPM_HOMEconfig目录下拷贝hibernate.cfg.xml文件中的相关配置，切记:加入一个JBPM缓存的东西
执行jbpm.jpdl.oracle.sql，创建JBPM的所有数据库表
3.2 与Spring集成
集成JBPM与spring，需要用到第三方的集成包：将其中的spring-modules-jbpm31.jar拷贝到WEB-INF/lib下面即可 集成JBPM与Spring的方法是：将JbpmConfiguration对象的创建交给Spring来完成
所以，需要在spring配置文件中配置JbpmConfiguration对象的创建 class=“org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean”>
3.3 如何实现业务逻辑类，请参考WorkflowManage.java 用到jbpmConfiguration对象的时候，需要注入(
)当我们使用JbpmContext对象来操纵JBPM的时候，需要将JbpmContext的HibernateSession对象设置为当前的HibernateSession对象
private JbpmContext getJbpmContext(){
} JbpmContext tJbpmContext = jbpmConfiguration.createJbpmContext();tJbpmContext.setSession(getSession());return tJbpmContext;
2.2与系统用户模型结合
在JBPM中定义了一个简单的用户模型。但是在实际项目中，我们的用户模型可能远比这个模型复杂，或者有很大的差异。
JBPM有两种分配任务的模式，推模式和拉模式。
推模式：系统主动分配任务给actorId。推模式只有一个人能参与这个任务。通过actorId指定用户。
拉模式：actorId去申请这个任务。拉模式的任务可以是多个人参与的，但是只能有其中的一个人能结束。通过PooledActors指定用户群。
当同时指定了这两个属性的时候，actorId才是真正被指定的参与者。只有这个参与者才能完成这个任务，其他的在PooledActors里面的用户，是无法得到这个任务的，所以也没有办法处理这个任务。
设置用户
推模式：Assignable.setActorID(String actorId)；
拉模式：Assignable.setPooledActors(String[] actorIds)；
得到用户任务列表
推模式：TaskMgmtSession.findTaskInstances(String actorId)拉模式：TaskMgmtSesion.findPooledTaskInstances(String actorId)或
TaskMgmtSession.findPooledTaskInstances(List actorIds)为了防止冲突，需要把执行任务的这个候选参与者升格为参与者，即把这个用户设置到actorId里面，如果需要重新把这个任务作为共享任务，只需要把actorId这个属性设置为null。
实际业务中参与者实体模式，最基础的分配模式可包括直接分配（Direct Allocation）、基于角色分配（Role-Based Allocation）、基于规则分配（Rule-Based Allocation）。
直接分配模式：在工作流设计期，直接为某个活动节点指定具体的用户为参与者；
基于角色分配模式：在工作流设计期，直接为某个活动节点指定某个角色为参与者； 基于规则的分配模式：在设计期或运行期，根据某个具体的规则来决定某个活动节点的参与者（通过JBPM中的自己来创建任务实例来实现）；
图1
图2 图1是请假流程图，图2为JBPM流程代码。用上述两图的例子来具体说明分配任务的模式。
直接分配模式采用推模式，如图3所示任务“申请人核假”的操作者直接指定为发起申请人。
图3 角色分配模式采用拉模式，如图4所示任务“主管审核”的操作者是通过具体的类进行指定的，属于即竞争分配模式。活动节点的参与者有多个人，多个人共同竞争此活动，某个人竟得此活动后，其他的参与者不能再竞争。所以系统处理时，任务角色可以查询无操作者的任务实例，如果一个用户申请处理此处务时，那么任务实例的操作者置为此用户。
图4
图5 基于规则的分配模式：设置属性create-tasks=“false”。自己通过业务规则来创建不同任务实例。
图6
图7
延期分配/动态分配（Deferred Allocation/Dynamic Allocation）、基于历史分配（History-Based Allocation）
延期/动态分配模式：在运行期动态的分配某个参与实体给某个活动节点；（通过JBPM的定时器来实现）
基于历史分配模式：当前活动节点的参与者为前续某个已经执行过的活动节点的参与者，此模式在电子政务的审批流程中经常会用到，例如某个工作项由秘书办理后发给领导，然后又从领导处返回个秘书。（采用直接分配模式，在JBPM的变量进行存储前续已经某个已经执行过活动节点的参与者）
2.3流程业务应用模式
2.3.1流程挂起
在Jbpm的processInstance与taskInstance都对外提供了挂起进程实例或工作实例的的接口，同时也提供了释放的接口。分别是：
1、processinstance.suspend();processInstance.resume();
2、taskInstance.suspend();taskInstance.resume();同时processinstance与 taskInstance还提供了一个标志位，isSuspended与isOpen分别表示是挂起还是开放状态，如果标志位isSuspended = true && isOpen = fasle，那么这个进程实例或任务实例在用户界面就不会被找出来，但在管理界面还是可以看到。如果isSuspended = false && isOpen = true，结果就是正常情况了。
2.3.2流程加签
工作流加签即在流程节点上可选择增加已流程模板订制的可增加的流程节点。节点进行加签后，回到节点时的任务分配与流程退签一致，故此点在流程退签中讨论。
1、正常加签，如图1所示，流程节点主管审核可以选择发起节点领导审批。
2、加签拆分：某一流程实例在某一节点是否允许发起多个加签，如签核者A同时发起B和C的并行加签。
图8
图9
3、层次加签：加签者可以再次发起到指定人的加签。如图10所示，使用Fork中的Script实现多路路由选择。流程节点task1用Fork产生节点task2或task4的同时也会产生task1，这样task1就又可以发起的流程加签。如果不允许同一加签流程或发起的加签流程还未结束前不允许再次发起。可以通过流程决策节点decision进行判断。如下图所示：
图10
图11
4、加签流程同步或异步：图9与图10的例子，就是多个加签后，主流程节点与加签流程节点可进行异步处理。如果需要进行流程的同步处理，需要在流程决策节点decision增加判断发起的加签流程是否完成的判断，如果没有完成，则退回到主流程节点。
2.3.3流程跳签
流程跳签：即跳过接下来的一个或连续的多个节点，直接到指定的节点执行。通过流程转换实现。但无法实现从流程分支外跳入流程分支内。如果要从流程分支内跳出到流程分支外，需要取消该任务实例对应的未完成的兄弟令牌的任务实例。
2.3.4流程退签
流程退签可以认为是流程跳签的一种特例。流程退签的任务分配采用直接分配，操作者是此流程节点已操作过的操作者。
流程退签的实现方法有两种：
1、流程转换
流程退签的任务分配，需要先查询此流程实例回退节点之前是否存在已经进行过操作的任务实例。如果有则说明是流程退签，没有则正常实例。流程退签时，如果已有的流程任务实例如果采用直接分配模板，不需要进行特殊处理；如果采用角色分配模板，则在分配类中校验流程变量中是否有当前节点的退签变量，如果有则查询流程中上次任务实例的操作者，并对任务进行直接分配。如图1所示，由主管发起加签操作，领导进行了审批后，回到主管审批节点。此时，节点任务分配就需要进行退签判断。
图12
2、修改流程实例的状态
如何开关一个任务：任务实例TaskInstance有三个重要的属性end(任务结束时间)，isOpen(任务是否开启)，isSignalling(任务是否可流转)。控制这3个属性就可以控制任务实例.如果要开启一个任务，就让end=null，isOpen=true，isSignalling=true。如果要关闭一个任务就是end=new Date()，isOpen=false，isSignalling=false。另外还有一个属性isCancelled，如果你关闭的任务作废了，不需要作为历史任务保留，就让isCancelled=true；
流程回退大致分为三种：
1、简单流程回退（无流程分支）
先做个假设有流程 a—>b—>c—>d—>e 当前流程已经跑到d，如果要回到b重新跑怎么做那.步骤是：
一、关闭任务b后创建的并且没有关闭的任务。(与任务b同在一个节点上没有完成的任务除外)
二、开启任务b。
三、将令牌指向任务b所在的节点。
图13 经过测试发现对分支的回退会出现两个问题: 1）当流程执行到分支内节点时（b，c，d），如果要退回到a任务，并把分支内的任务关闭掉，当再次进入分支节点后，流程就只能运行到join节点，不能到达e。
2）当流程执行到F时，如果要将流程回退到一个分支内的任务上（b，c，d），流程就也只能运行到join节点，不能再到达e。
当流程执行到fork时，会根据分支的个数创建几个子令牌(本例是创建2个)，子令牌会各自流转，直到到达join节点。join节点会检查子令牌是否都到达join节点，如果是就流转主令牌到点一个节点，如果不是就继续等待其他子令牌。完成这个逻辑主演是依靠Token的isAbleToReactivateParent属性来完成这个功能。isAbleToReactivateParent这个属性的含义可以理解成，当前持有这个属性的子令牌是否可以激活(恢复)其父令牌。所以这个属性只有分支的子令牌才具有。
isAbleToReactivateParent在fork创建分支令牌为true，当子令牌到达join是会被设为false。具体说一下过程(详细的可以看看join的execute方法)每一个子令牌到达join节点，都会触发join的execute方法。该方法的第一步就是检测子令牌的isAbleToReactivateParent是否为true，不是ture你这个子令牌就什么都别想干了。当为true时子令牌才有权尝试(仅仅是尝试)驱动一下父令牌。
子令牌过这第一关，isAbleToReactivateParent就会被赋值false。(每个子令牌只有一次机会去见他的父令牌)下面还要过好多关。所有的关卡都通过，来到它的父令牌面前。这时这个父令牌会找到它的全部子令牌，检查子令牌的isAbleToReactivateParent属性是否都为fasle。如果还有为true的子令牌，说明还有子令牌没有完成。父令牌会 等待。要是全为fasle。那就是全部子令牌都完成，父令牌就可以执行到下一个节点。
2、回退到流程分支中
关闭里分支内的任务，但没有让子令牌放弃见父令牌。所以当你再次由a进入分支时，又创建了两个子令牌.这个老爸现在有4个子令牌了。其中先前的两个子令牌，却永远都见不到父令牌，父令牌会在join会一直等。所以要从分支往分支外跳的时候，除了杀掉任务，也别忘了让子令牌放弃见父令牌的想法。isAbleToReactivateParent=false。
3、从流程分支中回退
从e跳到分支里。历史任务开启，任务上的子令牌不想见父令牌(此时isAbleToReactivateParent = false)。这个子令牌到了join，该方法的第一步就是检测子令牌的isAbleToReactivateParent是否为true，不是ture你这个子令牌就什么都别想干了。所以，开启分支里的任务时，不要忘记将该任务的令牌属性isAbleToReactivateParent = true。这样他才能见到父令牌让他走人。
2.5子流程
2.5.1子流程部署与删除
1、jbpm的流程deploy方法之一是: JbpmConfiguration.getInstance().createJbpmContext().deployProcessDefinition(processDefinition);如果流程中涉及子流程的话,deploy需要注意先后顺序,否则父流程会找不到子流程.发布流程遵循的顺序是先子后父。
2、流程实例结束后删除流程实例的方法之一是: JbpmConfiguration.getInstance().createJbpmContext().getGraphSession().deleteProcessInstance(processInstance.getId());如果流程涉及子流程的话,删除流程实例同样需要注意先后顺序。如果先删除子流程实例：子流程已结束，会将Token表中父令牌的SubProcessInstance字段清空，此时可以删除子流程；如果子流程未结束，Token表中父令牌的SubProcessInstance（外键关联子流程的流程ID）字段未清空，会报约束错误。如果要删除父流程实例直接删除，JBPM会按照先子后父的关系将此父流程的子孙流程全部删除。
JBPM的删除流程的方法存在一个BUG。例如图17所示：如果父流程实例中存在多个令牌，且存在子流程实例。如果子流程实例未结束时，无法删除父流程实例。因为JBPM删除父流程实例同时也会删除子流程实例。如图14所示，JBPM是用令牌来来查询发起的子流程实例会进行删除。但实际任何查询令牌都可查询到子流程。查询条件如图15所示，在首个令牌中已经将子流程删除，在后续令牌进行操作时则会报约束错误。如果发生此类情况，先判断删除的流程实例是否有父流程实例。没有则查询流程实例中的令牌，将Token表中令牌的SubProcessInstance字段清空后，再调用上述流程实例的删除方法即可。
图14
图15
图16
2.5.2发起子流程
1、子流程就是流程模板是的一个流程节点，发起子流程与发起其他流程节点一致。
2、流程节点可任意发起子流程，即将子流程可由当前流程操作者自行判断是否发起。可以通过类似于加签的方法。如图17所示：task1拥有两个流向选择，一是处理当前节点任务，二是发起子流程协助处理。task1的操作者，如果选择处理当前节点任务后流程进入task4进行；如果是选择发起子流程协助处理，流程发起子流程与task3，模板设置task3与task1的操作者一致，但只有唯一的流向即处理当前节点任务。
图17
3、子流程的同步与异步
如图17所示，子流程实例与父流程实例是同步的，父流程实例必须的子流程实例完成后才能继续流程，父流程实例与子流程实例是一个整体。
如图18所示，子流程实例与父流程实例是异步的，父流程实例只是负责发起子流程实例，子流程的完成情况对父流程实例没有影响。
图18 2.6 JBPM定时器 2.6.1定时器的配置
1、jbpm.cfg.xml中配置，关于定时器运行时间的配置如图19所示：
图19
2、jbpm.cfg.xml中配置，关于业务日历的配置如图20所示：
图20 jbpm.business.calendar.properties是关于业务日历的具体配置如图21所示：
图20 对于上面定义通俗的理解就是它归定了从星期一到星期五的9:00-12:00 & 12:30-17:00这段时间为上班时间也就是业务时间，星期六和星期日没有定义也就是放假的时间，再往下就是定义了12个节假日，最后是一些工作时长的统计如一天7.5小时，一个星期37.5小时等。
3、web.xml中配置，如图21所示
图21
4、配置时需要注意，JBPM的定时器本身有一个BUG，无法让JobExecutorServlet使用自己的jbpm.cfg.xml，因为Java类JbpmConfiguration源码(如图22所示)实现就是使用“org/jbpm/default.jbpm.cfg.xml”。在 default.jbpm.cfg.xml使用中默认hibernate配置文件如下所示：
图22 2.6.2定时器的运用
定时器timer可以被用于decision、fork、join、node、process-state、state、super-state、task-node，可以设置开始时间duedate和频率repeat，定时器动作可以是所支持的任何动作元素，如action或script。timer 还有一个很重要的属性cancel-event，这个是timer和task结合时使用的，任务定时器的cancel-event可以被定制。默认情况下，当任务被结束时（=完成）任务上的定时器将被取消，这是通过在定时器上使用cancel-event属性，流程开发者可以定制诸如task-assign或task-start。cancel-event支持多个事件，通过在属性中指定一个用逗号分割的列表，可以组合cancel-event 的类型。如图23所示：
定时器的时间分为绝对时间与业务时间。业务日历在jbpm.cfg.xml中进行配置。业务日历运用的为语法：
图23
2.7 邮件服务器 2.7.1邮件服务器的配置
在jbpm.cfg.xml中配置邮件服务器，如图24所示
图24
1、邮件模板的设置如图25所示：
图25 jbpm.mail.templates.xml的具体内容如图26所示：
图26
2、邮件地址设置，如图27所示
图27 jbpm.mail.properties的具体内容如图28所示：
图28
3、用户Email地址的查找，如图29
图29 查找类org.jbpm.identity.mail.IdentityAddressResolver可以根据业务的用户模型进行替换。
4、自定义邮件支持，如图30
图30 邮件类：com.sinosoft.ups.service.workflow.Mail
与默认邮件类：org.jbpm.mail.Mail的区别在于public static void send(Properties, String, List, List, String, String)不同，如图31所示
图31 2.7.2邮件服务器的运用
1、邮件在流程中自动提醒，如图32所示
图32
2、工作流模板中定义邮件节点与邮件作
在hibernate.cfg.xml增加如图33所示的配置文件，不然在发布带有MailNode与MailAction的工作流模板时会报hibernate错误。
图33 邮件节点订置如图34所示：
图34 邮件动作订置如图35所示：
图35 2.8结合工单（待定）
工单：一次申请的提交记录，该记录具有唯一性。工单相关的概念：
工单管理：对投诉工单、等不同类型的工单进行派发、接收处理、回复等一系列工单处理操作。
工单统计：对各种处理工单的数量，类型进行数据统计和导出、报表打印。
工单系统管理：对工单系统进行管理，设置相应的处理部门、处理人员和相应的权限，规定处理流程。
工单日志：记录工单操作日志，有效管理日志的处理状况和责任。
第五篇：办公自动化论文：办公自动化 工作流
办公自动化论文：办公自动化 工作流
【中文摘要】随着计算机和网络技术的迅猛发展,基于工作流的办公自动化技术在企业里逐渐普及。办公自动化的实现需要依靠工作流这一关键技术。本文以张家界航院办公自动化项设计和开发为背景,使用Lotus Notes/Domino群件产品作为开发平台,设计了符合学院特点的工作流,并应用到办公自动化系统中,具体工作如下；
1、针对工作流的概念、参考模型、工作流管理系统以及基于XPDL的流程建模型语言进行了综述。并最后通过工作流平台的对比,确定使用Lotus Notes/Domino群件产品进行张航工作流系统的设计与开发。
2、基于张航学院的办公自动化系统的需求,设计了体系结构、功能结构以及数据库设计。完成了工作流系统设计,并讨论了远程办公实现方案。
3、重点分析了基于XPDL的办公流程的设计与实现,并给出了具体应用实例。通过部署、测试与分析,证明了系统的有效性。
4、讨论了在张航学院办公自动化系统的安全性设计以及在张航办公自动化系统中的应用。最后,总结了全文的工作,并展望了本课题未来的研究方向,提出了需要进一步研究的问题。
【英文摘要】With the rapid development of computer and Network technology, workflow-based office automation technology becoming more common in the enterprise.Implementation of Office Automation technology rely on the key technology-Workflow.This paper has the background of design and development of OA project of Zhangjiajie Institute of
Aeronautical Engineering, which based on Lotus Domino/Notes R7 groupware.Research and design features of a consistent workflow Institute and its application to the Office Automation System, including the following special work:1.For the concept of workflow, reference model, workflow management systems and processes based on the model language XPDL reviewed.And finally after the comparison of workflow platform, determine to put Lotus Notes/Domino groupware products into the design and development of Zhang Hang workflow system.2.For the demands of office automation system of Zhang Hang Institute, the system structure, functional structure and database have been designed.The workflow system design have been completed, and the remote office implementations have been discussed.3.Emphatially analized the design and implementation of office procedure which based on XPDL process, and advanced some specific application examples.Through the deployment, testing and analysis proved the effectiveness of the system.4.Discussed the security design and the application of the office automation system in Zhang Hang Institute.Finally, the conclusion and the developing trend were put forward.【关键词】办公自动化 工作流 Notes/Domino XPDL 工作流引擎 【英文关键词】OA Workflow Notes/Domino
XPDL Workflow Engines 【目录】基于工作流的张航校园网OA系统的设计与开发3-48-9现状10ABSTRACT4
第一章 绪论8-12
摘要
1.1 引言1.2 OA的定义和发展9-101.3 国内外OA的研究
第二章
2.2 1.4 课题的提出与研究的内容10-12工作流技术综述12-31工作流参考模型14-171414-15
2.1 工作流技术概述12-142.2.1 工作流参考模型结构2.2.2 工作流参考模型中涉及到的数据2.2.3 工作流参考模型中的组件15-17
2.3.1 工作流管理系统的定义
2.3.3 2.3 工作流管理系统17-2017-182.3.2 工作流管理系统的功能和特性18工作流管理系统的分类18-2020-2621-22
2.4 基于XPDL的工作流模型
2.4.2 XPDL结构
2.4.4 过程模型2.4.1 XPDL发展20-212.4.3 包定义及重定义22-23定义中的组成元素及属性23-24实现24-26
2.4.5 过程控制模式的XPDL
2.5.1
2.5 工作流开发平台的选择26-30开发平台的对比27-28简介28-30
2.5.2 Lotus Notes/Domino群件产品
第三章 张航OA系统
2.6 本章小节30-31需求分析及设计31-5331-33描述31-33
3.1 张航OA系统需求分析
3.1.2 系统需求
3.2.1 基3.2.2 系统3.1.1 校园网网络拓扑结构
3.2 张航OA系统体系结构33-35
33-34于Lotus Notes/Domino的工作流体系结构
框架结构34-35功能模块35-36
3.3 系统功能35-383.3.1 系统整体
3.3.3 学
3.3.2 模块接口关系36-37
3.4 数据库设计院组织结构与办公人员角色37-3838-413.4.1 Domino数据库设计原则39-403.4.2 数据库设计内容40-4141
3.4.3 张航OA系统数据库组成3.5.1 模型库3.5.3 过程模型实例3.5 张航OA系统工作流设计41-50
3.5.2 流程配置44的设计41-44化与客户机接口44-5050-52
3.6 对远程办公的支持
50-51
3.6.2 基于
第四章 3.6.1 基于VPN的解决方案B/S开发的解决方案51-52张航OA系统部署与实现53-6653-54
3.7 本章小节52-53
4.1 张航OA系统部署4.1.1 Lotus Notes/Domino部署53-54
4.2 公文办理模块的实现
4.1.2 系统的安装与配置5454-624.2.1 公文办理工作流程分析54-564.2.2 公文发文工作流程XPDL定义56-58设计58-6060-61
4.2.3 公文办理模块数据库
4.2.4 过程模型的建立和过程配置4.2.5 工作流具体流程61-62
4.3 关系数据库
4.5 访问模块的实现62-64本章小节65-6666-71
4.4 系统测试与维护64-65
第五章 系统安全分析与设计
5.2 Lotus 5.1 系统安全需求描述Notes/Domino安全机制6666-68
5.3 网络安全设计
5.5 应用程序安全设5.4 系统安全设计68-70
计7071-725.6 本章小节70-716.1 全文总结71
致谢76-77
.......第六章 结论与展望6.2 研究展望71-72主要研究成果77
.......参考文献72-76【采买全文】 139938848 138113721 同时提供论文写作一对一辅导和论文发表服务.保过包发.【说明】本文仅为中国学术文献总库合作提供，无涉版权。作者如有异议请与总库或学校联系。
点击咨询 