《流程的永恒之道》（四）：BPM 的生命周期之执行阶段

在上篇文章中，我们讲到了 BPM 的生命周期包括设计、建模、执行、监控和优化 5 个阶段，本篇我们以住建行业的预销售许可审批的主线流程对 BPM 的执行过程进行详细的解剖。

1.1.1 预销售许可主线流程的执行分析

BPM 中的流程包括可执行流程和不可执行流程，不可执行流程在企业中占据了非常重要的位置，它包括战略流程、规划流程和管理层面的流程，目前大多数的 BPMS 套件只是实现了对 BPM 中的可执行流程的支持，而未支持不可执行流程。有的厂商通过称为 BPA（Business Process Analysis）的产品来支持 BPM 中的不可执行流程，相关内容可参考 8.3.1.1 节关于 ARIS 及 Control-ES 产品的介绍。这里先看可执行流程，讲解执行过程之前，我们先来分析流程的组成。从建模期的流程定义上讲，流程组成就是由多个活动节点（在 BPMS 中，此活动节点一般都可以继续向下分解为子流程）按照一定的模式组成的一个转移序列，具体的组成分析如下。

1. 可执行流程组成分析

BPM 的流程组成如图 1 所示。

图 1 端到端的预售证许可审批业务流程示意图

图中虚线框内的是流程的图形化组成，可以看到，这是一个端到端的预售证许可审批业务流程。要运行这个流程，需要在流程属性（整个流程上）和环节属性上（每个环节上）挂接一些资源，并配置一些属性。这些属性有业务方面的，也有技术方面的。

流程属性

• 收件名称列表：此属性描述的是办理预售证许可证需要收取哪些证件。就像你去银行办理信用卡一样，需要提供身份证、收入证明、房产、车的证明等。不同的业务流程需要的证明材料不同，因此，此属性作为流程属性进行配置。有人可能说，这个属性是业务属性呀，怎么能当作流程属性呢。没错，收件名称列表确实是业务属性，对于完全封闭的、通用的 BPM 产品来讲，肯定不会把它作为流程属性来开发 BPM 产品；但是对于行业流程产品，从技术角度来考虑，作为流程属性来处理才是正道，因为这样能更方便使用。

此属性本质上属于业务属性，虽然被行业流程产品封装为流程属性了，但是在使用时还是由业务人员进行定义。

流程定义的组成实现

(1) 自定义流程定义规范

可以给 Process 专门定义一个属性集合，来存储收件资料名称。如下：

 
<process>
<requiredDocs>
       <doc> 名称 </doc>
       <doc> 名称 </doc>
    </requiredDocs>
<activities>
   <activity>…</activity>
</activities>
<trasitions>
   <transition>…</transition>
</transitions>
</process>

(2) BPMN 2.0 规范中的实现

在 BPMN 2.0 规范中，提供了 extensionDefinitions 的扩展机制，可以利用此扩展机制来存储业务上需要与流程定义绑定的相关属性，例如本例中的收件名称。不过扩展了此属性后，此 BPMN 2.0 的流程就不再是通用的流程了。交换到其他符合 BPMN 2.0 规范的 BPMS 产品中去时，extensionDefinitions 属性是不能交换的。这就是为什么我们多次说到，不要妄想遵循相同规范的产品可以互相兼容。如果真的兼容，那也肯定是个实验室产品，因为任何一个厂商都会以客户的需求为第一要素，必然会在规范的基础上加入很多规范所允许的扩展。

除了利用 extensionDefinitions 属性以外，也可以单独定义一个关系表，即流程定义模版名称与收件资料集合的关系表。这样也可实现收件名称列表与流程的绑定。

• 表单：表单作为业务与流程的一个主要结合点，是流程的一个必有属性。尤其是在 MIS 信息系统中，业务人员的主要工作是通过表单做相关的工作（录入数据、扫描附件、编辑处理、填写审批意见、打印、统计、查询等）。整个业务的办理，归纳起来就是不同岗位的人员，在不同的业务环节，通过不同的业务表单进行不同的操作。这个业务的运转过程是通过流程来带动的，因此每一个业务流程必须与其对应的业务表单建立绑定关系。例如本例中，预售证审批流程必须与预售证申报的业务表单进行绑定。这里需要注意的是，如果在流程上绑定表单，那么对应的业务场景只能是，整个业务在不同环节进行流转的过程中使用相同的表单。这种场景一般在单一系统的工作流应用中较多（例如电信、移动的工单派送、OA 中的请假单等）。

