在面向服务体系架构（Service Oriented Architecture，SOA）中，流程是一个很重要的概念，其中业务流程管理包含了人工任务等，结合《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以下简称《 SOA和DW 》）以及《面向服务体系架构（SOA）和业务组件（BC）的思考》（以下简称《 SOA和BC 》）中关于共享库、业务组件的设计，本文进一步给出了关于如何搭建企业级的工作流引擎，建立工作流管理组件的设计方法和实现。

　　流程和作业

　　流程（Process）是产生某一结果的一系列作业。流程是多个人员、多个作业按照一定的规则的有序组合。它关心的是谁做了什么事，产生了什么结果，传递了什么信息给谁。流程一定是体现企业价值的，没有价值的流程是没有意义的，因此每个流程都有其特定的目标。在信息系统中，流程由若干作业（Operation）按照一定的规则组合而成，可以用业务流程图来描述，其目标通过绩效指标体现。作业是为了实现一个可定义的目标而进行的一系列活动，是业务流程的基本单元。在信息系统中，作业的前端表现为若干界面，后端由若干个服务按照一定的规则组合而成。

　　在本文中，流程是指企业运作的所有流程，即企业的所有的活动都可以看作是一个个流程，流程是由若干个作业组成的，在 IT 技术上流程称为工作流，作业称为流程节点。

　　流程规范XPDL和BPEL

　　在IT技术中，关于流程最早是以 WfMC 为代表的“业务流程开发商”， 工作流管理联盟（WfMC）于 1993 年成立，他们主要拥护以 XPDL 作为描述语言来描述业务流程；之后是以 OASIS（Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织）组织为代表的，被 IBM，MicroSoft，BEA 所拥护的 BPEL/BPEL4WS 规范；之后向来以规范著称的 OMG 组织也不甘示弱，联合 BPMI 组织，独辟蹊径以 Notation Specification 为入口，首先推出了 BPMN 规范，进而推出了 BPDM（Business Process Definition Metamodel BPDM)。

　　2003年4月BPEL规范提交给了OASIS更名为WSBPEL（Web Services Business Process Execution Language）规范。此规范描述如何处理输入的消息，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作 XML 形式的编程语言，提供将WSDL-Services组合成控制流的能力。由于BPLE对于人工活动支持不好，为此进一步扩展为BPEL4People（WS-BPEL Extension for People），从只能编排Web服务，扩展为同时支持对Web服务和基于角色的人工活动进行编排。

　　业务流程管理（BPM）和工作流管理（WFM）

　　业务流程管理 (Business Process Management BPM)，一般的定义是一套达成企业各种业务环节整合的全面管理模式。BPM涵盖了人员、设备、桌面应用系统、企业级后台应用等内容的优化组合，从而实现跨应用、跨部门、跨合作伙伴与客户的企业运作。

　　根据WfMC的定义，工作流（Work Flow）就是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。

　　工作流管理（Workflow Management, WFM）是人与电脑共同工作的自动化协调、控制和通讯，在电脑化的业务过程上，通过在网络上运行软件，使所有命令的执行都处于受控状态。在工作流管理下，工作量可以被监督，分派工作到不同的用户达成平衡。

　　在本文中业务流程管理（BPM），是指基于BPEL标准的业务流程整合，主要实现系统和系统之间的整合；工作流（WF）是指人工活动的业务流程，基于XPDL标准或者BPEL4People标准，主要实现人机交互的整合，目的是实现系统内部以及跨系统的流程审批。关于业务流程（BPM），当前有很多成熟的产品，不做过多介绍，本文以工作流管理（WFM）为主，进行设计。工作流是和绩效紧密相关，每个岗位流程节点汇总在一起，在前端展示为个性化门户，除了工作流的沟通之外还有消息平台实现人员之间的协同

　　工作流管理（WFM）组件设计

