Activiti7多实例会签实战：从比例条件到自定义逻辑的深度解析
在复杂业务流程中，会签机制是确保决策民主性和科学性的关键技术手段。Activiti7作为业界领先的工作流引擎，其多实例特性为会签场景提供了强大支持。本文将带您超越基础的任务分配，深入探索如何利用Activiti7的多实例机制实现灵活多样的会签逻辑。
1. 多实例会签的核心概念与配置
会签本质上是一种分布式决策机制，它允许一个任务节点由多个参与者共同处理。与简单的任务分配不同，会签需要解决三个核心问题：参与者如何确定、执行顺序如何安排以及完成条件如何判定。
在Activiti7中，多实例会签通过BPMN XML中的multiInstanceLoopCharacteristics元素实现。以下是一个典型的配置示例：
<userTask id="reviewTask" name="立项评审"> <multiInstanceLoopCharacteristics isSequential="false" activiti:collection="${approveUserList}" activiti:elementVariable="approver"> <completionCondition>${nrOfCompletedInstances/nrOfInstances > 0.67}</completionCondition> </multiInstanceLoopCharacteristics> </userTask>关键配置参数说明：
| 参数 | 类型 | 说明 | 示例值 |
|---|---|---|---|
| isSequential | Boolean | 是否顺序执行 | false（并行） |
| collection | Expression | 参与者集合 | ${approveUserList} |
| elementVariable | String | 元素变量名 | approver |
| completionCondition | Expression | 完成条件 | ${nrOfCompletedInstances>1} |
实际应用建议：
- 并行执行（
isSequential="false"）适合无依赖关系的评审场景 - 顺序执行适合需要前序意见参考的场景，如层级审批
- 元素变量名应与任务处理人的赋值表达式一致
2. 比例条件会签的实现与优化
比例条件是最常见的会签完成标准，它通过数学表达式定义通过阈值。Activiti提供了三个内置变量用于条件判断：
nrOfInstances：总实例数（参与者总数）nrOfCompletedInstances：已完成审批的实例数nrOfActiveInstances：尚未完成的实例数
2.1 典型比例条件表达式
// 简单多数通过（超过50%） ${nrOfCompletedInstances/nrOfInstances > 0.5} // 三分之二多数通过 ${nrOfCompletedInstances/nrOfInstances >= 0.6667} // 一票否决制（任一拒绝即终止） ${rejectCount > 0}2.2 Spring Boot集成实践
在Spring环境中启动带会签的流程实例：
@RestController @RequestMapping("/process") public class ProcessController { @Autowired private RuntimeService runtimeService; @PostMapping("/start") public String startProcess(@RequestBody ApproveRequest request) { Map<String, Object> variables = new HashMap<>(); variables.put("approveUserList", request.getApprovers()); variables.put("businessKey", request.getProjectId()); ProcessInstance instance = runtimeService.startProcessInstanceByKey( "projectApproval", request.getProjectId(), variables ); return instance.getId(); } }性能优化技巧：
- 对于大规模会签（>50人），考虑分批加载参与者列表
- 使用异步执行器（async executor）减轻系统负载
- 高频查询时添加
processInstanceId索引
3. 自定义Java条件类的进阶应用
当业务规则超出表达式能力范围时，可以通过实现JavaDelegate或ActivityBehavior接口创建自定义条件类。
3.1 实现自定义完成条件
@Component public class RoleBasedCompleteCondition implements JavaDelegate { @Override public void execute(DelegateExecution execution) { List<String> approvedRoles = (List<String>) execution.getVariable("requiredRoles"); List<String> approvers = (List<String>) execution.getVariable("approveUserList"); Map<String, String> approvals = (Map<String, String>) execution.getVariable("approvalResults"); long requiredApprovals = approvedRoles.stream() .filter(role -> approvers.contains(role) && "approve".equals(approvals.get(role))) .count(); execution.setVariable( "meetsCondition", requiredApprovals >= approvedRoles.size() ); } }对应的BPMN配置：
<serviceTask id="completeCondition" activiti:class="com.example.RoleBasedCompleteCondition"> <multiInstanceLoopCharacteristics isSequential="false" activiti:collection="${approveUserList}"> <completionCondition>${meetsCondition}</completionCondition> </multiInstanceLoopCharacteristics> </serviceTask>3.2 复杂业务场景处理
在实际项目中，我们可能需要处理更复杂的规则：
public class AdvancedCompleteCondition implements JavaDelegate { @Override public void execute(DelegateExecution execution) { // 获取审批历史 List<Comment> comments = taskService.getProcessInstanceComments( execution.getProcessInstanceId()); // 检查关键角色审批情况 boolean hasCEOApproval = checkApprovalByRole(comments, "CEO"); boolean hasCFOApproval = checkApprovalByRole(comments, "CFO"); // 计算总体通过率 double approvalRate = calculateApprovalRate(comments); // 综合判断条件 boolean isComplete = (hasCEOApproval && hasCFOApproval) || approvalRate > 0.75; execution.setVariable("completionFlag", isComplete); } private boolean checkApprovalByRole(List<Comment> comments, String role) { return comments.stream() .anyMatch(c -> c.getType().equals(role) && c.getMessage().contains("APPROVED")); } private double calculateApprovalRate(List<Comment> comments) { long total = comments.size(); long approved = comments.stream() .filter(c -> c.getMessage().contains("APPROVED")) .count(); return (double)approved/total; } }4. 会签与或签的对比与选型
虽然会签和或签都基于多实例机制，但它们的适用场景和实现方式有显著差异：
| 特性 | 会签 | 或签 |
|---|---|---|
| 完成条件 | 自定义复杂条件 | 任意一人完成即可 |
| 执行顺序 | 可顺序可并行 | 通常并行 |
| 业务场景 | 需要集体决策 | 快速响应场景 |
| 数据一致性 | 需要额外处理 | 天然一致 |
| 性能影响 | 较高 | 较低 |
或签的典型配置：
<userTask id="quickApprove" name="快速审批"> <multiInstanceLoopCharacteristics isSequential="false" activiti:collection="${candidates}"> <completionCondition>${nrOfCompletedInstances >= 1}</completionCondition> </multiInstanceLoopCharacteristics> </userTask>在实际项目架构中，建议将会签任务与其他服务解耦：
[客户端] → [API网关] → [流程服务] ←→ [审批服务] ↓ [规则引擎] ←→ [角色服务]这种架构允许：
- 审批服务专注于业务逻辑处理
- 流程服务维护流程状态
- 规则引擎处理复杂决策逻辑
- 各服务可独立扩展和演进
