flowable工作流学习笔记

一级目录

二级目录

三级目录

什么是BPMN

BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由图形对象（graphical objects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flow controls）。
大白话理解：
BPMN是一套符号的标准，这些符号描述了如果做一个业务，并且这个业务在做的过程中被人监控和控制。业务人员和开发人员通过这套图形可以很好的完成协作。

Flowable简介

用flowable来创建一个工作流，设置流程中各个节点的操作，以及对应的之后的流程，这些都在xml文件中设定

Flowable是BPMN的一个基于java的软件实现，不过Flowable不仅仅包括BPMN，还有DMN决策表和CMMN Case管理引擎，并且有自己的用户管理、微服务API等一系列功能，是一个服务平台。

Activiti 中的 Start event（启动事件元素）介绍

启动事件元素就是启动流程实例的，也就是发起一个流程的，是流程的起点。它可以配置的很简单，也可以很复杂。

StartEvent：空启动事件。它的属性介绍如下：

Id: id 标识编号

Name: 名称

asynchronous:是否异步（默认否）表示是否能被异步执行。

exclusive: 是否排他（默认是）表示同一个流程实例在同一时刻只能由一个人执行该步骤, 跟asynchronous互斥。

initiator:定义一个变量来记录谁发起了该流程实例。

Form Key：与其关联的一个外部表单的名字，如果采用了外部表单的话。

Documentation：文档说明

Form properties：动态表单

在这里可以定义一个动态表单，下面是具体的属性介绍。

Id: 字段的主键，唯一标识

Name: 字段的名称

Type: 字段的类型 ，如 string 、long、enum（下拉选择）、date、boolean

Expression：表达式。可以通过计算表达式设置字段的值

Variable：将字段的值以Variable指定的变量名保存。

Default：字段的默认值

Date pattern：属性type为date时，需要设置此属性定义日期格式，例如：yyyy-MM-dd

Readable：是否可以读

Writable：是否可以写

Required：是否必填

Form values：当type为enum时有效。指定多个下拉选项值让其选择。

Activiti中的activiti:expression和activiti:delegateExpression有什么区别？

以serviceTask为例，delegateExpression是引用一个JavaDelegate实现bean，具体的操作在这个bean中定义；而expression则可以写成#{loggerHandler.log()} 这样的，表达式本身就是要做的操作。

会签和或签的概念

会签：指同一个审批节点设置多个人，如ABC三人，三人会同时收到审批，需全部同意之后，审批才可到下一审批节点；
或签：指同一个审批节点设置多个人，如ABC三人，三人会同时收到审批，只要其中任意一人审批即可到下一审批节点；

多实例实现会签功能

一个任务需要多个角色进行审批或者表决，根据这些审批结果来决定流程的走向。实现以上任务，activiti已经提供了支持，可以使用BPMN规范的多实例活动来实现。

Flowable-BPMN操作流程部署启动方案设计

BpmnModel bpmnModel = genBpmnModel(buildParam);
Deployment deploy = repositoryService.createDeployment().addBpmnModel(buildParam.getProcessKey() + “.bpmn20.xml”, bpmnModel).deploy();

先将传入的json格式的数据转换为bpmnModel，再把model放入仓库reposity

1.Flowable的流程部署通过仓库服务来完成部署，仓库服务的接口为RepositoryService。该接口通过创建DeploymentBuilder来完成部署
2.部署前我们编辑了一个普通的流程文件，需要加载下改文件来防止文件有错误，把文件转换为BPMNModel来校验，核心接口为BpmnXMLConverter，通过API接口convertToBpmnModel来实现xml到模型的转换
3.加载完成流程后，我们将流程启动，Flowable的启动接口为runtimeService，运行时服务调用startProcessInstanceByKey启动一个流程，并且返回流程对象ProcessInstance。该对象包含ID，后续我们将经常用到该ID。

flowable流程部署

部署流程的定义