此属性属于技术属性，但是如果做得足够简单易用，可以由业务人员定义（例如，提供可选择的单列表，表单名称具备足够的业务含义，就可以由业务人员通过选择进行绑定）。

流程定义的组成实现

(1) 自己定义流程定义语言

 
<process>
<form  id=’’ url=’’ />
</process>

(2) BPMN 2.0 规范中的实现

在 BPMN 2.0 规范中，表单属性是与 UserTask 类型的活动绑定的，在 UserTask 活动上，定义了一个 rendering 属性，用来绑定此活动所对应的渲染表单。

• 期限：对于 BPM 来讲，既有人工任务，也有自动任务（不要以为人工任务就是工作流才会有的场景，BPM 中的人工任务也不少，只是 BPM 中的人工任务是在不同的业务系统进行操作）。对于有人工参与的流程或任务，在很多的业务场景中需要设定其执行期限（在政府的办理流程中，称之为行政许可期限和非行政许可期限）。如果某个业务流程实例的执行期限超过了 15 天，就属于超时流程。

此属性属于业务属性，可以由业务人员进行定义。

流程定义的组成实现

(1) 自定义流程定义规范

 
<process>
<duration>…</duration>
</process>

(2) BPMN 2.0 规范中的实现

BPMN 2.0 规范中有一个 timer 事件，但是不要搞混了，timer 事件是属于定时事件，即在某个时间点触发事件的动作。对于时间的属性，并没有给出显式的说明，但是对于 Activity 活动，BPMN 2.0 规范定义了属性，通过此属性，可以定义任务期限。

• 事件：流程产品作为中间件，独立运行是没有任何意义的，它必须为业务系统提供支撑和服务，因此流程与业务的交互是实现流程支撑业务的关键。这种交互通过事件的机制进行。那么事件的定义是什么？可能很多人对事件（Event）和动作（Action）比较模糊。事件就是通过某个触发点（触发条件、时间点）执行特定的动作。在 BPM 的产品或实现中，这个动作往往是 SOA 中的某个服务（例如 ESB 上的注册服务）。

此属性是技术属性，因此梦想由业务人员去定义是完全不可能的。虽然一些 SOA 的厂商鼓吹 SOA 就是搭积木（服务就是底层的积木）。天哪！这世界什么时候变得这样简单了。

流程定义的组成实现

(1) 自定义流程定义规范

 
<process>
<events>
   <event  refAction=’’ />
</events>
</process>

(2) BPMN 2.0 中的实现

在 BPMN 2.0 规范中，定义了大量的事件，详见第 7 章及第 9 章。

• 消息：用于给人工任务的参与者发送通知（可以是在线消息、邮件、IM 即时消息、手机短信等）。当然，此功能可以完全通过事件机制实现，或者在程序中内置也可。如果有灵活的配置需求，则单独进行定义。

此属性属于介于业务属性与技术属性之间。通过灵活配置，可以做到让业务人员来定义。

流程定义的组成实现

(1) 自定义流程定义规范

 
<process>
<messages >
   <message  type=’’  name=’’/>
</messages>
</process>

(2) BPMN 2.0 中的实现

在 BPMN 2.0 规范中，定义了消息调解事件（Message Intermediate Event）可以支持发送消息或等待消息触发，详见第 9 章的内容。

数据变量：在讲述事件时，我们提到流程与业务的交互是实现流程支撑业务的关键。流程与业务的交互通过事件实现。事件是实现方式，真正交互的是什么呢？是数据。也就是说，一些业务数据需要与流程执行引擎进行交互（关于交互的数据分类，详见 3.5 节工作流数据模式一节）。因此这个数据交互就必须通过数据变量作为桥梁来实现。在 BPM 的业务流程产品或实现中，如果 BPM 用于企业异构系统的应用集成，此场景中交互的数据较多，因此这个数据变量一般会通过 SDO 封装数据来实现。

