oracle-jump-query-public/references/generic-interface.md

# 通用接口业务逻辑

## 业务名称和适用范围

本业务统一称为：**通用接口**。

通用接口通常由四张业务表和一个任务程序入口组成：

```text
H_INTERFACE
H_INSTRUCTION
PUSH_LOG
INF_LOG
AD_PROCESS
```

前四张表描述接口配置和收发队列，`AD_PROCESS` 注册 BOS 可执行的任务程序。它们是常见接口框架，不是所有客户服务器都完全一致的固定数据库契约。不同环境可能出现：

- 某张表不存在，或存在额外的接口方明细、IP 白名单、请求头、参数映射等子表。
- 字段数量、字段类型、默认值、是否可空、索引和约束不同。
- 状态值、限定值组、入站入口函数、出站任务和业务处理过程不同。
- 只有入站接口、只有出站接口，或者入站和出站同时存在。
- `H_INSTRUCTION_ID`、`H_INTERFACE_ID` 只有逻辑关联，没有物理外键。

因此分析通用接口时，必须先查询目标服务器的实际结构、BOS 元数据、限定值和过程源码，不得直接套用其他客户环境的接口名称、过程名、字段列表、状态含义、数据量或结论。

## 核心对象职责

| 表 | 通用职责 | 数据性质 |
| --- | --- | --- |
| `H_INTERFACE` | 定义外部接口方、目标地址和通用回执处理方式 | 接口方配置表 |
| `H_INSTRUCTION` | 定义接口指令、传输方向、处理过程、调度、重试和启停规则 | 核心指令/路由配置表 |
| `PUSH_LOG` | 保存待发送数据，并记录出站推送、重试和处理结果 | 出站队列兼日志表 |
| `INF_LOG` | 保存外部传入请求，并记录入站处理状态和返回结果 | 入站请求兼日志表 |
| `AD_PROCESS` | 注册数据生成、队列封装、队列推送等 BOS 任务程序 | 任务程序注册表 |

可以用下面的业务问题快速理解四表分工：

```text
H_INTERFACE：数据发给谁？目标地址和公共回执如何处理？
H_INSTRUCTION：发什么或收什么？由哪个过程处理？何时执行？
PUSH_LOG：准备发出去什么？是否已经发送和处理成功？
INF_LOG：外部传进来什么？本地是否处理成功？返回了什么？
AD_PROCESS：BOS 任务引擎可以定期执行哪些接口程序？
```

## 常见关系

```text
H_INTERFACE（接口方）
    1
    |
    | 常见关联字段 H_INSTRUCTION.H_INTERFACE_ID
    n
H_INSTRUCTION（接口指令）
    1                         1
    |                         |
    | H_INSTRUCTION_ID        | H_INSTRUCTION_ID
    n                         n
PUSH_LOG（出站记录）       INF_LOG（入站记录）
```

常见但必须核验的关系：

- 出站指令通常通过 `H_INSTRUCTION.H_INTERFACE_ID` 指向 `H_INTERFACE.ID`。
- `PUSH_LOG.H_INSTRUCTION_ID` 通常指向产生或处理该推送记录的指令。
- `INF_LOG.H_INSTRUCTION_ID` 通常指向匹配并处理该入站请求的指令。
- `PUSH_LOG.TYPE`、`INF_LOG.TYPE` 可能保存 `H_INSTRUCTION.CODE`，也可能保存其他接口类型标识。
- `H_INTERFACE` 可能通过 `AD_REFBYTABLE` 关联接口方明细表，用于保存路径、请求方式、请求头、参数或其他分项配置。

不要只根据同名字段认定存在强制关系。必须同时检查：

- `AD_REFBYTABLE` 的 BOS 逻辑关系。
- `ALL_CONSTRAINTS` / `ALL_CONS_COLUMNS` 的物理外键。
- 存储过程源码中的查询和写入条件。

## H_INTERFACE：接口方配置

### 业务职责