要构建的流程是一个非常简单的请假流程。Flowable引擎需要流程定义为BPMN 2.0格式，这是一个业界广泛接受的XML标准。

在Flowable术语中，我们将其称为一个流程定义(process definition)。一个流程定义可以启动多个流程实例(process instance)。流程定义可以看做是重复执行流程的蓝图。 在这个例子中，流程定义定义了请假的各个步骤，而一个流程实例对应某个雇员提出的一个请假申请。

BPMN 2.0存储为XML，并包含可视化的部分：使用标准方式定义了每个步骤类型（人工任务，自动服务调用，等等）如何呈现，以及如何互相连接。这样BPMN 2.0标准使技术人员与业务人员能用双方都能理解的方式交流业务流程。

我们要使用的流程定义为：

bpmm配置文件详解

process: 流程定义根元素,代表了一个流程定义的开始,属性如下
属性名 含义
id 流程唯一id,启动流程时需要
isExecutable 流程是否可执行
name 流程名称
type 流程类型
isClosed 流程是否已关闭,关闭不能执行

startEvent: 流程启动事件,一个process只能有一个,且必须为流程起始元素

属性名 含义
id 启动节点id
name 启动节点名称

endEvent: 流程结束事件,一个process只能有一个,且必须为流程结束元素

属性名 含义
id 结束节点id
name 节点名称

userTask: 流程中间用户任务,夹在startEvent与endEvent之间的节点

属性名 含义
id 任务id,使用id操作任务
name 任务名称
activiti:assignee 任务所属用户,只能指定用户完成这个任务,即任务办理人
activiti:candidateUsers 多个任务办理人
activiti:candidateGroups 任务处理人候选组,处理人必须在这个组内
activiti:exclusive 独家的,好像是在排它性网关中使用,意思应该是在有并行分支情况下,只会走其中一条
activiti:dueDate 设置用户任务到期日期
activiti:priority 用户任务优先级,0-100

extensionElements: userTask的子元素,用于扩展元素

activiti:taskListener: 扩展元素之一,用于监听某个任务的运行

属性名 含义
event 监听的任务事件名,create、assignment（分配任务）、complete
class 任务监听器类,需要实现TaskListener

sequenceFlow: 顺序流分为两种：标准顺序流 条件顺序流,其实就是连接两个节点的一条线

属性名 含义
id 顺序流id
sourceRef 连线的起始节点id,即接近startEvent的节点
targetRef 连线结束节点id,即接近endEvent的节点

conditionExpression: sequenceFlow子元素,根据表达式确定是否执行这一顺序流,一条顺序流只能联系两个节点

属性名 含义
xsi:type 含义不知道,值为tFormalExpression
子元素 表达式,${days <= 3}
如果需要表达式判断,有多条顺序流连接了同一开始节点,一般这样的开始节点都是网关

exclusiveGateway: 排它性网关,即多个sequenceFlow以网关节点开始时,只根据条件执行其中一条流,其他流不再判断

虽然与userTask同属于节点,但是其不作为任务执行

属性名 含义
id 节点id
name 节点名称
gatewayDirection 网关方向,Unspecified

Execution和Task是一对多关系，Task可以是任何类型的Task实现，可以是用户任务（UserTask）、Java服务（ServiceTask）等，在实际流程运行中只不过面向对象不同，用户任务需要有人完成（complete），Java服务需要有系统自动执行（execution）。

事件（Event）：用来表明流程的生命周期中发生了什么。
活动（Activity）：活动（Activities）是业务流程定义的核心元素，中文称为“活动”、“节点”、“步骤”。一个活动可以是流程的基本处理单元（如人工任务、服务任务），也可以是一个组合单元（如外部子流程、嵌套子流程）。
网关（Gateway）：用来控制流程的流向。
流向/顺序流（Flow）：是连接两个流程节点的连线。

创建的表格说明

flowable命名规则：