　　企业可以看作是企业实体对象，包括组织、人员、产品等在不同的环境和条件下的不断的运转的过程，实体对象和运转过程映射到信息系统中，分别对应着数据（可以用 ER 图描述）和业务流程（可以用流程图、业务逻辑和业务规则描述）。数据和业务流程能够全面反映实体对象及其运动的状态。在现实社会中，实体对象的运动体现为一系列活动，在信息系统中，活动表现为一个流程节点，实体对象通过一系列的业务活动直至最终完成任务，在信息系统中体现为数据状态的不断变化，直到数据最终完成。

　　在《 SOA和BC 》一文中提到了关于基于OSGi的模块化的设计思路，工作流管理作为其中的一个公共组件的模块，如果是提升到企业级的公共服务平台中，则是独立的工作流管理业务组件，可以实现跨系统的工作流整合，以下结合《 SOA和BC 》的思路，进一步细化工作流管理模块（或工作流管理业务组件）的设计思路。

　　工作流组件的松耦合设计

　　传统的办公自动化或者协同办公系统，要实现基于工作流的流转，需要有两个基本的功能：工作流引擎和自定义表单，有了这两个基本功能就可以在一个系统中实现流程的流转。但是如果要实现整合企业所有的应用（不管是什么平台、什么开发商），特别是要将所有的业务全部整合到一个工作流中，就需要工作流组件提供一个松耦合的连接方式，将所有的应用整合在一块，保证现有的系统都能最大程度的整合到统一的工作流中，从而实现统一企业的工作流。

　　结合《 SOA和BC 》的思路，将工作流组件作为一个独立的公共组件，为了更好的实现和其它业务组件以及公共组件内部的不同模块之间的松耦合，工作流组件对外以Web服务的方式对外提供接口，通过ESB和业务组件进行调用。同时为了保证性能，可以将工作流引擎内嵌到业务组件中，通过类总线（API）进行调用。这样既可以实现和内部业务组件之间的结合，也可以实现和应用外部的系统进行流程整合。从业务组件划分角度来看，工作流模块可以作为独立的业务组件，从方便管理角度来看，将其和其它的功能模块合并在一起，是公共组件的一个部分。公共组件模型如图 1 所示：

图 1. 公共组件模型－工作流模块

　　表单自定义功能是界面管理模块的重要功能之一。

　　本文中的工作流管理组件实际上是公共组件的一个部分

　　工作流组件和其他业务组件通过Web服务方式调用可以采用异步和同步传输两种模式。同步传输主要适用于两个系统必须同时提交的业务场景，采用同步传输需要等待另外一个系统的反馈信息，对提交 Web 服务的系统有性能的影响；异步传输的方式主要适用于可以异步提交 Web 服务的业务场景，保证了提交Web服务系统的性能，异步提交的方式需要考虑接受服务的系统出现宕机或者网络故障的情况下还可以准确无误的将Web服务传递到接收系统。异步传输一般通过消息中间件完成。

　　关于松偶合的Web服务的调用顺序在《 SOA和BC 》文中建议尽量采用触发的方式进行调用，基于这种调用方式，业务组件对外只提供查询或者写入服务，而不会直接通过写代码调用服务，实现业务组件的松偶合，这种调用方式同样适应于工作流组件中。比如客户注册流程，一开始实在CRM系统完成的，但是如果随着业务的发展，客户注册采用网上注册，原来CRM系统客户注册流程的任务启动就会发生变化，如果是采用的触发的方式，仅仅修改流程的编排即可，而不需要修改 CRM 的程序。在工作流组件中，最好的一个实现方式就是由工作流组件进行流程的发起，如图 2 启动流程所示。

图 2. 工作流组件的松偶合调用

　　为了实现松偶合，业务组件和工作流组件之间不进行业务数据交互，传递的仅仅是任务信息。业务组件对外提供获取信息或者写入信息的 Web 服务，和普通的业务组件之间的Web服务没有什么区别，读取信息和写入信息是标准的业务服务，保证了为工作流使用的Web服务具有通用性。如果需要和工作流整合，仅仅提供一个特殊的Web服务“通知完成”将任务的完成状况或者任务的基本信息等传递到工作流组件，任务的基本信息主要是为了痕迹化管理，将修改的信息做一个记录，便于未来的审计。通过这种模式实现业务数据和流程数据分离，工作流组件和业务组件不进行业务数据的交互，简化了工作流整合的难度。工作流组件则提供启动流程、修改流程状态，启动下一环节以及保存任务基本信息等 Web 服务。

