别再只当画图工具了！Flowable Modeler + Task App 实战：模拟一个请假审批流程
Flowable实战：从零构建企业级请假审批系统
当大多数开发者第一次接触Flowable时，往往把它当作一个简单的流程图绘制工具。但真正深入使用后才会发现，这套开源工作流引擎能带来的价值远超想象。本文将带你从业务场景出发，完整实现一个包含"员工申请-经理审批-HR备案"三环节的请假审批系统，体验Flowable Modeler与Task App的无缝协作。
1. 环境准备与基础配置
在开始建模前，我们需要确保开发环境就绪。Flowable UI套件提供了开箱即用的Spring Boot应用，包含四个核心模块：
- IDM：统一身份认证中心
- Modeler：可视化流程设计器
- Task：任务处理中心
- Admin：系统管理后台
推荐使用Docker快速搭建环境，避免复杂的依赖配置：
docker run -p 8080:8080 flowable/all-in-one:6.6.0启动后访问http://localhost:8080/flowable-ui，使用默认账号admin/test登录。首次使用需要完成三项基础配置：
- 创建组织结构：在IDM模块中建立部门树
- 分配角色权限：为不同岗位设置Modeler和Task的访问权限
- 初始化用户：至少创建张三（员工）、李四（部门经理）、王五（HR）三个测试账号
提示：生产环境务必修改默认密码，并启用HTTPS加密传输
2. 业务流程建模实战
进入Modeler模块，我们开始构建请假审批的核心流程。不同于单纯画图，需要特别关注以下几个业务要素：
2.1 流程变量设计
| 变量名 | 类型 | 作用域 | 示例值 |
|---|---|---|---|
| leaveType | string | 全局 | 年假/病假 |
| leaveDays | int | 全局 | 3 |
| approveOpinion | string | 任务级 | 同意 |
2.2 用户任务配置
提交申请节点：
- 表单字段：请假类型、天数、事由、附件
- 分配方式：
${initiator}（自动绑定提交人）
经理审批节点：
<humanTask id="managerApprove" name="部门审批"> <potentialOwner> <resourceAssignmentExpression> <formalExpression>group:dept_leader</formalExpression> </resourceAssignmentExpression> </potentialOwner> </humanTask>HR备案节点：
- 设置多实例会签：当请假天数>5时需双HR确认
- 添加监听器：审批通过后自动同步到考勤系统
2.3 网关逻辑设计
使用排他网关处理特殊场景：
graph LR A[天数≤3] --> B[自动通过] A --> C[天数>3] --> D[人工审批]注意：连线条件要使用
${leaveDays <= 3}这样的表达式语法
3. 多角色协同操作指南
流程发布后，我们切换到Task App模拟真实业务流转：
3.1 员工视角（张三）
- 登录后点击"启动流程"，选择"请假审批"
- 填写表单关键字段：
{ "leaveType": "年假", "leaveDays": 2, "reason": "家庭旅行" } - 上传行程单附件
- 提交后可在"我的申请"中跟踪状态
3.2 经理视角（李四）
- 待办列表出现"张三的请假审批"任务
- 点击处理时系统自动执行：
- 校验剩余假期额度
- 检查历史请假记录
- 审批操作示例：
// 通过审批 completeTask({ action: 'approve', comment: '行程合理，准假' }); // 拒绝示例 completeTask({ action: 'reject', comment: '项目冲刺期暂不批准' });
3.3 HR视角（王五）
- 查看部门所有已批假条
- 导出月度请假统计报表
- 异常处理：修改已归档记录需附加审计日志
4. 高级功能与性能优化
当基础流程跑通后，可以考虑引入这些增强特性：
4.1 动态任务分配
// 根据请假类型指定审批人 taskService.setAssignee(taskId, leaveType.equals("病假") ? "hr_specialist" : "dept_manager");4.2 并行会签优化
| 策略 | 适用场景 | 配置方式 |
|---|---|---|
| 固定数量会签 | 重要财务审批 | nrOfInstances=3 |
| 条件触发会签 | 高风险操作 | completionCondition=${score>80} |
| 动态添加参与者 | 临时增补专家 | runtime添加新assignee |
4.3 性能监控指标
在Admin模块中可以跟踪：
- 平均任务处理时长
- 各节点积压情况
- 表单加载耗时百分位
建议对以下表建立索引：
CREATE INDEX idx_act_ru_task_procdef ON ACT_RU_TASK(PROC_DEF_ID_); CREATE INDEX idx_act_hi_var_type ON ACT_HI_VARINST(VAR_TYPE_);5. 避坑指南与最佳实践
在实际项目中我们总结出这些经验：
- 版本控制：每次修改流程定义都要升版，避免运行时冲突
- 变量清理：长期运行实例要定期清理历史变量
- 异常处理：为每个用户任务配置timeout事件
- 测试策略：
- 边界测试：模拟连续提交10次1天请假
- 并发测试：50人同时发起审批
- 恢复测试：强制终止实例后补偿机制
一个典型的反模式是过度使用子流程，导致调试困难。建议单个流程的节点数控制在15个以内，复杂逻辑拆分为服务任务。
最后分享一个实用技巧：在Task App的URL后添加?processInstanceId=xxx可以直接定位到指定实例，这在排查生产问题时特别有用。