ACT_RE_* ：’ RE ’表示repository（存储）。RepositoryService接口操作的表。带此前缀的表包含的是静态信息，如，流程定义，流程的资源（图片，规则等）。

ACT_RU_* ：’ RU ’表示runtime。这是运行时的表存储着流程变量，用户任务，变量，职责（job）等运行时的数据。flowable只存储实例执行期间的运行时数据，当流程实例结束时，将删除这些记录。这就保证了这些运行时的表小且快。

ACT_ID_* : ’ ID ’表示identity(组织机构)。这些表包含标识的信息，如用户，用户组，等等。

ACT_HI_* : ’ HI ’表示history。就是这些表包含着历史的相关数据，如结束的流程实例，变量，任务，等等。

ACT_GE_* : 普通数据，各种情况都使用的数据。

flowable各种表的说明

表分类 表名 表说明

一.工作流部署—RepositoryService

1.流程定义数据表：act_re_procdef

2.流程设计模型部署：act_re_model

3.部署信息表：act_re_deployment

二.工作流运行表—RuntimeService

1.运行时流程人员表：act_ru_identitylink

2.Event时间监听信息表：act_ru_event_subscr

3.运行时流程执行实例表：act_ru_execution

4.运行时定时任务数据表：act_ru_job

5.运行时任务节点表：act_ru_task

6.运行时流程变量数据表：act_ru_variable

三.工作流历史表 — HistoryService

1.历史节点表：act_hi_actinst 记录流程流转过的所有节点

2.历史任务实例表：act_hi_taskinst 只记录usertask内容

3.历史附件表：act_hi_attachment

4.历史意见表：act_hi_comment

5.历史详情表：act_hi_detail 流程中产生的变量详情

5.历史变量表：act_hi_varinst

四.工作流组织机构表 — IdentityService

1.用户信息表：act_id_user

2.用户扩展信息表：act_id_info

3.用户组信息表：act_id_group

4.用户与用户组对应信息表：act_id_membership

五.全局属性表

1.二进制数据表：act_ge_bytearray

2.全局属性：act_ge_property

请假流程的部署和实例化

1.部署流程定义

流程定义的说明：

我们假定启动流程需要提供一些信息，例如雇员名字、请假时长以及说明。当然，这些可以单独建模为流程中的第一步。 但是如果将它们作为流程的“输入信息”，就能保证只有在实际请求时才会建立一个流程实例。否则（将提交作为流程的第一步），用户可能在提交之前改变主意并取消，但流程实例已经创建了。 在某些场景中，就可能影响重要的指标（例如启动了多少申请，但还未完成），取决于业务目标。

左侧的圆圈叫做启动事件(start event)。这是一个流程实例的起点。

第一个矩形是一个用户任务(user task)。这是流程中人类用户操作的步骤。在这个例子中，经理需要批准或驳回申请。

取决于经理的决定，排他网关(exclusive gateway) (带叉的菱形)会将流程实例路由至批准或驳回路径。

如果批准，则需要将申请注册至某个外部系统，并跟着另一个用户任务，将经理的决定通知给申请人。当然也可以改为发送邮件。

如果驳回，则为雇员发送一封邮件通知他。

以下是与上面展示的流程图对应的BPMN 2.0 XML。即流程的xml文件这里只包含了“流程部分”。如果使用图形化建模工具，实际的XML文件还将包含“可视化部分”，用于描述图形信息，如流程定义中各个元素的坐标（所有的图形化信息包含在XML的BPMNDiagram标签中，作为definitions标签的子元素）。

下面展示一些 内联代码片。

