12.16采购运维事项处理
采购下单地址校对问题分析处理
任务描述
12.16采购运维事项处理
采购下单地址校对问题分析处理
| 所属迭代 | 技术研发中心 12月运维事项（2022年） |
|---|---|
| 所属模块 | / |
| 相关需求 | 暂无 |
| 指派给 | Closed 于 2023-01-05 09:18:09 |
| 任务类型 | 运维 |
| 任务标签 | 初始 |
| 开发组 | 敏捷开发组 |
| 任务状态 | 已关闭 |
| 进度 | 100% |
| 优先级 | P2 |
| 关键词 | |
| 抄送给 |
| 由谁创建 | 何建宝 于 2022-12-19 13:45:38 |
|---|---|
| 由谁完成 | 邹声全 于 2022-12-19 13:47:42 |
| 由谁取消 | 暂无 |
| 由谁关闭 | zhengqiao 于 2023-01-05 09:18:09 |
| 关闭原因 | 已完成 |
| 最后编辑 | zhengqiao 于 2023-01-05 09:18:09 |
| 团队 | 最初预计 | 总计消耗 | 预计剩余 |
|---|
| 最初预计 | 6工时 |
|---|---|
| 总计消耗 | 6工时 |
| 预计剩余 | 0工时 |
| 预计开始 | 2022-12-16 |
| 实际开始 | 2022-12-19 |
| 截止日期 | 2022-12-16 |
bug出现原因：
1.1688下单时，会调用这个接口：跨境订单创建com.alibaba.trade:alibaba.trade.createCrossOrder
调用完成后，此时会将下单号信息从地址中清理掉再保存到我们的数据库。
2.紧接着会再次调用这个接口：订单详情查看(买家视角)com.alibaba.trade:alibaba.trade.get.buyerView
如上图所示，程序会判断 国内物流 这个字段是否为null，不为null的话，又进行了一次地址的覆盖——测试环境不会出现这种情况
原因分析：
1.测试环境和线上环境的1688下单 存在差异，导致测试和开发均没发现这种特殊情况；
2.开发时还是要更加注重细节，不放过一个方法调用的逻辑（当然，和工时松紧也有一定关系）
解决方案：
1.尽量保证下单环境能和线上保持一致——下单账号(付款类型之类)、1688配置（比如这次'国内物流'这个字段）等..
2.在发布当天，代码封板后，提前发布一个临时网站，供采购那边使用，提前发现问题。
处理历史数据sql：
--这个 CHARINDEX(' 下单号', a.Alibaba_Address) + 11是动态的，以后如果采购单号超过7位，就不能这么使用了
UPDATE b
SET b.Alibaba_Address = t.newAddress
FROM RB_Alibaba_SingleList b
INNER JOIN
(
SELECT ID,
newAddress = SUBSTRING(a.Alibaba_Address, 0, CHARINDEX(' 下单号', a.Alibaba_Address))
+ SUBSTRING(a.Alibaba_Address, CHARINDEX(' 下单号', a.Alibaba_Address) + 11, 30)
FROM RB_Alibaba_SingleList a
WHERE CustomerID = 1
AND ID > 6506349
AND a.Alibaba_Address like '% 下单号%'
) t
ON b.ID = t.ID;