`H_INTERFACE` 用于描述一个外部系统或接口目标，常见于出站推送场景。它通常保存接口名称、地址、公共回执解析方式和启用状态，本身不保存具体待推送业务数据。

常见做法是“一个第三方 API 或一类共用地址/回执协议对应一个接口方”。`URL` 提供基础或实际接口地址；第三方回执返回后，框架先调用接口方的 `SETPCDE` 解析传输层结果，再决定是否进入指令级业务处理。一个第三方系统拥有多个地址、请求头或协议时，也可能拆成多个接口方或接口方明细，不能把“一接口一接口方”当成物理约束。

### 常见字段族

| 常见字段 | 常见含义 | 核验要求 |
| --- | --- | --- |
| `ID` | 接口方主键 | 核验主键和生成方式 |
| `NAME` | 接口名称或接口方名称 | 不同环境可能有编码字段 |
| `URL` | 基础地址或目标地址 | 可能拆到明细表或指令表 |
| `SETPCDE` | 通用回执解析或后处理过程 | 必须查源码确认签名和作用 |
| `DESCRIPTION` | 备注 | 不能作为程序判断依据 |
| `ISACTIVE` | 是否可用 | 必须查限定值，不直接假定 Y/N |
| `AD_CLIENT_ID`、`AD_ORG_ID` | 公司、组织 | 检查是否硬编码或从配置继承 |
| 创建人、修改人、创建时间、修改时间 | 审计字段 | 字段名可能不同 |

### 判断原则

- `H_INTERFACE` 为空不一定是异常。如果目标环境只有入站接口，可能根本不需要接口方记录。
- 有出站指令时，如果接口地址不在 `H_INTERFACE`，需要继续检查接口方明细表、`H_INSTRUCTION` 或过程代码中的地址来源。
- 不要仅看到 `URL` 就认为它是完整请求地址；它可能只是基础地址或逻辑来源标识。

## H_INSTRUCTION：接口指令和路由

### 业务职责

`H_INSTRUCTION` 是通用接口的核心配置表。它定义接口指令编号、传输方向、入站处理过程、出站生成过程、调度规则、优先级、重试次数、启用状态和日志保留参数。

### 常见字段族

| 常见字段 | 常见含义 | 核验要求 |
| --- | --- | --- |
| `ID` | 指令主键 | 核验主键和生成方式 |
| `CODE` | 外部或内部使用的指令编号 | 检查是否唯一、是否区分大小写 |
| `NAME` | 指令名称 | 只用于显示，不替代 CODE |
| `INOUT` | 传输方向 | 常见为 `IN`/`OUT`，必须查询限定值 |
| `SETPCDE` | 入站触发处理过程 | 查源码、参数签名、异常处理和影响表 |
| `PCDE_PUSH` | 出站数据生成或推送准备过程 | 查源码确认是否产生 `PUSH_LOG` |
| `H_INTERFACE_ID` | 出站目标接口方 | 入站指令可能为空 |
| `TIMERULES` | 即时、定时或间隔规则 | 必须查询限定值 |
| `TIMES_H`、`TIMES_M` | 定时执行时分 | 字段可能不存在或改名 |
| `SETTIMES`、`SETTIMES_S`、`TIMESCOUNT` | 间隔调度参数 | 核对单位和计时更新任务 |
| `ISRUN`、`ISACTIVE` | 是否运行、是否有效 | 查询限定值和实际过滤条件 |
| `IS_READY` | 调度就绪或运行中状态 | 状态集合以任务过程源码为准 |
| `NUM_REPUSH` | 允许或默认重试次数 | 核对是配置上限还是当前次数 |
| `PRIORITY` | 执行优先级 | 核对数字大/小谁优先 |
| `IS_THROWING` | 是否立即向调用方抛错 | 查入口函数和处理过程如何使用 |
| `IS_IPTEST` | 是否启用来源 IP 校验 | 同时检查白名单表和网络层控制 |
| `IS_DATA` | 是否执行数据处理 | 语义以过程源码为准 |
| `DELQTY` | 常见为日志保留天数 | 必须验证是否真的存在清理任务 |
| `MSG_ERROR` | 最近一次任务错误或执行信息 | 可能被后续执行覆盖，不等于完整历史 |