<?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: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"
             xmlns:flowable="http://flowable.org/bpmn"
             typeLanguage="http://www.w3.org/2001/XMLSchema"
             expressionLanguage="http://www.w3.org/1999/XPath"
             targetNamespace="http://www.flowable.org/processdef">

    <process id="holiday-request" name="Holiday Request" isExecutable="true">
        <!--开始事件：流程实例的起点-->   <!--就是图里的圆圈-->
        <startEvent id="startEvent"/>
        <!--顺序流：执行时会从一个活动流向另一个活动--> <!--从圆圈指向第一步-->
        <sequenceFlow sourceRef="startEvent" targetRef="approveTask"/>

        <!--用户任务：需要人工来进行操作-->  <!--图片里的第一步-->  <!--将任务指派给经理组-->
        <userTask id="approveTask" name="Approve or reject request" flowable:candidateGroups="managers"/>
        <sequenceFlow sourceRef="approveTask" targetRef="decision"/>


        <!--排他网关-->
        <exclusiveGateway id="decision"/>


        <sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
            <!--顺序流条件：以表达式(expression)的形式定义了条件(condition) -->
            <conditionExpression xsi:type="tFormalExpression">
                <!--条件表达式：是${approved == true}的简写-->
                <![CDATA[
                  ${approved}
                ]]>
            </conditionExpression>
        </sequenceFlow>


        <sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
            <conditionExpression xsi:type="tFormalExpression">
                <!--条件表达式：是${approved ！= true}的简写-->
                <![CDATA[
                  ${!approved}
                ]]>
            </conditionExpression>
        </sequenceFlow>

        <!--服务任务，一个自动活动，它会调用一些服务-->
        <!--指派任务的时候要注意class路径上的类是写在org.flowable包里面的-->
        <serviceTask id="externalSystemCall" name="Enter holidays in external system" flowable:class="org.flowable.CallExternalSystemDelegate"/>
        <!--第二个用户任务指派给请假申请的提交人，，指派给请假审批的审批人，${employee}使用流程变量动态指派，在流程实例启动时传递-->
        <userTask id="holidayApprovedTask" name="Holiday Approve!"/>
        <sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd"/>

        <serviceTask id="sendRejectionMail" name="Send out rejection email" flowable:class="edu.hpu.process.SendRejectionMail"/>
        <sequenceFlow sourceRef="sendRejectionMail" targetRef="rejectEnd"/>

        <!--结束事件-->
        <endEvent id="approveEnd"/>
        <endEvent id="rejectEnd"/>
    </process>

</definitions>

每一个步骤（在BPMN 2.0术语中称作活动(activity)）都有一个id属性，为其提供一个在XML文件中唯一的标识符。所有的活动都可以设置一个名字，以提高流程图的可读性。

活动之间通过顺序流(sequence flow)连接，在流程图中是一个有向箭头。在执行流程实例时，执行(execution)会从启动事件沿着顺序流流向下一个活动。

离开排他网关(带有X的菱形)的顺序流很特别：都以表达式(expression)的形式定义了条件(condition) 。当流程实例的执行到达这个网关时，会计算条件，并使用第一个计算为true的顺序流。这就是排他的含义：只选择一个。当然如果需要不同的路由策略，可以使用其他类型的网关。

这里用作条件的表达式为approved，这是{approved == true}的简写。变量’approved’被称作流程变量(process variable)。流程变量是持久化的数据，与流程实例存储在一起，并可以在流程实例的生命周期中使用。在这个例子里，我们需要在特定的地方（当经理用户任务提交时，或者以Flowable的术语来说，完成(complete)时）设置这个流程变量，因为这不是流程实例启动时就能获取的数据。

将流程BPMN 2.0 XML文件部署(deploy)到引擎中

部署一个流程定义意味着：

流程引擎会将XML文件存储在数据库中，这样可以在需要的时候获取它。

流程定义转换为内部的、可执行的对象模型，这样使用它就可以启动流程实例。

