同步 Skill 1.5.47 公共快照
This commit is contained in:
chen qiang
@@ -180,7 +180,7 @@ PUSH_LOG（出站记录） INF_LOG（入站记录）
|
||||
| `NAME`、`TYPE` | 接口或业务类型 | 以生成过程为准 |
|
||||
| `URL` | 实际请求地址 | 可能由接口方配置拼接产生 |
|
||||
| `JSON`、`JSON_BEFORE` | 待推送、转换前或转换后内容 | 必须查写入源码确认区别 |
|
||||
| `HEAD_DATA` | 单条推送的附加请求头 | 部分环境不存在或封装任务不读取 |
|
||||
| `HEAD_DATA` | 供 BOS 后台接口合并的单条推送附加请求头 | 数据库封装过程不读取并不代表最终请求未使用 |
|
||||
| `TBSTATUS` | 传输/同步状态 | 查询限定值和任务过程 |
|
||||
| `DOSTATUS` | 本地处理状态 | 不要与 TBSTATUS 混用 |
|
||||
| `NUM_REPUSH` | 已重试次数或剩余次数 | 以更新逻辑为准 |
|
||||
@@ -216,7 +216,7 @@ D/J 调度：H_INSTRUCTION_TASK 判断到期
|
||||
-> 把 URL、内容、请求头等封装成 BOS 后台可识别的请求 JSON
|
||||
-> H_INTERFACE_TASK01 抢占未同步记录并置为同步中
|
||||
-> 调用 BOS_INF_PUSH，经 Oracle HTTP 请求 BOS 后台 API，并传入 PUSH_LOG.ID
|
||||
-> BOS 后台按 ID 读取数据，补充应用密钥、签名或 Oracle 不便实现的加密
|
||||
-> BOS 后台按 ID 读取数据，合并 PUSH_LOG.HEAD_DATA，并补充应用密钥、签名或 Oracle 不便实现的加密
|
||||
-> BOS 后台请求第三方 API，取得完整回执后调用 INF_PUSH_DEAL 回写数据库
|
||||
-> 先调用 H_INTERFACE.SETPCDE，更新 TBSTATUS
|
||||
-> 再调用 H_INSTRUCTION.SETPCDE，更新 DOSTATUS
|
||||
@@ -228,8 +228,10 @@ D/J 调度：H_INSTRUCTION_TASK 判断到期
|
||||
### 请求数据和请求头封装
|
||||
|
||||
- 常见顺序是：`PCDE_PUSH` 先写业务 JSON，封装任务把它复制到 `JSON_BEFORE`，再用 `JSON` 保存包含 URL、业务内容和请求头的外层请求对象。
|
||||
- 公共请求头可能来自接口方明细表；单条记录的额外请求头可能来自 `PUSH_LOG.HEAD_DATA`。旧实现常见形态为 `[{"head":"content"}]`，另一些实现使用 `name`/`value` 对象。部分实现会合并两者并让单条请求头覆盖同名公共头。
|
||||
- 请求头合并和冲突优先级不是固定契约。某些服务器虽然存在 `HEAD_DATA` 字段，当前封装过程却完全不读取它。分析时必须在封装过程源码中查找实际字段和覆盖顺序，不能只根据字段存在下结论。
|
||||
- 公共请求头可能来自接口方明细表；单条记录的动态或附加请求头保存在 `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` 为空时，先检查是否存在启用的出站指令和数据生成过程，再判断是“按设计未使用”还是“出站链路没有产生日志”。
|
||||
|
||||
@@ -390,8 +392,9 @@ ORDER BY t.NAME, c.ORDERNO
|
||||
- `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_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` 的函数/过程：查实际入站入口和状态更新逻辑。
|
||||
@@ -448,7 +451,7 @@ python scripts/oracle_skill.py analyze <schema> <object>
|
||||
- `DELQTY` 是否被实际任务读取，保留期是否真正执行。
|
||||
- 清理前是否满足审计、归档、备份和可恢复要求。
|
||||
- `JSON`、`JSON_BEFORE` 是否重复存储，原始报文是否真的可追溯。
|
||||
- `HEAD_DATA` 是否被封装过程读取，公共头与单条请求头冲突时谁覆盖谁。
|
||||
- `PCDE_PUSH` 是否正确写入 `HEAD_DATA`；BOS 后台是否读取并合并；公共头与单条请求头冲突时谁覆盖谁。不要因数据库封装过程未读取该字段就判定请求头丢失。
|
||||
- `DOCNO` 等搜索字段是否填充；敏感标识是否应脱敏或哈希。
|
||||
- 大量 CLOB、失效索引或长期历史是否造成空间增长。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user