2635 字
13 分钟

2026-06-05|交付文件查询模块改造

一、今日主要工作#

  • 围绕供应交付智能助手第一期迭代需求,完成 交付文件查询模块 的功能改造与技术文档沉淀。
  • 针对原有交付文件查询中”订单号和设备 SN 共用输入框、纯软订单查不到、签章状态展示不清晰、超限跳转不精准”等问题,重新梳理并优化查询链路。
  • 完成订单号与设备 SN 两类输入方式的拆分,使用户可以明确选择通过销售订单号或设备 SN 查询交付文件。
  • 实现销售订单号直连 IT-GW searchTid 查询路径,避免订单号查询继续依赖 productsys 中 order_dataorder_sninfo 的数据库 JOIN。
  • 优化设备 SN 查询链路,使 SN 查询通过 IT-GW 的 sn 参数定向查询验收材料。
  • 完成签章状态展示优化,将未签章、已签章、无需签章等文件状态进行分栏和标签化展示。
  • 优化文件超限场景下的跳转逻辑,当文件超过展示上限时,生成带订单号参数的专属官网跳转链接。

二、核心完成内容#

1. 交付文件查询需求背景梳理#

今天主要处理交付文件查询模块的迭代需求。原有交付文件查询模块存在几个比较明显的问题:

  1. 订单号和设备 SN 共用同一个输入框:前端和后端都需要根据输入内容进行智能判断,纯数字按订单号处理,含字母按 SN 或关键词处理,逻辑分散且容易出错。
  2. 纯软订单查不到交付文件:原有订单号路径走 productsys 数据库的 order_data INNER JOIN order_sninfo 查询。纯软订单由于没有设备序列号,order_sninfo 中没有记录,JOIN 后返回 0 行,导致即使 IT-GW 中存在文件,也会被系统误判为”查无数据”。
  3. 签章状态展示不清晰:文件列表原来以平铺方式展示,未签章文件、已签章文件、无需签章文件混在一起。
  4. 文件数量超限时跳转不精准:当文件超过 20 条时,原逻辑只展示通用官网链接。

2. 查询链路重构设计#

今天将交付文件查询模块拆分为两条更清晰的路径:

销售订单号查询
→ 前端传 tid
→ AcceptanceMaterialGatewayService.aggregateByTid
→ IT-GW getDiverseData(searchTid=订单号)
→ 返回交付文件 / 验收材料
设备 SN 查询
→ 前端传 keyword + itgwOnly=true
→ AcceptanceMaterialGatewayService.aggregate
→ IT-GW getDiverseData(sn=设备SN)
→ 返回交付文件 / 验收材料

改造后的核心原则是:订单号查询不再走 DB JOIN,直接走 IT-GW searchTid;设备 SN 查询仍走 IT-GW sn;前端通过两个独立输入框明确用户意图。

3. IT-GW Gateway 能力增强#

今天对 AcceptanceMaterialGatewayService 进行了重点改造。将原方法泛化为通用的 fetchDiverse(jwtToken, Map<String, String> formParams, String retryKey, String logLabel),可接收任意表单参数,同时支持 SN 查询和订单号查询。

在此基础上,新增 aggregateByTid(tid, moreUrl) 方法,用于订单号直连 IT-GW 查询,主要完成:校验 IT-GW 聚合能力是否启用、校验订单号是否为空、构造带订单号的官网跳转链接、获取 IT-GW JWT、调用 getDiverseData 传入 searchTid、按文件 URL 去重、判断文件数量是否超过展示上限、返回标准化 payload。

4. 后端服务层改造#

今天对 DeliveryDocumentService 进行了调整,重点新增 queryFileLinksByTid(tid) 方法用于处理销售订单号查询。此外在原 queryFileLinks(keyword) 方法开头增加纯数字判断,纯数字订单号自动兜底路由到 queryFileLinksByTid(),避免回落到旧 DB JOIN。

5. Controller 接口路由改造#

今天对 PangugongDeliveryController.fileLinks() 进行了接口参数扩展,新增 tid 查询参数,路由逻辑调整为:tid 非空优先调用 queryFileLinksByTiditgwOnly=true 则走 queryFileLinksItgwOnly;其他情况走原有 queryFileLinks

6. 前端输入框拆分与交互改造#

今天将原混合输入框拆分为”销售订单号”和”设备 SN”两个独立输入框,前端查询逻辑改为互斥校验:两个都空提示用户输入、两个都填提示只填一个、分别走 tidkeyword+itgwOnly 两条路径。

7. 签章状态分栏展示#

今天根据 signStatus 做分组展示:未签章文件展示”下载”和”签章并下载”、已签章文件展示”已签章”标签和下载入口、无需签章文件展示”无需签章”标签和下载入口。前端渲染时,将未签章文件和已签章 / 无需签章文件拆分为左右两栏展示。

8. 超限跳转逻辑优化#

当 IT-GW 返回文件数量超过配置上限时,订单号查询场景会构造带 tid 参数的订单专属官网短链 https://support.sangfor.com.cn/DocumentDownLoad?tid=订单号,减少用户二次检索成本。

9. IT-GW 配置调整#

今天处理了 dev 环境 IT-GW 配置问题。原 dev 配置指向 UAT IT-GW,但 UAT IT-GW 没有注册当前 clientId。因此将 dev 环境 IT-GW 地址切换到生产 IT-GW,保证本地和 UAT 联调可以验证真实链路。

10. 技术文档沉淀#

