CPI

这次工作最初是一份接口问题清单：找到对应的 iFlow，用已有请求触发，结合 Trace 和 S/4 程序逻辑，判断字段为什么没有返回、应该由哪一侧调整。 随着 Bruno 请求集合和历史接口材料补齐，FAQ 接口的工作逐渐明确：先对齐已有可用接口的调用方式，再把登录逻辑从业务 iFlow 中抽出，交给公共 iFlow 管理。这里记录这条已经完成验证的改造链路，以及过程中几个容易误判的地方。 文中的流程名称使用 FAQ_FLOW 和 TOKEN_FLOW 代称。租户地址、凭据别名、业务设备号和原始 Trace 均不公开。代码片段用于说明实现原则，不是可以直接导入任意租户的完整部署包。 从“字段没返回”开始，先建立证据边界 会话前半段涉及多个接口：设备档案、特征值和 FAQ。排查材料既有接口清单，也有数据库查询结果、表截图和业务顾问对记录出现时间的反馈。 这些材料回答的问题并不相同。 材料 可以确认的事情 不能单独推出的结论 Bruno 请求 请求路径、方法、参数、认证方式 当前部署的 iFlow 一定按相同方式调用 CPI Trace 某一次运行中具体步骤的报文 所有调用都经过同一分支 S/4 表记录 查询时该环境中存在这些数据 这些记录一定由某次接口调用创建 ABAP 源码 被阅读版本的取数及处理逻辑 另一 client 的数据和运行结果必然相同 最终 HTTP 响应 调用方实际收到的内容 中间每个步骤都正确 例如，返回中没有 characteristics ，需要继续区分：后端没查到数据、程序没有填充字段、映射没有传递，还是序列化改变了空值的表达方式。 又例如，顾问说“下午之后才出现第一条记录”，这能帮助缩小时间窗口，但不能直接证明记录由我的测试创建。还需要把请求内容、运行时间、消息关联标识和后端写入路径对起来。 因此，这篇文章不把前面所有问题归结为“S/4 的问题”或“CPI 的问题”。后面 FAQ 的修复有独立的请求、部署和运行证据，其结论只覆盖这条链路。 Bruno 提供了认证协议，不能从旧 iFlow 的名字猜 补充材料中的请求集合给出了当前可用的 FAQ 调用方式：先发 JSON 登录请求，取出响应里的 token ，再把它放进业务请求的 Bearer header。 ...