如何在ServiceNow中关联归档规则？批量归档关联业务记录咨询

我之前帮不少人解决过ServiceNow海量关联数据归档的问题，你遇到的单独写规则达不到预期的情况太常见了——因为这些表是强关联的，必须以Catalog Request为核心，顺着关联链批量处理，才能保证数据一致性不遗漏。下面给你一套可行的落地方案：

核心思路 #

所有待归档的RITM、任务、变量表记录，最终都关联到sc_request（Catalog Request）表。所以我们要以sc_request作为归档入口，每次批量筛选1000条符合时间条件的请求，再逐层找出所有依赖的关联记录，按子表到主表的顺序统一归档（避免外键约束报错）。

具体实现步骤 #

1. 批量筛选待归档的Catalog Request #

先从主表中捞取2.5年以上的1000条请求，注意加限制避免一次性拉取过多数据：

// 计算2.5年前的时间节点
var twoAndHalfYearsAgo = new GlideDateTime();
twoAndHalfYearsAgo.subtractYears(2);
twoAndHalfYearsAgo.subtractMonths(6);

// 从sc_request中获取1000条符合条件的记录
var requestGR = new GlideRecord('sc_request');
requestGR.addQuery('sys_created_on', '<', twoAndHalfYearsAgo);
requestGR.setLimit(1000);
requestGR.query();

2. 捞取所有关联的RITM记录 #

通过请求的sys_id批量关联sc_req_item表：

var ritmSysIds = [];
while (requestGR.next()) {
  ritmSysIds.push(requestGR.sys_id.toString());
}

// 批量获取关联的RITM
var ritmGR = new GlideRecord('sc_req_item');
ritmGR.addQuery('request', 'IN', ritmSysIds);
ritmGR.query();

3. 捞取关联的任务记录（如SCTASK） #

从RITM关联到任务表，这里以sc_task为例，如果有其他任务类型可以换成task主表加类型筛选：

var taskSysIds = [];
while (ritmGR.next()) {
  taskSysIds.push(ritmGR.sys_id.toString());
}

var taskGR = new GlideRecord('sc_task');
taskGR.addQuery('request_item', 'IN', taskSysIds);
taskGR.query();

4. 捞取关联的变量表记录 #

处理sc_item_option和sc_item_option_mtom这两个变量关联表，它们是绑定RITM的变量数据：

// 先处理sc_item_option_mtom，收集关联的变量ID
var mtomGR = new GlideRecord('sc_item_option_mtom');
mtomGR.addQuery('request_item', 'IN', taskSysIds); // 这里传入的是RITM的ID集合
mtomGR.query();

var optionSysIds = [];
while (mtomGR.next()) {
  optionSysIds.push(mtomGR.sc_item_option.toString());
}

// 再获取对应的sc_item_option记录
var optionGR = new GlideRecord('sc_item_option');
optionGR.addQuery('sys_id', 'IN', optionSysIds);
optionGR.query();

5. 按顺序批量归档 #

必须从最底层的子表开始归档，最后处理主表，避免外键约束导致失败：

// 1. 归档sc_item_option
while (optionGR.next()) {
  optionGR.archive();
}

// 2. 归档sc_item_option_mtom
mtomGR.reset();
while (mtomGR.next()) {
  mtomGR.archive();
}

// 3. 归档任务记录
while (taskGR.next()) {
  taskGR.archive();
}

// 4. 归档RITM
ritmGR.reset();
while (ritmGR.next()) {
  ritmGR.archive();
}

// 5. 最后归档Catalog Request
requestGR.reset();
while (requestGR.next()) {
  requestGR.archive();
}

优化与注意事项 #

• 循环处理直到完成：把上述逻辑套在一个外层循环里，每次处理1000条请求，直到requestGR.hasNext()返回false，也就是没有符合条件的记录为止。
• 性能优化：全程用IN查询代替循环内的单条查询，减少数据库交互；如果数据量极大，可以考虑分批次收集ID，避免单个IN条件里的ID过多。
• 错误处理：给脚本加上try-catch块，捕获归档过程中的异常（比如记录被锁定、存在未处理的依赖），确保批量处理的稳定性，不会因为一条记录失败导致整个批次卡住。
• 测试验证：先在测试环境小批量测试（比如每次处理10条），验证所有关联记录都被正确归档，没有遗漏或数据不一致的情况。
• 自动调度：把这个脚本做成Schedule Job，定时执行（比如每周一次），自动完成归档任务，不用手动触发。

替代方案：用Archive Manager插件（如果可用） #

如果你的ServiceNow实例有Archive Manager插件，可以直接创建归档规则：以sc_request为父表，配置所有关联表的归档依赖，设置批量大小为1000，系统会自动处理关联记录的归档。这种方式更可视化，不用写脚本，但需要插件支持。

内容的提问来源于stack exchange，提问作者Darshil Shah