将流程定义部署至Flowable引擎，需要使用RepositoryService，其可以从ProcessEngine对象获取。使用RepositoryService，可以通过XML文件的路径创建一个新的部署(Deployment)，并调用deploy()方法实际执行：

  //创建RepositoryService实例，通过processEngine获取RepositoryService
        //repositoryService主要用于管理流程部署的数据
        RepositoryService repositoryService=processEngine.getRepositoryService();
        //加载流程,到这里请假流程就存储在数据库里面了 createDeployment()创建新的部署
        Deployment deployment=repositoryService.createDeployment()
                .addClasspathResource("holiday-request.bpmn20.xml") //将xml文件中的流程存入
                .deploy();

2.启动流程实例（有流程定义才可以启动流程实例）

现在已经在流程引擎中部署了流程定义，因此可以使用这个流程定义作为“蓝图”启动流程实例。

要启动流程实例，需要提供一些初始化流程变量。一般来说，可以通过呈现给用户的表单，或者在流程由其他系统自动触发时通过REST API，来获取这些变量。在这个例子里，我们简化为使用java.util.Scanner类在命令行输入一些数据：

接下来，我们使用RuntimeService启动一个流程实例。收集的数据作为一个java.util.Map实例传递，其中的键就是之后用于获取变量的标识符。这个流程实例使用key启动(还有其它方式)。这个key就是BPMN 2.0 XML文件中设置的id属性，在这个例子里是holiday-request。
在流程实例启动后，会创建一个执行(execution)，并将其放在启动事件上。从这里开始，这个执行会沿着顺序流移动到经理审批的用户任务，并执行用户任务行为。这个行为将在数据库中创建一个任务，该任务可以之后使用查询找到。用户任务是一个等待状态(wait state)，引擎会停止执行，返回API调用处。

流程启动后，会有一个数据库事务从流程实例启动时持续到下一个等待状态。在这个例子里，指的是第一个用户任务。当引擎到达这个用户任务时，状态会持久化至数据库，提交事务，并返回API调用处。

在Flowable中，当一个流程实例运行时，总会有一个数据库事务从前一个等待状态持续到下一个等待状态。数据持久化之后，可能在数据库中保存很长时间，甚至几年，直到某个API调用使流程实例继续执行。请注意当流程处在等待状态时，不会消耗任何计算或内存资源，直到下一次APi调用。

在这个例子中，当第一个用户任务完成时，会启动一个数据库事务，从用户任务开始，经过排他网关（自动逻辑），直到第二个用户任务。或通过另一条路径直接到达结束。

/1、获取流程初始化变量
        Scanner scanner = new Scanner(System.in);

        System.out.println("Who are you?");
        String employee = scanner.nextLine();

        System.out.println("How many holidays do you want to request?");
        String nrOfHolidays = String.valueOf(scanner.nextLine());

        System.out.println("Why do you need them?");
        String description = scanner.nextLine();

        //RuntimeService则主要用于管理流程在运行时产生的数据(流程参数，事件，流程实例，以及执行流)以及对正在运行的流程进行操作的API
        RuntimeService runtimeService=processEngine.getRuntimeService();
        Map<String, Object> variables = new HashMap<String, Object>();
        variables.put("employee", employee);
        variables.put("nrOfHolidays", nrOfHolidays);
        variables.put("description", description);
        //这里的holiday-request就是在流程部署中导入的xml文件的process id
        ProcessInstance processInstance=runtimeService.startProcessInstanceByKey("holiday-request",variables);
        //一下子存入了三条数据在act_hi_varinst表中，输入的数据在text字段中的三条记录里

查询与完成任务

在更实际的应用中，会为雇员及经理提供用户界面，让他们可以登录并查看任务列表。其中可以看到作为流程变量存储的流程实例数据，并决定如何操作任务。在这个例子中，我们通过执行API调用来模拟任务列表，通常这些API都是由UI驱动的服务在后台调用的。

