简介：这份《Activiti6.0工作流使用说明文档v1.0.pdf》面向正在学习或落地工作流引擎的Java开发者、流程设计人员与项目架构师，帮助读者系统掌握Activiti 6.0的建模与任务配置方法。文档以模型设计器为主线，逐一讲解用户任务、服务任务、脚本任务、业务规则任务、接收任务、手动任务、邮件任务、Camel任务、Mule任务与决策任务等十类任务的适用场景与配置要点，并延伸至子流程、事件子流程、泳道列表，以及排他、并行、包容、事件等分支结构，目录层次清晰，便于按模块查阅。资源为单个PDF文件，压缩包约1.72MB，内容精炼、结构完整，适合作为日常开发中的速查手册。目前已有1166人学习下载，可作为从流程建模到任务落地的实践参考。
1. 从一份 37 页的 Activiti 6.0 说明文档说起：它到底能帮你省掉哪些试错
如果你正在做审批流、工单流转或者订单状态机，大概率绕不开 Activiti 6.0 这个开源工作流引擎。但真正让人头疼的往往不是引擎本身，而是从「知道有这个东西」到「能跑通一条完整流程」之间的那段空白——BPMN 元素那么多，哪些是必须掌握的，哪些是配错了才后悔的，官方手册又厚又散。这份 37 页的《Activiti 6.0 工作流使用说明文档 v1.0》就是冲着这个空白来的：它把模型设计器里任务、构造、泳道、分支、事件、属性元素、监听器这七大类元素逐个拆开讲，还附带了 workflow-service 的数据更新逻辑和自定义外置表单配置。适合两类人：一是刚接手 Activiti 项目、需要快速建立全局认知的后端开发；二是已经用过但总在网关条件、定时器格式、监听器注册这些地方翻车的熟手。文档不是官方手册的翻译，而是带着「哪些属性必须配、配错了会怎样」的实操视角写的，这一点在后面的章节里会反复体现。
2. 模型设计器里的任务与构造：从用户任务到事件子流程的落地拆解
2.1 十种任务类型的选型逻辑与配置入口
模型设计器是 Activiti 6.0 里设计流程的主战场，而任务节点是流程的基本单元。文档里列了十种任务类型，但实际项目中最常用的其实就四五个，先把它们的关系理清楚比死记硬背强。
用户任务是需要人为介入的节点，比如审批、复核、填写表单。它的核心配置项包括分配（指定处理人或处理组）、到期时间、表单引用和多实例设置。这里有个容易忽略的点：分配支持直接指定用户、用户组，也支持通过表达式动态计算，比如${assignee}从流程变量里取。到期时间同样支持表达式，常见做法是配${dueDate}，在启动流程时把计算好的时间塞进变量。
服务任务用于执行外部 Java 类，文档给了三种实现方式：实现JavaDelegate或ActivityBehavior接口的类、值表达式/方法表达式、以及委托表达式。三者的区别在于耦合度——直接指定类名最直接但硬编码；表达式方式灵活，方法表达式有返回值时可以指定结果变量名，后续节点直接引用；委托表达式要求类已经在ActivitiEngineConfiguration中注册为 bean，适合需要依赖注入的场景。我一般会优先用委托表达式，因为 Spring 容器管理生命周期，测试和替换都方便。
脚本任务走的是 JSR-223 规范，默认支持 JavaScript，其他脚本类型需要额外加引擎依赖。脚本里可以直接引用流程变量，也能用execution.setVariable("variableName", variableValue)设置新变量。这里有个血泪经验：变量名千万别用out、out:print、lang:import、context、elcontext这几个，它们是脚本引擎的保留字，用了之后报错信息极其隐晦，排查起来很折磨。
业务规则任务依赖 Drools 引擎，.drl规则文件需要和流程定义一起导入。多个规则文件用逗号隔开，多个输入变量也用逗号隔开，但输出变量只能有一个名称，缺省值是org.activiti.engine.rules.OUTPUT。决策任务则是根据决策表自动判断流转方向，这里有个坑：如果决策表里某个输出没有结果，下一个节点引用该变量时会是空值，如果是在判断节点引用，可能直接抛「无法识别属性」的异常。文档里举的例子是loanAmount>2时输出rejectLoan=true，但后续判断节点引用${riskCheck==false}就会报找不到riskCheck属性——因为决策表根本没输出这个变量。
接收任务、手动任务、邮件任务、Camel 任务、Mule 任务这几种属于特定场景才会用到。邮件任务需要在activiti-app.properties里配好邮件服务器地址，各属性都支持表达式。Camel 和 Mule 任务不是 BPMN 2.0 标准内容，属于 Activiti 的扩展集成能力，需要在 Spring 容器里配好对应的camelContext或 Mule 组件。
2.2 子流程与事件子流程的边界规则
构造类元素里，子流程和事件子流程是最容易配错的。普通子流程必须包含一个空起始事件和一个结束事件，序列流不能越过子流程的框定范围。它的典型用途是把几个审批节点打包成一个整体，定时器监听的是整个子流程的耗时，而不是单个节点的耗时。
事件子流程则不同，它由非空开始事件触发，没有任何出入序列流。Activiti 6.0 只支持错误开始事件和消息开始事件来触发事件子流程。这意味着如果你想用信号事件触发一个子流程，在当前版本是走不通的，得换方案。
泳道列表主要是为了让流程图层次分明，部署时会根据泳道的流程 ID 生成流程定义任务。操作上先把泳道池拖到界面，再把泳道拖进泳道池形成分割线。这个功能在多人协作的审批流里特别有用，谁负责哪一段一目了然。
2.3 分支网关的四种类型与条件配置
分支也叫网关，是控制流程流转的核心。排他分支有且仅有一个后续连线会被执行，多个条件为 true 时默认走第一条，没有满足条件的连线则抛「找不到后续节点」异常。并行分支包含分叉和聚合，每个任务节点执行完会在聚合口等待，直到所有分支都完成才继续。这里有个强制行为：并行分支后的任务节点会被强制生成并行实例，即使在连线上配了流转条件也无效。
包容分支是排他和并行的结合体，可以在连线上定义条件，只并行执行条件为 true 的连线，同时又能并行执行多个任务。事件分支比较特殊，后续节点只能连接中间捕获事件，并且必须连接两个或两个以上的中间捕获事件，否则执行时会报错。连接事件分支的中间捕获事件必须只有一个信号输入流。
文档里给了一个事件分支的典型场景：流程执行到事件分支时被挂起，流程实例订阅了一个信号事件并创建了一个 10 分钟的定时器。如果信号在 10 分钟内到达，定时器取消，流程沿信号方向继续；如果信号没来，流程沿定时器方向继续，同时信号订阅被取消。这种「等待多个事件，先到先得」的模式在超时补偿场景里很实用。
3. 事件与属性元素：定时器格式、信号广播和异步回滚边界的实操细节
3.1 定时器事件的三种配置格式与发布校验
定时器事件可以被用作开始事件、中间事件和边界事件，但前提是jobExecutorActivate或asyncExecutorActivate属性必须设置为 true，否则定时器根本不会执行。定时器必须包含以下三种配置之一，否则流程发布不成功：
第一种是 ISO-8601 格式的日期时间，比如2011-03-11T12:13:14+08:00或20040503T093008+08，其中T分隔日期和时间，+08:00表示北京时间。第二种是时间间隔格式，用P开头，比如P1Y3M5DT6H7M30S表示间隔 1 年 3 个月 5 天 6 小时 7 分 30 秒。第三种是循环周期格式，比如R3/{startDatetime}/PT10H/${EndDatetime}表示循环执行 3 次，每次间隔 10 小时，到指定结束时间停止。也支持 cron 表达式。
我一般会在边界定时器事件上配一个邮件提醒，同时保证流程正常流转。比如审批节点超过 24 小时未处理，触发提醒邮件，但流程本身不中断，继续等待处理人操作。这种「提醒但不阻断」的模式比直接终止任务要温和得多。
3.2 信号事件与消息事件的广播范围差异
信号事件和消息事件容易混淆，核心区别在于广播范围。信号事件分全局和流程实例两种：全局信号一旦抛出，所有订阅了该信号的流程实例都会收到；流程实例信号只在当前流程内通讯。捕获信号只能捕获信号流程发起之后的信号，之前的信号不会补发。
抛出信号可以用中间信号抛出事件，也可以用代码：
// 全局信号：所有订阅了该信号的流程实例都会收到 runtimeService.signalEventReceived("alert"); // 指定实例信号：只通知指定的执行实例 runtimeService.signalEventReceived("alert", executionId);查询信号订阅的代码也很直接：
List<Execution> executions = runtimeService.createExecutionQuery() .signalEventSubscriptionName("alert") .list();消息事件则不同，一个消息事件只能指向一个唯一接收人。Activiti 本身不关注消息的抛出和接收，应用需要自己接入 JMS、WebService 或 REST 请求来处理。触发订阅的消息事件用messageEventReceived方法，可以带流程变量：
// 不带变量 messageEventReceived("messageName", executionId); // 带流程变量 HashMap<String, Object> variables = new HashMap<>(); variables.put("approved", true); messageEventReceived("messageName", executionId, variables);错误事件不是程序异常，而是业务异常的一种表达方式。在实现了JavaDelegates接口的类中可以抛出BpmnError，这个异常可以被边界错误事件或子流程错误事件捕获。错误开始事件可以触发事件子流程，但不能用来开启一个流程实例。
3.3 异步属性与补偿、中断任务的配合方式
Activiti 默认按顺序执行流程节点，从一个完成节点到下一个等待状态节点之间的所有节点属于同一单元任务，执行的成功与失败具有原子性。如果中间某步出错，整个单元回滚到起点。异步属性可以人为控制回滚边界：把某个节点的异步设为 true，该节点之前的节点会照常执行完成，流程挂起在异步节点，不会因为后续失败而回滚前面的操作。
典型场景是提交订单后发短信。短信发送失败不应该导致订单提交失败，所以把发短信的任务设为异步，订单提交照常完成，短信任务独立执行，失败了挂起在那里等重试或人工处理。
补偿属性选择为「是」时该节点即为补偿节点，用于补偿另一个活动的影响。补偿节点没有出入顺序流，不包含在一般流程中，只在补偿事件被抛出时执行。一个补偿节点必须定向关联一个边界补偿事件，反之亦然。边界补偿事件在其附着的节点成功完成时才被激活，流程完成时才取消。目前 Activiti Designer 中暂未加入抛出补偿事件的支持，所以补偿功能在实际项目里用得不多，但理解它的机制对排查复杂流程问题有帮助。
中断任务通常和边界事件配合使用，默认勾选。当达到边界事件抛出条件时，当前边界事件附属的任务被主动终止，边界事件关联的任务及后续流程被激活，附属任务的后续流程全部取消。这个默认行为在超时审批场景里很常见：审批节点超时后，自动终止当前审批，转交给上级处理。
4. 监听器配置与 workflow-service：执行监听、任务监听和自定义外置表单的接入
4.1 三类监听器的注册时机与典型用途
监听器是 Activiti 里实现业务解耦的关键机制，文档里分了执行监听器、任务监听器、事件监听器和全局事件监听器四类。
执行监听器挂在流程节点或连线上，监听start、end、take等事件。典型用途是在节点开始时往流程变量里塞数据，或者在节点结束时清理临时变量。配置方式是在节点的「执行监听器」属性里添加，指定实现类或表达式。
任务监听器只挂在用户任务上，监听create、assignment、complete、delete事件。最常见的用法是在create事件里动态设置处理人，比如根据表单里的部门字段查找到对应的审批人，然后task.setAssignee(approver)。这样流程定义里不需要硬编码处理人，灵活性高很多。
事件监听器和全局事件监听器的区别在于作用范围。事件监听器可以挂在特定节点上，全局事件监听器则监听整个引擎的事件，比如流程启动、流程结束、任务创建等。全局监听器需要在配置文件里注册，适合做统一的日志记录或审计。
4.2 workflow-service 的数据更新逻辑与方法表达式
workflow-service 是文档第二部分的内容，主要讲数据更新逻辑、方法表达式配置、自定义外置表单和事件监听器配置。数据更新逻辑的核心是：流程实例运行时产生的变量、任务、执行实例等数据，最终都要落到数据库表里。Activiti 6.0 的表结构分运行时表和历史表，流程结束后运行时数据被清理，历史数据保留。
方法表达式配置是服务任务里常用的方式。比如一个服务任务需要调用 Spring bean 的方法，可以配成${myService.process(execution)}这种形式。方法表达式有返回值时，可以指定结果变量名，后续节点直接引用该变量。这里要注意方法签名：参数可以是DelegateExecution，也可以是流程变量，返回值类型要和结果变量的使用场景匹配。
自定义外置表单是 Activiti 6.0 里比较实用的功能。表单文件（.form）和流程定义一起部署，用户任务引用表单地址后，任务办理页面会自动渲染表单字段。表单字段和流程变量的映射关系在表单文件里定义，支持文本、日期、下拉框等类型。文档里提到外置表单的部署方式和.drl规则文件类似，都是和流程定义一起导入。
4.3 打印 SQL 与配置文件的关键路径
排查 Activiti 问题时，打开 SQL 日志是最直接的手段。在log4j.properties里加一行：
log4j.logger.org.activiti.engine.impl.persistence.entity=DEBUG这样引擎执行的所有 SQL 都会打印出来，包括参数绑定和返回结果。流程启动慢、任务查询不到、变量丢失这些问题，看 SQL 日志基本能定位到是哪张表、哪个条件出了问题。
数据库和邮件服务器的配置文件在qqdznyyglpt-workflow-designer\src\META-INF\activiti-app\activiti-app.properties。这个路径是模型设计器项目的配置入口，数据库连接、邮件服务器地址、租户配置都在这里改。文档里特别提到：只有和 admin（密码默认 test）相同租户的用户才能使用设计器的全功能，其他租户用户登录后只有流程设计、表单配置、决策表配置功能，无法在设计器里执行流程。这个租户隔离机制在多租户场景下要特别注意，别配了半天发现是租户权限问题。
模型、表单、决策表修改后必须重新发布才生效。发布之后新启动的流程按最新版本走，发布之前已经启动的流程仍然按前一版本执行。这个版本隔离机制是 Activiti 的标准行为，理解这一点对版本管理和灰度发布很重要。
5. 避坑与排查：信号订阅、决策表空值和定时器发布失败的常见问题
5.1 信号事件订阅查询不到或捕获失败
现象：流程执行到中间信号捕获事件后，用runtimeService.createExecutionQuery().signalEventSubscriptionName("alert").list()查不到订阅记录，或者抛出信号后流程没有继续执行。
原因：信号捕获只能捕获信号流程发起之后的信号。如果信号在流程到达捕获节点之前就已经抛出，捕获节点不会收到。另外，全局信号和流程实例信号的订阅范围不同，用signalEventReceived(signalName)抛全局信号时，只有订阅了全局信号的实例才会收到。
解决：确认信号抛出的时机在捕获节点激活之后。如果是跨流程通讯，用全局信号；如果是流程内通讯，用流程实例信号并指定executionId。查询订阅时注意区分signalEventSubscriptionName和messageEventSubscriptionName，两者不能混用。
5.2 决策表输出为空导致后续判断节点报错
现象：决策任务执行后，后续判断节点引用某个变量时抛出「无法识别属性」异常。
原因：决策表里某个输出没有结果，该变量在流程中为空。如果判断节点直接引用这个空变量做比较，表达式解析失败。
解决：在决策表配置时确保所有可能被引用的输出都有默认值，或者在判断节点前加一个服务任务做空值兜底。文档里的例子是riskCheck变量在决策表没有输出时为空，后续${riskCheck==false}直接报错。我一般会在决策表后面加一个脚本任务，用 JavaScript 给可能为空的变量赋默认值。
5.3 定时器事件发布失败或到点不触发
现象：流程发布时提示定时器配置错误，或者发布成功但定时器到点后没有触发。
原因：定时器格式不符合三种配置之一，或者jobExecutorActivate/asyncExecutorActivate没有设置为 true。
解决：检查定时器配置是否符合 ISO-8601、时间间隔或循环周期格式。确认引擎配置里jobExecutorActivate为 true。如果是边界定时器事件，确认附着的节点已经激活。另外注意 cron 表达式的时区问题，默认是服务器时区，跨时区部署时要显式指定。
5.4 并行分支后的任务条件不生效
现象：在并行分支的连线上配置了流转条件，但流程仍然生成了所有分支的并行实例。
原因：并行分支后的任务节点被强制生成并行实例，连线上的流转条件无效。这是 Activiti 的设计行为，不是 bug。
解决：如果需要条件控制，改用包容分支。包容分支可以在连线上定义条件，只并行执行条件为 true 的连线。如果必须用并行分支，把条件判断移到分支后的服务任务或用户任务里，用表达式决定后续走向。
5.5 脚本任务变量名冲突导致执行失败
现象：脚本任务执行时报错，提示变量未定义或语法错误，但脚本内容看起来没问题。
原因：变量名用了out、out:print、lang:import、context、elcontext这些脚本引擎保留字。
解决：改掉变量名，加前缀或后缀区分。比如用outVar代替out，用ctxVar代替context。这个坑在 JavaScript 脚本里特别常见，因为out在 Nashorn 引擎里有特殊含义。
6. 从能跑到好用：一套流程定义从设计到上线的检查清单
把流程跑通只是第一步，真正上线前还有几件事必须过一遍。我自己的习惯是维护一份检查清单，每次发布新版本流程定义前逐项确认。
第一项是版本兼容性。Activiti 6.0 的流程定义有版本号，新版本发布后旧实例继续走旧版本。如果修改了流程变量名或表单字段，旧实例在流转到新节点时可能找不到变量。常见做法是：变量名只增不改，旧变量保留但不再使用；表单字段新增时给默认值，避免旧实例渲染报错。
第二项是监听器异常处理。执行监听器和任务监听器里抛出的异常会中断流程执行。如果监听器里调用了外部服务，一定要加 try-catch，把异常吞掉或转成流程变量记录，不要让监听器异常导致整个流程挂起。我一般会在监听器里加日志和降级逻辑，外部服务不可用时记录状态但不阻断流程。
第三项是定时器与异步任务的线程池配置。asyncExecutorActivate打开后，异步任务和定时器共用线程池。默认配置在高并发场景下可能不够用，需要根据实际任务量调整asyncExecutorCorePoolSize和asyncExecutorMaxPoolSize。线程池满了之后任务会排队，排队时间过长会导致定时器延迟触发。
第四项是历史数据清理策略。Activiti 的历史表会随着流程实例增多而膨胀。文档里没有展开讲历史级别配置，但实际项目里必须设置。historyLevel可以配成none、activity、audit、full四档，级别越高记录越详细，数据量也越大。我一般用audit，保留任务和活动实例，不记录变量更新细节。
第五项是流程定义缓存。Activiti 会缓存流程定义，修改流程文件后需要重新部署才能生效。在开发环境频繁修改时，可以关闭缓存或缩短缓存时间。生产环境保持默认缓存，通过重新部署触发缓存更新。
第六项是租户隔离验证。如果系统是多租户的，确认每个租户的流程定义、表单、决策表都正确隔离。文档里提到只有 admin 租户能用设计器全功能，其他租户只能设计不能执行。上线前用不同租户账号各跑一遍完整流程，确认权限和数据隔离都符合预期。
第七项是 SQL 日志开关。生产环境默认关闭 SQL 日志，但排查问题时需要动态打开。我一般会在配置中心留一个开关，出问题时不用改配置文件重启，直接通过配置中心打开log4j.logger.org.activiti.engine.impl.persistence.entity=DEBUG，排查完再关掉。
这份文档最值钱的地方不是它列了多少个元素，而是它把每个元素的配置边界和常见错误都点到了。37 页的体量不可能覆盖所有细节，但作为案头参考，在配网关条件、定时器格式、监听器注册这些高频翻车点上，它能帮你省掉大量查官方手册和试错的时间。从那以后我每次新建流程定义，都会先把这份文档里的属性元素章节过一遍，确认没有漏配关键属性再发布。希望帮到你。
本文还有配套的精品资源，点击获取