`CODE` 是接口路由的稳定标识，常见命名为“接口方缩写_业务或档案_功能”，例如用末段区分创建、更新、取消或查询。这个规则用于提高可读性，不替代唯一性约束；入站 API 的 `v_type`、日志的 `TYPE` 和代码中的大小写处理仍须实查。

时间规则的通用语义是：

| `TIMERULES` | 语义 | 配置和触发方式 |
| --- | --- | --- |
| `F` | 即时 | 通常由业务事件直接生成 `PUSH_LOG`；标准任务不轮询调用 `PCDE_PUSH` |
| `D` | 定时 | `TIMES_H`、`TIMES_M` 必填，到达当天指定时刻后把指令置为待执行 |
| `J` | 间隔 | `SETTIMES` 保存选项，配置校验过程换算到 `SETTIMES_S`；任务累计 `TIMESCOUNT` 后触发 |

常见配置校验过程会在 `F` 时清空 `PCDE_PUSH` 和调度字段，在 `D/J` 时要求 `PCDE_PUSH` 及对应时间参数。因而“即时”不等于定时任务立即调用生成过程；必须追踪业务提交过程、表单事件或其他过程在哪里直接写入 `PUSH_LOG`。

### 入站配置的常见约束

- `INOUT` 为入站时，通常必须配置 `SETPCDE`。
- 接口方、推送过程和调度字段通常可以为空。
- 入站入口函数通常按 `CODE` 或 `TYPE` 查找启用指令，然后调用 `SETPCDE`。

### 出站配置的常见约束

- `INOUT` 为出站时，通常需要接口方或可解析出的目标地址。
- 非即时任务通常需要 `PCDE_PUSH` 和有效调度参数。
- 定时或间隔任务可能通过 `IS_READY`、`TIMESCOUNT` 等字段协调执行。
- `PCDE_PUSH` 是 `H_INSTRUCTION` 上的数据生成过程配置，不是 `PUSH_LOG` 字段。标准签名常接收指令 ID，并输出结果码和消息；签名以源码为准。
- `SETPCDE` 是指令级触发/业务处理过程。出站时在接口方回执解析后调用；入站时在请求落入 `INF_LOG` 后调用。

### 分析重点

- `CODE` 是否有唯一约束；如果没有，先查询是否存在重复配置。
- 新增后、修改后是否配置 `TRIG_AC`、`TRIG_AM` 进行配置校验。
- 入口函数匹配 `CODE` 时是否统一大小写，未知指令是否返回明确错误。
- 动态调用过程名是否来自 `SETPCDE` / `PCDE_PUSH`，谁有权限修改这些字段。
- `DELQTY` 是否只是配置，还是确实被清理任务读取。

## PUSH_LOG：出站队列和日志

### 业务职责

`PUSH_LOG` 用于保存待推送到外部系统的数据，并记录同步状态、本地处理状态、重试次数、目标地址、业务关键字、请求内容和外部响应。它通常既是待处理队列，也是历史日志。

### 常见字段族

