Flowable学习笔记（二、BPMN 2

PT4H

4.1.3.2、错误边界事件

• 描述

在活动边界上的错误捕获中间（事件），或简称错误边界事件（error boundary event），捕获其所依附的活动范围内抛出的错误。

在嵌入式子流程或者调用活动上定义错误边界事件最有意义，因为子流程的范围会包括其中的所有活动。错误可以由错误结束事件抛出。这样的错误会逐层向其上级父范围传播，直到在范围内找到一个匹配错误事件定义的错误边界事件。

当捕获错误事件时，会销毁边界事件定义所在的活动，同时销毁其中所有的当前执行（例如，并行活动，嵌套子流程，等等）。流程执行将沿着边界事件的出口顺序流继续。

• 图示：

错误边界事件用内部有一个错误图标的标准中间事件（两层圆圈）表示。错误图标是白色的，代表捕获的含义。

• xml表示：

错误边界事件与标准边界事件一样定义：

4.1.3.3、信号边界事件

• 描述:

依附在活动边界上的信号捕获中间（事件），或简称信号边界事件（signal boundary event），捕获与其信号定义具有相同名称的信号。

与其他事件例如错误边界事件不同的是，信号边界事件不只是捕获其所依附范围抛出的信号。信号边界事件为全局范围（广播）的，意味着信号可以从任何地方抛出，甚至可以是不同的流程实例。

• 图示：

信号边界事件，用内部有一个信号图标的标准中间事件（两层圆圈）表示。信号图标是白色的，代表捕获的含义。

• xml表示：

信号边界事件与标准边界事件一样定义：

4.1.3.4、消息边界事件

• 描述：

在活动边界上的消息捕获中间（事件），或简称消息边界事件（message boundary event），捕获与其消息定义具有相同消息名的消息。

• 图示：

消息边界事件，用内部有一个消息图标的标准中间事件（两层圆圈）表示。信号图标是白色的，代表捕获的含义。

息边界事件既可以是中断型的（右图），也可以是非中断型的（左图）。

• XML表示：

消息边界事件与标准边界事件一样定义：

4.1.3.5、取消边界事件

• 描述

依附在事务子流程边界上的取消捕获中间事件，或简称取消边界事件（cancel boundary event），在事务取消时触发。当取消边界事件触发时，首先会中断当前范围的所有活动执行。接下来，启动事务范围内所有有效的的补偿边界事件（compensation boundary event）。补偿会同步执行，也就是说在离开事务前，边界事件会等待补偿完成。当补偿完成时，沿取消边界事件的任何出口顺序流离开事务子流程。

>>> 一个事务子流程只允许使用一个取消边界事件。

>>> 如果事务子流程中有嵌套的子流程，只会对成功完成的子流程触发补偿。

>>> 如果取消边界事件放置在具有多实例特性的事务子流程上，如果一个实例触发了取消，则边界事件将取消所有实例。

• 图示：

取消边界事件，用内部有一个取消图标的标准中间事件（两层圆圈）表示。取消图标是白色的（未填充），代表捕获的含义。

• xml表示：

取消边界事件与标准边界事件一样定义：

4.1.3.6、补偿边界事件

• 描述：

依附在活动边界上的补偿捕获中间（事件），或简称补偿边界事件（compensation boundary event），可以为活动附加补偿处理器。

补偿边界事件必须使用直接关联的方式引用单个的补偿处理器。

补偿边界事件与其它边界事件的活动策略不同。其它边界事件，例如信号边界事件，在其依附的活动启动时激活；当该活动结束时会被解除，并取消相应的事件订阅。而补偿边界事件不是这样。补偿边界事件在其依附的活动成功完成时激活，同时创建补偿事件的相应订阅。当补偿事件被触发，或者相应的流程实例结束时，才会移除订阅。请考虑下列因素：

>>> 当补偿被触发时，会调用补偿边界事件关联的补偿处理器。调用次数与其依附的活动成功完成的次数相同。

>>>如果补偿边界事件依附在具有多实例特性的活动上，则会为每一个实例创建补偿事件订阅。

>>> 如果补偿边界事件依附在位于循环内部的活动上，则每次该活动执行时，都会创建一个补偿事件订阅。

>>> 如果流程实例结束，则取消补偿事件的订阅。

• 图示：