　　为了使流程平台具有良好的扩展性，如果工作流组件需要业务数据，比如需要根据业务数据进行判断业务流转，也是以Web服务的方式有业务组件提供一个标准的服务，通过BPEL实现，比如为了进行痕迹化，则需要对进行审批的内容进行保存，通过BPLE调用查询服务将数据保存到流程数据库中，其调用跟工作流引擎没有关系。实现跨系统的流程流转，也是通过BPEL的编排，通过调用业务Web服务实现。

　　工作流组件组成及和业务组件关系

　　作为公共组件的工作流模块主要包含三个主要功能：工作流引擎、待办任务管理、工作流可视化管理。工作流引擎是基础模块，可以为所有的系统提供工作流引擎，实现工作流流转的逻辑控制；待办任务管理主要实现人机交互，提供一个统一管理的待办任务管理，整合公共的工作流引擎以及企业已经存在的工作流引擎（如OA），形成一个统一的待办任务管理；工作流可视化管理，主要用于工作流的可视化展示，用于除了用于工作流定义外，可以实现流程监控、流程业务监控、流程导航等功能。

　　工作流管理组件和业务组件整合根据结合紧密程度可以分成三种：完全独立的公共工作流管理组件，工作流引擎和业务完全隔离开，流程任务通过 Web 服务方式交互；内嵌的工作流管理模块，业务组件通过API的方式调用内嵌在业务组件中的工作流引擎，工作流引擎和公共的工作流引擎共享数据库；公共工作流管理组件和内嵌工作流模块组合，工作流引擎有自己的流程数据库，包含已有系统的工作流引擎有自己的流程数据库，工作流引擎和业务组件紧密集成，通过ESB以Web服务方式或者通过数据总线和公共工作流引擎进行数据交换，内嵌的工作流引擎负责任务的处理，公共的工作流组件集成待办任务。如图 3 所示：

图 3. 工作流模块内容及和业务组件关系

    如上文所示，第一种方式是完全松偶合的；第二种方式易于开发，性能更好；第三种方式能够集成已有的各种工作流引擎，适合于集成遗留系统。

　　工作流的流程节点类型

　　根据工作流组件跟业务组件的融合程度，可以将工作流组件和业务组件的关系分成以下几种情况：

　　审批流程节点：直接和工作流组件集成，工作流组件中可以体现待办任务，并带有可以直接操作的表单（含带有附件的表单），典型的例子是协同办公中的公文流转、单据审批等功能。审批流程节点是和工作流组件的耦合性最大，完全依赖于工作流组件工作。审批流程节点可以进行转批、驳回等操作，详细记录流程相关的操作信息。

图 4. 审批流程节点带个性化表单的松偶合设计

    根据表单是否独立，可以分成两种实现方式，采用自定义表单或独立开发表单。自定义表单中的数据源有两种，一种是由自定义表单直接读写数据库（如上图 1.1），一种是由自定义表单直接调用 Web 服务进行读写，业务组件提供Web服务，在自定义表单中进行展示（如上图 1.2）。采用自定义表单的方式，和工作流组件结合紧密，不便于实现松偶合，为了实现更好的松偶合，可以独立开发的表单，然后以 Web 服务的方式和工作流管理组件交互，使得表单和工作流引擎松偶合（如上图 2.1），或者将工作流管理作为一个公共模块，内嵌到业务组件中，通过类总线（API）工作流引擎和业务组件集成（如上图 2.2）。采用 2.1 方式能更加方便的组件松偶合的业务组件。

　　审核流程节点：和工作流组件应用集成，通过 Web 服务交互，表单显示格式固定，Web服务可以携带审核信息，但是没有个性化的表单操作，仅仅可以完成审核确认功能。审核流程节点可以进行转批、驳回等操作，详细记录流程相关的操作信息。审核流程节点和业务组件之间是通过 web 服务交互的，因此是松偶合的，但是也限制了其应用，不便于直接操作业务组件的详细内容。由于其模式简单，适合于大规模使用，如订单审批确认、领导审批等功能，（如图 5－3.1 所示）。

