企业官网建设流程全解析

做OA系统运维或者二开的朋友，肯定绕不开泛微E-cology（圈内习惯叫fwoa）里的那几张核心表。今天想聊的是workflow_requestbase这张表，以及一个让不少人头疼过的字段：currentnodetype。这名字看起来直观，真到排查问题的时候，取值含义搞不清楚，归档流程的requestid又对不上号，很容易把自己绕进去。

这篇文章就围绕这个主题展开，先讲清楚workflow_requestbase在流程体系里到底扮演什么角色，再逐个拆解currentnodetype不同取值的真实含义，最后给出一套通过requestid去追查归档流程的完整实操方法。不管你是刚接手OA维护的新手，还是已经跟泛微数据库打过几年交道的老手，遇到流程状态判断、归档数据核对、报表统计这类需求，这篇都能给你一些可以照着用的思路和SQL。

1. workflow_requestbase：一张被低估的“流程总账”

1.1 这张表到底存了什么

泛微e-cology的流程引擎非常庞大，围绕一条审批流程会涉及很多张表，比如记录当前办理人的workflow_currentoperator、记录审批日志的workflow_requestlog、记录表单数据的formtable_main_*等等。但所有这些表，几乎都围绕一个核心ID在转，那就是requestid。而workflow_requestbase，就是存放这个核心ID以及流程基础信息的“总账表”。

这张表里的每一条记录，代表一次发起的流程申请。你可以把它理解成快递公司的运单登记簿：快递走到哪个中转站、当前处于什么状态、是谁发的货，这些信息都会在这张表里有一个汇总性的记录。具体到字段，比较常用的包括：

• requestid：流程请求的唯一标识，是整个流程体系的“主键级”字段，后面所有关联查询基本都靠它。
• requestname：流程申请的名称，一般是发起人填写或系统自动生成的摘要。
• workflowid：对应流程模板的ID，也就是这个申请走的是哪一条审批流程。
• currentnodeid：当前节点ID。
• currentnodetype：当前节点类型，这是今天的主角，后面单独展开。
• creater：发起人ID。
• createdate和createtime：发起日期和时间。
• requestmark：流程标记，用于区分正常流程、分支流程等。
• isbill：是否关联了单据或表单。
• archived或类似字段：不同版本叫法有差异，用于标记归档状态。

这些字段在OA界面的流程列表里大多能看到对应的展示，只是界面展示经过了封装，看不到原始字段名。所以，当你需要做二次开发、定制报表或者排查流程异常时，直接跳开界面去查这张表，反而更直观、更准确。

1.2 为什么说它是排查流程的“入口表”

如果你接触过泛微的数据结构，你会发现很多业务表都带有requestid这个字段，比如流程日志表、当前办理人表、表单数据表。而workflow_requestbase恰恰是所有这些表的“上游”：通过一条requestid，你可以从这张表出发，关联出这条流程从发起到结束的所有痕迹。

我在实际工作中，接到过不少类似的排查需求：业务部门反馈某条审批突然“消失”了，或者某条流程在待办里反复出现但无法处理，再或者月底做流程统计时发现数据对不上。这些问题的排查路径，十有八九都是从workflow_requestbase开始的。因为这条记录还在不在、状态是什么、节点在哪，一眼就能看出个大概。

打个比方，你想知道一个人在某个城市的完整活动轨迹，最好的办法是先找到他住的酒店登记信息，也就是workflow_requestbase，然后再根据这个登记信息去调取交通记录、消费记录。没有这个入口，后面所有查询都是无头苍蝇。

1.3 常用关联查询的“表关系地图”

初学者最容易懵的一点是：这些表之间到底怎么关联。我习惯记一张简单的“关系地图”：

• workflow_requestbase.requestid=workflow_requestlog.requestid（获取审批日志）
• workflow_requestbase.requestid=workflow_currentoperator.requestid（获取当前办理人、待办信息）
• workflow_requestbase.requestid=formtable_main_*.requestid（获取具体业务表单数据，需要按实际表名替换）
• workflow_requestbase.workflowid=workflow_base.id（获取流程模板名称）

这套关系捋顺了，后续所有查询都有章可循。至于currentnodetype在中间扮演什么角色，下面单独说。

