Flowable入门系列文章3 - 部署流程定义

我们将建立的过程是一个非常简单的请假过程。Flowable引擎期望过程在BPMN 2.0格式中定义，这是业界广泛接受的XML标准。在Flowable术语中，我们将这作为一个流程定义来说明。从流程定义中，可以启动许多流程实例。将流程定义视为许多执行过程的蓝图。在这种特殊情况下，流程定义定义了请假所涉及的不同步骤，而一个流程实例与特定员工的请假相匹配。

BPMN 2.0是以XML的形式存储的，但它也有一个可视化的部分：它以标准的方式定义了每个不同的步骤类型（一个人工任务，一个自动服务调用等）是如何表示的以及如何将这些不同的步骤连接到彼此。通过这个，BPMN 2.0标准允许技术和业务人员以双方理解的方式交流业务流程。
我们将使用的流程定义如下：

这个过程应该是不言而喻的，但是为了清楚起见，我们来描述不同的部分：

• 我们假设这个过程是通过提供一些信息来开始的，例如员工姓名，请求的假期数量和描述。当然，这可以作为这个过程中的第一步。但是，通过将其作为进程的输入数据，只有在发出真正的请求时才会创建进程实例。在另一种情况下，用户可以在提交之前改变主意并取消，但流程实例现在将在那里。在某些情况下，这可能是有价值的信息（例如，请求已启动多少次，但尚未完成），具体取决于业务目标。
• 左边的圆叫做开始事件。这是流程实例的起点。
• 第一个矩形是一个用户任务。这是人类用户必须执行的过程中的一个步骤。在这种情况下，经理需要批准或拒绝请求。
• 根据管理者的决定，排他网关（带十字的菱形）将流程实例路由到批准路径或拒绝路径。
• 如果获得批准，我们必须在某个外部系统中注册该请求，然后再为用户通知用户任务，通知他们该决定。这当然可以用电子邮件来代 替。
• 如果被拒绝，则会向员工发送电子邮件，通知他们这一点。

通常，这样的流程定义是使用可视化建模工具（例如Flowable Designer（Eclipse）或Flowable Modeler（Web应用程序））建模的。
但是，在这里，我们将直接编写XML来熟悉BPMN 2.0及其概念。
对应于上图的BPMN 2.0 XML如下所示。请注意，这只是过程的一部分。如果您使用的是图形建模工具，则底层的XML文件还包含描述图形信息的可视化部分，例如流程定义的各个元素的坐标（所有图形信息包含在XML 中的BPMNDiagram标记中，这是定义标记的子元素）。

将以下XML保存在src / main / resources文件夹中名为holiday-request.bpmn20.xml的文件中。

<definitions xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:flowable="http://flowable.org/bpmn" xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC" xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" expressionLanguage="http://www.w3.org/1999/XPath" targetNamespace="http://www.flowable.org/processdef" typeLanguage="http://www.w3.org/2001/XMLSchema" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL">
    <process name="Holiday Request" id="holidayRequest" isExecutable="true">
        <startEvent id="startEvent" />
        <sequenceFlow sourceRef="startEvent" targetRef="approveTask" />
        <userTask name="Approve or reject request" id="approveTask" />
        <sequenceFlow sourceRef="approveTask" targetRef="decision" />
        <exclusiveGateway id="decision" />
        <sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
            <conditionExpression xsi:type="tFormalExpression">
                
            conditionExpression>
        sequenceFlow>
        <sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
            <conditionExpression xsi:type="tFormalExpression">
                
            conditionExpression>
        sequenceFlow>
        <serviceTask name="Enter holidays in external system" id="externalSystemCall" flowable:class="org.flowable.CallExternalSystemDelegate" />
        <sequenceFlow sourceRef="externalSystemCall" targetRef="holidayApprovedTask" />
        <userTask name="Holiday approved" id="holidayApprovedTask" />
        <sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd" />
        <serviceTask name="Send out rejection email" id="sendRejectionMail" flowable:class="org.flowable.SendRejectionMail" />
        <sequenceFlow sourceRef="sendRejectionMail" targetRef="rejectEnd" />
        <endEvent id="approveEnd" />
        <endEvent id="rejectEnd" />
    process>
definitions>

第2到第11行看起来有点令人生畏，但几乎在每个流程定义中都会看到。这是一种样板文件，需要与BPMN 2.0标准规范完全兼容。

每一步（在BPMN 2.0术语中，活动）都有一个id属性，在XML文件中给它一个唯一的标识符。所有的活动也可以有一个可选的名字，当然这会增加可视化的可读性。
这些活动通过一个顺序流程来连接，这个顺序流程是视觉图中的一个指示箭头。执行流程实例时，执行流程将从开始事件流向下一个活动，顺序流程之后。

离开专用网关（带有X的钻石形状）的序列流显然是特殊的：都具有以表达式的形式定义的条件（参见第25行和第32行）。当流程实例执行到达此网关时，将评估条件并获取解析为true的第一个条件。这是独家代表在这里：只有一个被选中。当然，如果需要不同的路由行为，其他类型的网关也是可能的。

这里以表达式形式写出的条件是$ {approved}，它是$ {approved == true}的简写形式。批准的变量称为过程变量。甲过程变量是与过程实例存储在一起，并且可以在过程实例的生命周期过程中使用的数据的持久性位。在这种情况下，这意味着我们将不得不在流程实例中的某个点（当提交管理器用户任务时，或者在流程术语中完成）设置此流程变量，因为它不是可用流程实例启动。

现在我们有了BPMN 2.0 XML文件的流程，接下来我们需要将它部署到引擎中。部署流程定义意味着：

• 流程引擎会将XML文件存储在数据库中，因此可以在需要时进行检索
• 流程定义被解析为一个内部可执行的对象模型，以便流程实例可以从中启动。
  要将流程定义部署到Flowable引擎，使用了RepositoryService，可以从ProcessEngine对象中检索。使用RepositoryService，通过传递XML
  文件的位置并调用deploy（）方法来实际执行它，创建一个新的部署：

RepositoryService repositoryService = processEngine.getRepositoryService();
Deployment deployment = repositoryService.createDeployment()
.addClasspathResource("holiday-request.bpmn20.xml")
.deploy();

现在，我们可以通过API查询流程定义来确认流程定义是否已经被引擎所了解（并学习了一些API）。这是通过RepositoryService创建一个新的ProcessDefinitionQuery对象来完成的。

ProcessDefinition processDefinition = repositoryService.createProcessDefinitionQuery()
.deploymentId(deployment.getId())
.singleResult();
System.out.println("Found process definition : " + processDefinition.getName());

上面文章来自盘古BPM研究院：http://vue.pangubpm.com/
文章翻译提交：https://github.com/qiudaoke/flowable-userguide
了解更多文章可以关注微信公众号：