补偿边界事件，用内部有一个补偿图标的标准中间事件（两层圆圈）表示。补偿图标是白色的（未填充），代表捕获的含义。另外，补偿边界事件使用单向连接关联补偿处理器，如下图所示：

• xml表示：

补偿边界事件与标准边界事件一样定义：

<association associationDirection=“One” id=“a1”

sourceRef=“compensateBookHotelEvt” targetRef=“undoBookHotel” />

4.1.4、中间事件

在开始事件和结束事件之间发生的事件都称为中间事件。中间事件会影响流程的流转路线，但不会启动或直接终止流程的执行。

中间事件按照其特性可以分为两类：中间Catching(捕获)事件和中间Throwing(抛出)事件，当流程到达中间Catching事件时，它会一直在等待被触发，直接接收到的信息，才会被触发，而当流程到达中间Throwing事件时，该事件会自动被触发并抛出相应的结果或者信息。

4.1.4.1、捕获中间事件

所有的捕获中间事件（intermediate catching events）都使用相同方式定义：

捕获中间事件由下列元素定义:

• （流程范围内）唯一的标识符

• 定义了捕获中间事件类型的，形如XXXEventDefinition的XML子元素（例如TimerEventDefinition等）。查阅特定中间捕获事件类型，以了解更多细节。

4.1.4.1.1、定时器捕获中间事件

• 描述：

定时器捕获中间事件（timer intermediate catching event）的行为像是跑表。当执行到达捕获事件时，启动定时器；当定时器触发时（例如在一段时间间隔后），沿定时器中间事件的出口顺序流继续执行。

• 图示：

定时器中间事件用内部有定时器图标的中间捕获事件表示。

• XML表示：

定时器中间事件与捕获中间事件一样定义。子元素为timerEventDefinition。

PT5M

4.1.4.1.2、信号捕获中间事件

• 描述：

信号捕获中间事件（signal intermediate catching event），捕获与其引用的信号定义具有相同信号名称的信号。

>>> 与其他事件如错误事件不同，信号在被捕获后不会被消耗。如果有两个激活的信号中间事件，捕获相同的信号事件，则两个中间事件都会被触发，哪怕它们不在同一个流程实例里。

• 图示：

信号捕获中间事件用内部有信号图标的标准中间事件（两层圆圈）表示。信号图标是白色的（未填充），代表捕获的含义。

• xml表示：

信号中间事件与捕获中间事件一样定义。子元素为signalEventDefinition。

4.1.4.1.3、信号捕获中间事件

• 描述：

消息捕获中间事件（message intermediate catching event），捕获特定名字的消息。

• 图示：

消息捕获中间事件用内部有消息图标的标准中间事件（两层圆圈）表示。消息图标是白色的（未填充），代表捕获的含义。

• xml表示：

消息中间事件与捕获中间事件一样定义。子元素为messageEventDefinition。

4.1.4.2、抛出中间事件

所有的抛出中间事件（intermediate throwing evnet）都使用相同方式定义：

抛出中间事件由下列元素定义:

• （流程范围内）唯一的标识符

• 定义了抛出中间事件类型的，形如XXXEventDefinition的XML子元素（例如signalEventDefinition等）。查阅特定中间抛出事件类型，以了解更多细节。

4.1.4.2.1、空抛出中间事件

下面的流程图展示了空抛出中间事件（intermediate throwing none event）的简单例子。其用于指示流程已经到达了某种状态。

添加一个执行监听器后，空中间事件就可以成为很好的监视某些KPI（Key Performance Indicators 关键绩效指标）的钩子。

<flowable:executionListener class=“org.flowable.engine.test.bpmn.event.IntermediateNoneEventTest$MyExecutionListener” event=“start” />

4.1.4.2.2、信号抛出中间事件

• 描述：

信号抛出中间事件（signal intermediate throwing event），抛出所定义信号的信号事件。

在Flowable中，信号会广播至所有的激活的处理器（也就是说，所有的信号捕获事件）。可以同步或异步地发布信号。

• • 在默认配置中，信号同步地传递。这意味着抛出信号的流程实例会等待，直到信号传递至所有的捕获信号的流程实例。所有的捕获流程实例也会在与抛出流程实例相同的事务中，也就是说如果收到通知的流程实例中，有一个实例产生了技术错误（抛出异常），则所有相关的实例都会失败。
• • 信号也可以异步地传递。这是由到达抛出信号事件时的发送处理器来决定的。对于每个激活的处理器，JobExecutor会为其存储并传递一个异步通知消息(asynchronous notification message),即作业（Job）。