此属性是技术属性，必须由技术人员来定义。

流程定义的组成实现

(1) 自定义流程定义规范

 
<process>
<variants>
   <variant  name=’’  tye=’’ value=’’ />
</variants>
</process>

(2) BPMN 2.0 中的实现

在 BPMN 2.0 规范中，采用 Data Object 相关对象来实现对数据变量的支持，详见 7.3.2.4 节数据元素与数据关联。

活动属性

• 表单：在 BPM 的应用场景中，由于多是跨系统的业务流程，因此有可能是组成流程的每一个活动环节都对应不同系统的处理，因此，此时只能在每个活动上绑定不同的业务表单。此时，如果集成的业务系统有 C/S 的业务系统，需要单独对它开发可在 BPM 中使用的 B/S 表单。

活动定义的组成实现同流程。

• 参与人：此属性定义活动与人的交互。通过此属性，流程以推送待办任务的方式推动不同的人去参与业务。实现此属性需要流程与组织结构模型进行挂接（例如，与企业的 LDAP 组织结构库挂接）。挂接之后，此属性可以与组织结构模型中的任意实体进行绑定（如组、岗位、角色、人等）。除了简单绑定组织模型中的实体以外，可能还会有更复杂的参与者及参与模式的定义（详见，本书第 3 章 3.4.4 及第 10 章 10.3.3 两节关于资源模式的内容）。

此属性是属于业务属性，与组织结构中的实体（例如角色、岗位等）简单绑定时，可以由业务人员来定义。但是涉及比较复杂的参与者计算或参与模式时，则必须由技术人员定义。

流程定义的组成实现

(1) 自定义流程定义规范

 
<process>
<activities>
<activity/>
   <participants>
       <participant  name=’’  type=’’  id=’’>
   </participants>
</activity>
</activities>
</process>

(2) BPMN 2.0 规范中的实现

在 BPMN 2.0 规范中，对于参与者，是按照流程的私有与公开特性定义泳道（池及道）来区分（见第 7 章 7.3.1.1 节）；对于流程编制，在后端定义了 ResourceRole、Performer 等对象来支持参与者；对于流程会话，则定义了 Participants 等对象来实现参与者定义。

• 期限：在流程属性中，需要定义整个流程的期限。流程是由活动组成的，因此对于单个的活动，同样需要设置其办理期限。即便是一个自动节点，也是有执行时间的。活动期限往往用于统计其对应的办理岗位的绩效。另外可用于待办任务的红绿灯机制。

活动定义组成实现

(1) 自定义流程定义规范

 
<activity>
<duration>…</duration>
</activity>

(2) BPMN 2.0 规范中的实现

在 BPMN 2.0 规范中，对于活动的时间属性并没有给出显式的说明，但是对于 Activity 活动，BPMN 2.0 规范定义了、、等属性，它们都可做为任务期限的存储容器。

• 事件：与流程上的属性相同，只不过是在活动节点上进行触发。其活动定义的组成实现同流程。
• 消息：与流程上属性相同，只不过是在活动节点上触发。其活动定义的组成实现同流程。
• 数据变量：与流程上属性相同，只是其作用域为活动节点，只对当前活动可见。而流程上的数据变量对整个流程（所有的活动节点）都可见。其活动定义的组成实现同流程。

我们通过以上对可执行流程的组成分析发现，一个建模期的、由业务分析师通过 BPMN 流程设计器建模后的业务流程要成为可支撑业务的可执行流程，还需要定义很多的业务属性和技术属性。只有这些业务属性和技术属性全部定义完毕，业务流程才真正成为可执行的流程。

提示：在上文中，已经给出了 BPMN 2.0 规范中的实现，那么在 BPEL 及 XPDL 规范中是怎样实现的呢？在 BPEL 和 XPDL 中，有些属性规范本身已经定义，有些属性则没有定义，不过都提供了扩展机制，例如 XPDL 的和 bpelextensions。利用这些扩展机制，可以实现对本例中所有属性的支持。

2. 可执行流程的执行过程

