审批流程上线怎么验收？版本分流、在途待办、结果回写与回退检查

测试环境里点通了“提交申请→部门审批→结束”上线就算完成了吗实际最容易漏的是新版定义发布时仍有旧实例在运行新单可能意外启动旧版旧单可能被错误迁移页面上的旧待办虽已隐藏接口仍允许提交引擎显示通过业务单却留在审批中。这几类问题分别发生在定义、实例、任务和业务系统单看一个页面无法发现。本文给出一套有输入、有查询、有阻断条件的流程上线验收方法。例子是虚构的甲公司采购审批V1 为“部门审批后结束”V2 增加“金额超过 1000 元需合规复核”。发布前已有P601/I601停在部门审批发布后新建P602/I6021200 元和P603/I603800 元。另设P604/I604模拟终态回调丢失。示例用 Java 11 和 MySQL 8.x 描述可复核的规则不依赖任何产品内部流程配置。目录发布前先冻结哪些事实发布后先查定义和实例版本在途单据与待办怎样验收通过、驳回与丢回调怎样验收放量和回退的门槛怎样定用 Java 固定验收断言用 SQL 找出遗漏与重复执行顺序与参考资料一、发布前先冻结哪些事实上线验收要回答“发布改变了什么”所以先要保存发布前的基线。只记“版本号 V1”不够还应记定义 ID、实例 ID、当前活动节点、任务 ID、业务单关联和业务状态。否则发布后看见一张“部门审批”待办无法判断它来自旧版实例还是新版实例看见一张已通过业务单也不知道是本次发布产生的还是原来就通过了。样本发布前事实发布后预期要取的证据P601/I6011200 元在 V1 启动部门审批待办未办默认继续绑定 V1按旧路径完成原定义 ID、实例绑定、活动待办P602/I6021200 元发布后才提交使用 V2部门审批后出现合规复核启动返回的定义 ID、节点轨迹P603/I603800 元发布后才提交使用 V2本次让部门驳回直接进入驳回终态定义 ID、驳回轨迹、终态P604/I604故障注入样本引擎通过而业务仍审批中时被发现并恢复引擎终态、业务状态、处理记录这里的“V1 继续运行”是默认策略。若法规或业务决策要求把部分在途单也纳入合规复核需要单独制定迁移清单、映射和审批不应在本次普通发布验收中偷偷改变I601。Flowable 的定义部署文档说明新定义发布会生成新版本按定义键启动的新实例使用最新版本实例迁移文档把在途实例迁移作为单独操作。落地时还要看所用引擎版本和启动 API 的实际行为。发布基线建议导出为一份只读清单release_id、tenant_id、definition_key、old_definition_id、new_definition_id、instance_id、business_id、active_task_id、captured_at。验收记录也带release_id以便后来区分“本次上线造成的差异”和既有存量问题。若生产环境不能创建完整测试单至少在预发环境执行全链路再在生产用脱敏、可清理的小流量样本核对入口和指标。图1发布前固定定义、在途实例、业务状态和待办事实后续才能判断变化是否符合预期。二、发布后先查定义和实例版本发布接口返回成功只能证明引擎接受了定义不能证明业务系统的新单已经路由到它。常见原因包括启动入口显式传了旧定义 ID、应用缓存仍保存旧版本、某个租户没有切到新发布配置或多个服务节点使用的启动参数不一致。因此验收第一步是从新建业务单追到实际实例定义 ID不要从页面显示的流程名称推断版本。对P602和P603分别查业务库里的实例关联再查引擎实例的定义 ID两单都应是 V2 的定义。对P601实例定义仍应是 V1。若I601无迁移决策却变成 V2或I602落到 V1都应暂停放量。不能用“待办看着能办”掩盖版本错配因为金额条件和后续节点可能直到下一步才出错。还要区分发布定义和切换启动入口。前者创建一个可用版本后者决定新请求何时开始用它。大型系统可以先部署并验证定义元数据再小范围启用启动入口。回退时先关闭新版入口或恢复旧入口配置控制新的启动已经生成的 V2 实例不会因为入口回退自动变回 V1需要单列受影响实例继续处理。图2旧单P601保持 V1新单P602、P603必须由实例定义 ID 证实落到 V2。三、在途单据与待办怎样验收版本正确以后验收要从“看得到待办”推进到“谁能办理、旧任务能否继续办理”。对仍在运行的I601和I602正常串行节点通常应各有一条活动待办若流程设计有并行会签预期数量应来自模型而不是固定写成 1。本文的教学样本是串行审批故把“1 条活动待办”作为明确断言。对每条活动待办做四种操作目标办理人查询列表和详情、目标办理人实际提交、无权限用户尝试提交、旧任务链接在完成或转办后再次提交。最后一种必须通过服务端接口验证页面隐藏按钮不能证明旧任务不可执行。任务完成后再查引擎活动任务与业务侧待办投影允许短暂同步延迟但必须有约定的上限和最终一致结果。若P602金额超过 1000部门审批通过后应出现合规复核待办P603在部门环节驳回时应直接结束不应出现合规待办。要验证“800 元且部门通过时跳过合规”这条条件分支应另建一张独立的小额通过样本不能让同一实例既通过又驳回。验收记录至少保留提交前后的task_id、办理人、实例 ID、定义 ID、处理时间、接口结果和当前活动任务列表。否则“审批成功”可能只表示接口响应成功实际待办仍重复留在列表中。注意不要用生产真实待办做破坏性试验。对“无权限用户”和“旧链接重放”使用隔离的验收单若权限系统与待办投影分开存储应同时验证引擎能否办理与业务页面是否可见两者任一侧放行都不算通过。图3检查活动待办、目标办理人、无权限请求及失效旧链接避免只看页面列表。四、通过、驳回与丢回调怎样验收流程结束还没有走完整条链。以P602通过为例至少要同时看到I602APPROVED、P602APPROVED、活动待办为 0、业务侧有结果处理记录、通过后的业务动作按业务键只发生一次。P603则用驳回结果验证反向分支I603REJECTED时不能把业务单写成通过也不能触发通过后的采购动作。故障样本P604/I604故意让终态通知丢失引擎已通过业务单仍审批中。上线验收不是要求“这类窗口永远不存在”而是要求能监测差异、在规定时间内补偿、迟到消息不产生第二次效果。若定时对账发现I604的已提交终态核实组织和原实例绑定后可补写业务状态并记录对账来源若业务单已撤销或出现相反终态应阻断自动补写并人工核对。这部分与上一节的普通通过样本一起验才能证明系统不仅能处理顺畅路径也能从中断处恢复。不能把单个 HTTP 200 当成终态回写完成。流程中心、业务库和后续动作可能各自提交验收要从三处读事实并按instance_id与业务编号关联。如果后续通知是异步的可单独设通知完成时限不应把“审批状态已回写”写成“所有外部动作均已成功”。图4通过、驳回和丢回调三种样本分别核对引擎事实、业务状态、处理记录和后续效果。五、放量和回退的门槛怎样定上线可分为三段发布定义但不切换入口选定组织或小比例新单启动 V2通过验收后扩大到全部目标范围。每段都有可观察窗口和退出条件。发布前就要写清“谁看指标、看多久、出现什么立即停”不能等到故障发生再讨论是否回退。下面是一套示例门槛具体阈值应依据实际流量和业务延迟设定门槛放行证据阻断条件首要动作定义与入口新单实例全部落 V2旧实例保持 V1新单落 V1或旧单无授权迁移暂停 V2 新单入口查启动参数与租户配置待办与权限活动任务数量符合模型越权和旧链接被拒绝重复待办、失效任务可提交停止放量保留任务与权限快照业务回写引擎终态与业务状态一致处理记录可追溯终态相反或重复业务效果关闭新入口隔离受影响实例与后续动作故障恢复丢回调可被发现并补偿迟到消息幂等差异积压持续增长或补偿覆盖冲突暂停自动补偿按实例排查回退不是“删除 V2 定义”或“把所有 V2 实例的版本字段改成 V1”。安全的第一步是停止产生更多受影响实例保存已经启动的 V2 实例清单再决定它们继续、补救还是经预检迁移。即便启动入口切回 V1已经完成的 V2 实例和业务回写也不能靠发布回退倒转。若已产生错误的业务效果还要按业务补偿流程处理不能仅恢复流程配置。发布记录应写出负责人、开始/结束时间、定义 ID、样本编号、失败项、受影响实例数、补偿状态和最终放行人。这样下一次升级时可以复用判定方式而不是只留下“上线正常”四个字。图5版本、待办、回写和恢复四类证据共同决定是否放量入口回退后仍需核对已启动实例。六、用 Java 固定验收断言下面的 Java 11 程序把每张验收单的观察结果归约成失败原因。它不是流程引擎实现也不访问真实接口真正上线时应把读取引擎、业务库和待办接口的适配器接到这些断言前。程序覆盖旧版在途、新版启动、通过、驳回以及五类必须阻断的异常运行方式为javac -encoding UTF-8 Stage10WorkflowReleaseGateExample.java、java Stage10WorkflowReleaseGateExample预期TOTAL 9/9 PASS。importjava.util.ArrayList;importjava.util.List;/** 教学程序将流程上线验收事实归约为可复核的放行结果。Java 11。 */publicclassStage10WorkflowReleaseGateExample{enumVersion{V1,V2}enumState{IN_APPROVAL,APPROVED,REJECTED}enumEngineState{RUNNING,APPROVED,REJECTED}staticfinalclassCaseFact{finalStringorderId,instanceId;finalVersionexpectedVersion,actualVersion;finalStatebusinessState;finalEngineStateengineState;finalintactiveTasks,authorizedUsers,effectCount;finalbooleanoldTaskCanSubmit,resultInboxRecorded;CaseFact(StringorderId,StringinstanceId,VersionexpectedVersion,VersionactualVersion,StatebusinessState,EngineStateengineState,intactiveTasks,intauthorizedUsers,inteffectCount,booleanoldTaskCanSubmit,booleanresultInboxRecorded){this.orderIdorderId;this.instanceIdinstanceId;this.expectedVersionexpectedVersion;this.actualVersionactualVersion;this.businessStatebusinessState;this.engineStateengineState;this.activeTasksactiveTasks;this.authorizedUsersauthorizedUsers;this.effectCounteffectCount;this.oldTaskCanSubmitoldTaskCanSubmit;this.resultInboxRecordedresultInboxRecorded;}}staticListStringcheck(CaseFactf){ListStringfailuresnewArrayList();if(f.orderIdnull||f.instanceIdnull)failures.add(缺少业务单或实例编号);if(f.actualVersion!f.expectedVersion)failures.add(实例定义版本不符);if(f.oldTaskCanSubmit)failures.add(失效待办仍可办理);if(f.activeTasks0||f.activeTasks1)failures.add(活动待办数量异常);if(f.authorizedUsers0||f.authorizedUsers1)failures.add(待办授权人数异常);if(f.engineStateEngineState.RUNNING){if(f.businessState!State.IN_APPROVAL)failures.add(运行中实例与业务状态不一致);if(f.activeTasks!1||f.authorizedUsers!1)failures.add(运行中待办不可唯一办理);if(f.effectCount!0)failures.add(未结束就产生终态业务效果);}else{if(f.activeTasks!0)failures.add(终态实例仍有活动待办);Stateexpectedf.engineStateEngineState.APPROVED?State.APPROVED:State.REJECTED;if(f.businessState!expected)failures.add(终态未正确回写业务单);if(!f.resultInboxRecorded)failures.add(终态缺少处理记录);if(f.effectCount!1)failures.add(终态业务效果不是一次);}returnfailures;}staticvoidrequire(Stringlabel,booleanok){if(!ok)thrownewAssertionError(label);System.out.println(PASS label);}publicstaticvoidmain(String[]args){CaseFactoldRunningnewCaseFact(P601,I601,Version.V1,Version.V1,State.IN_APPROVAL,EngineState.RUNNING,1,1,0,false,false);CaseFactnewRunningnewCaseFact(P602,I602,Version.V2,Version.V2,State.IN_APPROVAL,EngineState.RUNNING,1,1,0,false,false);CaseFactnewApprovednewCaseFact(P602,I602,Version.V2,Version.V2,State.APPROVED,EngineState.APPROVED,0,0,1,false,true);CaseFactnewRejectednewCaseFact(P603,I603,Version.V2,Version.V2,State.REJECTED,EngineState.REJECTED,0,0,1,false,true);CaseFactlostCallbacknewCaseFact(P604,I604,Version.V2,Version.V2,State.IN_APPROVAL,EngineState.APPROVED,0,0,0,false,false);CaseFactduplicateTasknewCaseFact(P605,I605,Version.V2,Version.V2,State.IN_APPROVAL,EngineState.RUNNING,2,1,0,false,false);CaseFactstaleTasknewCaseFact(P606,I606,Version.V2,Version.V2,State.IN_APPROVAL,EngineState.RUNNING,1,1,0,true,false);CaseFactwrongVersionnewCaseFact(P607,I607,Version.V2,Version.V1,State.IN_APPROVAL,EngineState.RUNNING,1,1,0,false,false);CaseFactduplicateEffectnewCaseFact(P602,I602,Version.V2,Version.V2,State.APPROVED,EngineState.APPROVED,0,0,2,false,true);require(旧版在途不被覆盖,check(oldRunning).isEmpty());require(新版实例正常启动,check(newRunning).isEmpty());require(新版通过完整回写,check(newApproved).isEmpty());require(新版驳回完整回写,check(newRejected).isEmpty());require(丢失回调必须阻断放行,check(lostCallback).contains(终态未正确回写业务单));require(重复待办必须阻断放行,check(duplicateTask).contains(活动待办数量异常));require(旧待办可提交必须阻断,check(staleTask).contains(失效待办仍可办理));require(错误定义版本必须阻断,check(wrongVersion).contains(实例定义版本不符));require(重复业务效果必须阻断,check(duplicateEffect).contains(终态业务效果不是一次));System.out.println(TOTAL 9/9 PASS);}}代码中的effectCount代表终态业务动作的实际生成次数包括通过后的采购动作或驳回后的结案动作不是事件到达次数事件可以重投同类业务动作必须按业务键防重。oldTaskCanSubmit也要求真的请求办理接口不能从前端按钮状态推导。若流程含并行任务应替换“活动任务恰好一条”的教学断言为按模型节点计算的期望集合而不是把代码硬套到所有流程。七、用 SQL 找出遗漏与重复下面给出业务侧最小取证表。流程定义、实例和活动任务仍应以引擎 API 或引擎公开查询为准不建议直接修改引擎运行表。业务侧保存原实例与定义 ID才能把新旧版本、结果回写和后续动作串在一起。字段和索引是教学示例可按既有业务表调整。CREATETABLEpurchase_apply(tenant_idVARCHAR(32)NOTNULL,apply_idVARCHAR(32)NOTNULL,amountDECIMAL(12,2)NOTNULL,instance_idVARCHAR(64)NOTNULL,definition_idVARCHAR(128)NOTNULL,state_codeVARCHAR(24)NOTNULL,result_atDATETIME(3)NULL,PRIMARYKEY(tenant_id,apply_id),UNIQUEKEYuk_instance(tenant_id,instance_id),KEYidx_state(tenant_id,state_code,apply_id));CREATETABLEworkflow_result_receipt(tenant_idVARCHAR(32)NOTNULL,event_idVARCHAR(64)NOTNULL,instance_idVARCHAR(64)NOTNULL,apply_idVARCHAR(32)NOTNULL,result_codeVARCHAR(24)NOTNULL,source_codeVARCHAR(24)NOTNULL,handled_atDATETIME(3)NOTNULL,PRIMARYKEY(tenant_id,event_id),KEYidx_apply(tenant_id,apply_id,instance_id));CREATETABLEpurchase_effect(tenant_idVARCHAR(32)NOTNULL,effect_keyVARCHAR(96)NOTNULL,apply_idVARCHAR(32)NOTNULL,effect_typeVARCHAR(32)NOTNULL,created_atDATETIME(3)NOTNULL,PRIMARYKEY(tenant_id,effect_key),KEYidx_apply(tenant_id,apply_id));验收查询按release_id或验收单编号缩小范围以下用四张样本单说明预期。definition_id的具体值应来自发布记录而不是在 SQL 中猜一个“V2”。SELECTapply_id,instance_id,definition_id,state_code,amountFROMpurchase_applyWHEREtenant_idorgAANDapply_idIN(P601,P602,P603,P604)ORDERBYapply_id;-- P601 应绑定旧定义P602/P603/P604 应绑定新定义。-- P602APPROVEDP603REJECTEDP604 补偿后才应为 APPROVED。SELECTapply_id,effect_type,COUNT(*)ASeffectsFROMpurchase_effectWHEREtenant_idorgAANDapply_idIN(P602,P603,P604)GROUPBYapply_id,effect_typeHAVINGCOUNT(*)1;-- 预期 0 行重复回调不应生成第二份同类业务效果。SELECTa.apply_id,a.instance_id,a.state_codeFROMpurchase_apply aLEFTJOINworkflow_result_receipt rONr.tenant_ida.tenant_idANDr.apply_ida.apply_idANDr.instance_ida.instance_idWHEREa.tenant_idorgAANDa.apply_idIN(P602,P603,P604)ANDa.state_codeIN(APPROVED,REJECTED)ANDr.event_idISNULL;-- 预期 0 行终态业务单应有回写或对账处理记录。上述查询只能证明业务库内部的版本记录与处理记录不足以证明引擎事实。最终仍需按instance_id向引擎查定义 ID、终态和活动待办形成“引擎事实↔业务事实”的对照表。还要特别核查P604对账前故意出现差异报警应触发补偿后差异归零、迟到回调再来purchase_effect仍只有一条。MySQL 的SELECT 文档给出GROUP BY和HAVING的语义生产查询应结合实际数据量和执行计划校验。八、执行顺序与参考资料一次可复核的上线演练可以按以下顺序执行发布前保存P601/I601基线发布 V2 并核对定义 ID用小流量创建P602/P603确认都落 V2验证金额分支、授权办理与旧链接拒绝分别完成通过和驳回注入P604丢回调并验证监测、补偿和迟到消息最后汇总 SQL 与引擎查询证据决定放量或暂停。任何一环失败都记录失败样本与受影响范围修复后从失败点重测并复核其前后关联状态。这套验收的核心不是多做几张截图而是让每个结论都有可读取的事实实例用了哪个定义、当前谁有活动任务、终态是否已回写、重复消息是否只产生一次业务效果。发布入口可以回退已启动实例和已发生业务动作仍要单独处理。参考资料Flowable流程定义部署与版本Flowable运行实例迁移MySQLSELECT、GROUP BY 与 HAVING