• 图示：

消息抛出中间事件用内部有信号图标的标准中间事件（两层圆圈）表示。信号图标是黑色的（已填充），代表抛出的含义。

• xml表示：

信号中间事件与抛出中间事件一样定义。子元素为signalEventDefinition。

异步信号事件这样定义：

4.1.4.2.3、补偿抛出中间事件

• 描述：

补偿抛出中间事件（compensation intermediate throwing event）用于触发补偿。

触发补偿：既可以为设计的活动触发补偿，也可以为补偿事件所在的范围触发补偿。补偿由活动所关联的补偿处理器执行。

• • 活动抛出补偿时，活动关联的补偿处理器将执行的次数，为活动成功完成的次数。
• • 抛出补偿时，当前范围中所有的活动，包括并行分支上的活动都会被补偿。
• • 补偿分层触发：如果将要被补偿的活动是一个子流程，则该子流程中所有的活动都会触发补偿。如果该子流程有嵌套的活动，则会递归地抛出补偿。然而，补偿不会传播至流程的上层：如果子流程中触发了补偿，该补偿不会传播至子流程范围外的活动。BPMN规范指出，对“与子流程在相同级别”的活动触发补偿。
• • 在Flowable中，补偿按照执行的相反顺序运行。这意味着最后完成的活动会第一个补偿。
• • 可以使用补偿抛出中间事件补偿已经成功完成的事务子流程。

>>> 如果抛出补偿的范围中有一个子流程，而该子流程包含有关联了补偿处理器的活动，则当抛出补偿时，只有该子流程成功完成时，补偿才会传播至该子流程。如果子流程内嵌套的部分活动已经完成，并附加了补偿处理器，但包含这些活动的子流程还没有完成，则这些补偿处理器仍不会执行。参考下面的例子：

在这个流程中，有两个并行的执行：一个执行嵌入子流程，另一个执行“charge credit card（信用卡付款）”活动。假定两个执行都已开始，且第一个执行正等待用户完成“review bookings（检查预定）”任务。第二个执行进行了“charge credit card（信用卡付款）”活动的操作，抛出了错误，导致“cancel reservations（取消预订）”事件触发补偿。这时并行子流程还未完成，意味着补偿不会传播至该子流程，因此不会执行“cancel hotel reservation（取消酒店预订）”补偿处理器。而如果“cancel reservations（取消预订）”运行前，这个用户任务（因此该嵌入式子流程也）已经完成，则补偿会传播至该嵌入式子流程。

流程变量：当补偿嵌入式子流程时，用于执行补偿处理器的执行，可以访问子流程的局部流程变量在子流程完成时的值。为此，会对范围执行（为执行子流程所创建的执行）所关联的流程变量进行快照。意味着：

• • 补偿执行器无法访问子流程范围内并行执行所添加的变量。
• • 上层执行所关联的流程变量（例如流程实例关联的流程变量）不在该快照中。因为补偿处理器可以直接访问这些流程变量在抛出补偿时的值。
• • 只会为嵌入式子流程进行变量快照。其他活动不会进行变量快照。

目前的限制：

• • 目前不支持waitForCompletion=“false”。当补偿抛出中间事件触发补偿时，只有在补偿成功完成时，才会离开该事件。
• • 补偿由并行执行运行。并行执行会按照补偿活动完成的逆序启动。
• • 补偿不会传播至调用活动（call activity）生成的子流程。

• 图示：

补偿抛出中间事件用内部有补偿图标的标准中间事件（两层圆圈）表示。补偿图标是黑色的（已填充），代表抛出的含义。

• xml表示：

补偿中间事件与抛出中间事件一样定义。子元素为compensateEventDefinition。

另外，activityRef可选项用于为指定的范围或活动触发补偿：

4.2、顺序流

---

• 描述：

顺序流（sequence flow）是流程中两个元素间的连接器。在流程执行过程中，一个元素被访问后，会沿着其所有出口顺序流继续执行。这意味着BPMN 2.0的默认是并行执行的：两个出口顺序流就会创建两个独立的、并行的执行路径。

• 图示：

