解决档案审批慢：BPMN并行网关与超时自动实操指南
环境准备与基础搭建
档案审批流程缓慢的核心原因通常在于流程设计采用了“串行”模式，且缺乏对超时节点的自动处理机制。本文将使用业界标准的开源工作流引擎 Flowable，通过 Docker 快速搭建环境，并演示如何配置 BPMN 2.0 文件来实现“并行审批”与“超时自动流转”。
请在服务器本地创建一个工作目录，并创建 docker-compose.yml 文件。该文件将定义 Flowable REST API 服务及数据库环境，直接复制以下内容：
```yaml version: '3' services: flowable-rest: image: flowable/flowable-rest:latest ports: - "8080:8080" environment: - DATASOURCE_DRIVER=org.h2.Driver - DATASOURCE_URL=jdbc:h2:mem:flowable;DB_CLOSE_DELAY=-1 - DATASOURCE_USERNAME=sa - DATASOURCE_PASSWORD= ```保存文件后，在终端执行以下命令启动服务：
```bash docker-compose up -d ``>服务启动后，访问 http://localhost:8080/flowable-rest/docs/index.html 确认 API 接口可用。这将作为我们部署和测试流程的基础。
核心策略：并行与超时逻辑设计
在传统的档案审批中，流程往往是“部门审批 -> 财务审批 -> 档案管理员归档”。这种串行方式会导致只要有一个人的审批速度慢，整个流程就会停滞。
我们的优化方案包含两个技术点：
- 并行网关：将互不依赖的审批节点（如部门确认和合规检查）同时触发，谁先处理完都行，极大缩短总耗时。
- 定时器边界事件：在关键节点设置“死信”机制，如果审批人在规定时间（如24小时）内未处理，系统自动触发替代逻辑（如自动通过或升级给上级）。
实操一：编写 BPMN 流程定义文件
我们需要编写一个完整的 .bpmn20.xml 文件。为了方便理解，我们将流程设计为：开始 -> 并行拆分 -> [部门经理审批] 与 [合规专员审批] -> 并行汇聚 -> 结束。
“合规专员审批”节点将附加一个“定时器边界事件”。如果该任务在 30 分钟（PT30M）内未完成，系统将自动执行“自动通过服务”并跳过该审批。
请在项目目录下创建名为 archive_approval_process.bpmn20.xml 的文件，并完整复制以下代码。请勿修改 processDefinitionKey，后续接口调用将依赖此 ID：
```xml代码细节解析：
- timeDuration：设置为
PT30M表示 ISO 8601 标准的 30 分钟。你可以根据实际需求修改为PT24H（24小时）。 - cancelActivity="true"：表示一旦超时触发，原来的“合规专员审批”任务将被自动作废，防止人工重复审批。
- serviceTask：这里使用 Flowable 的 UEL 表达式设置流程变量，实际生产环境中可替换为调用 Java Delegate 或发送 HTTP 通知。
实操二：部署流程定义
有了 XML 文件后，我们需要通过 Flowable REST API 将其部署到引擎中。请确保 Docker 容器正在运行，然后使用以下 curl 命令进行部署。
假设你的 XML 文件和当前终端在同一目录下：
```bash curl -X POST "http://localhost:8080/flowable-rest/service/repository/deployments" \ -F "deployment-name=ArchiveOptimization" \ -F "deployment-source=tech-guide" \ -F "upload=@archive_approval_process.bpmn20.xml" \ -H "Accept: application/json" ```
执行成功后，你会返回包含 id 和 deploymentName 的 JSON 数据。此时，流程引擎已解析我们的并行与超时逻辑。
实操三：启动流程实例与验证
部署成功后，我们模拟发起一个档案审批请求。执行以下命令启动流程实例：
```bash curl -X POST "http://localhost:8080/flowable-rest/service/runtime/process-instances" \ -H "Content-Type: application/json" \ -d '{ "processDefinitionKey": "archiveOptimizationProcess", "variables": [ { "name": "initiator", "value": "admin" } ] }' ```流程启动后，由于我们配置了并行网关，系统会同时生成两个待办任务。我们可以通过查询 deptManager 的任务来验证：
```bash curl -X GET "http://localhost:8080/flowable-rest/service/runtime/tasks?assignee=deptManager" \ -H "Accept: application/json" ```同时查询 complianceOfficer 的任务：
```bash curl -X GET "http://localhost:8080/flowable-rest/service/runtime/tasks?assignee=complianceOfficer" \ -H "Accept: application/json" ``>此时，你应该能看到两个并行的任务均处于 active 状态。
实操四：模拟超时自动流转场景
为了验证超时功能，我们故意不处理“合规专员审批”的任务，只处理“部门经理审批”的任务。
1. 首先获取部门经理的任务 ID（从上一步的返回结果中复制 id）：
```bash 假设获取到的任务ID为 deptTaskId export TASK_ID="deptTaskId" ```2. 完成该任务：
```bash curl -X POST "http://localhost:8080/flowable-rest/service/runtime/tasks/$TASK_ID/complete" \ -H "Content-Type: application/json" ```3. 此时，部门经理的任务已完成，但合规专员的任务仍在挂起。由于我们在 XML 中设置了 PT30M，为了演示效果，我们需要修改数据库中的任务创建时间，或者等待 30 分钟。在开发调试阶段，我们可以通过直接调用 Flowable 的 ManagementService 来触发定时器，或者简单地修改 XML 中的时间为 PT10S（10秒）重新部署测试。
如果将时间改为 10 秒并重新部署，你会观察到：在 10 秒后，原本分配给 complianceOfficer 的任务自动消失，流程实例流转至结束节点。这是因为定时器边界事件触发了 autoPassTask，随后流向了汇聚网关。
实操五：后端集成代码示例
在实际的业务系统中，审批完成后通常需要更新数据库中的档案状态。以下是一段 Java 代码示例，展示了如何在 Spring Boot 集成 Flowable 时，监听流程结束事件并更新业务数据：
```java import org.flowable.engine.delegate.delegateExecution; import org.flowable.engine.delegate.JavaDelegate; import org.springframework.stereotype.Component; @Component public class ArchiveStatusUpdater implements JavaDelegate { @Override public void execute(DelegateExecution execution) { String processInstanceId = execution.getProcessInstanceId(); boolean autoApproved = execution.getVariable("autoApproved") != null && (boolean) execution.getVariable("autoApproved"); // 模拟获取档案ID，实际业务中应从流程变量中获取 String archiveId = (String) execution.getVariable("archiveId"); if (autoApproved) { System.out.println("流程 " + processInstanceId + " 因超时自动通过，更新档案 " + archiveId + " 状态为【自动归档】"); // archiveRepository.updateStatus(archiveId, "AUTO_ARCHIVED"); } else { System.out.println("流程 " + processInstanceId + " 人工审批完成，更新档案 " + archiveId + " 状态为【已归档】"); // archiveRepository.updateStatus(archiveId, "ARCHIVED"); } } } ```将上述逻辑配置在 BPMN 的结束事件监听器或 Service Task 中，即可实现技术闭环。通过这种方式，无论是因为人工快速审批通过，还是因为超时自动流转，最终的档案系统状态都能得到准确更新，彻底解决了审批时间过长导致的数据积压问题。
相关文章