2. currentnodetype字段深度解读：核心状态机

2.1 常见取值的含义对照表

currentnodetype这个字段，从名字上看是“当前节点类型”，但它实际上更像一个“流程状态指示器”。不同版本、不同流程模板配置下，它的取值含义会有些差异。根据我的实际使用经验，以及和同行交流整理的结果，最常见的取值对应关系如下：

需要注意的是，这个对应关系在不同版本、不同流程引擎配置下可能略有不同。我之前在某个客户的系统里就遇到过一次：他们的归档流程currentnodetype取值为3，但另一个版本的测试环境里，已归档流程却是2。所以，最稳妥的办法是在自己的库里先做一轮数据验证，不要直接照搬网上的结论。

2.2 不同取值背后的业务含义与判断技巧

理解了基本取值，还得知道这些状态对实际业务意味着什么。

currentnodetype=0，说明流程还处于“草稿”状态，发起人可能填了一半就关掉了，或者保存了但没提交。这种流程在待办列表里可能不会出现，但会占用一个requestid。做统计报表的时候，这类数据要不要纳入，需要根据业务口径来判断。我见过不少统计差异问题，最后查下来就是把草稿状态的流程也算进去了。

currentnodetype=1，这是最正常的“流转中”状态。说明流程已经在审批链上走动了，当前办理人可能是某个人、某个角色或者某个部门。如果要排查“流程卡在谁那里”，除了看workflow_currentoperator表，也可以顺手看一下currentnodetype确认流程确实处于进行中，而不是已经结束但待办没清干净。这种情况很常见，尤其是移动端和PC端数据同步出问题的时候。

currentnodetype=2和currentnodetype=3，这两者最容易混淆，也是排查归档流程时最关键的区别。简单来说，2表示流程走到了终点但还没归档，3表示已经归档完毕。归档动作在OA里通常是一个后台任务，有时候审批结束后并不会立刻归档，中间会有一段延迟，这时你会看到状态为2的情况。如果业务上已经走完了审批，但数据库里还是2，可以再等等看，或者手动触发归档任务。而这种场景下，用户端可能出现“审批已完成但列表看不到流程”的情况，实际就是归档流程的查询条件没查对。

currentnodetype=4，强制归档或异常归档。这种一般是管理员干预过，或者流程在某种异常条件下被系统强制结束。遇到这种数据，要特别小心，因为它的审批过程可能不完整，如果有合规审计需求，最好单独筛查出来。

2.3 实际使用中的几个注意点

第一，不要单靠currentnodetype判断流程是否结束。我见过有人写报表统计时只查currentnodetype != 3来统计“未完成流程”，结果把状态为2的流程全部算成了“进行中”，统计结果自然有偏差。正确做法是结合workflow_currentoperator表判断是否还有待办，或者结合requestlog看最后的操作时间。

第二，不同流程模板可能对currentnodetype的语义有自己的“二次加工”。泛微允许在流程节点属性里做很多配置，某些集成场景下甚至可能通过接口直接改写这个字段。所以，如果发现数据状态和你预期不符，先不要急着怀疑字段含义，先看看有没有第三方系统在写数据。

第三，这个字段和归档状态之间不是完全等同的。有些流程虽然currentnodetype=3被归档了，但正文数据、附件数据可能因为归档策略问题没有完整迁移。查归档流程时，不能只看workflow_requestbase这一张表就下结论，还得关联表单表、附件表确认数据完整性。

3. 如何通过requestid查看归档流程：从SQL到实操

3.1 先理解“归档”在fwoa里的数据结构表现

归档流程，从系统逻辑上讲，就是流程实例从“运行时”状态变成了“历史”状态。在这个转变过程中，workflow_requestbase里的currentnodetype会被置为归档对应的值（大多数版本是3），同时，流程相关的待办信息（在workflow_currentoperator表里）会被清掉或标记为已完成。

这里要特别提醒一个点：归档不等于删除。数据都还在，只是换了状态。所以，你要找的归档流程数据，依然可以通过workflow_requestbase表筛选出来。问题往往出在查询条件上，很多人习惯在前端界面去“已办事项”或“归档查询”里翻，但界面层面的筛选条件有时并不完整，尤其是跨年数据、被管理员手动调整过的流程，界面可能看不到，数据库里却能查到。