顺序流，用从源元素指向目标元素的箭头表示。箭头总是指向目标元素。

• xml表示：

顺序流需要有流程唯一的id，并引用存在的源与目标元素。

4.2.1、条件顺序流

• 描述：

在顺序流上可以定义条件（conditional sequence flow）。当离开BPMN 2.0活动时，默认行为是计算其每个出口顺序流上的条件。当条件计算为true时，选择该出口顺序流。如果该方法选择了多条顺序流，则会生成多个执行，流程会以并行方式继

需要文中资料的朋友，可以加我\/信获取：vip1024b 备注Java

续。

>>> 上面的介绍针对BPMN 2.0活动（与事件），但不适用于网关（gateway）。不同类型的网关，会用不同的方式处理带有条件的顺序流。

• 图示：

条件顺序流用起点带有小菱形的顺序流表示。在顺序流旁显示条件表达式。

• xml表示：

条件顺序流的XML表示格式为含有conditionExpression（条件表达式）子元素的普通顺序流。请注意目前只支持tFormalExpressions。可以省略xsi:type=""定义，默认为唯一支持的表达式类型。

<![CDATA[${order.price > 100 && order.price < 250}]]>

>>> 目前conditionalExpressions只能使用UEL。使用的表达式需要能解析为boolean值，否则当计算条件时会抛出异常。

• 下面的例子，通过典型的JavaBean的方式，使用getter引用流程变量的数据。

<![CDATA[${order.price > 100 && order.price < 250}]]>

• 这个例子调用了一个解析为boolean值的方法。

<![CDATA[${order.isStandardOrder()}]]>

Flowable发行版中包含了下列示例流程，用于展示值表达式与方法表达式的使用。

4.2.2、默认顺序流

• 描述：

所有的BPMN 2.0任务与网关都可以使用默认顺序流（default sequence flow）。只有当没有其他顺序流可以选择时，才会选择默认顺序流作为活动的出口顺序流。流程会忽略默认顺序流上的条件。

• 图示：

默认顺序流用起点带有“斜线”标记的一般顺序流表示。

• XML表示：

活动的默认顺序流由该活动的default属性定义。下面的XML片段展示了一个排他网关（exclusive gateway），带有默认顺序流flow 2。只有当conditionA与conditionB都计算为false时，才会选择默认顺序流作为网关的出口顺序流。

${conditionA}

${conditionB}

对应下面的图示：

4.3、网关

---

网关（gateway）用于控制执行的流向（或者按BPMN 2.0的用词：执行的“标志（token）”）。网关可以消费（consuming）与生成（generating）标志。

网关用其中带有图标的菱形表示。该图标显示了网关的类型。

这里出口顺序流的含义与BPMN 2.0中的一般情况不一样。一般情况下，会选择所有条件计算为true的顺序流，并行执行。而使用排他网关时，只会选择一条顺序流。当多条顺序流的条件都计算为true时，会且仅会选择在XML中最先定义的顺序流继续流程。如果没有可选的顺序流，会抛出异常。

4.3.1、排他网关

• 描述：

排他网关（exclusive gateway）（也叫异或网关 XOR gateway，或者更专业的，基于数据的排他网关 exclusive data-based gateway），用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为true的顺序流（当没有设置条件时，认为顺序流为true）继续流程。

• 图示：

排他网关用内部带有’X’图标的标准网关（菱形）表示，'X’图标代表异或的含义。请注意内部没有图标的网关默认为排他网关。BPMN 2.0规范不允许在同一个流程中混合使用有及没有X的菱形标志。

• xml表示：

排他网关的XML表示格式很简洁：一行定义网关的XML。条件表达式定义在其出口顺序流上。

以下面的模型为例：

其xml表示如下：

${input == 1}

${input == 2}

${input == 3}

4.3.2、并行网关

• 描述：

网关也可以建模流程中的并行执行。在流程模型中引入并行的最简单的网关，就是并行网关（parallel gateway）。它可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行。

并行网关的功能取决于其入口与出口顺序流：

• • 分支：所有的出口顺序流都并行执行，为每一条顺序流创建一个并行执行。
• • 合并：所有到达并行网关的并行执行都会在网关处等待，直到每一条入口顺序流都到达了有个执行。然后流程经过该合并网关继续。

>>> 如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。

与其他网关类型有一个重要区别：并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。