图 5. 不带个性化表单的工作流

　　消息流程节点：和工作流组件应用集成，仅仅提供待办信息，可以通过Web服务调用，根据查询条件直接查询本节点需要处理的任务，然后进入相应的操作界面进行操作，操作完成之后，任务状态发生变化，待办任务完成。通知流程节点仅仅是一个消息通知，适合于大业务量的操作场景，可以实现简单的业务集成，提高系统易用性，简单记录操作过程。（如图 5－4.1 所示）

　　审核流程节点和消息流程节点差异主要体现在前者工作流模块为主，和工作流紧密集成，但是只是简单业务操作，后者则以业务组件为主，工作流简单集成，但是却可以完成复杂的业务操作。和工作流引擎模块无关，仅和待办任务管理、流程可视化管理模块相关。

　　消息流程节点可以包含多种实现场景，由于和其它的业务组件是松耦合的，可以对整个系统的所有应用进行整合，主要包括：

　　通知流程节点：根据数据的状态，由应用自动或者被动生成简单的任务信息，以通知的方式通知到工作流引擎，在待办任务中仅仅提供待办信息数量，具体操作还是在原来的系统完成。自动生成通知信息可以实时通知，但是需要原有的系统进行改造，被动通知则不需要原有的系统变化，仅仅是做一个数据查询的接口即可完成。
 
　　预警流程节点：有预警模块生成预警信息，将预警和流程结合起来，可以看到那些流程节点出现预警，并根据预警的级别，分成待办任务、确认完成和确认了解三种类型。待办任务需要启动新的流程，对预警信息进行处理（可以采用审批流程节点的处理）；审核完成需要落实预警信息的原因；确认了解则只需要了解即可。消息和预警的差异主要是后者属于异常的信息。

　　导航流程节点：和工作流简单集成，仅仅提供一个菜单导航的功能，提高系统的易用性，没有待办任务信息，简单记录操作过程，如操作人、时间、操作的功能，但是无法记录具体操作了什么内容。和工作流引擎模块无关，仅和流程可视化管理模块相关。

　　人工任务流程节点：和工作流无关，仅仅为了完整流程而做的一个描述。为了进一步提升系统的易用性，可以在所有流程节点上（包含人工流程节点）增加说明文字，作为企业业务流程指导书。和工作流引擎模块无关，仅和流程可视化管理模块相关。

　　通过以上分析，可以看到，为了搭建松偶合的工作流组件，可以采用通过服务总线（ESB）以 Web 服务方式或者通过类总线以 API 方式进行集成，搭建企业级的公共工作流组件。工作流组件和业务组件之间没有直接的业务数据交换，工作流组件相对更加独立；工作流组件包含了集成各种方式的工作流，特别是遗留系统的工作流引擎；工作流组件的适用范围更广，不仅仅是涉及流程审批，所有的业务系统都可以整合进来，建立一个企业的完整视图的工作流，搭建了一个企业级的技术架构平台。

　　工作流管理（WFM）组件实现

　　工作流组件和工作流数据库

　　如前文所示，工作流组件在应用方面主要包含三个部分：工作流引擎、待办任务管理、工作流可视化管理，在数据库层面，主要包含两个部分：流程数据和业务操作记录，流程数据保存企业所有流程的流程定义、流程运行状态、待办任务以及流程可视化等流程本身的数据，业务数据保存流程过程中的业务数据。由于业务数据结构多样，为了保证对流程操作过程的详细记录，将所有通过工作流的业务操作信息全部直接以 XML 方式存放到流程数据库。如图 6 所示：

图 6. 流程整合平台

    基于IBM产品的实现
　