将第一个任务指派给"经理(managers)"组，而第二个用户任务指派给请假申请的提交人。

  <!--服务任务，一个自动活动，它会调用一些服务-->
        <!--指派任务的时候要注意class路径上的类是写在org.flowable包里面的-->
        <serviceTask id="externalSystemCall" name="Enter holidays in external system" flowable:class="org.flowable.CallExternalSystemDelegate"/>
        <!--第二个用户任务指派给请假申请的提交人，，指派给请假审批的审批人，${employee}使用流程变量动态指派，在流程实例启动时传递-->
        <userTask id="holidayApprovedTask" name="Holiday Approve! " flowable:assignee="${employee}"/>
        <sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd"/>

要获得实际的任务列表，需要通过TaskService创建一个TaskQuery。这个查询配置为只返回’managers’组的任务：

下面展示一些 内联代码片。

 //通过TaskService查询 manager 组的任务
        TaskService taskService=processEngine.getTaskService();
        List<Task> tasks=taskService.createTaskQuery().taskCandidateGroup("managers").list();
        System.out.println("You have " + tasks.size() + " tasks:");
        for (int i=0; i<tasks.size(); i++) {
            System.out.println((i+1) + ") " + tasks.get(i).getName());
        }

使用集合下标获取特定流程实例的变量,在控制台输出
        //使用集合下标获取特定流程实例的变量,在控制台输出
        System.out.println("Which task would you like to complete?");
        int taskIndex = Integer.valueOf(scanner.nextLine());
        Task task=tasks.get(taskIndex-1);
        Map<String,Object> processVariables=taskService.getVariables(task.getId());
        System.out.println(processVariables.get("employee") + " wants " +
                processVariables.get("nrOfHolidays") + " of holidays. Do you approve this?");

请假流程中使用到的表：

流程实例，活动实例，任务实例三者的关系

activity中几种对象的关系
一个流程中有多个实例，一个实例对应一个任务，一个流程对应多项任务，一个任务对应一个活动，一个流程对应多个活动

流程实例（ProcessInstance），通过runtimeService.startProcessInstance()来获得，就是有人来使用请假流程来申请请假了
会创建一条数据到ACT_RU_EXECUTION表，同时也会根据history的级别决定是否查询相同的历史数据到ACT_HI_PROCINST表。

业务和流程之间的关系

使用activiti自带表act_ru_execution中的BUSINESS_KEY字段我存在业务的唯一表示
在流程创建的时候可以传入，不传入的话默认为空

启动流程是第二个参数就是表act_ru_execution中的BUSINESS_KEY字段，我一般喜欢使用业务名+ id来存储当前业务，查询当前任务详情是，获得当前的task,通过task获得当前流程，通过当前流程获取当前流程的业务id，从而获得业务详情，如图所示：

启动流程和业务关联区别：

对于自定义表单来说启动的时候会传入businessKey作为业务和流程的关联属性
对于动态表单来说不需要使用businessKey关联，因为所有的数据都保存在引擎的表中
对于外部表单来说businessKey是可选的，但是一般不会为空，和自定义表单类似

用Java来讲： ProcessDefinition就是代码中的一个类，而ProcessInstance就是把这个类new了出来，创建了一个实例；

一个Process Instance（流程实例）是一个ProcessDefinition（流程定义）的执行；

一个Process Instance（流程实例）可以有许多同时执行的步骤（concurrent executions）

执行步骤组成了以ProcessIntance（流程实例）为根节点（root）的结构化树

有时execution id和流程实例id是不同的 ，当一个节点中使用了定时器，execution id中就会使用额外的后缀， 这就会导致当我们通过execution id查询时，这个节点不会出现在结果列表中。

实际操作下来也是如此：

刚开始的时候，ExectionId与ProcessId是相同的；
如果流程执行中，每时刻只有一个步骤（是否可以说任务）在处理，则ExectionId和ProcessId是相同的，
但是当同一时刻有多个任务要处理，譬如上述的定时器、或者进入fork/join流程，这个时候ExectionId和ProcessId就不同。
可以理解为Execution为执行路径，当同时有几个路径在执行，ExecutionId就和ProcessId不同了