• 图示：

并行网关，用内部带有’加号’图标的网关（菱形）表示，代表与（AND）的含义。

• xml表示：

定义并行网关只需要一行XML：

实际行为（分支，合并或两者皆有），由连接到该并行网关的顺序流定义。

例如，上面的模型表示为下面的XML：

在上面的例子中，当流程启动后会创建两个任务：

ProcessInstance pi = runtimeService.startProcessInstanceByKey(“forkJoin”);

TaskQuery query = taskService.createTaskQuery()

.processInstanceId(pi.getId())

.orderByTaskName()

.asc();

List tasks = query.list();

assertEquals(2, tasks.size());

Task task1 = tasks.get(0);

assertEquals(“Receive Payment”, task1.getName());

Task task2 = tasks.get(1);

assertEquals(“Ship Order”, task2.getName());

当这两个任务完成后，第二个并行网关会合并这两个执行。由于它只有一条出口顺序流，因此就不会再创建并行执行路径，而只是激活Archive Order(存档订单)任务。

并行网关不需要“平衡”（也就是说，前后对应的两个并行网关，其入口/出口顺序流的数量不需要一致）。每个并行网关都会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，而不受流程模型中的其他结构影响。因此，下面的流程在BPMN 2.0中是合法的：

4.3.3、包容网关

• 描述：

可以把包容网关（inclusive gateway）看做排他网关与并行网关的组合。与排他网关一样，可以在包容网关的出口顺序流上定义条件，包容网关会计算条件。然而主要的区别是，包容网关与并行网关一样，可以同时选择多于一条出口顺序流。

包容网关的功能取决于其入口与出口顺序流：

• • 分支：流程会计算所有出口顺序流的条件。对于每一条计算为true的顺序流，流程都会创建一个并行执行。
• • 合并：所有到达包容网关的并行执行，都会在网关处等待。直到每一条具有流程标志（process token）的入口顺序流，都有一个执行到达。这是与并行网关的重要区别。换句话说，**包容网关只会等待可以被执行的入口顺序流。**在合并后，流程穿过合并并行网关继续。

>>> 如果包容网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有具有流程标志的入口顺序流，然后为每一个条件计算为true的出口顺序流分裂出并行执行路径。

包容网关的汇聚行为比并行网关更复杂。所有到达包容网关的并行执行，都会在网关等待，直到所有“可以到达”包容网关的执行都“到达”包容网关。 判断方法为：计算当前流程实例中的所有执行，检查从其位置是否有一条到达包容网关的路径（忽略顺序流上的任何条件）。如果存在这样的执行（可到达但尚未到达），则不会触发包容网关的汇聚行为。

• xml表示：

定义包容网关需要一行XML：

实际行为（分支，合并或两者皆有），由连接到该包容网关的顺序流定义。

例如，上面的模型表现为下面的XML：

${paymentReceived == false}

${shipOrder == true}

在上面的例子中，当流程启动后，如果流程变量paymentReceived == false且shipOrder == true，会创建两个任务。如果只有一个流程变量等于true，则只会创建一个任务。如果没有条件计算为true，会抛出异常（可通过指定默出口顺序流避免）。在下面的例子中，只会创建ship order（传递订单）一个任务：

HashMap<String, Object> variableMap = new HashMap<String, Object>();

variableMap.put(“receivedPayment”, true);

variableMap.put(“shipOrder”, true);

ProcessInstance pi = runtimeService.startProcessInstanceByKey(“forkJoin”);

TaskQuery query = taskService.createTaskQuery()

.processInstanceId(pi.getId())

.orderByTaskName()

.asc();

List tasks = query.list();

assertEquals(1, tasks.size());

Task task = tasks.get(0);

assertEquals(“Ship Order”, task.getName());

当这个任务完成后，第二个包容网关会合并这两个执行。并且由于它只有一条出口顺序流，所有不会再创建并行执行路径，而只会激活Archive Order(存档订单)任务。

>>> 包容网关不需要“平衡”（也就是说，对应的包容网关，其入口/出口顺序流的数量不需要匹配）。包容网关会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。

>>> 包容网关不需要“平衡”（也就是说，前后对应的两个包容网关，其入口/出口顺序流的数量不需要一致）。每个包容网关都会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。

4.3.4、 基于事件的网关

• 描述：