| 常见字段 | 常见含义 | 核验要求 |
| --- | --- | --- |
| `ID` | 推送记录主键 | 核验生成方式 |
| `H_INSTRUCTION_ID` | 对应出站指令 | 检查物理/逻辑关系 |
| `NAME`、`TYPE` | 接口或业务类型 | 以生成过程为准 |
| `URL` | 实际请求地址 | 可能由接口方配置拼接产生 |
| `JSON`、`JSON_BEFORE` | 待推送、转换前或转换后内容 | 必须查写入源码确认区别 |
| `HEAD_DATA` | 供 BOS 后台接口合并的单条推送附加请求头 | 数据库封装过程不读取并不代表最终请求未使用 |
| `TBSTATUS` | 传输/同步状态 | 查询限定值和任务过程 |
| `DOSTATUS` | 本地处理状态 | 不要与 TBSTATUS 混用 |
| `NUM_REPUSH` | 已重试次数或剩余次数 | 以更新逻辑为准 |
| `DOCNO` | 单号或快速搜索标识 | 可按业务保存单号、手机号、SKU 等；注意索引和脱敏要求 |
| `MSG`、`REMARK` | 处理结果或外部响应 | 可能包含敏感信息 |
| `CREATIONDATE`、`MODIFIEDDATE` | 创建、更新时间 | 用于队列时效和历史分析 |

### 常见状态参考

部分环境中常见：

```text
TBSTATUS：1 未同步、0 同步中、2 同步成功、3 同步失败
DOSTATUS：1 未处理、2 处理成功、3 处理失败
```

这只是常见参考，不是跨服务器固定契约。实际分析时必须从 `AD_COLUMN.OBTAINMANNER`、`AD_LIMITVALUE_GROUP_ID`、`AD_LIMITVALUE` 和任务过程源码核实。

两类状态不能合并解释：

- `TBSTATUS` 表示接口传输/回执解析层是否跑通。常见实现由 `H_INTERFACE.SETPCDE` 的返回码决定；第三方已经收到请求并返回可解析回执时，即使业务结果为拒绝，也可能仍是“同步成功”。
- `DOSTATUS` 表示接口回执后的本地业务处理结果。`H_INSTRUCTION.SETPCDE` 的业务判断、单据处理或异常都可能令它失败。
- 指令没有配置 `SETPCDE` 时，部分实现会直接把 `DOSTATUS` 映射为 `TBSTATUS`；报告必须注明这是回退行为，不代表执行过业务处理过程。

### 标准出站流程

```text
F 即时：业务事件直接生成第三方所需 JSON 并写入 PUSH_LOG
D/J 调度：H_INSTRUCTION_TASK 判断到期
  -> 执行 H_INSTRUCTION.PCDE_PUSH，生成业务 JSON 并写入 PUSH_LOG
两条路径汇合，PUSH_LOG 初始为未同步/未处理
  -> H_INTERFACE_DATA_TASK 补 URL，先把业务 JSON 留存到 JSON_BEFORE
  -> 把 URL、内容、请求头等封装成 BOS 后台可识别的请求 JSON
  -> H_INTERFACE_TASK01 抢占未同步记录并置为同步中
  -> 调用 BOS_INF_PUSH，经 Oracle HTTP 请求 BOS 后台 API，并传入 PUSH_LOG.ID
  -> BOS 后台按 ID 读取数据，合并 PUSH_LOG.HEAD_DATA，并补充应用密钥、签名或 Oracle 不便实现的加密
  -> BOS 后台请求第三方 API，取得完整回执后调用 INF_PUSH_DEAL 回写数据库
  -> 先调用 H_INTERFACE.SETPCDE，更新 TBSTATUS
  -> 再调用 H_INSTRUCTION.SETPCDE，更新 DOSTATUS
  -> 成功结束，或按重试规则重新入队/转人工处理
```

标准过程名是常见实现入口，不是所有客户必须同名。`BOS_INF_PUSH` 通常只负责从 Oracle 发起到 BOS 后台的 HTTP 请求，真正面向第三方的密钥补充、签名、加密和 HTTP 调用在后台 API 完成；只看 Oracle 源码无法证明后台内部行为，必要时还要核对对应后台接口代码。

### 请求数据和请求头封装

