深入Activiti流程引擎：核心原理与高阶实战
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

2.3 BPM相关标准

BPM的发展过程中，在基于Web服务的XML执行语言方面进行过很多探索，如BPEL、BPMN等语言标准。BPEL是一种基于XML的、用于描写业务过程的编程语言，是一种用于产品间交换的标准。业务过程中的各步骤则由Web服务实现。BPMN是一种基于流程图的通用可视化标准，提供通用、易于理解的流程符号。BPMN在业务流程设计与业务流程实现之间搭建了一座标准化桥梁。目前，国内市场上的BPM产品多采用的BPMN 2.0标准。

2.3.1 BPMN 2.0概述

BPMN 2.0是OMG于2011年推出的一种业务流程建模通用语言标准，是对BPMN 1.0的重定义。BPMN 2.0相对于BPMN 1.0、XPDL、BPML及BPEL等规范最大的区别是定义了规范的执行语义和格式，利用标准图元描述真实业务发生过程，保证同一业务流程在不同的工作流引擎下的执行结果是一致的。制定BPMN 2.0标准的一个目的是提供一种能够创建简单易懂业务流程模型的机制，以处理复杂的业务流程。为此，BPMN 2.0定义了丰富的元素，并对这些元素进行了分类，使用户能够轻松识别，从而读懂并理解模型。掌握了BPMN 2.0基本元素，就掌握了BPMN 2.0的核心。BPMN 2.0基本元素分类及符号如表2.1和表2.2所示。

表2.1　BPMN 2.0基本元素分类

表2.2　BPMN 2.0基本元素符号

图2.4使用BPMN 2.0中的图形符号创建了一个简单请假流程示例，主要由事件、活动、网关、顺序流这4种基本元素构成。

图2.4　简单请假流程示例

流程定义文件扩展名一般为.bpmn.xml或者.bpmn20.xml，可以看出BPMN 2.0实际上基于XML表示业务流程。使用文本编辑器可以打开该请假流程示例的流程定义文件，其中内容如下：

<?xml version='1.0' encoding='UTF-8'?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:activiti="http://activiti.org/bpmn" 
  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" 
  xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC" 
  xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" 
  typeLanguage="http://www.w3.org/2001/XMLSchema" 
  expressionLanguage="http://www.w3.org/1999/XPath" 
  targetNamespace="http://www.activiti.org/processdef">
  <process id="process_simple" name="请假流程" isExecutable="true">
    <startEvent id="startEvent1"/>
    <userTask id="leave_apply" name="请假申请" activiti:assignee="${initiator}" 
      activiti:formKey="simple_form"/>
    <sequenceFlow id="sf1" sourceRef="startEvent1" targetRef="leave_apply"/>
    <userTask id="leader_approval" name="领导审批" activiti:assignee="${leader}" 
      activiti:formKey="simple_form"/>
    <sequenceFlow id="sf2" sourceRef="leave_apply" targetRef="leader_approval"/>
    <exclusiveGateway id="gateway1"/>
    <sequenceFlow id="sf3" sourceRef="leader_approval" targetRef="gateway1"/>
    <serviceTask id="holiday_management" name="假期管理"/>
    <endEvent id="endEvent1"/>
    <sequenceFlow id="sf4" sourceRef="holiday_management" targetRef="endEvent1"/>
    <sequenceFlow id="sf5" name="通过" sourceRef="gateway1" 
      targetRef="holiday_management">
      <conditionExpression xsi:type="tFormalExpression">
        <![CDATA[${task_领导审批_outcome=='agree'}]]></conditionExpression>
    </sequenceFlow>
    <sequenceFlow id="sf6" name="驳回" sourceRef="gateway1" targetRef="leave_apply">
      <conditionExpression xsi:type="tFormalExpression">
        <![CDATA[${task_领导审批_outcome=='disagree'}]]></conditionExpression>
    </sequenceFlow>
  </process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_qj">
    <bpmndi:BPMNPlane bpmnElement="qj" id="BPMNPlane_qj">
      <bpmndi:BPMNShape bpmnElement="startEvent1" id="BPMNShape_startEvent1">
        <omgdc:Bounds height="30.0" width="30.0" x="100.0" y="163.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="leave_apply" id="BPMNShape_leave_apply">
        <omgdc:Bounds height="80.0" width="100.0" x="175.0" y="138.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="leader_approval" id="BPMNShape_leader_approval">
        <omgdc:Bounds height="80.0" width="100.0" x="320.0" y="138.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="gateway1" id="BPMNShape_gateway1">
        <omgdc:Bounds height="40.0" width="40.0" x="465.0" y="158.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="holiday_management" id="BPMNShape_holiday_management">
        <omgdc:Bounds height="80.0" width="100.0" x="570.0" y="138.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="endEvent1" id="BPMNShape_endEvent1">
        <omgdc:Bounds height="28.0" width="28.0" x="715.0" y="164.0"/>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge bpmnElement="sf5" id="BPMNEdge_sf5">
        <omgdi:waypoint x="504.57089552238807" y="178.42910447761193"/>
        <omgdi:waypoint x="570.0" y="178.18587360594796"/>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="sf1" id="BPMNEdge_sf1">
        <omgdi:waypoint x="130.0" y="178.0"/>
        <omgdi:waypoint x="175.0" y="178.0"/>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="sf4" id="BPMNEdge_sf4">
        <omgdi:waypoint x="670.0" y="178.0"/>
        <omgdi:waypoint x="715.0" y="178.0"/>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="sf2" id="BPMNEdge_sf2">
        <omgdi:waypoint x="275.0" y="178.0"/>
        <omgdi:waypoint x="320.0" y="178.0"/>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="sf6" id="BPMNEdge_sf6">
        <omgdi:waypoint x="485.5" y="158.5"/>
        <omgdi:waypoint x="485.5" y="110.0"/>
        <omgdi:waypoint x="225.0" y="110.0"/>
        <omgdi:waypoint x="225.0" y="138.0"/>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="sf3" id="BPMNEdge_sf3">
        <omgdi:waypoint x="420.0" y="178.2164502164502"/>
        <omgdi:waypoint x="465.4130434782609" y="178.41304347826087"/>
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</definitions>

