Java简单工作流引擎应聚焦任务顺序执行、条件跳转与状态管理,用状态机模型(枚举状态+Map映射迁移规则)、外置JSON流程定义、可序列化Context实现暂停恢复,并通过事件钩子支持灵活扩展。
Java中实现简单工作流引擎,核心不在于重造Activiti或Flowable那样的全功能框架,而在于用最少的代码表达“任务顺序执行+条件跳转+状态管理”这三个本质能力。关键是要把流程逻辑从硬编码中解耦出来,让业务开发者能通过配置或轻量API定义流程,而不是改Java类、重新编译。
多数初学者会用一堆if-else判断当前步骤该走哪,结果流程一变就要动代码。更合理的方式是把流程抽象为状态(如SUBMIT→REVIEW→APPROVE→DONE)和迁移规则(比如reviewResult==true时允许迁移到APPROVE)。推荐用枚举定义状态,用Map
把流程结构外置,是走向可维护的关键一步。不必追求BPMN标准,一个简化的JSON就足够:
{ "id": "leave-process", "start": "submit", "nodes": [ {"id": "submit", "type": "service", "action": "com.example.SubmitHandler"}, {"id": "review", "type": "service", "action": "com.example.ReviewHandler"}, {"id": "approve", "type": "service", "action": "com.example.ApproveHandler"} ], "transitions": [ {"from": "submit", "to": "review", "condition": "true"}, {"from": "review", "to": "approve", "condition": "context.get('reviewResult').equals('pass')"}, {"from": "review", "to": "submit", "condition": "context.get('reviewResult').equals('reject')"} ] }启动时解析该JSON,构建Node和Transition对象,运行时按当前状态查表驱动。这样产品提个新流程,运维改个JSON文件重启即可,开发不用上线。
真实业务中流程常跨天、跨系统(比如审批人出差两天才看邮件)。因此必须支持将当前状态+Context序列化到DB或Redis。关键点有三个:
节点数据,防止冗余不需要完整事务,但需保证“保存上下文→触发动作→更新状态”这三步原子性,可用数据库update where version方式实现乐观锁。
当需要在节点执行前后加日志、通知、校验时,别急着让Handler继承某个基类。直接在引擎调度器里预留几个事件点:
用户通过registerListener()注册任意监听器,完全解耦。比如加个邮件通知,只需写一个实现了onNodeExit的MailListener,和流程定义本身零耦合。