- 常见顺序是：`PCDE_PUSH` 先写业务 JSON，封装任务把它复制到 `JSON_BEFORE`，再用 `JSON` 保存包含 URL、业务内容和请求头的外层请求对象。
- 公共请求头可能来自接口方明细表；单条记录的动态或附加请求头保存在 `PUSH_LOG.HEAD_DATA`。旧实现常见形态为 `[{"head":"content"}]`，另一些实现使用 `name`/`value` 对象。
- BOS 标准通用接口中，`HEAD_DATA` 由 BOS 后台 API 按 `PUSH_LOG.ID` 读取并合并到最终第三方请求，数据库侧的 `H_INTERFACE_DATA_TASK` 等过程可能完全不读取该字段。因此，只看 Oracle 表和存储过程无法看到请求头合并动作，也不能据此判断 `HEAD_DATA` 未生效。
- 不要为了让数据库源码“看见” `HEAD_DATA` 而直接修改全局 `H_INTERFACE_DATA_TASK`。排查请求头时，应先确认 `PCDE_PUSH` 是否正确写入 `HEAD_DATA`，再核对 BOS 后台接口代码、运行日志或最终发出的 HTTP 请求。
- 请求头冲突优先级由 BOS 后台接口实现决定，不是 Oracle 数据库固定契约。需要判断公共头和 `HEAD_DATA` 同名时谁覆盖谁，必须查目标客户的后台实现；仅靠数据库查询无法得出结论。

`PUSH_LOG` 为空时，先检查是否存在启用的出站指令和数据生成过程，再判断是“按设计未使用”还是“出站链路没有产生日志”。

## INF_LOG：入站请求和处理日志

### 业务职责

`INF_LOG` 用于接收外部系统传入的数据，保存来源、指令类型、请求内容、处理状态和返回信息。入口函数通常先写日志，再调用指令配置的处理过程，最后把结果更新回同一条日志。

### 常见字段族

| 常见字段 | 常见含义 | 核验要求 |
| --- | --- | --- |
| `ID` | 入站日志主键 | 核验生成方式 |
| `H_INSTRUCTION_ID` | 匹配到的入站指令 | 检查是否存在孤儿记录 |
| `TYPE` | 外部传入的指令或类型 | 核对是否等于 `H_INSTRUCTION.CODE` |
| `URL` | 来源地址、来源 IP 或请求 URL | 字段名不能证明具体语义，查入口参数 |
| `JSON`、`JSON_BEFORE` | 原始或规范化后的请求内容 | 查写入顺序，避免错误假定 |
| `DOSTATUS` | 本地处理状态 | 查询限定值和入口函数源码 |
| `MSG` | 处理结果或返回内容 | 失败消息可能掩盖真实异常 |
| `DOCNO` | 单号或业务关键字 | 可能未填充；注意敏感信息保护 |
| `CREATIONDATE` | 接收时间 | 用于时效、流量和保留期分析 |

### 标准入站流程

```text
第三方请求 BOS 后台 API
  -> 后台调用 GET_HYJINF1(jsonstr, v_type, v_url) 或客户等效入口
  -> 以 v_type 匹配 H_INSTRUCTION.CODE，并检查启用、运行和可选 IP 白名单
  -> 写 INF_LOG，保留来源、TYPE、原始/规范化内容和指令 ID
  -> 动态调用 H_INSTRUCTION.SETPCDE
  -> 根据返回码更新 DOSTATUS 和 MSG
  -> 将业务结果经 BOS 后台返回第三方
```

配置模型要求入站指令使用 `INOUT='IN'`，但部分入口函数只按 `CODE`、`ISRUN`、`ISACTIVE` 匹配，并未在 SQL 中强制过滤 `INOUT`。分析时必须同时核对配置和入口源码；缺少方向校验应作为路由风险记录，不能因表单校验存在就假定运行时一定安全。

### 分析重点