当流程中没有分支时，Execution等同于ProcessInstance，甚至连ID也相同；
当流程中存在分支(fork, parallel gateway)，则在分支口会形成子Execution，在下一个gateway才会合并(joined)

子流程是15008，父流程是15004
而在act_ru_task 表中

15008是当前流程，15004是定义流程，即已经执行到子流程了

一个流程实例对应某个雇员提出的一个请假申请

举一个子流程的例子

例如一个购物流程中除了下单、出库节点之外可能还有一个付款子流程，在实际企业应用中付款流程通常是作为公用的，所以使用子流程作为主流程（购物流程）的一部分。

当任务到达子流程时引擎会自动创建一个付款流程，但是这个流程有一个特殊的地方，在数据库可以直观体现，如下图。

图3 ID_和PROC_INST_ID_不相等

上图中有两条数据，第二条数据（嵌入的子流程）的PARENT_ID_等于第一条数据的ID_和PROC_INST_ID_，并且两条数据的PROC_INST_ID_相同。

上图还有一点特殊的地方，字段IS_ACTIVE_的值一个是0一个是1，说明正在执行子流程主流程挂起。

bpmn中每一个步骤，包括各种启动事件，用户任务，网关，连线，都是一个activity，记录在act_hi_actinst表中(历史节点信息表)

或者说是节点

用户任务（usertask）是一个等待状态(wait state)，引擎会停止执行，返回API调用处。

taskService获取当前的usertask

抄送

BpmnModel

BpmnModel对象，是activiti动态部署中很重要的一个对象，如果BpmnModel对象不能深入的理解，那可能如果自己需要开发一套流程设计器，使用bpmn-js使用前端或者C/S展现流程流转而不是使用工作流引擎，就显得力不从心

ativiti监听器

activiti使用的时候，通常需要跟业务紧密的结合在一起，有些业务非常的复杂，通常有如下一些场景：

1.activiti人员动态的分配。

2.当前任务节点完成的时候，指定需要指定下一个节点的处理人(比如，一个请假流程，a员工请假，需要指定下一步需要处理请假流程的领导。)。

3.任务节点完成的时候，需要一些复杂业务，(比如当前节点完成的时候，需要调用我们的jms消息系统发送消息)。

4.任务流转到当前的节点的时候，需要监控当前任务节点的一些信息或者其他的业务信息。

5.当前的任务节点分配处理人的时候，需要触发自定义的一些业务。

6.流程开始结束的时候，需要处理业务信息。

7.经过任务节点的出线，也就是连线的时候，需要触发自定义的业务。

那我们怎么实现以上的这些需求呢？这个时候，我们就需要使用activiti监听器

部署id和流程id的区别

有可能一个流程只构建了一半，然后用户保存了，那这流程就还未部署，只有流程id没有部署id。

工作流中的脚本

活动：包括用户任务（User Task），脚本任务（Script Task），服务任务（Java Service Task）
用户任务（User Task）：即用户操作的任务（用户可以是：人，角色，组织）
脚本任务（Script Task）：脚本任务是一个自动化活动。当一个流程执行到达脚本任务时，执行被选择的脚本。

工作流 bpmn和cmmn的区别

CMMN和BPMN都描述了业务流程中的活动。 这些标准之间的主要区别是：

1、BPMN采用绑定方法。 它提供了活动的确切顺序。 提供自由度比较困难。比如加个节点、任意跳转就很麻烦。
2、CMMN采用非约束性方法，然后增加了限制。 建立排序比较困难。

CMMN

Case Management Model and Notation，CMMN是一种图形化的符号，用于捕获工作方法，这些工作方法基于处理需要各种活动的情况，这些活动可能以不可预测的顺序执行，以响应不断变化的情况。通过使用以事件为中心的方法和案例文件的概念，CMMN扩展了可以用BPMN建模的边界，包括结构化程度较低的工作和由知识工人驱动的工作。结合使用BPMN和CMMN，用户可以涵盖更广泛的工作方法。