流程实例、节点审批与业务回调

一次业务提交可以产生一个流程实例，实例内可有多个审批节点任务，结束后仍保留历史信息。审批完成还需要通知业务服务落地变更；因此“流程通过”和“所有业务回调成功”是两个需要分别查询的事实。

几种ID不可混用

标识	示例用途	归属
model_id	设计者正在维护的模型	Flowable设计对象
process_definition_id	某次发布后的可执行定义版本	Flowable定义
process_instance_id / 事件id	一次实际审批流程	Flowable运行及历史对象
task_id	该流程中的一次审批工作项，不是Task微服务投放任务ID	Flowable任务及抄送关联
business_key	发起方业务主对象的ID字符串	业务服务解释；不同业务可能使用相同数字
message_key	一次状态事件的关联键，连接原始消息和各服务处理回执	BPM状态消息记录
ruleBusinessInfos[].businessId	需要跟随审批变化的规则业务对象ID	rule业务绑定；可能是主表ID，也可能是广告位ID

按业务ID查询流程应结合流程定义key或流程实例ID限定业务范围。BpmProcessInstanceServiceImpl查询/取消API中的组合条件体现了这一点；business_key不是跨服务全局主键，也没有跨库外键。

发起、审批和历史

实例创建校验定义可用、发起权限及候选人后，把表单变量和系统变量交给RuntimeService，设置PROCESS_STATUS=审批中并启动实例。节点审批通过时，BpmTaskService写审批意见、更新流程变量、调用TaskService完成任务；拒绝、退回、委派、转派走各自引擎操作，不能简化成只更新一列状态。

流程状态存于流程变量并在状态事件中传递：当前枚举为-2系统错误、-1未开始、1审批中、2通过、3不通过、4取消。任务节点另有TASK_STATUS，业务服务又有valid/draft。这些状态属于不同对象，不能用一个数字表通解。完成监听发现流程仍为RUNNING时改成APPROVE，再通知申请人、发业务事件，并按配置执行流程后置通知。

运行态由act_ru_*承担，历史列表和轨迹通过HistoryService查询act_hi_*。审批原因还存在项目直接SQL读取：FlowableUtils.getTaskReason按TASK_ID从ACT_HI_COMMENT取最近非空评论，说明框架表也有本项目显式读依赖。

自定义运行辅助表

表	业务作用	关键关系
bpm_process_instance_copy	“抄送给我”的独立查询记录；每个接收用户形成记录，保留流程/节点名称快照及原因	process_instance_id/process_definition_id/activity_id/task_id关联引擎对象，start_user_id/user_id关联system；均为逻辑关系
bpm_oa_leave	模块内请假业务示例；先存申请，再发起oa_leave流程并回填实例ID	user_id申请人，start_time/end_time/day请假区间及天数，status保存审批结果；day由源码计算整天间隔
bpm_instance_status_message	审批状态事件发送与各服务处理结果的跟踪、重试、忽略	message_key关联事件，parent_id关联根消息，retry_topic区分服务补偿入口

抄送服务的单taskId重载存在字段传递疑点，见核验页；此处列的是字段业务意图，不宣称当前所有抄送记录均正确关联节点。

回调消息如何维护

Publisher先写一条parent_id=0、status=WAITING、retry_count=0的消息记录，保存序列化事件，再向bpm-inst-status-ycs发送Kafka消息。业务监听基类同时消费公共主题和带应用名的补偿主题，按流程定义key或前缀判断是否处理。执行后通过BpmProcessInstanceApi回写成功或失败及异常信息。

消息状态为0待处理、1成功、2失败、3忽略；与process_instance_status分开。回执Service先更新根消息，再按retry_topic更新或创建子记录。根消息的成功不能单独证明所有服务都已成功，需要结合各服务子记录判断。源码message_key由毫秒时间戳加随机数生成，数据库没有唯一索引；这是事件关联键，不是本次已验证的全局去重保障。

人工重试取保存的JSON并发送到指定或原补偿主题，递增重试次数；忽略仅允许待处理或失败状态。这套记录机制提供排查与补偿入口，但本次没有验证Kafka发送确认、事务提交顺序、重放幂等性或跨服务原子性，不将其描述为“恰好执行一次”。

与业务草稿的关系

业务服务	已确认的关联方式
task	业务主表ID作为businessKey；Task监听审批结果后更新自己的主表/关系、草稿及有效状态；规则业务类型为TASK_PUSH
launcher	launcher主表ID作为businessKey；ruleBusinessInfos可以是一组广告位ID，不能直接用主表ID替代规则业务ID
blacklist	黑名单主表ID作为businessKey，规则业务ID也取该主表ID；对应服务落地黑名单变更

BPM不直接更新上述服务业务库；它传递结果和业务标识。draft/valid保存于相应业务表，定义key前缀用于监听分流。BPM中的模型草稿则是尚未发布的设计，两种“草稿”不可混为一谈。

源码证据：service/task/BpmProcessInstanceServiceImpl.java:743、:922、:1023；service/task/BpmTaskServiceImpl.java:523、:748；framework/flowable/core/util/FlowableUtils.java:300；service/task/BpmProcessInstanceCopyServiceImpl.java:50；service/oa/BpmOALeaveServiceImpl.java:47；framework/flowable/core/event/BpmProcessInstanceEventPublisher.java:36；service/instancestatusmessage/BpmInstanceStatusMessageServiceImpl.java:108。API证据：event/BpmProcessInstanceStatusEvent.java:22、event/BpmProcessInstanceStatusEventListener.java:28、enums/task/BpmProcessInstanceStatusEnum.java:20。

跨服务证据（相对各服务Java根）：task的service/task/TaskBpmServiceImpl.java:105与:429；launcher的service/push/LauncherBaseInfoBpmServiceImpl.java:152与:190、listener/BpmLauncherStatusListener.java:27；blacklist的service/blacklisted/AppBlackListedBpmServiceImpl.java:116与:131、listener/BpmBlacklistStatusListener.java:27。