接到一次数据核对的需求业务方只丢过来一句话“帮我把那笔发起失败的流程找出来把requestid给我。”登录到负责的泛微E-cology环境我的第一反应就是打开workflow_requestbase表按流程名称过滤。流程倒是很快定位了但这个过程中有个字段特别容易让人上头——currentnodetype。明明是同一条流程线发起的数据有的记录值是0有的是2还有的是8这几个数字到底代表什么意思而且业务方问的是“归档流程的requestid”这意味着我还要搞清楚流程归档之后requestid是不是还能查用什么样的方式查最稳这篇文章就顺着这次真实排查过程把workflow_requestbase表里currentnodetype字段的含义讲透同时把“查看归档流程requestid”的几种可靠做法整理出来。适合正在做泛微OA二次开发、流程报表统计、数据迁移核对的小伙伴。文中所有SQL都是实际能跑的我会把每个条件的用意讲清楚而不是丢给你一段代码让你自己猜。1. 先把 workflow_requestbase 放到泛微工作流数据模型里看泛微E-cology的工作流模块数据模型并没有想象中那么复杂。核心就是几张表互相配合workflow_requestbase在其中扮演的是“流程请求主表”也就是每次发起一条流程就会在这张表里插入一条记录。这条记录的主键就是requestid它是一个流程实例在整个生命周期里的唯一标识。很多人第一次接触这张表光看字段名会觉得有点懵。其实只要把“一条审批请求”作为一个中心点周边表就很好理解了。我这里列一下实际工作中最常用的几张配套表以及它们和workflow_requestbase的关系表名角色与workflow_requestbase的关联方式workflow_base流程定义表存放所有流程模板workflow_requestbase.workflowidworkflow_base.idworkflow_node流程节点定义表定义每个节点类型和属性workflow_requestbase.nodeidworkflow_node.idworkflow_requestlog流转日志表记录每次提交、退回、归档动作workflow_requestlog.requestidworkflow_requestbase.requestidworkflow_currentoperator当前操作人表记录待办、已办队列workflow_currentoperator.requestidworkflow_requestbase.requestidformtable_main_xxx表单数据表存放流程关联的业务单据formtable_main_xxx.requestidworkflow_requestbase.requestid为什么要先看这个数据模型因为currentnodetype这个字段里的“节点”两个字指的不是requestbase自身意义上的节点而是workflow_node里定义的节点类型。也就是说workflow_requestbase只是把“当前流程实例停在了哪个节点、这个节点是什么类型”这个结果冗余存储了下来。如果你不看workflow_node、不看workflow_currentoperator单拎出currentnodetype一个字段去猜确实会越绕越晕。拿一条请求的完整生命周期来看就清楚了。流程发起时workflow_requestbase插入新记录requestid生成同时workflow_currentoperator写入当前待办人。每次审批提交或退回workflow_requestlog都会追加一条日志workflow_currentoperator里的待办人会跟着更新。流程走到最后一个节点审批人点击归档workflow_currentoperator中的待办记录被清掉workflow_requestlog写入归档日志workflow_requestbase里的状态字段也会跟着变化。但注意workflow_requestbase里这条记录始终都在这正是我们能查历史归档流程的前提。2. currentnodetype 到底代表什么0、1、2、3、4、5、8的常见语义字段名直译就是“当前节点类型”。泛微工作流引擎里节点并不只有“审批人”这一种还包括会签节点、子流程节点、异常节点、自由流程节点等。currentnodetype就是用来标记当前实例停在哪种节点上的。从我接触过的多个E-cology版本来看currentnodetype常见取值大概是这样currentnodetype值常见业务语义对应场景举例0正常节点常规审批节点某个审批人正在处理待办1异常节点流程找不到下一步处理人、节点配置异常等2并行/会签节点多人同时审批需要所有或部分人签字3子流程节点主流程当前停在某个子流程实例里4自由流程节点下一步节点可以自由指定不按固定路由走5无节点/未指定流程初始化阶段或流程结束后处于无节点状态8归档/结束状态流程已完成归档不再有正在处理的待办节点这里必须强调一句**不同版本的泛微E-cology对currentnodetype取值定义并不完全一致我在8.x和9.x环境里都见过但确实有个别版本针对某些业务场景有差异甚至有极少数环境里会额外出现别的数字。**所以别把网上任何一个“标准答案”直接套到你生产环境上。最可靠的做法是拿你自己环境里的已知数据做验证。验证方法很简单。找两条你心里有数的流程一条是明确还在审批中的一条是明确已经归档的。然后把它们的currentnodetype连同周边字段一起查出来SELECT requestid, requestname, workflowid, nodeid, currentnodetype, isvalid, deleteflag FROM workflow_requestbase WHERE requestid IN (未归档流程的requestid, 已归档流程的requestid);把结果对比一下你就能确切知道自己环境下“审批中”和“已归档”分别对应什么值。我自己的习惯是每接触一个新环境第一件事就是跑这条SQL把样本数据存下来当参考。因为后面做统计报表、写判断条件时依赖的就是这份实测数据而不是文档里的描述。另外要注意currentnodetype和nodeid的配合。nodeid记录的是当前节点IDcurrentnodetype记录的是这个节点的类型。比如查出来一条记录nodeid 345、currentnodetype 2说明流程当前停在345号节点而这个节点被配置成了会签节点。只有两者结合起来看才能准确判断流程“停在哪、是什么状态”。只取一个字段做判断很容易出错。3. 归档后的流程在 requestbase 里会留下哪些特征先说一个容易误解的点流程归档不等于删除数据。workflow_requestbase里的记录会一直保留这也是所有历史流程报表能跑出来的基础。归档前后的区别主要体现在“当前状态”字段和“待办痕迹”上。实际生产环境中归档后的流程通常会有这些变化workflow_currentoperator表里这个requestid的有效待办记录会被清掉或者状态变更所以你查待办是查不到的但这不代表数据丢了。workflow_requestlog里会写入流程结束或归档的日志这是判断“这条流程确实走完了”的铁证。workflow_requestbase里的nodeid、currentnodetype可能会导致变化。比如有些环境里归档后currentnodetype变成5无节点或8归档nodeid变成0或-1有些版本里则保持不变。因为版本差异太大我更推荐用“样本对比法”来判断归档状态而不是直接套用某个字段值。操作步骤是这样的在系统里找到一条你完全确认已经归档的流程拿到它的requestid。再找一条你确认还在审批中的流程也拿到requestid。把两条记录的整行数据拉出来对比SELECT * FROM workflow_requestbase WHERE requestid IN (已归档的requestid, 审批中的requestid);你重点看这几个字段的差异字段名判断思路nodeid归档后是否变成0、-1或某个特殊节点currentnodetype归档后是否变成无节点/归档类型isclosed是否被标记为关闭isvalid是否仍为有效状态deleteflag是否为删除状态还有一个关键点**判断流程是否归档最稳的指标不是requestbase里的单个字段而是“当前操作人表无有效待办 流转日志表有结束归档日志”这两个条件同时成立。**原因是流程如果走到一个异常节点可能requestbase里节点状态看着很奇怪但流程并没有归档反之部分流程因为配置原因归档后currentnodetype还停留在0只看一个字段就会被误导。再提醒一个子流程相关的问题。如果一条主流程里挂了子流程那么子流程实例在workflow_requestbase里也有自己独立的requestid通常会有一个字段常见是mainrequestid或类似命名指向主流程的requestid。你在统计“一整单完整流程”的时候注意把主流程和子流程的记录都考虑进去否则统计出来的数量会偏少或者对不上账。4. 查归档流程的 requestid这几条路都能走通实际业务中“查requestid”有不同的场景有人只知道流程标题有人只知道经办人有人只记得表单上的单据号还有人甚至连流程名都说不清只给一个大概时间范围。针对不同场景用的方法也不一样。下面这几条路我都实际走过按推荐程度排个序。4.1 方法一前端打开流程详情直接从URL里拿这是我认为最快的方法没有之一。如果用户还能打开那条已归档流程——不管是从已办事项进还是管理员从流程监控里进——只要流程详情页面能在浏览器里正常打开地址栏URL里基本都会带有requestid参数。直接把那一串数字抠出来就是结果。这个方法适合绝大多数“帮我查一下某条流程的requestid”的临时需求不用写SQL不用猜表结构也不用担心删没删数据。要注意的是有些页面URL经过二次封装可能不直接显示requestid而是显示一串加密参数但泛微的管理端在流程监控详情打开时URL通常还是会暴露这个关键ID的。4.2 方法二管理员后台流程监控可视化搜索泛微自带“流程监控”功能进入后端应用中心找到流程管理下的流程监控按流程名称、发起人、发起时间范围、当前节点等条件组合筛选列表里就能看到每一笔流程的requestid。这个方法不需要写SQL适合不太熟悉数据库的同事去操作。如果说有什么要注意的那就是流程监控的查询范围受权限控制普通账号可能只能看到部分数据管理员账号才看得全。如果你用的是受限账号查不到归档数据先检查权限再考虑走SQL路线。4.3 方法三按流程名称查workflowid再查requestbase这是数据库查询里最基础的一条路。流程名称是最容易获取的信息先通过workflow_base拿到workflowid再回workflow_requestbase按流程ID过滤。-- 第一步根据流程名称查流程ID SELECT id, workflowname FROM workflow_base WHERE workflowname LIKE %合同审批%; -- 第二步把上面查到的id填进下面的workflowid SELECT requestid, requestname, workflowid, nodeid, currentnodetype, creater, createdate FROM workflow_requestbase WHERE workflowid 123 ORDER BY requestid DESC;第二步的ORDER BY requestid DESC是有意加的。在泛微里requestid通常是自增生成的ID越大说明发起时间越晚。这样排序最新的流程记录会出现在最上面方便快速定位目标。4.4 方法四按创建人/部门/时间范围组合查如果只知道大概是谁发起的、大概是什么时候的流程那就在第三步的基础之上组合条件SELECT r.requestid, r.requestname, r.workflowid, r.creater, r.createdate, r.nodeid, r.currentnodetype, r.deleteflag FROM workflow_requestbase r WHERE r.workflowid 123 AND r.creater 456 AND r.createdate BETWEEN 2024-01-01 AND 2024-06-30 AND r.deleteflag 0 ORDER BY r.createdate DESC;这里有个很重要的细节我加了r.deleteflag 0。泛微的表设计里删除标记字段普遍存在不一定是deleteflag这个名字但逻辑是一样的。如果漏掉这个条件统计出来的数据可能会把作废流程都算进去数量虚高后面核对的时候特别头疼。4.5 方法五按表单字段值反查requestid这个方法强烈推荐记下来。因为业务方经常不记得流程标题但一定记得单据号比如“采购单号CG20240001”。这时候先去表单表里反查。泛微里每条流程关联的业务表单表名一般是formtable_main_表ID这样的格式表内主键通常就是requestid。拿到这条记录后再回workflow_requestbase查完整流程信息-- 第一步先确认业务表单里的单据号反查requestid SELECT requestid, col1, col2 FROM formtable_main_123 WHERE col1 CG20240001; -- 第二步带回requestbase查完整流程信息 SELECT requestid, requestname, workflowid, creater, createdate, nodeid, currentnodetype FROM workflow_requestbase WHERE requestid 上面查到的requestid;实际项目中这种方法在财务对账、采购核对场景里特别常用。要注意的是formtable_main_123这个表名里的数字对应的是流程表单设置的内部表ID不同流程不一样。怎么确认表名可以在流程表单设计页面里看也可以在数据库里用formtable_main_开头模糊匹配表和流程的对应关系。这个细节如果环境里不好确认先让系统管理员帮你定位表单表名比自己猜要快得多。4.6 方法六通过流转日志反查或验证上面几种方法拿到requestid之后我强烈建议顺手做一步验证查一下这条流程在workflow_requestlog里的流转记录确认它的归档动作确实存在。SELECT requestid, nodeid, actionname, operateid, operatetype, operatordate, operatortime FROM workflow_requestlog WHERE requestid 上面查到的requestid ORDER BY id;这条SQL的作用有两个。一是验证如果日志里能看到归档/结束相关的动作记录那这个requestid对应的流程确实是归档状态业务方要的就是这条。二是追溯当只知道某个节点处理人时也可以从workflow_requestlog按操作人反查出requestid虽然这种情况用得少但多一条路总比卡住强。5. 实战中的版本差异与踩坑经验5.1 版本差异导致currentnodetype取值对不上这是我踩过最实在的一个坑。刚开始做泛微项目时我拿A环境总结出来的“currentnodetype8代表归档”这个结论直接拿去B环境写统计报表结果跑出来的归档数据明显不对。后来一查B环境的归档流程在currentnodetype里根本没有8这个值很多都停在了5。所以我现在养成了一个习惯**凡是涉及状态字段判断先在当前环境拉样本数据确认再写条件。**这个问题看起来小但一旦写进报表逻辑返工成本很高。5.2 只靠currentnodetype判断归档不可靠前面已经提过流程如果走了会签、子流程、退回分支状态字段的组合会很复杂。比如说一条流程在最后一个节点被退回重填它的currentnodetype可能又是0、又是2但流程绝对没有归档。这时候如果拿“currentnodetype某值”来筛归档流程结果一定不准确。我的经验是归档判断标准应该是一个组合条件**workflow_currentoperator表里无有效待办 workflow_requestlog里有归档/结束日志 workflow_requestbase的deleteflag0。**三个条件同时满足才能比较放心地说这条流程归档了。5.3 deleteflag和isvalid统计时最容易漏的过滤条件有段时间我做流程数量月报发现数字比OA后台统计的多了不少。排查到最后原因就是我把deleteflag 0和isvalid 1这两个过滤条件漏了。泛微里消息流程、作废流程在workflow_requestbase里都有记录如果不排除掉统计结果必然虚高。建议在写任何查询前先想清楚业务上“有效流程”的定义再把对应的过滤条件写进SQL里。这比写完再找差异要省事得多。5.4 子流程的requestid会“多”出来主流程挂子流程的场景会让初次接触的人觉得数据“多了一条”。子流程实例在workflow_requestbase中是独立记录有自己的requestid同时会通过类似mainrequestid的字段指向主流程。如果业务方要的是“一整单主流程”你只查主流程的requestid没问题但如果你要做流程实例总数统计就一定要决定好子流程算不算否则数量怎么都对不上。5.5 currentoperator查不到待办不代表流程丢了还有一个小场景有人发现workflow_currentoperator里查不到某条归档流程的待办记录就以为数据丢了。其实恰恰相反归档流程的待办记录被清理是正常现象。要确认一条流程是否存在应该看workflow_requestbase和workflow_requestlog而不是看待办表。最后说一个我自己的习惯不管用上面哪种方法查到requestid我都会顺手再执行一条SELECT * FROM workflow_requestbase WHERE requestid xxx把这条记录整行过一遍。特别是currentnodetype、nodeid、deleteflag、isclosed这几个字段多看一眼花不了30秒但能让你对“这条流程现在到底是什么状态”心里有底做报表、给业务方答复的时候都更有把握。这个习惯帮我避过不少雷希望你也能用上。