基于SOA的业务流程管理（BPM）和工作流（WF）

目录

摘要

什么是流程

流程和作业

流程规范XPDL和BPEL

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

业务流程建模符号(BPMN)

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

工作流组件的松耦合设计

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

工作流的流程节点类型

工作流的流程节点绩效和审计

工作流组件和个人门户

工作流组件和消息组件

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

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

基于IBM产品的实现

工作流模块实现举例

总结

---

最初由 IBM developerWorks 中国网站发表，网址http://www.ibm.com/developerworks/cn

2010-05-17

摘要

当前基于BPLE的业务流程管理（BPM）以及基于XPDL的工作流（WF）都有成熟的理论和相应的产品支持，特别是在国内，工作流（WF）的应用十分广泛。本文从流程入手，结合业务流程管理、工作流、绩效管理、个人门户等概念，将业务流程管理和工作流结合起来，搭建企业级的跨系统的流程整合架构。

什么是流程

在面向服务体系架构（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）为基础，基于《SOA和BC》的方法进行设计，给出了工作流管理组件的设计模型。工作流和绩效、个人门户、即时沟通等紧密相关，比如每个岗位流程节点汇总在一起，在前端展示为个性化门户，即时沟通平台实现人员之间实时沟通。

业务流程建模符号(BPMN)

业务流程建模符号(Business Process Modeling Notation，BPMN)由BPMI(The Business Process Management Initiative)开发是一套标准叫业务流程建模符号，于2004年5月对外发布了BPMN 1.0 规范。BPMN的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（Flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型 (Business Process Model)，指一个由的图形对象(graphical objects)组成的网状图，图形对象包括活动(acticities)和用于定义这些活动执行顺序的流程控制器(flow controls)

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

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

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

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

工作流组件的松耦合设计

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

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

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

 

[注]

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

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

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

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

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

 

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

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

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

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

工作流管理组件和业务组件整合根据结合紧密程度可以分成三种：完全独立的公共工作流管理组件，工作流引擎和业务完全隔离开，流程任务通过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方式进行集成，搭建企业级的公共工作流组件。工作流组件和业务组件之间没有直接的业务数据交换，工作流组件相对更加独立；工作流组件包含了集成各种方式的工作流，特别是遗留系统的工作流引擎；工作流组件的适用范围更广，不仅仅是涉及流程审批，所有的业务系统都可以整合进来，建立一个企业的完整视图的工作流，搭建了一个企业级的技术架构平台。

工作流的流程节点绩效和审计

工作流和企业绩效紧密相关，每个企业有一个总体的目标，目标的实现由一个个的工作流来支持，也就是说每个业务流程都是在为了实现企业的某个目标，因此工作流以及工作流的环节都可以对应着企业总体目标细化之后的细化目标，因此，可以通过流程节点KPI的监控实现对企业目标实现的监控，实现管理的可视化，从而的实现对企业运行的可视化监控，当某个环节出现问题，超出了预警值之后，就可以进行报警。流程节点主要包含的属性包含开始时间、结束时间、工作内容，操作内容、业务目标〔可选，主要是大的流程和环节〕待办任务、预警信息等。除了流程跟企业绩效关联的关系之外，工作流本身也是企业绩效的一个关键要素。通过工作流平台可以更加清晰的记录每一个流程节点的时间成本，为监控和优化每一个流程节点提供一个重要的参数。比如一个流程分成10个流程节点，通过对每个流程节点操作记录，可以方便的对每一个流程节点进行管理，特别是对于有时间要求的流程节点，可以起到一个很好的监控功能。

工作流管和痕迹化管理紧密相关，工作流的操作信息记录之后可以方便的实现工作的痕迹化管理，可以对操作本身以及操作内容痕迹化，工作流通过ESB可以对每次操作的数据统一保存一份到流程数据库中，这样就可以很方便的实现操作审计，谁在什么时候修改了什么数据等信息，保证系统的安全性。

因此流程的可视化管理可以进行分成两类，监管流程可视化和操作流程可视化，前者主要是监控、管理，后者主要是操作。为了便于理解，除了监控流程和操作流程的级别之外，流程可以进行分层，从宏观的大的流程，到各个级别的子流程，不同类别不同层次的流程节点包含的内容和主要体现的信息是不一样的，即流程环节可以有多个层次的子流程，从而便于流程的查看和管理。。如图6所示。

图 6. 监控流程及操作流程

 

工作流组件和个人门户

企业的业务运转是有若干工作流来完成，每个工作流则是由一个个的流程节点组成，每个流程节点对应这一个岗位，因此如果从具体的一个岗位来看，把这个岗位在所有流程节点需要作的工作汇总在一块，即形成这个岗位的在企业的所有流程的一个切面，从信息门户角度看，即为一个岗位的个人门户。为了使得系统更加易用，需要以门户的方式，把个人所需要作的工作汇集到个人门户中，工作流和个人门户的关系如图7所示：

图 7. 工作流和个人门户

 

[注]个人门户功能是界面管理模块的重要功能之一。

通过工作流可以让员工从整体上对企业的业务流程有一个整体的认识，使管理者更加清楚的明白业务流程操作细节，使每一个员工对于自己的工作在整个流程节点的位置有一个更加直观的了解，通过个人门户，让每一个员工对于自己需要在整个系统中需要完成的工作有一个清晰的分类，这样通过工作流和个人门户，便于员工在岗位更换之后更好的适应新的岗位。

工作流组件和消息组件

在企业业务运作过程中，具体的业务流转在对于岗位形成一个流程的切面个人门户，主要以任务的方式体现，有人员到待办任务界面查看，除此之外还有一个消息的沟通，包含各种将任务信息通知到具体负责人和即时消息，可以以邮件、即时消息工具、短信等不同的方式通知到人员。业务相关的协同信息来源一般都可以归结到具体的一个流程上，但是除了业务信息之外，还有其它的一些信息，跟具体的流程无关，或者有些信息无法和流程进行关联，以消息的方式进行传播，因此需要建立一个消息处理模块进行处理各种消息，处理的消息的渠道有多种，即时消息、邮件、短信、电话等，需要一个统一的消息模块统一处理各种消息，包括消息订阅、消息发布等功能。

代办任务可以以消息的方式通过消息模块通知到相关人员，跟流程无关的内容可以直接通过消息模块进行相应的沟通。

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

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

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

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

图 8. 流程整合平台

 

基于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，建立流程数据库，可以有效解决多种格式的业务数据痕迹化管理带来的数据保存的问题，为流程审计提供数据。

工作流服务器（Lombardi）

工作流服务器（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服务）。由于财务系统无法进行大的改造，在财务审批、财务入账环节，采用消息流程节点处理方式，由财务系统提供一个查询单据状态的接口，这样财务人员就可以在待办任务中看到报销单据的待办，财务人员通过单点登录，点击待办任务进入财务系统进行操作，报销单据的填报者则不需要进入财务系统，在报销系统中就可以看到报销单据的整个流程的状态，这样既可以实现整合所有流程，又对财务系统本身不会造成大的影响。

图 9. 报销流程举例

 

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

总结

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