今天同步沉淀了《交付文件查询 — 技术实现文档》,文档中记录了原问题背景、改造目标、整体架构链路、签章状态流转、后端核心文件变更、Controller 接口契约、IT-GW 参数说明、前端表单与展示逻辑、部署配置、改动文件汇总和提交记录。

三、今日工作产出#

  • 完成交付文件查询模块改造,实现销售订单号与设备 SN 输入框拆分。
  • 新增 GET /api/pangugong/delivery/file-links?tid=订单号 查询路径,支持订单号直连 IT-GW searchTid
  • 新增 DeliveryDocumentService.queryFileLinksByTid(),使订单号查询不再依赖 productsys DB JOIN。
  • 改造 DeliveryDocumentService.queryFileLinks(),纯数字输入自动兜底路由。
  • 新增 AcceptanceMaterialGatewayService.aggregateByTid(),支持通过 searchTid 查询验收材料。
  • 重构 fetchDiverseForSn() 为通用 fetchDiverse(),支持 SN 和 searchTid 两类参数。
  • 新增对 IT-GW 返回 is_certified 字段的解析,并优先用于签章状态判断。
  • 改造 PangugongDeliveryController.fileLinks(),新增 tid 参数和路由优先级。
  • 重构前端交付文件查询逻辑,新增双输入框互斥校验和定向请求路径。
  • 优化前端签章状态展示,按未签章 / 已签章 / 无需签章进行分栏和标签化展示。
  • 优化超限跳转链接,支持生成带 tid 参数的订单专属官网短链。
  • 调整 dev 环境 IT-GW 配置,解决 UAT IT-GW 未注册 clientId 导致无法调试的问题。
  • 沉淀《交付文件查询 — 技术实现文档》。

四、遇到的问题与解决情况#

1. 纯软订单因缺少 SN 查不到文件#

  • 问题:原订单号查询依赖 order_data INNER JOIN order_sninfo,纯软订单没有设备 SN,JOIN 结果为空。
  • 处理:新增订单号直连 IT-GW searchTid 查询路径,不再依赖产品库中的 SN 关联表。
  • 结果:纯软订单可以绕过 DB JOIN,直接通过 IT-GW 按订单号查询交付文件。

2. 混合输入框导致前后端路由复杂#

  • 问题:订单号和 SN 共用输入框,需要前后端共同判断输入内容,逻辑容易分散且出错。
  • 处理:前端拆分为销售订单号和设备 SN 两个输入框,并增加互斥校验。
  • 结果:用户输入意图更明确,后端路由也更稳定。

3. IT-GW 查询方法原本只支持 SN#

  • 问题:原 fetchDiverseForSn() 方法硬编码 sn 参数,无法复用到订单号 searchTid 查询。
  • 处理:将其重构为通用 fetchDiverse(),由调用方传入表单参数。
  • 结果:同一个底层请求方法同时支持 SN 和订单号查询。

4. 签章状态展示不清晰#

  • 问题:已签章、未签章、无需签章文件混合展示,用户不容易判断应该下载哪个版本。
  • 处理:根据 signStatus 进行分组,未签章文件和已签章 / 无需签章文件分栏展示,并增加状态标签。
  • 结果:文件版本区分更清晰,用户操作路径更明确。

5. UAT IT-GW 无法使用当前 clientId#

  • 问题:dev 配置原本指向 UAT IT-GW,但 UAT IT-GW 未注册当前 clientId。
  • 处理:将 dev 环境 IT-GW 地址切换到生产 IT-GW,保证本地和 UAT 联调可以验证真实链路。
  • 结果:交付文件查询链路可以正常调用 IT-GW 进行测试。

6. 超限场景跳转不精准#

  • 问题:文件数量超过 20 条时,只返回通用官网链接,用户跳转后仍需手动查找文件。
  • 处理:订单号查询时构造带 tid 的订单专属跳转链接。
  • 结果:超限跳转更加精准,用户可以直接进入对应订单的文件页面。

五、明日计划#

  • 继续对交付文件查询模块进行联调测试,重点验证订单号查询、SN 查询、纯软订单查询和文件超限跳转。
  • 使用更多真实订单号和设备 SN 验证 IT-GW searchTidsn 两条路径的返回一致性和稳定性。
  • 补充前端异常状态展示,例如 IT-GW 超时、无文件、JWT 获取失败、签章接口失败等场景。
  • 对签章并下载链路继续做回归测试。
  • 与产品或测试同事确认签章分栏展示是否符合预期,必要时进一步优化 UI 文案和标签样式。
  • 将本次交付文件查询改造与前期订单关注模块、供应风险预警模块一起纳入第一期迭代回归测试范围。

六、总结#

今天主要围绕交付文件查询模块展开开发和改造,解决了原有混合输入框、纯软订单查不到、签章状态不清晰和超限跳转不精准等问题。通过新增订单号直连 IT-GW searchTid 路径、拆分订单号与设备 SN 输入框、重构 IT-GW 通用请求方法、优化签章状态分栏展示和调整 dev 环境 IT-GW 配置,交付文件查询模块的查询链路更加清晰,用户操作也更直观。结合前期完成的订单关注模块 UAT 优化,当前第一期迭代中的核心业务能力正在逐步从功能开发推进到联调验证和体验优化阶段。

2026-06-05|交付文件查询模块改造
https://jupiter-ws.cn/posts/internship/实习日报-2026-06-05/
作者
Jupiter
发布于
2026-06-05
许可协议
CC BY-NC-SA 4.0