上文分析了可执行流程的组成，由此可以给出流程执行的定义：流程的执行也就是对可执行流程的流程定义进行实例化的过程。业内曾有这样的说法：对于工作流，执行 = 任务分配；对于 BPM，执行 = 服务调用。应该说，这样的说法在一定的程度上反映了工作流与 BPM 的主要特点及区别。在大多数 BPM 项目中，存在着一定数量的 Task 分配，因此我们对 BPM 执行的定义如下：

BPM执行=任务分配（参与人、消息、表单、收件、期限）+ 业务流转（活动转移） + 路由决策 + 服务调用（执行事件）

任务分配（参与人、表单、收件、期限）

流程是指挥家，是导演，是参谋长。它运筹帷幄，运用各种战略、战术、规则，有序地指挥企业中的人，按照不同的控制模式、资源模式、数据模式进行业务的驱动。在 BPM 的项目中，任务分配是不可缺少的部分，只是其数量相对于 WFM 项目要少一些，其整个过程如下。

(1) 流程第一个环节的参与人（本例中是房地产开发商的预售证申报人员）登录预售申报系统，并请求第一个申报数据的表单，预售申报系统从预售审批流程的第一个环节（预售证申报）的活动定义中读取绑定的业务表单（预售申报录入单和收件列表表单）并展示给预售申报人员。

(2) 预售申报人员在录入单上填写相关的申报数据，并保存；

(3) 预售申报人员切换到收件列表表单，进行收件扫描件的上传；

(4) 保存业务数据，办结并转出此任务。

业务流转（活动转移）

房地产开发商的申报人员提交申报请求后，流程执行引擎需要按照流程定义，将活动驱动到第二个环节“房号登记”，那么这个驱动是怎么实现的呢？目前主流的实现技术有以下三种。

基于有限状态机（FSM）的状态转移

这是国内大多数流程执行引擎所采用的机制。有限状态机（FSM）又称为有限状态自动机或简称状态机，是表示有限个状态以及这些状态之间的转移和动作等行为的数学模型。

状态存储过去的信息，就是说它反映从系统开始到现在时刻的输入变化。转移指示状态变更，且转移本身是通过用必须满足转移发生的条件来描述的。动作是在给定时刻要进行的活动的描述。有多种类型的动作：

• 进入动作：在进入状态时进行
• 退出动作：在退出状态时进行
• 输入动作：依赖于当前状态和输入条件进行
• 转移动作：在进行特定转移时进行

有限状态机是一种算法思想，简单而言，它由一组状态、一个初始状态、输入和根据输入及现有状态转换为下一个状态的转换函数组成。GoF 的 23 种设计模式里的 State 模式是一种面向对象的状态机思想，可以适应非常复杂的状态管理。

现在，有限状态机在硬件领域被用于电路设计，而在软件领域被普遍用于搜索引擎的分词、编译器实现、游戏开发和流程执行引擎的实现。它在游戏开发中，通常用来实现 NPC 控制；而在流程执行引擎实现中，通常用来实现对于流程实例、活动实例、转移实例、工作项实例的状态迁移。有限状态机有多种实现方式，在流程执行引擎中一般采用面向对象的方式，如图 2 所示。

图 2 有限状态机逻辑图

可以看出，有限状态机的下一个状态和输出是输入和当前状态的函数，也就是说，输入和条件触发当前状态变迁为下一个状态，而下一个状态的实现会产生输出结果，如图 3 所示。

图 3 流程执行引擎部分实例对象关系图

表 1 给出了流程执行引擎中工作项的状态转移情况。

表 1 流程执行引擎中工作项的状态转移

状态

条件

准备

初始化

待签

待办

拾取

终止

异常

挂起

委托

结束

定义加载为实例

1

                初始化
2
 
              分配任务
  3
 
            签收
    4
          竞签
      5
        终止
        6
      程序异常
          7
    挂起
            8
  有委托记录
 
              9
提交任务
 
                10

流程执行引擎中工作项状态转移图如图 4 所示。

图 4 工作项状态转移图

表 2 以状态转移表的形式描述了流程执行引擎中单个工作项（任务实例）的有限的多个状态、这些状态之间的转移、转移条件及触发转移的事件（执行动作）。图 6.14 以状态转移图的形式描述了在流程执行引擎内部一个具有 2 个节点的串行流程的工作项（任务实例）的状态转移情况：