- 是否存在长时间停留在“未处理”的积压记录。
- 失败是业务拒绝还是系统异常；不能只根据 `DOSTATUS` 汇总。
- 处理过程是否把 `WHEN OTHERS` 统一包装成业务错误，导致根因丢失。
- `JSON` 与 `JSON_BEFORE` 是否真的分别保存原始报文和转换后报文。
- `DOCNO` 是否实际填充；如果为空，相关复合索引可能无法发挥预期作用。
- 来源地址是否单一、是否启用 IP 白名单、网络层是否有等效控制。
- 请求内容、响应信息是否包含个人信息、凭证、令牌或其他敏感数据。

## AD_PROCESS 和三段任务链路

`AD_PROCESS` 是 BOS 任务程序注册表，常见字段包括名称、说明、过程名、累计执行次数/耗时和启用状态。通用接口部署通常注册：

| 常见任务 | 常见过程 | 作用 |
| --- | --- | --- |
| 数据接口任务触发 | `H_INSTRUCTION_TASK` | 累加间隔计时，判断 D/J 指令是否到期，按优先级动态调用 `PCDE_PUSH` |
| 数据队列数据封装 | `H_INTERFACE_DATA_TASK` | 处理已生成但尚未补齐地址/外层请求的 `PUSH_LOG` |
| 数据队列推送 | `H_INTERFACE_TASK01` | 抢占已封装的未同步记录，调用 `BOS_INF_PUSH` 进入后台推送链路 |

`AD_PROCESS` 注册“执行什么”，通常不保存完整的执行日历。不能只凭该表判断每十秒、每分钟或每天执行；还要检查 BOS 任务实例/调度配置、调用方和过程源码。标准任务也常设置单批行数、只处理最近记录、优先级和同步中状态，以避免重复推送；这些边界必须逐环境核验。

## 标准分析流程

用户要求分析“通用接口”、核心四表、数据队列或上述任务过程时，按以下顺序执行。

### 1. 确认目标环境

```powershell
python scripts/oracle_skill.py status
python scripts/oracle_skill.py switch <clientCode|clientName>
```

必须确认当前 client、Agent 在线状态和授权状态。不要把一个客户的结构、接口配置或结论复制到另一个客户。

### 2. 确认实际 schema 和表结构

依次执行 `describe`：

```powershell
python scripts/oracle_skill.py describe <schema> H_INTERFACE
python scripts/oracle_skill.py describe <schema> H_INSTRUCTION
python scripts/oracle_skill.py describe <schema> PUSH_LOG
python scripts/oracle_skill.py describe <schema> INF_LOG
python scripts/oracle_skill.py describe <schema> AD_PROCESS
```

如果指定 schema 不正确，使用命令返回的实际 owner，并继续核验 `ALL_TAB_COLUMNS`。不要因为某环境常用某个 schema 就硬编码 owner。

通用物理字段查询模板：

```sql
SELECT OWNER,
       TABLE_NAME,
       COLUMN_ID,
       COLUMN_NAME,
       DATA_TYPE,
       DATA_LENGTH,
       DATA_PRECISION,
       DATA_SCALE,
       NULLABLE,
       DATA_DEFAULT
FROM ALL_TAB_COLUMNS
WHERE OWNER = '<ACTUAL_OWNER>'
  AND TABLE_NAME IN ('H_INTERFACE', 'H_INSTRUCTION', 'PUSH_LOG', 'INF_LOG')
  AND ROWNUM <= 300
ORDER BY TABLE_NAME, COLUMN_ID
```

### 3. 查询 BOS 元数据和字段值域

先确认目标环境 `AD_TABLE` 的实际字段，再查询四表的业务说明、表单事件过程和字段元数据。不同版本的 `AD_TABLE` 可能没有相同的扩展列，遇到 `ORA-00904` 时应先 `describe AD_TABLE`，不要反复套用固定列名。

```sql
SELECT ID,
       NAME,
       DESCRIPTION,
       PROC_SUBMIT,
       HAS_TRIG_BD,
       TRIG_BD,
       HAS_TRIG_AC,
       TRIG_AC,
       HAS_TRIG_AM,
       TRIG_AM
FROM AD_TABLE
WHERE UPPER(NAME) IN ('H_INTERFACE', 'H_INSTRUCTION', 'PUSH_LOG', 'INF_LOG')
  AND ROWNUM <= 20
```

