跳转至

Activiti 7.20.0-rc.808

为什么要使用Activiti

想象一下，你的团队正困在一个由电子邮件、即时消息串、Excel表格和“我记得”组成的流程迷宫里。每当有一个新员工要入职，或是一张采购单需要审批，整个部门就如临大敌，陷入一场寻找负责人、追溯历史记录和催促进度的游击战。矛盾就在这里：我们身处数字化时代，却用原始的手工作坊方式管理着现代企业的核心——业务流程。

你或许尝试过硬编码这些流程，将“规则”死死钉在代码里。结果呢？任何细微的业务变动——比如将审批额度从5000元调整到10000元，或是在报销流程中增加一个合规审核节点——都意味着开发人员需要停下手头一切工作，去修改、测试、部署。业务部门在等待中焦灼，技术团队在重复劳动中耗尽创意。这是效率与灵活性之间一场无声的战争。

而Activiti，正是打破这一僵局的“流程解放者”。它让你将业务逻辑从复杂的代码底层中抽离出来，变成可视化的流程图。使用它，不是因为追逐技术潮流，而是为了赢回两项企业最宝贵的资产：时间与清晰度。业务专家能直接设计、优化流程；开发者则从繁琐的流程编码中解脱，专注于更核心的系统能力。它解决的不仅是技术问题，更是组织协同的深层矛盾——让业务奔跑的速度，终于能跟上思维闪光的节奏。

Activiti是什么

简单来说，Activiti是一个轻量级、开源的工作流和业务流程管理（BPM）引擎。它的核心使命是**将现实世界中的业务流程（如请假审批、订单处理）自动化**。

你可以把它想象成一套乐高说明书（BPMN 2.0标准）和一个强大的执行引擎。业务人员用可视化工具画出流程图（说明书），这张图定义了“谁在什么时候做什么”。Activiti引擎则负责严格按照这张图来驱动流程：在正确的时刻，将任务推送给正确的人或系统，并管理流程的状态与数据。它完美地充当了业务需求与IT系统实现之间的翻译官与执行官。

入门示例

真实场景：员工请假流程

让我们描绘一个熟悉的情景：小张想申请三天年假。在传统方式下，他需要发邮件给经理，经理同意后再转发给HR备案，过程松散且难以追踪。

使用Activiti，我们将这样实现：

  1. 流程设计：使用Activiti Modeler（或任何支持BPMN 2.0的工具）绘制一个简单的流程图。流程包含：

    • 开始事件：申请开始。
    • 用户任务“经理审批”：分配给申请人的经理。
    • 排他网关：判断审批结果。
    • 用户任务“HR备案”（仅当审批通过时）：分配给HR专员。
    • 结束事件：流程结束。

  2. 开发示例（基于Spring Boot）：

    • 引入依赖：在pom.xml中加入Activiti Spring Boot Starter。
    • 部署流程：将画好的流程图（.bpmn文件）放入项目的资源目录，应用启动时Activiti会自动部署它。
    • 编写核心代码：
    // 1. 启动一个流程实例（小张发起请假）
ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("leaveApplication", variables);

// 2. 经理查询并完成任务
List<Task> tasks = taskService.createTaskQuery().taskAssignee("经理李总").list();
taskService.complete(task.getId(), approvalVariables); // 李总审批通过

// 3. 此时，引擎会自动将任务推送给“HR专员”
Task hrTask = taskService.createTaskQuery().processInstanceId(processInstance.getId()).singleResult();
taskService.complete(hrTask.getId()); // HR完成备案

// 流程自动结束。

整个过程中，开发者无需关心“如何流转”、“下一步找谁”这些逻辑，引擎会根据流程图自动驱动。业务变更时，只需修改流程图并重新部署，代码在多数情况下无需改动。

Activiti 7.20.0-rc.808版本更新了什么

根据官方发布信息，本次版本更新主要聚焦于维护和提升项目基础健康度，是一次典型的迭代优化。主要变更包括：升级了多个核心依赖库（如Spring Security Crypto, Commons Lang3等）至新版本以获取安全补丁和功能改进；同时更新了构建工具链相关插件（如Maven版本插件、许可检查插件）的版本。此外，对持续集成（CI）的GitHub Actions工作流进行了优化，使用了可复用的工作流脚本并加强了安全检查。为了确保测试环境的兼容性，还特别覆盖了Testcontainers的版本。总体而言，此版本致力于保持项目的稳定性、安全性与开发体验的顺畅。

更新日志

发生了什么变化

⬆️ 依赖更新
  • build(deps): 在1个目录中升级了github-actions组的2项依赖。
  • build(deps): 将org.codehaus.mojo:versions-maven-plugin从2.19.1版本升级至2.20.0版本。
  • build(deps): 将commons-io:commons-io从2.20.0版本升级至2.21.0版本。
  • build(deps): 将org.owasp:dependency-check-maven从12.1.5版本升级至12.1.9版本。
  • build(deps): 将org.apache.commons:commons-lang3从3.19.0版本升级至3.20.0版本。
  • build(deps): 将org.codehaus.mojo:extra-enforcer-rules从1.10.0版本升级至1.11.0版本。
  • build(deps): 将org.springframework.security:spring-security-crypto从6.5.5版本升级至7.0.0版本。
🔨 其他更改
  • AAE-35226：为PR检查使用可复用的工作流。
  • AAE-40082：在GitHub Actions中使用新的action来检查sha。
  • AAE-39907：将org.openjdk.nashorn:nashorn-core依赖从15.6版本升级至15.7版本。
  • AAE-40316：为了Docker兼容性，覆盖了Testcontainers的版本。
  • AAE-40334：将alfresco-build-tools升级至v10.0.0版本。
  • AAE-40032：更新了许可证插件的配置。

完整更新日志：7.20.0-rc.807...7.20.0-rc.808

总结

总而言之，本次更新是一次以**维护和优化为核心**的版本迭代。它并未引入颠覆性的新功能，而是沉稳地夯实了项目地基：通过系统性地升级关键依赖库来强化安全性与功能性，并同步优化构建与持续集成工具链，确保了开发过程的可靠与高效。这体现了项目维护团队对长期稳定性和开发体验的持续关注。