2.2 工作流技术概述

工作流技术是当今一项飞速发展的技术,能够结合人工和机器行为,特别是能够与应用程序和工具进行交互,从而完成业务过程的自动化处理。WfMC颁布的一系列工作流产品标准,包括工作流参考模型、工作流管理系统等,奠定了工作流技术的基础。

2.2.1 工作流参考模型

工作流参考模型(workflow reference model)是1995年由WfMC提出的工作流管理系统体系结构模型,标识了工作流管理系统的基本组件和这些组件的交互接口,如图2.1所示。其中的组件包括工作流执行服务、工作流引擎、流程定义工具、工作流客户端应用、调用应用及管理和监控工具。

图2.1 工作流参考模型的组件和接口

工作流执行服务由一个或多个工作流引擎组成,用于创建、管理和执行工作流实例的软件服务。

工作流引擎是为流程实例提供运行时执行环境的软件服务。

流程定义工具用于提供工作流定义服务,可以以图形方式显示并操作复杂的流程定义,并输出可被工作流引擎识别的工作流定义。

工作流客户端应用是一种通过请求的方式与工作流执行服务交互的应用。也可以说,工作流客户端应用调用工作流执行服务。

调用应用是被工作流执行服务调用的应用,调用应用与工作流执行服务交互,协作完成一个流程实例的执行。

管理和监控工具是管理和监控工作流管理系统的工具,包括用户管理、角色管理、审计管理、资源管理、流程监控等。

此外,工作流参考模型还定义了5个接口,用于定义以上组件间的交互接口规范。

接口1:工作流定义接口。此接口的规范有WPDL、XPDL、BPEL等,用于为用户提供一种可视化的、可以对实际业务进行建模的工具,并生成可被计算机处理的业务过程形式化描述。

接口2:工作流客户应用接口。此接口的规范为WAPI(代表workflow application programming interface)。它提供了一种手段,使用户可以处理流程运行过程中需要人工干预的任务[实际上就是工作项(workitem)],工作流管理系统负责维护这个工作项列表。

接口3:工作流调用应用接口。此接口的规范为WAPI。工作流引擎调用外部业务应用的规范,如在流程执行过程中调用业务系统提供的接口处理业务数据等。

接口4:工作流引擎协作接口。此接口的规范为Wf-XML 2.0,是不同的工作流引擎之间进行协作的接口规范。

接口5:管理和监控接口。此接口的规范为CWAD(代表common workflow audit data)。该接口监控工作流管理系统中所有实例的状态,如组织机构管理、实例监控管理、统计分析管理等。

工作流参考模型目前已成为工作流软件系统设计的权威参考标准。它提供了一个规范的工作流术语表,使在一般意义上讨论工作流系统体系结构成为了可能。它还为工作流管理系统的关键组件提供了独立于特定产品或技术实现的功能与交互描述。此外,它从功能的角度定义5个关键组件的交互接口,推动信息交换标准化,使不同产品间的交互成为可能。

2.2.2 工作流管理系统

早期办公自动化系统通常采用硬编码的方式来处理业务、公文的流转。然而,随着业务和公文愈发复杂,需求的不断变更,这种方式显然已难以满足现实的需求,工作流管理系统应运而生。

工作流管理系统(Workflow Management System, WfMS)是一款用于定义和管理工作流,并按照在计算机中预先定义好的工作流逻辑推进工作流实例执行的软件系统。WfMS通过分析、抽象业务、公文流转过程,解决业务交互逻辑、业务处理逻辑及参与者的问题。

业务交互逻辑对应业务流转过程。WfMS通过工作流引擎、工作流设计、流程操作等功能解决业务交互逻辑的问题。

业务处理逻辑对应业务流转过程中表单、文档等的处理。WfMS通过表单设计工具与表单的集成等功能解决业务处理逻辑的问题。

参与者对应流转过程中各环节中的人或程序。WfMS通过与应用程序的集成解决参与者的问题。

WfMS为方便修改业务交互逻辑、业务处理逻辑及参与者提供了可视化流程设计及表单设计工具,为实现WfMS的扩展提供了一系列接口,其产品结构如图2.2所示。

