Activiti-5.22.0——activiti-modeler界面设计组件介绍
目录
1、启动事件(Start Events)：
（1）无启动事件(Start event)：
A、描述：
B、图标：
（2）计时器事件(Start timer event)：
A、描述：
B、图标：
（3）信号事件(Start signal event)：
A、描述：
B、图标：
（4）消息事件(Start message event)：
A、描述：
B、图标：
（5）异常事件(Start error event)：
A、描述：
B、图标：
2、活动列表(Activities)：
（1）用户活动(User task)：
A、描述：
B、图标：
（2）服务任务(Service task)：
A、描述：
B、图标：
（3）脚本任务(Script task)：
A、描述：
B、图标：
（4）规则任务(Business rule task)：
A、描述：
B、图标：
（5）接受任务(Receive task)：
A、描述：
B、图标：
（6）手动任务(Manual task)：
A、描述：
B、图标：
（7）邮件任务(Mail task)：
A、描述：
B、图标：
（8）Camel任务(Camel task)：
A、描述：
B、图标：
（9）Mule任务(Mule task)：
A、描述：
B、图标：
3、结构列表(Structural)：
（1）子流程(Sub process)：
A、描述：
B、图标：
（2）事件子流程(Event sub process)：
A、描述：
B、图标：
（3）调用活动(Call activity)：
A、描述：
B、图标：
4、网关列表(Gateways)：
（1）互斥网关(Exclusive gateway)：
A、描述：
B、图标：
（2）并行网关(Parallel gateway)：
A、描述：
B、图标：
（3）包容性网关(Inclusive gateway)：
A、描述：
B、图标：
（4）事件网关(Event gateway)：
A、描述：
B、图标：
5、边界事件(Boundary Events)：
（1）边界错误事件(Boundary error event)：
A、描述：
B、图标：
（2）定时边界事件(Boundary timer event)：
A、描述：
B、图标：
（3）边界信号事件(Boundary signal event)：
A、描述：
B、图标：
（4）边界消息事件(Boundary message event)：
A、描述：
B、图标：
（5）边界取消事件(Boundary cancel event)：
A、描述：
B、图标：
（6）边界修正事件(Boundary compensation event)：
A、描述：
B、图标：
6、中间捕获事件列表(Intermediate Catching Events)：
（1）中间定时器捕获事件(Intermediate timer catching event)：
A、描述：
B、图标：
（2）中间信号捕获事件(Intermediate signal catching event)：
A、描述：
B、图标：
（3）中间消息捕获事件(Intermediate message catching event)：
A、描述：
B、图标：
7、中间抛出事件(Intermediate Throwing Events)：
（1）中间无抛出事件(Intermediate none Throwing event)：
A、描述：
B、图标：
（2）信号中间抛出事件(Intermediate signal throwing event)：
A、描述：
B、图标：
8、结束任务列表(End events)：
（1）结束任务(End event)：
A、描述：
B、图标：
（2）结束错误任务(End error event)：
A、描述：
B、图标：
（3）结束取消任务(End cancel event)：
A、描述：
B、图标：
（4）终结任务(End terminate event)：
A、描述：
B、图标：
设计activiti工作流的界面组件大致分为：启动事件、活动列表、结构列表、网关列表、结束任务列表、中间捕获事件列表、中间抛出事件、边界事件等几大类。
个人认为简单流程大概用到启动事件---活动列表--网关列表--结束列表；复杂点的流程可能会再增加用上结构列表；更加复杂完美的流程可能才会增加用上中间捕获事件列表、中间抛出事件、边界事件。
所以学习activiti设计界面组件应该从简单流程开始，先掌握基础组件即可，以后设计到复杂流程时再详细查看对应的复杂组件即可。
1、启动事件(Start Events)：
（1）无启动事件(Start event)：
A、描述：
空启动事件就是一个圆圈。在工作流里面使用的非常多。但是空启动事件必须要人工去启动一个流程。空启动事件是建立在部署完成的流程上面的。每启动一次，就会产生一个新的流程实例。只能通过API调用startProcessInstanceByXXX方法来启动一个流程实例，一个子进程也是以此方式开始的。大多数我们设计的流程都是以此方式开始的，方便用户在需要的时候通过在线手动发起流程实例。
B、图标：
（2）计时器事件(Start timer event)：
A、描述：
定时启动事件是一个时钟图标，注意的是，这个时钟图标是比较少圆圈的，要跟定时边界事件区分清楚。定时器启动事件用于在给定的时间点创建流程实例。它可以用在只启动一次的流程中，也可以用在特定时间间隔下启动。如果是有重复执行的，流程在周期内都有效，可以重复利用。该方式设计的模型一旦部署后，将会自动调度计时器时间，不需要再通过API调用startProcessInstanceByXXX来启动流程实例，但是如果需要还是可以通过API调用startProcessInstanceByXXX来再次启动。
B、图标：
（3）信号事件(Start signal event)：
A、描述：
信号启动事件，使用具名信号启动流程实例。这个信号可以由流程实例中的信号抛出中间事件（intermediary signal throw event），或
者API（runtimeService.signalEventReceivedXXX方法）触发。这些情况下，所有拥有相同名字信号启动事件的流程定义都会被启动。
请注意这些情况下，都可以选择异步还是同步启动流程实例。需要为API传递的signalName，是由signal元素的name属性决定的名字。signal元素被signalEventDefinition的signalRef属性所引用。
B、图标：
（4）消息事件(Start message event)：
A、描述：
流程的消息名称必须是唯一的，一个流程定义不得包含多个同名的启动消息。否则部署流程的时候就会抛异常。
消息启动事件，在所有部署的流程里面必须要唯一，否则也会抛异常。
直接启动消息定义事件，会当作一个普通启动事件执行。
新版本发布，会取消上一版本的消息订阅。
启动流程实例的三种方法：
注：messageName是由message元素的name属性决定的名字。message元素被messageEventDefinition的messageRef属性引用。
只有顶层流程（toplevel process）才支持消息启动事件 ，嵌入流程（子流程）不支持消息事件。
如果一个流程定义多个消息事件无法使用runtimeService.startProcessInstanceByKey(…) 与
runtimeService.startProcessInstanceById(…) 启动消息事件，但是一个流程定义单个消息事件可以启动。如果同一个流程定义同时具有多个消息事件和空启动事件，就会启动空启动事件，同一个流程定义多个消息事件的时候，使用这个方法启动，就会抛异常。
B、图标：
（5）异常事件(Start error event)：
A、描述：
BPMN2.0规定了错误开始事件只能使用在事件子流程（Event Sub-Process）中，该该事件不能使用在其他流程中，包括最高级流程（Top-Level Process）、嵌套子流程（Sub-Process）和调用子流程（Call Activity）。BPMN错误与Java异常不是一回事。事实上，这两者毫无共同点。BPMN错误事件是建模业务异常（business exceptions）的方式。
B、图标：
2、活动列表(Activities)：
（1）用户活动(User task)：
A、描述：
用户任务用于对需要由人工参与者完成的工作建模。当流程执行到达这样一个用户任务时，将在分配给该任务的用户或组的任务列表中创建一个新任务。
B、图标：
（2）服务任务(Service task)：
A、描述：
服务任务用于调用外部Java类。当客户有这么一个需求：下一个任务我需要自动执行一些操作，并且这个节点不需要任何的人工干涉，也就是说这个节点是自动化的。那么，这个当前面一个经办人员把任务发送下去的时候，自然而然的下一个节点就会开始马上执行。这个时候。我们就需要使用Activiti工作流的ServiceTask任务。操作主要步骤分为：设计流程、编写委托类、把委托类设置到流程的监听类上面。
B、图标：
（3）脚本任务(Script task)：
A、描述：
脚本任务是一个自动化活动。当一个流程执行到达脚本任务时，执行相应的脚本。脚本任务比较少用，脚本任务一般是用在当前的监听器或者监听服务类都不能满足的情形下面，或者说后期系统维护，突然在不想改动系统的情况下需要对流程做一些适当的改变。仅仅是几个变量或者仅仅是一个计算公式等等。这个时候可以使用脚本任务。至于还用其他的作用，我暂时没去多了解。
B、图标：
（4）规则任务(Business rule task)：
A、描述：
业务规则任务用于同步执行一个或更多规则。Activiti使用Drools Expert和Drool规则引擎来执行业务规则。目前而言，包含有业务规则的.drl文件必须与定义了业务规则任务的流程定义一同部署才能执行这些规则。这意味着在流程中使用的所有.drl文件必须像任务表单一样被打包进流程的BAR文件中。更多关于使用Drool Expert来创建业务规则的信息，请参考Jboss Drools上的Drools文档。使用该任务的时候比较少。
B、图标：
（5）接受任务(Receive task)：
A、描述：
接收任务是一个等待消息到来的简单任务。目前，我们仅实现了该任务的Java语义。当流程执行到接收任务时，流程状态被提交到持久化数据库中。这意味着，流程将进入一种等待状态，直到引擎接收到明确的消息，来触发流程通过接收任务继续执行。
Activiti接受任务（receiveTask）其实和Activiti的手动任务是差不多的，不过手动任务是直接通过，而Activiti接受任务（receiveTask）则在任务启动到该节点的时候停下来等待信号。当任务接收到信号的时候，该流程就会继续往下执行。
B、图标：
（6）手动任务(Manual task)：
A、描述：
手动任务定义了BP引擎之外的任务。用来对那些需要人来完成的工作进行建模，引擎不需要知道他是系统还是UI接口。对引擎而言，手动任务是作为直接通过的活动处理的，流程执行到此会自动继续流程的执行。所以这个流程其实没有什么好说的。就是一个直接通过的任务。可以使用它来自动执行一些可以直接通过的任务。手动任务几乎不在程序中做什么事情，只是在流程的历史中留下一点痕迹，表明流程是走过某些节点的。而且这个任务是无法用taskservice查询到的。
B、图标：
（7）邮件任务(Mail task)：
A、描述：
邮件任务就是流程办理到邮件任务的时候，系统就会自动的给你发送任务。Activiti允许通过向一个或多个收件人发送电子邮件的自动邮件服务任务来增强业务流程，包括对抄送、密件抄送、HTML内容等的支持。请注意，邮件任务不是BPMN 2.0规范的正式任务（因此它没有专用的图标）。因此，在Activiti中，邮件任务被实现为专用服务任务。
B、图标：
（8）Camel任务(Camel task)：
A、描述：
Camel任务可以从Camel发送和介绍消息，由此强化了activiti的集成功能。 注意camel任务不是BPMN 2.0规范定义的官方任务。（它也没有对应的图标）。在activiti中，camel任务时由专用的服务任务实现的。
B、图标：
（9）Mule任务(Mule task)：
A、描述：
mule任务允许向mule发送消息，增强了Activiti的集成特性。请注意，mule任务不是BPMN 2.0规范的正式任务（因此它没有专用的图标）。因此，在Activiti中，mule任务被实现为一个专用的服务任务。
B、图标：
3、结构列表(Structural)：
（1）子流程(Sub process)：
A、描述：
子流程是一个包含其他活动、网关、事件等的活动，这些活动本身形成了一个流程，是更大的流程的一部分。子流程完全是在父流程中定义的（这就是为什么它通常被称为嵌入式子流程）。
子流程为事件创建一个新的范围。在子流程执行期间抛出的事件可以由子流程边界上的边界事件捕获，从而为该事件创建一个范围，该范围仅限于子流程。
子进程只能有一个无启动事件，不允许有其他启动事件类型。子流程必须至少有一个end事件。注意，BPMN 2.0规范允许省略子流程中的开始和结束事件，但是当前的Activiti-5.22.0实现不支持这一点。
B、图标：
（2）事件子流程(Event sub process)：
A、描述：
事件子流程是BPMN 2.0中新出现的。事件子流程是由事件触发的子流程。可以在流程级或任何子流程级添加事件子流程。用于触发事件子流程的事件是使用start事件配置的。由此可见，事件子流程不支持无启动事件。可以使用消息事件、错误事件、信号事件、计时器事件或补偿事件等事件触发事件子流程。在创建承载事件子流程的范围(流程实例或子流程)时创建对start事件的订阅。当范围被销毁时，订阅将被删除。
事件子流程可以是中断的，也可以是非中断的。中断子进程取消当前范围内的任何执行。非中断事件子进程生成一个新的并发执行。对于承载中断事件的范围的每次激活，中断事件子流程只能触发一次，而非中断事件子流程可以触发多次。子流程是否中断的事实是使用启动事件触发事件子流程来配置的。
事件子流程不能有任何传入或传出序列流。由于事件子流程是由事件触发的，因此传入的序列流没有意义。当一个事件子流程结束时，要么当前范围结束(在中断事件子流程的情况下)，要么为非中断子流程派生的并发执行结束。
目前activiti-5.22.0版本限制：只支持中断事件子流程；只支持使用错误启动事件或消息启动事件触发的事件子流程。
B、图标：
（3）调用活动(Call activity)：
A、描述：
BPMN 2.0对常规子流程(通常也称为嵌入式子流程)和调用活动进行了区分，二者看起来非常相似。从概念上看，当流程执行到达活动时，两者都将调用子流程。不同之处在于，call活动引用流程定义外部的流程，而子流程则嵌入到原始流程定义中。call活动的主要用例是拥有一个可重用的流程定义，该定义可以从多个其他流程定义中调用。当流程执行到达调用活动时，将创建一个新执行，它是到达调用活动的执行的子执行。然后使用这个子执行来执行子流程，可能会像在常规流程中一样创建并行的子执行。超级执行一直等到子进程完全结束，然后继续执行原来的进程。
B、图标：
4、网关列表(Gateways)：
（1）互斥网关(Exclusive gateway)：
A、描述：
排他网关exclusive gateway 经常使用流程变量决定流程下一步要选择的路径；
排他网关（也叫异或网关 XOR gateway，或者更专业的，基于数据的排他网关 exclusive data¬based gateway），用于为流程中的决策建模；
当执行到达这个网关时，所有出口顺序流会按照它们定义的顺序进行计算。条件计算为true的顺序流（当没有设置条件时，认为顺序流定义为true）会被选择用于继续流程；
用排他网关时，只会选择一条顺序流。当多条顺序 流的条件都计算为true时，其中在XML中定义的第一条（也只有这条）会被选择，用于继续流程。如果没有可选的顺序流，会抛出异常。
排他网关，用内部带有’X’图标的标准网关（菱形）表示，'X’图标代表异或（XOR）的含义。请注意内部没有图标的网关默认为排他网关。BPMN 2.0规范不允许在同一个流程中，混合使用带有及没有X的菱形标志。
一个排他网关对应一个以上的顺序流。
B、图标：
（2）并行网关(Parallel gateway)：
A、描述：
并行网关还可以用于对流程中的并发性进行建模。在流程模型中引入并发性的最直接的网关是并行网关，它允许分叉到多个执行路径或连接多个传入的执行路径。
并行网关两个重要特性：
分支（fork）： 并行后的所有外出顺序流，为每个顺序流都创建一个并发分支。
合并（join）： 所有到达并行网关，在此等待的进入分支， 直到所有进入顺序流的分支都到达以后， 流程就会通过汇聚网关。
注意：
如果并行网关同时具有入口顺序流和出口顺序流，并行网关会先执行入口顺序流，然后执行再分裂成多条可以执行的路径。
并行网关不执行计算条件。并行网关上面的计算条件会被忽略。
并行网关分支和合并是同时存在的，就是说，一个至少有一个分支和一个合并。但是，网关是可以不平衡的，分支和合并的数量可以不一致。
B、图标：
（3）包容性网关(Inclusive gateway)：
A、描述：
包容网关（Inclusive Gateway）就是并行网关（Parallel Gateway）和排他网关（Exclusive Gateway）的组合。可以在出口顺序流上定义条件，包容网关会计算它们。然而主要的区别是，包容网关与并行网关一样，可以选择多于一条（出口）顺序流。
包容网关、并行网关和排他网关的相同点：
都有出口顺序流和入口顺序流。
至少有一个分支。
包容网关、并行网关和排他网关的不同点：
排他网关只有一条分支被执行，如果有多条符合条件的分支，流程会默认走第一条。并行网关至少有一条分支被执行，而且所有的分支都会被执行。包容网关有多条或者一条分支会被执行。
包容网关包括了并行网关和排他网关的所有功能。
B、图标：
（4）事件网关(Event gateway)：
A、描述：
基于事件的网关允许基于事件做出决策。网关的每个传出序列流都需要连接到一个中间捕获事件。当流程执行到达基于事件的网关时，网关的行为类似于等待状态：执行被挂起。此外，对于每个传出序列流，将创建一个事件订阅。
B、图标：
5、边界事件(Boundary Events)：
（1）边界错误事件(Boundary error event)：
A、描述：
活动边界上的中间捕获错误，或简称为边界错误事件，捕获在其定义的活动范围内抛出的错误。
定义边界错误事件在嵌入式子流程或调用活动上最有意义，因为子流程为子流程内的所有活动创建范围。错误由错误结束事件抛出。这样的错误将向上传播它的父范围，直到找到一个范围，在这个范围上定义了与错误事件定义相匹配的边界错误事件。
当捕获到一个错误事件时，定义边界事件的活动将被销毁，同时销毁所有当前执行(例如并发活动、嵌套子进程等)。流程执行继续遵循边界事件的传出序列流。
B、图标：
（2）定时边界事件(Boundary timer event)：
A、描述：
计时器边界事件充当秒表和闹钟。当执行到达附加边界事件的活动时，将启动计时器。当定时器触发时(例如在一个指定的时间间隔之后)，活动被中断的边界事件被跟随。
B、图标：
（3）边界信号事件(Boundary signal event)：
A、描述：
活动边界上附加的中间捕获信号(简称边界信号事件)捕获与引用信号定义具有相同信号名称的信号。
注意：与边界错误事件等其他事件相反，边界信号事件不仅捕获从其附加的范围抛出的信号事件。相反，信号事件具有全局范围(广播语义)，这意味着可以从任何地方抛出信号，甚至从不同的流程实例抛出。
注意：与其他事件(如错误事件)相反，如果捕获到信号，则不会使用它。如果有两个活动的信号边界事件捕捉相同的信号事件，则会触发这两个边界事件，即使它们是不同流程实例的一部分。
B、图标：
（4）边界消息事件(Boundary message event)：
A、描述：
附加在活动边界上的中间捕获消息，或简称为边界消息事件，捕获与引用的消息定义具有相同消息名称的消息。
B、图标：
（5）边界取消事件(Boundary cancel event)：
A、描述：
当事务被取消时，将触发附加在事务子进程边界上的中间捕获取消，或简称为边界取消事件。当取消边界事件被触发时，它首先中断当前范围内所有活动的执行。接下来，它开始补偿事务范围内的所有活动补偿边界事件。补偿是同步执行的，即边界事件在离开事务之前等待补偿完成。当补偿完成时，事务子流程将使用耗尽cancel边界事件的序列流。
注意：对于事务子进程，只允许一个取消边界事件。
注意：如果事务子流程承载嵌套的子流程，则仅对已成功完成的子流程触发补偿。
注意：如果将取消边界事件放置在具有多个实例特征的事务子流程上，如果一个实例触发取消，则边界事件将取消所有实例。
B、图标：
（6）边界修正事件(Boundary compensation event)：
A、描述：
附加在活动边界上的中间捕获补偿或简称为补偿边界事件，可用于将补偿处理程序附加到活动上。补偿边界事件必须使用有向关联引用单个补偿处理程序。
补偿边界事件与其他边界事件具有不同的激活策略。其他边界事件(例如信号边界事件)在它们所连接的活动启动时被激活。当活动离开时，它们将被停用，相应的事件订阅将被取消。补偿边界事件是不同的。当附加到的活动成功完成时，补偿边界事件将被激活。此时，将创建补偿事件的相应订阅。当触发补偿事件或相应的流程实例结束时，订阅将被删除。据此可得:
当补偿被触发时，与补偿边界事件关联的补偿处理程序被调用的次数与它附加到的活动成功完成的次数相同。
如果补偿边界事件附加到具有多个实例特征的活动，则为每个实例创建补偿事件订阅。
如果补偿边界事件附加到循环中包含的活动，则在每次执行活动时创建补偿事件订阅。
如果流程实例结束，对补偿事件的订阅将被取消。
注意：补偿边界事件在嵌入的子进程中不受支持。
B、图标：
6、中间捕获事件列表(Intermediate Catching Events)：
（1）中间定时器捕获事件(Intermediate timer catching event)：
A、描述：
计时器中间事件充当秒表。当执行到达捕获事件活动时，将启动计时器。当定时器触发时(例如，在一个指定的间隔之后)，从定时器中间事件发出的序列流被跟随。
B、图标：
（2）中间信号捕获事件(Intermediate signal catching event)：
A、描述：
中间捕获信号事件捕获与引用信号定义具有相同信号名称的信号。
注意：与其他事件(如错误事件)相反，如果捕获到信号，则不会使用它。如果有两个活动的信号边界事件捕捉相同的信号事件，则会触发这两个边界事件，即使它们是不同流程实例的一部分。
B、图标：
（3）中间消息捕获事件(Intermediate message catching event)：
A、描述：
中间捕获消息事件捕获具有指定名称的消息。
B、图标：
7、中间抛出事件(Intermediate Throwing Events)：
（1）中间无抛出事件(Intermediate none Throwing event)：
A、描述：
中间无抛出事件通常用于指示流程中实现的某些状态。
B、图标：
（2）信号中间抛出事件(Intermediate signal throwing event)：
A、描述：
中间抛出信号事件为已定义的信号抛出信号事件。
在Activiti中，信号被广播到所有活动处理程序(即所有捕获信号事件)。信号可以同步发布，也可以异步发布。
在默认配置中，信号是同步发送的。这意味着抛出流程实例将等待，直到将信号传递给所有捕获流程实例。捕获流程实例也会在与抛出流程实例相同的事务中得到通知，这意味着如果其中一个被通知的实例产生了技术错误(抛出异常)，所有涉及的实例都会失败。
信号也可以异步传递。在这种情况下，可以确定哪些处理程序在到达抛出信号事件时处于活动状态。对于每个活动处理程序，JobExecutor将存储和传递异步通知消息(作业)。
B、图标：
8、结束任务列表(End events)：
（1）结束任务(End event)：
A、描述：
结束任务是最常见的一种结束任务，也是最简单的一种结束任务，只要把结束任务置于流程的最后节点，流程实例运行到该节点的时候，流程引擎就会结束该流程实例。并没有太多复杂的技术。所以不作太多的介绍。
B、图标：
（2）结束错误任务(End error event)：
A、描述：
错误结束事件会在流程到达错误结束事件的时候抛出错误，并结束当前的流程分支。错误可以使用使用匹配的错误边界中间事件（intermediate boundary error event）捕获。如果找不到匹配的错误边界事件，将会抛出异常。
B、图标：
（3）结束取消任务(End cancel event)：
A、描述：
结束取消事件，只能与bpmn事务子流程（bpmn transaction subprocess）一起使用。当到达取消结束事件时，会抛出取消事件，且必须由取消边界事件（cancel boundary event）捕获。之后这个取消边界事件将取消事务，并触发补偿（compensation）。
B、图标：
（4）终结任务(End terminate event)：
A、描述：
当到达终止结束事件时，当前的流程实例或子流程会被终止。概念上说，当执行到达终止结束事件时，会判断第一个范围 scope（流程或子流程）并终止它。请注意在BPMN 2.0中，子流程可以是嵌入式子流程，调用活动，事件子流程，或事务子流程。有一条通用规则：当存在多实例的调用过程或嵌入式子流程时，只会终止一个实例，其他的实例与流程实例不会受影响。可以添加一个可选属性terminateAll。当其为true时，无论该终止结束事件在流程定义中的位置，也无论它是否在子流程（甚至是嵌套子流程）中，都会终止（根）流程实例。
B、图标：