所以，做归档流程排查和统计时，我更习惯直接走SQL，用requestid或时间范围去定位，再把必要字段关联出来。下面这套实操就是基于这个思路。

3.2 核心SQL：按requestid定位归档流程

假设你已经知道一条流程的requestid，想知道它到底是不是归档状态、当前是什么状态，最直接的SQL是这样的：

SELECT requestid, requestname, workflowid, currentnodeid, currentnodetype, createdate, createtime, creater FROM workflow_requestbase WHERE requestid = 11024;

这条SQL会返回该流程的基本信息和当前节点类型。如果返回的currentnodetype是3，那基本可以确认是归档流程；如果是2，说明流程审批完了但没归档；如果是1，说明流程还在走。拿到这个结果，就能判断下一步该怎么处理。

如果你要批量查看某个时间段内所有已归档流程，可以这样写：

SELECT requestid, requestname, workflowid, currentnodetype, createdate FROM workflow_requestbase WHERE currentnodetype = 3 AND createdate >= '2024-01-01' AND createdate < '2025-01-01' ORDER BY createdate DESC;

这样能把指定时间段内归档的流程全部捞出来。配合workflow_base表可以显示出对应的流程名称，方便核对：

SELECT r.requestid, r.requestname, w.name AS workflow_name, r.currentnodetype, r.createdate FROM workflow_requestbase r LEFT JOIN workflow_base w ON r.workflowid = w.id WHERE r.currentnodetype = 3 AND r.createdate >= '2024-01-01' AND r.createdate < '2025-01-01' ORDER BY r.createdate DESC;

3.3 扩展到查看归档流程的审批记录与正文数据

只知道归档状态还不够，很多时候你是需要把这条归档流程的完整数据导出来，比如审计查证、部门需要补一份历史审批记录。这时要用requestid去关联其他表。

首先，查看这条流程的审批日志：

SELECT l.requestid, l.nodeid, l.logtime, l.operateoredit, l.remark FROM workflow_requestlog l WHERE l.requestid = 11024 ORDER BY l.logtime ASC;

这条SQL能按时间顺序展示这条流程经过的每一个节点，以及每一步的操作人和操作时间。这里要说明一下，logtime是操作时间，operateoredit是操作人ID，如果需要显示姓名，再关联hrmresource表。

其次，如果要看这条归档流程提交的具体业务数据，比如差旅报销的金额、请假的天数，就需要去表单表查询。表单表的名称规则是formtable_main_加上表单ID，比如你这个流程模板对应的是表单ID 12，那表单表就是formtable_main_12：

SELECT * FROM formtable_main_12 WHERE requestid = 11024;

这里你可能会遇到一个问题：你怎么知道这条流程对应的表单表是哪个？可以通过以下SQL去确认：

SELECT r.requestid, r.workflowid, b.formid, b.name AS workflow_name FROM workflow_requestbase r LEFT JOIN workflow_base b ON r.workflowid = b.id WHERE r.requestid = 11024;

拿到formid之后，再拼上formtable_main_前缀去查询即可。不同版本的字段命名可能略有差异，但整体思路是一致的。基本思路就是：requestid在表单表里同样存在，用它再去反查业务数据即可。

3.4 在OA前端界面快速反查requestid的两种方式

有时候手头没有数据库查询权限，只能从前端界面入手，这时怎么拿到requestid呢？我用的比较多的是两种方式。

第一种是看URL。泛微OA的流程相关页面，尤其是流程详情页，网址里通常带有requestid参数。你只需要在前端打开一条归档流程，看浏览器地址栏里的requestid=xxxx，就能直接拿到。这种方法最快，不需要任何数据库权限。

第二种是从“流程监控”或“归档查询”里导出数据。泛微的流程管理功能里，一般有查询后导出的能力，导出的Excel里往往包含requestid字段，或者可以通过流程名称、发起人、发起时间定位后再结合第一种方式拿到ID。如果你在界面做了很多条件筛选，导出后再筛选，效率比自己拼SQL要高。