完整的WfMS通常由工作流引擎、工作流设计器、流程操作、工作流客户端程序、流程监控、表单设计器、与表单的集成,以及与应用程序的集成8个部分组成。

工作流引擎作为WfMS的核心部分,主要提供对工作流定义文件的解析及流程流转的支持。工作流定义文件描述了业务的交互逻辑,由工作流引擎解析并按照业务交互逻辑进行业务的流转。工作流引擎通常通过参考某种模型进行设计,通过流程调度算法进行流程流转(如流程的启动、终止、挂起、恢复等),通过各种环节调度算法实现环节的流转(如环节的合并、分叉、选择、条件选择等)。

流程设计工具一般是可视化的,用户可以以拖放元素的方式来绘制流程,并通过环节配置实现对环节操作、环节表单、环节参与者的配置。流程设计工具的好坏决定了WfMS是否易用。

流程操作指工作流支持的针对流程环节的操作,如启动、终止、挂起、分支、合并等,工作流引擎直接支持上述操作。而在实际需求中,通常需要自由操作流程,如回退、跳转、加签、减签等,对于这些操作,工作流引擎不直接支持,用户必须单独实现。是否支持流程操作直接决定了WfMS是否实用。

工作流客户端程序是WfMS的工作界面,通常以Web方式展现,通过提供待办列表和已办列表、执行流程操作、查看流程历史信息等内容,展现WfMS的功能。

流程监控以图形化方式监控流程执行过程,包括流程运转状况、每个环节耗费的时间等,流程监控数据是流程优化的依据。

表单设计工具一般是可视化的,用户可以以拖放元素的方式绘制业务所需的表单,并绑定表单数据。表单设计工具的好坏也会决定WfMS是否易用。

图2.2 WfMS产品结构

通常业务流转需要表单来表达实际的业务,因此需要与表单进行集成来实现业务意义。与表单的集成通常包括表单数据的自动获取、存储、修改,表单域的权限控制,流程相关数据的维护,以及流程环节表单的绑定。与表单的集成程度直接决定WfMS对开发效率的提升效果。

与应用程序的集成用于完善WfMS的业务意义,主要涉及与权限系统及组织机构的集成。流程环节需要绑定相应的执行角色,而流程操作需要关联权限系统、组织机构。

2.2.3 工作流开源框架

目前市面上主流的工作流开源框架有4个,分别是jBPM、Activiti、Camunda和Flowable。其中,Activiti、Camunda和Flowable均是基于jBPM 4.0的框架,它们之间的关系如图2.3所示。

图2.3 jBPM、Activiti、Camunda、Flowable

jBPM 4.0是JBoss公司推出的一款工作流开源框架,后来由于团队内部出现分歧,部分团队核心人员离开JBoss公司加入Alfresco公司,很快Alfresco公司推出了新的基于jBPM 4.0的开源工作流框架Activiti 5.0。

Activiti 5.0以jBPM 4.0为基础,继承了jBPM 4.0强大的可扩展能力,同时增强了流程可视化与管理能力。而JBoss公司的产品jBPM 5.0则完全抛弃了jBPM 4.0的架构,以Drools Flow为基础彻底重构了工作流引擎核心架构,因此,jBPM 5.0与jBPM 4.0是两款完全不同的产品。许多jBPM的老用户都转向了Activiti 5.0框架。目前,jBPM 5.0及其以后的版本的国内市场占有远不如Activiti。

Camunda和Flowable的诞生与Acitiviti如出一辙。目前Camunda和Flowable已经推出了各自的商业版本和开源版本,而Activiti则持续开源。虽然Camunda和Flowable这两位后起之秀都足够优秀,不但修复了Activiti 5.0的很多漏洞,在产品功能上也更加的完善,但是对于一家公司来说,从Activiti向Camunda或Flowable迁移代价太大。

本书选用Activiti来讲解企业级BPM开发与应用的实现,一方面是因为它免费开源、稳定可靠、应用广泛,另一方面是因为Activti有着十分优秀的设计思想及代码风格,易于入门。