　　本文提到的集成平台，基于IBM的产品共体系在实际搭建的时候需要包含应用服务器（产品：WAS）、流程整合服务器（产品：WPS，实现服务总线和流程编排）等，关于集成平台的详细描述，详见《 SOA和DW 》一文中“基于 IBM 产品体系的实现”的描述。除此之外，本文中涉及到的内容还包括：工作流引擎、基于XML的数据库、消息中间等。

　　工作流引擎可以有多种实现方式，比如采用 IBM 的 WPS 或者 FileNet，或者浪潮 Loushang 工作流引擎等，本文以 FileNet 为例。流程数据库采用 IBM 的 DB2 V9。

　　数据库服务器（IBM DB2 Enterprise Server，DB2）的XML主持

　　IBM?DB2?V9 整合了关系型数据服务器的能力并进行了扩展，使得它能够管理关系数据和XML数据，包括对数据的存储，检索，共享，确认等。这使得用户可以拥有一个高性能，高可扩展性的平台来方便的管理关系和XML这两类的数据。pureXML这个突破性的技术结合现有的数据管理技术可以带给用户所有期望从数据库系统中获得的功能特性。它提供高性能和高可靠性，并能够在极大的减小管理成本的同时，提高可用性和性能。DB2 V9实现了对XML数据的索引技术。通过建立索引，给查询检索提供很好的性能。如果没有索引的存在，则任何查询都要遍历XML的整个树形结构，其效率就很低了。

　　通过DB2 V9，建立流程数据库，可以有效解决多种格式的业务数据痕迹化管理带来的数据保存的问题，为流程审计提供数据。

　　工作流服务器（FileNet）

　　FileNet P8是IBM新一代的、统一的企业级内容和流程管理平台，它包含广泛的产品和服务，帮助用户在面向服务架构（SOA）的环境中构建，部署，运行和管理企业的内容和流程。本方案中主要是采用FileNet的流程管理 (FileNet Business Process Manager) 功能。流程管理包含流程配置控制台(Process Configuration Console)，流程设计器(Process Designer)，流程引擎(Process Engine)，应用引擎 (Application Engine) 等产品和应用。

　　FileNet的工作流具有分布式 (distributed)，可获取性 (availability)，可调控性 (scalability)，安全，标准化的能力，可以有效的承担公共工作流引擎的角色。

　　工作流模块实现举例

　　以下以报销流程为例说明工作流模块的使用，报销单据凭证处理都是在财务系统完整的，但是财务系统一般不支持所有员工在财务系统中录入报销单据数据（如发票号码、金额等），同时由于财务软件是产品化的软件，很难进行大的改造。因此实现每个员工填写报销单据，并由上级领导审批报销单据，最后由财务进行审核，需要一个报销管理。报销管理单据的维护、审批处理，信息简单，可以直接用表单定制和工作流管理模块定制出来，包括填写报销单据、直接上级审批、领导审批等流程节点，就像一般的办公自动化系统实现的功能。

　　领导审批完成之后，启动一个业务流程（采用BPEL进行编排），将单据数据自动写入财务系统（只需要财务系统提供写入单据Web服务）。由于财务系统无法进行大的改造，在财务审批、财务入账环节，采用消息流程节点处理方式，由财务系统提供一个查询单据状态的接口，这样财务人员就可以在待办任务中看到报销单据的待办，财务人员通过单点登录，点击待办任务进入财务系统进行操作，报销单据的填报者则不需要进入财务系统，在报销系统中就可以看到报销单据的整个流程的状态，这样既可以实现整合所有流程，又对财务系统本身不会造成大的影响。

图 7. 报销流程举例

    以上就实现工作流组件在数据库设计以及基于IBM产品体系如何实现做了简要说明，并以报销流程举例说明实现。

　　总结

　　本文通过对业务流程管理（BPM）和工作流（WF）的分析，给出了一个企业级的工作流组件设计，扩大了工作流适用范围，不再仅限于审批，而是扩展到所有的业务流程；提出了建立公共工作流引擎的思路，基于SOA的架构思想，整合企业流程；除了流程的整合，还对工作流和绩效、审计、个人门户和消息之间的关系做了简要说明。最后本文给出了工作流的实现思路以及基于IBM产品实现的产品支持。