加载并初始化第一个活动节点的任务实例（“预售申报”）形成待签à签收第一个任务实例形成待办à结束第一个任务实例à初始化第二个任务实例（“房号登记”）形成待签à签收第二个任务实例形成待办à结束第二个任务实例à继续向下驱动，直至整个流程结束。

在这个过程中，状态转移都是通过外部动作触发的，例如签收动作（sign in）会触发待签状态（to sign in）到待办状态（to do）的变迁。

基于 Petri 网中的 token 变迁

Pertri 网是面向并行系统建模的一种非常好的形式化模型。一方面，Petri 网可以采用图形进行表示；另一方面，它又有严格的数学定义可以进行一系列系统属性分析。关于 Pertri 网，感兴趣的读者可以阅读清华王建民老师翻译的《> 工作流管理——模型、方法和系统》。那本书就是围绕着 Pertri 网讲解的，是荷兰埃因霍恩科技大学的两位教授 Wil van der Aalst 和 Kees van Hee 所著。

基于 pi 演算（进程代数）

pi 演算是一种进程代数，起源于 20 世纪 80 年代末，由图灵奖得主罗宾·米尔纳（Robin Milner）提出。它是一种描述和分析并发系统的演算模型，采用演算中的归约来表示由进程间相互作用形成的动态演化，因此非常适合于描述动态系统。

在 2003 年，时任 BPMI.org 联席主席的 Howard Smith 和另一位 Peter Fingar 写了一篇文章“Workflow is just a Pi process”[2]，发表在 BPTrends 的网站上。荷兰埃因霍恩科技大学的 Wil van der Aalst 教授在 2004 年写了一篇“Why workflow is NOT just a Pi-process”[3] 的文章对此进行反驳，之后他又写了一篇为“Pi calculus versus Petri nets: Let us eat “humble pie” rather than further inflate the “Pi hype” ”[4] 的文章，分析了 pi 演算的局限，并提出了 7 个挑战，对 pi 演算进行了质疑。来自于德国波茨坦大学的 Frank Puhlmann 则写了另一篇文章“Why do we actually need the Pi-Calculus for Business Process Management?”[5]，认为在 BPM 中是需要 pi 演算的。

其实以上都是学术派的口水之战，大多从理论上进行争论，对于我们这些搞技术的 IT 从业者，不必太理会或者稍加了解就可以了。

通过以上的分析，读者应该清楚了流程执行引擎是怎样驱动业务进行流转的。

路由决策（路由节点的执行）

在预售证许可申报流程的第二个环节“房号登记”之后，要根据申报的预售项目的性质，决定发起哪个子流程（物业用房缴交核查子流程、拆迁安置房核查子流程、经适房核查子流程），这个决策通过一个 M 选 N（参见第 10 章 10.3.2.2 节）的自动路由分支节点实现。而关于路由决策节点的技术实现，我们已经在第 2 章的规则引擎一节中讲过。

服务调用（执行事件）

业务流转到三个核查子流程的某一个时，例如“物业用房缴交核查子流程”，此时如果物业用房管理子系统是独立部署的异构系统，则在当前环节需要通过事件机制，调用物业用房管理子系统提供的数据接收服务，将申报数据（PreSaleApplyDataSDO）传递给它。这个数据接收服务可能会注册在企业服务总线上。因此通过 ESB 提供的服务接口，由流程执行引擎进行这个服务调用。

通过以上四个步骤的分析，读者应该对流程执行引擎的执行过程有了较清晰的认识，下面我们给出完整的执行过程示意图，如图 5 所示。

图 5 预售许可证审批流程执行过程示意图

1. 《工作流管理–模型、方法和系统》, 清华大学出版社. 王建民，闻立杰。
2. http://www.fairdene.com/picalculus/workflow-is-just-a-pi-process.pdf。
3. http://bptrends.com/publicationfiles/02-04 ART WhyworkflowisNOTjustaPi - Aalst1.pdf。
4. http://is.tm.tue.nl/research/patterns/download/pi-hype.pdf。
5. http://blog.edu.cn/bpt.hpi.uni-potsdam.de/twiki/pub/Public/FrankPuhlmann/BIS2006-PIC.pdf。

感谢张龙对本文的审校，感谢张龙对本文的策划。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。