基于事件的网关（event-based gateway）提供了根据事件做选择的方式。网关的每一条出口顺序流都需要连接至一个捕获中间事件。当流程执行到达基于事件的网关时，与等待状态类似，网关会暂停执行，并且为每一条出口顺序流创建一个事件订阅。

>>> 基于事件的网关的出口顺序流与一般的顺序流不同。这些顺序流从不实际执行。相反，它们用于告知流程引擎：当执行到达一个基于事件的网关时，需要订阅什么事件。有以下限制：

• • 一个基于事件的网关，必须有两条或更多的出口顺序流。
• • 基于事件的网关，只能连接至intermediateCatchEvent（捕获中间事件）类型的元素（Flowable不支持在基于事件的网关之后连接“接收任务 Receive Task”）。
• • 连接至基于事件的网关的intermediateCatchEvent，必须只有一个入口顺序流。

• 图示：

基于事件的网关，用内部带有特殊图标的网关（菱形）表示。

• xml表示：

用于定义基于事件的网关的XML元素为eventBasedGateway。

• 示例：

下面是一个带有基于事件的网关的示例流程。当执行到达基于事件的网关时，流程执行暂停。流程实例订阅alert信号事件，并创建一个10分钟后触发的定时器。流程引擎会等待10分钟，并同时等待信号事件。如果信号在10分钟内触发，则会取消定时器，流程沿着信号继续执行，激活Handle alert用户任务。如果10分钟内没有触发信号，则会继续执行，并取消信号订阅。

<definitions id=“definitions”

xmlns=“http://www.omg.org/spec/BPMN/20100524/MODEL”

xmlns:flowable=“http://flowable.org/bpmn”

targetNamespace=“Examples”>

PT10M

4.4、任务

---

一个任务表示工作需要被外部实体完成， 比如人工或自动服务。

任务被描绘成一个圆角矩形，一般内部包含文字。 任务的类型（用户任务，服务任务，脚本任务，等等）显示在矩形的左上角，用小图标区别。 根据任务的类型， 引擎会执行不同的功能。

4.4.1、用户任务

• 描述：

“用户任务（user task）”，也叫人工任务，见名知意，是用于对需要人工执行的任务进行建模。当流程执行到达用户任务时，会为指派至该任务的用户或组的任务列表创建一个新任务。

• 图示：

用户任务用左上角有一个小用户图标的标准任务（圆角矩形）表示。

• xml表示：

用户任务在XML中如下定义。其中id是必须属性，name是可选属性。

也可以为用户任务添加描述（description）。事实上任何BPMN 2.0元素都可以有描述。描述由documentation元素定义。

Schedule an engineering meeting for next week with the new hire.

• 到期日期

每个任务都可以使用一个字段标志该任务的到期日期（due date）。可以使用查询API，查询在给定日期前或后到期的任务。

可以在任务定义中使用扩展指定表达式，以在任务创建时设定到期日期。该表达式必须解析为java.util.Date，java.util.String (ISO8601格式)，ISO8601时间长度（例如PT50M），或者null。例如，可以使用在流程里前一个表单中输入的日期，或者由前一个服务任务计算出的日期。如果使用的是时间长度，则到期日期基于当前时间加上给定长度计算。例如当dueDate使用“PT30M”时，任务在从现在起30分钟后到期。

任务的到期日期也可以使用TaskService，或者在TaskListener中使用传递的DelegateTask修改。

• 用户指派：

用户任务可以直接指派（assign）给用户。可以定义humanPerformer子元素来实现。humanPerformer需要resourceAssignmentExpression来实际定义用户。目前，只支持formalExpressions。

…

kermit

只能指定一个用户作为任务的humanPerformer。在Flowable术语中，这个用户被称作办理人（assignee）。拥有办理人的任务，在其他人的任务列表中不可见，而只能在该办理人的个人任务列表中看到。

可以通过TaskService获取特定用户办理的任务：

List tasks = taskService.createTaskQuery().taskAssignee(“kermit”).list();

任务也可以放在用户的候选任务列表中。在这个情况下，需要使用potentialOwner（潜在用户）结构。用法与humanPerformer结构类似。请注意需要指定表达式中的每一个元素为用户还是组（引擎无法自行判断）。

…

user(kermit), group(management)

可用如下方法获取定义了potentialOwner结构的任务：

