2196 字
11 分钟
2026-06-24｜盘古供应风险字段查询接口开发与联想复用方案落地
今日工作日报｜2026-06-24
一、今日主要工作
- 围绕盘古供应风险字段展示需求，完成业务需求分析、数据链路梳理和开发实施计划制定。
- 设计“销售型号联想复用 + 供应风险字段查询新增接口”的两阶段交互方案，明确硬件与配件的差异化数据关联链路。
- 完成供应风险查询 Mapper、请求与响应 DTO、Service 业务逻辑及 Controller 接口的代码开发。
- 完成单硬件、多硬件、单配件及中文参数编码等场景的接口测试，并沉淀开发计划和开发文档。
二、核心完成内容
1. 需求分析与开发计划制定
- 梳理盘古供应字段展示需求，明确用户输入一个或多个销售型号名后，需要查询并返回以下 7 个供应风险字段：
- 原始交付周期；
- 风险期间交付周期；
- 供应回复时间；
- 供应异常原因；
- 紧急项目保障举措；
- 材料链接；
- 供应风险。
- 分析现有系统能力后，确定复用已有销售型号联想接口：
- 前端通过
GET /api/pangugong/supply/models?keyword=xxx获取销售型号候选项； - 用户选择完整销售型号名后，再调用新增供应风险查询接口。
- 前端通过
- 制定新增接口方案：
- 接口地址：
POST /api/pangugong/supply/model-risk-query； - 请求参数支持传入一个或多个销售型号名；
- 返回销售型号、供应链型号编码及 7 个供应风险字段。
- 接口地址：
- 将开发任务拆分为 Mapper、DTO、Service、Controller 和编译测试五个步骤，形成可执行的开发计划。
2. 数据链路与查询方案设计
- 梳理 SCM 数据源中硬件与配件的查询链路：
- 硬件：
scm_model_tosales_machine.sales_model_name→scm_model_code→scm_model_machine； - 配件：
scm_model_tosales_component.sales_model_name→scm_model_num→scm_model_component。
- 硬件：
- 明确硬件与配件风险表中的 7 个目标字段名称保持一致，但关联键不同：
- 硬件使用
scm_model_code； - 配件使用
scm_model_num。
- 硬件使用
- 采用两段查询通过
UNION ALL合并硬件和配件结果，使同一个接口能够同时支持两类销售型号。 - 使用销售型号全称进行精确
IN匹配，避免模糊查询带来的错误命中；型号全称由前端联想接口提前确认。 - 在查询中增加
DISTINCT去重，处理路由表中同一销售型号可能存在重复映射记录的问题。
3. Mapper 与数据访问层开发
- 新增
SupplyRiskModelQueryMapper.java，负责根据销售型号名列表查询硬件和配件供应风险数据。 - 将 Mapper 放置在
com.sangfor.pangugong.mapper.scm包下，由现有 SCM MyBatis 配置统一扫描。 - 使用
@Select注解配合<script>、<foreach>动态构造IN查询，无需额外新增 XML 映射文件。 - Mapper 方法接收
List<String>类型的销售型号列表，并返回List<Map<String, Object>>，统一承接硬件和配件查询结果。 - SQL 同时关联四张 SCM 数据表，完成销售型号到供应链型号以及供应风险字段的映射。
4. DTO 与接口模型开发
- 新增
SupplyRiskModelQueryRequest请求 DTO：- 使用
salesModelNames字段接收一个或多个销售型号名； - 支持逗号、中文逗号、分号和换行等多种分隔方式。
- 使用
- 新增
SupplyRiskModelQueryResponse响应 DTO，封装：- 销售型号名；
- 供应链型号编码；
- 7 个供应风险字段。
- 为响应 DTO 增加 JSON 序列化配置，规范接口字段输出。
- 对数据库查询结果中的空值进行统一处理，转换为空字符串，避免前端展示时出现
null。
5. Service 业务逻辑实现
- 在
PangugongSupplyService中新增queryModelRisk方法，完成供应风险查询的核心业务逻辑。 - 对请求参数进行空值校验，避免无效请求进入数据库查询。
- 复用关键字拆分逻辑，将用户输入按照逗号、中文逗号、分号和换行拆分为销售型号列表。
- 调用
SupplyRiskModelQueryMapper.queryRiskBySalesModelNames查询 SCM 数据源中的硬件和配件风险信息。 - 将 Mapper 返回的
Map<String, Object>转换为SupplyRiskModelQueryResponse，完成数据库字段到接口字段的统一映射。 - 通过构造注入方式引入新增 Mapper，保持现有 Service 依赖管理方式一致。
6. Controller 接口开发
- 在
PangugongSupplyController中新增POST /model-risk-query接口。 - 接口通过
@RequestBody接收SupplyRiskModelQueryRequest。 - 调用 Service 层查询方法并返回
List<SupplyRiskModelQueryResponse>。 - 保持已有销售型号联想接口不变，实现“已有联想能力复用、新增风险字段查询能力”的最小改动方案。
7. 测试验证
- 完成登录认证及 Token 获取流程验证。
- 复用已有销售型号联想接口，验证销售型号候选列表能够正常返回。
- 调用新增供应风险查询接口，完成以下场景测试：
- 单硬件销售型号查询：正常返回 1 条记录及对应供应链型号编码；
- 多硬件销售型号查询：正常返回多条匹配记录；
- 单配件销售型号查询：正常返回配件供应链型号及供应风险字段；
- 中文销售型号参数：通过 UTF-8 请求能够正常解析和返回。
- 验证硬件与配件均可通过同一接口查询，7 个目标字段能够按统一响应结构返回。
- 验证数据库空字段能够转换为空字符串，降低前端展示处理复杂度。
三、今日工作产出
- 完成《盘古供应字段展示—开发计划》，明确需求范围、交互流程、数据链路、SQL 方案、接口设计和实施步骤。
- 新增
SupplyRiskModelQueryMapper.java，完成硬件与配件供应风险数据联合查询。 - 新增
SupplyRiskModelQueryRequest和SupplyRiskModelQueryResponseDTO。 - 完成
PangugongSupplyService.queryModelRisk业务逻辑开发。 - 完成
PangugongSupplyController新接口开发。 - 新增
POST /api/pangugong/supply/model-risk-query供应风险查询能力。 - 完成单型号、多型号、硬件、配件和中文参数场景测试。
- 形成《盘古供应字段展示—开发文档》，沉淀功能说明、数据链路、代码变更、接口使用方式、测试结果及相关表结构。
四、遇到的问题与解决情况
-
问题：硬件和配件分别存储在不同路由表和风险表中，且使用不同关联字段。
处理：分别构建硬件和配件查询 SQL，并通过UNION ALL合并为统一结果。
结果：同一接口能够同时查询硬件和配件的供应风险字段。 -
问题：销售型号路由表中可能存在同一型号对应多条映射记录，容易产生重复结果。
处理：在硬件和配件查询中增加DISTINCT去重。
结果：减少重复数据对接口展示的影响。 -
问题：用户可能一次输入多个销售型号，且使用不同类型的分隔符。
处理：在 Service 层统一拆分逗号、中文逗号、分号和换行。
结果：接口能够兼容单型号和多型号输入。 -
问题：数据库中的部分供应风险字段可能为空，直接返回会产生
null。
处理：在查询结果转换过程中将空值统一处理为空字符串。
结果：接口响应结构更加稳定，前端可以直接展示。 -
问题：中文销售型号通过命令行请求时可能出现编码异常。
处理：使用 Python 或明确 UTF-8 编码方式发送请求。
结果：中文型号能够正常解析并返回对应供应风险数据。
五、明日计划
- 配合前端完成销售型号联想与供应风险查询接口的页面联调。
- 验证多个硬件与配件混合输入时的返回顺序、去重和字段展示效果。
- 补充无匹配型号、空参数和重复型号等边界场景测试。
- 根据页面展示需求进一步确认供应风险字段的格式转换和空值展示规则。
- 整理代码变更和测试结果，为后续代码评审及 UAT 验证提供材料。
六、总结
今日主要围绕盘古供应字段展示需求开展工作，完成了从需求分析、开发计划制定、数据链路设计到后端代码实现和接口测试的完整流程。通过复用已有销售型号联想能力，新增供应风险查询接口，并打通 SCM 数据源中硬件和配件两条查询链路，实现了根据一个或多个销售型号统一返回 7 个供应风险字段。同时完成开发计划和开发文档沉淀，为后续前端联调、代码评审和功能验收提供了完整依据。
2026-06-24｜盘古供应风险字段查询接口开发与联想复用方案落地
https://jupiter-ws.cn/posts/internship/实习日报-2026-06-24/