```sql
SELECT t.NAME AS TABLE_NAME,
       c.ORDERNO,
       c.DBNAME,
       c.NAME AS COLUMN_NAME,
       c.DESCRIPTION,
       c.COLTYPE,
       c.OBTAINMANNER,
       c.AD_LIMITVALUE_GROUP_ID
FROM AD_TABLE t
JOIN AD_COLUMN c ON c.AD_TABLE_ID = t.ID
WHERE UPPER(t.NAME) IN ('H_INTERFACE', 'H_INSTRUCTION', 'PUSH_LOG', 'INF_LOG')
  AND ROWNUM <= 300
ORDER BY t.NAME, c.ORDERNO
```

对所有 `OBTAINMANNER='select'` 且具有限定值组的字段，继续查 `AD_LIMITVALUE`。`AD_LIMITVALUE` 的显示列在不同版本可能叫 `DESCRIPTION`、`NAME` 或其他名称，必须先查实际结构。

### 4. 查询关系、约束和索引

- 用 `AD_REFBYTABLE` 查 BOS 主子表和接口方明细关系。
- 用 `ALL_CONSTRAINTS` / `ALL_CONS_COLUMNS` 查主键、外键和 CHECK 约束。
- 用 `ALL_INDEXES` / `ALL_IND_COLUMNS` 查状态、时间、指令和业务关键字索引。
- 特别检查 `H_INSTRUCTION.CODE` 是否唯一，以及日志的 `H_INSTRUCTION_ID` 是否可能成为孤儿。

### 5. 查任务注册、处理过程和后台边界

从以下入口继续追踪：

- `AD_TABLE.TRIG_AC`、`TRIG_AM`：指令配置新增/修改后的校验过程。
- `H_INSTRUCTION.SETPCDE`：入站业务处理过程。
- `H_INSTRUCTION.PCDE_PUSH`：出站数据生成或推送准备过程。
- `AD_PROCESS`：确认 `H_INSTRUCTION_TASK`、`H_INTERFACE_DATA_TASK`、`H_INTERFACE_TASK01` 或客户等效任务是否注册和启用。
- `H_INSTRUCTION_TASK`：核对 F/D/J 实际触发、计时单位、就绪状态和批次边界。
- `H_INTERFACE_DATA_TASK`：核对 `JSON_BEFORE`、URL 和数据库侧外层请求封装；即使源码不读取 `HEAD_DATA`，也不能判定最终请求头缺失。
- `H_INTERFACE_TASK01`、`BOS_INF_PUSH`：核对抢占状态、重试、Oracle HTTP 的后台 API 入口和异常处理。
- BOS 后台 API：核对按 `PUSH_LOG.ID` 读取并合并 `HEAD_DATA`、公共头、密钥、签名和加密的实际规则；该边界无法只通过 Oracle 源码还原。
- `INF_PUSH_DEAL`：核对接口方回执解析与指令业务处理的调用顺序、返回码和两类状态迁移。
- `GET_HYJINF1` 或客户等效入口：核对 `v_type`/`CODE`、方向、启停、IP 白名单、日志落库和返回值。
- 依赖 `INF_LOG` 的函数/过程：查实际入站入口和状态更新逻辑。
- 依赖 `PUSH_LOG` 的过程：查出站任务、重试、状态迁移和回执处理。
- `USER_JOBS`、`USER_SCHEDULER_JOBS` 或 BOS 任务表：查调度和日志清理任务。

遇到标准过程名不存在时，按 `AD_PROCESS.PROCEDURENAME`、`USER_DEPENDENCIES` 和对 `PUSH_LOG`/`INF_LOG` 的源码引用定位等效对象，不要据名称猜测。Oracle 源码只覆盖数据库到 BOS 后台这一段；第三方请求方式、后台补参和加密必须从后台路由或代码继续核验。