List tasks = taskService.createTaskQuery().taskCandidateUser(“kermit”);

将获取所有kermit作为候选用户的任务，也就是说，表达式含有user(kermit)的任务。同时也将获取所有指派给kermit为其成员的组的任务（例如，kermit时management组的成员，且任务指派给management组）。组在运行时解析，并可通过身份服务管理。

如果并未指定给定字符串是用户还是组，引擎默认其为组。下列代码与声明group(accountancy)效果一样。

accountancy

• 用于任务指派的Flowable扩展

很明显，当指派关系不复杂时，这种用户与组的指派方式十分笨重。为避免这种复杂性，可以在用户任务上使用自定义扩展。

• • assignee（办理人）属性：这个自定义扩展用于直接将用户指派至用户任务。

与上面定义的humanPerformer结构效果完全相同。

• • candidateUsers（候选用户）属性：这个自定义扩展用于为任务指定候选用户。

与使用上面定义的potentialOwner结构效果完全相同。请注意不需要像在potentialOwner中一样，使用user(kermit)的声明，因为这个属性只能用于用户。

• • candidateGroups（候选组）attribute：这个自定义扩展用于为任务指定候选组。

与使用上面定义的potentialOwner结构效果完全相同。请注意不需要像在potentialOwner中一样，使用group(management)的声明，因为这个属性只能用于组。

• • 可以定义在一个用户任务上同时定义candidateUsers与candidateGroups。

4.4.2、脚本任务

• 描述：

脚本任务（Script Task）是一个自动化任务。当流程到达脚本任务时，自动执行编写的脚本，完毕后继续执行后继路线。

• 图示：

脚本任务用左上角有一个小“脚本”图标的标准BPMN 2.0任务（圆角矩形）表示。

• xml表示：

脚本任务使用script与scriptFormat元素定义。

scriptFormat属性的值，必须是兼容JSR-223（Java平台脚本）的名字。默认情况下，JavaScript包含在每一个JDK中，因此不需要添加任何JAR文件。如果想使用其它（兼容JSR-223的）脚本引擎，则需要在classpath中添加相应的jar，并使用适当的名字。例如，Flowable单元测试经常使用Groovy，因为其语法与Java十分相似。

请注意Groovy脚本引擎与groovy-all JAR捆绑在一起。在Groovy 2.0版本以前，脚本引擎是Groovy JAR的一部分。因此，必须添加如下依赖：

org.codehaus.groovy

groovy-all

2.x.x

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

• assignee（办理人）属性：这个自定义扩展用于直接将用户指派至用户任务。

与上面定义的humanPerformer结构效果完全相同。

• • candidateUsers（候选用户）属性：这个自定义扩展用于为任务指定候选用户。

与使用上面定义的potentialOwner结构效果完全相同。请注意不需要像在potentialOwner中一样，使用user(kermit)的声明，因为这个属性只能用于用户。

• • candidateGroups（候选组）attribute：这个自定义扩展用于为任务指定候选组。

与使用上面定义的potentialOwner结构效果完全相同。请注意不需要像在potentialOwner中一样，使用group(management)的声明，因为这个属性只能用于组。

• • 可以定义在一个用户任务上同时定义candidateUsers与candidateGroups。

4.4.2、脚本任务

• 描述：

脚本任务（Script Task）是一个自动化任务。当流程到达脚本任务时，自动执行编写的脚本，完毕后继续执行后继路线。

• 图示：

脚本任务用左上角有一个小“脚本”图标的标准BPMN 2.0任务（圆角矩形）表示。

• xml表示：

脚本任务使用script与scriptFormat元素定义。

scriptFormat属性的值，必须是兼容JSR-223（Java平台脚本）的名字。默认情况下，JavaScript包含在每一个JDK中，因此不需要添加任何JAR文件。如果想使用其它（兼容JSR-223的）脚本引擎，则需要在classpath中添加相应的jar，并使用适当的名字。例如，Flowable单元测试经常使用Groovy，因为其语法与Java十分相似。

请注意Groovy脚本引擎与groovy-all JAR捆绑在一起。在Groovy 2.0版本以前，脚本引擎是Groovy JAR的一部分。因此，必须添加如下依赖：

org.codehaus.groovy

groovy-all

2.x.x

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

[外链图片转存中…(img-L7nGvXdL-1716309667059)]