不过，前端界面能查到多少数据，取决于账号的数据权限范围。如果流程被归档后，当前账号没有权限查看，界面可能直接提示“数据不存在”或“无权访问”，这时数据库排查就是唯一的路子。

4. 常见问题与排查技巧实录

4.1 排查问题速查表

遇到实际问题时，下面几个场景很容易踩坑，我做了一个速查表，方便你对照使用。

4.2 三个容易翻车的细节

第一个细节，不同版本的归档状态值不统一。我在项目实施过程中遇到过几次，E-cology 9.0和某些定制化版本里，归档状态可能是3，也可能是2，还有特殊场景会用4。所以当我接手一个新的环境时，一定会先跑一条SQL，看看currentnodetype到底有哪些取值、分布情况如何，再决定后面的查询条件。这个习惯帮我避免了好几次“查不到数据”的尴尬。

第二个细节，workflow_requestbase表可能存在分表或归档历史库机制。在数据量大的环境下，泛微可能会把历史流程数据迁移到单独的库里，或者对workflow_requestbase进行分区、归档。这时候，你在默认库里查不到老的归档流程，不代表数据丢了，而是它被存到了别的地方。遇到这种问题，建议先问一下DBA或系统管理员，确认当前环境有没有开启历史数据归档，不要急着下“数据丢失”的结论。

第三个细节，requestid不是“永久不重用的”。虽然正常情况下它作为主键不会重复，但在极少数数据修复、手工导入的场景下，可能会出现requestid调整的情况。所以，在做非常关键的数据核对时，最好同时带上requestname、时间范围等辅助条件，避免被异常数据带偏。

4.3 推荐几个排查SQL模板

最后分享几个我平时用的比较顺手的SQL模板，算是个人的“压箱底”经验。

按流程名称模糊查requestid：

SELECT requestid, requestname, workflowid, currentnodetype, createdate FROM workflow_requestbase WHERE requestname LIKE '%差旅费%' AND createdate >= '2024-06-01' ORDER BY createdate DESC;

查某个人发起的所有已归档流程：

SELECT r.requestid, r.requestname, w.name AS workflow_name, r.currentnodetype, r.createdate FROM workflow_requestbase r LEFT JOIN workflow_base w ON r.workflowid = w.id WHERE r.creater = 10012 AND r.currentnodetype = 3 ORDER BY r.createdate DESC;

查某条归档流程当前办理历史（含操作人姓名）：

SELECT l.requestid, l.nodeid, l.logtime, h.lastname AS operator_name, l.remark FROM workflow_requestlog l LEFT JOIN hrmresource h ON l.operateoredit = h.id WHERE l.requestid = 11024 ORDER BY l.logtime ASC;

查所有状态为“审批完成但未归档”的流程，方便决定是否补归档：

SELECT requestid, requestname, workflowid, currentnodetype, createdate FROM workflow_requestbase WHERE currentnodetype = 2 AND createdate < '2024-01-01' ORDER BY createdate ASC;

这类“状态为2”的流程如果积累太多，会占用系统资源，也可能影响部分统计报表的准确性。定期排查并手动触发归档，是OA运维里一个不大不小的日常任务。

5. 写在最后的一些体会

做泛微OA的数据排查和二次开发，其实没什么玄学，关键在于把几张核心表的关系理顺，把状态字段的含义吃透。currentnodetype这种字段，看似不起眼，但哪天业务部门追着你要一份“已归档流程清单”，或者说某条审批流程“凭空消失”了，你能不能快速拿出对的SQL、对的排查路径，就看这些基础功夫扎不扎实。

我个人在操作中的体会是：遇到任何流程状态异常，先别急着从前端界面反复刷新、反复尝试，直接进数据库，用requestid把workflow_requestbase这一条记录拉出来，看看currentnodetype到底停在什么值。只要这个值确定下来，九成以上的问题都能定位到方向。

另外一个小技巧，建议把上面这几个常用SQL保存成一个脚本文件，放在本地或者公司的知识库平台里。下次再遇到归档流程查询、流程状态排查的时候，直接改一下requestid和时间范围就能用，省去每次重新回忆字段含义和表关联的时间。对于经常和泛微数据库打交道的人来说，这种“半自动化”的习惯，能帮你省下大量重复劳动。