流程定义文件的根元素是definitions，该元素至少需要包含xmlns和targetNamespace两个属性，xmlns用于声明默认命名空间，targetNamespace用于声明目标命名空间。这些属性值通常表示为固定的URI。每个流程定义文件都必须要包含这些属性。此外，每个流程定义文件都包含BPMN业务流程和流程图形化展示两部分，分别对应根元素definitions的两个子元素：process和BPMNDiagram。

子元素process代表一个真正的业务流程定义。definitions可以包含多个process，不过建议只包含一个，以简化流程定义开发和维护的难度。process元素有3个属性：id、name和isExecutable。属性id是必填项，是业务流程的标识，用以启动一个流程实例；属性name用于定义业务流程名称；属性isExecutable用于定义流程是否可执行。

使用BPMN定义的元素都包含在process元素下，在上述请假流程示例的流程定义文件中，process元素包括1个开始事件（startEvent）、2个用户任务（userTask）、1个排他网关（exclusiveGateway）、1个服务任务（serviceTask）、1个结束事件（endEvent）和6个顺序流（sequenceFlow）。工作流引擎在执行业务流程时会读取这部分内容来获取业务流程规则。

BPMNDiagram定义了业务流程模型的布局，包括每个BPMN元素的位置和大小等信息。流程设计工具可以根据BPMNDiagram中的描述信息绘制可视化流程图，让用户直观地理解业务流程。

2.3.2 BPMN 2.0结构

在BPMN 2.0基本元素中，要重点掌握事件、活动、网关这3类流对象。它们是BPMN 2.0的核心结构，如图2.5所示。

图2.5　BPMN 2.0核心结构

1．事件

事件主要分为开始事件、中间事件、边界事件和结束事件。

开始事件是流程的起点，定义流程如何启动，以及显示的图标类型。在流程定义文件中，开始事件类型由子元素声明定义。根据不同的触发条件，可将开始事件分为不同类型，如表2.3所示。

表2.3　依触发条件划分的开始事件类型

结束事件标志着流程或子流程中其一个分支结束。结束事件总是抛出型事件。这意味着当流程执行到达结束事件时，会抛出一个结果，结果类型由事件内部自带的填充图标表示。在流程定义文件中，结束事件类型由子元素声明定义。根据不同的触发条件，可将结束事件分为不同类型，如表2.4所示。

表2.4　依触发条件划分的结束事件类型

开始事件和结束事件之间发生的事件统称为中间事件。中间事件会影响流程的流转路径，但不会启动或直接终止流程。按照其特性，中间事件可以分为中间捕获事件和中间抛出事件两类。当流程执行到中间捕获事件时，它会一直处于待触发状态，直到接收特定信息时被触发；当流程执行到中间抛出事件时，它会被自动触发并抛出相应的结果或者信息。中间事件类型如表2.5所示。

表2.5　中间事件类型

边界事件是一种特殊的中间事件，依附在活动上。边界事件永远不会抛出。这意味着当活动运行时，边界事件将监听特定类型的触发器。当工作流引擎捕获到边界事件时，会终止活动，并沿该事件的外出顺序流继续执行。根据不同的触发条件，可将边界事件分为不同类型，如表2.6所示。

表2.6　依触发条件划分的边界事件类型

2．活动

活动是业务流程定义的核心元素，是业务流程中执行的工作或任务的统称。在工作流中所有具备生命周期状态的元素可以称为“活动”。

活动既可以是流程的基本处理单元（如人工任务、服务任务等），也可以是组合单元（如调用活动、嵌套子流程等）。

活动表示为圆角矩形。活动类型如表2.7所示。

表2.7　活动类型

3．网关

网关用于控制顺序流在流程中的汇聚和发散。从其名称可以看出，它具备网关门控机制。网关与活动一样，能够使用或生成额外的令牌，可以有效控制给定流程的执行语义。两者的主要区别在于，网关不代表正在完成的“工作”，它对正在执行的流程的运行成本、时间等的影响为零。

网关可以定义所有类型的业务流程序列流行为，如决策/分支（独占、包含和复杂）、合并、分叉和加入等。网关表示为菱形，虽然菱形传统上用于表示排他性决策，但BPMN 2.0扩展了菱形行为，所有类型的网关都有一个内部指示器或标记来表明正在使用的网关类型。网关类型如表2.8所示。

表2.8　网关类型

上一章目录下一章