优先使用：

```powershell
python scripts/oracle_skill.py deps <schema> <object>
python scripts/oracle_skill.py source <schema> <object>
python scripts/oracle_skill.py analyze <schema> <object>
```

### 6. 做有边界的数据统计

生产环境先限定最近 7 天、30 天或用户指定区间，再按指令和状态汇总。不要直接读取全部 CLOB 请求内容，也不要把敏感请求数据原样写入报告。

常见统计维度：

- 每条指令的调用量、成功量、失败量和未处理量。
- 最早/最近调用时间。
- 每日趋势、失败率和积压时长。
- 失败消息分类，区分业务拒绝和系统异常。
- 出站同步状态、重试次数和最终失败记录。
- 来源地址分布。
- 超出 `DELQTY` 或约定保留期的日志数量。
- 表段、LOB 段和索引空间。

所有业务表查询必须带日期、状态、指令或主键范围，并限制明细行数。统计 CLOB 时优先统计长度、空值和分类；只有排障确实需要时才抽取少量脱敏片段。

## 通用风险检查表

### 正确性

- 处理过程执行 `UPDATE` 后是否检查 `SQL%ROWCOUNT`，避免实际未更新却返回成功。
- 是否校验重复请求和幂等性，重试是否可能重复写业务数据。
- `CODE` 重复、大小写不一致或未知指令时是否返回明确错误。
- 动态调用的过程名是否经过白名单或严格配置权限控制。
- 入站入口是否实际限制 `INOUT='IN'`，出站任务是否实际限制 `INOUT='OUT'`。
- 即时指令由哪个业务事件写入 `PUSH_LOG`，是否可能重复入队。

### 可观测性

- 未处理、处理中状态是否可能长期积压。
- 技术异常是否被统一包装成普通业务失败。
- 日志是否同时保留可对外展示的信息和内部真实错误码。
- `MSG_ERROR` 是否只保存最后一次结果，导致历史被覆盖。

### 数据治理

- `DELQTY` 是否被实际任务读取，保留期是否真正执行。
- 清理前是否满足审计、归档、备份和可恢复要求。
- `JSON`、`JSON_BEFORE` 是否重复存储，原始报文是否真的可追溯。
- `PCDE_PUSH` 是否正确写入 `HEAD_DATA`；BOS 后台是否读取并合并；公共头与单条请求头冲突时谁覆盖谁。不要因数据库封装过程未读取该字段就判定请求头丢失。
- `DOCNO` 等搜索字段是否填充；敏感标识是否应脱敏或哈希。
- 大量 CLOB、失效索引或长期历史是否造成空间增长。

### 安全

- 是否启用来源 IP 校验，或网络层是否有等效限制。
- 请求和响应是否包含密码、令牌、手机号、证件号等敏感数据。
- 接口 URL、请求头和凭证是否被安全保存。
- 谁可以修改 `H_INSTRUCTION.SETPCDE`、`PCDE_PUSH` 和接口地址。

## 报告输出要求

通用接口分析报告至少包含：

1. 目标 client、实际 schema、分析时间和统计区间。
2. 四表是否存在、实际字段差异、行数和当前用途。
3. 指令配置清单：CODE、名称、方向、处理过程、启停、调度和重试。
4. 入站和出站数据流，以及四表关系。
5. 状态值的目标环境实查结果，不直接照搬常见值。
6. 近期调用量、成功、业务失败、技术失败、积压和来源分布。
7. 处理过程、异常处理、幂等性、重试和回执逻辑。
8. 索引、约束、日志保留、LOB 空间和敏感数据风险。
9. 明确区分：通用结构结论、目标环境事实、基于源码的推断、尚待验证事项。

报告中不得写入其他客户的接口名称、过程名、IP、账号、数据量或故障结论。发现字段或流程与本文不同时，以目标环境的实际元数据和源码为准，并把差异记录在报告中。