任务描述

该任务只需要完成以下功能点

需求描述

一、背景和价值

   1.背景

      目前仓库业务人员在使用PC端打单比较卡顿，非常影响业务的运作。

   2.价值

      减少PC的卡顿，提升打单的效率，从目前的3秒出完成打单，变成1秒完成。


二、需求描述

   2.1. 功能清单

          1.PC打单软件，开发一个Window Service 服务，预先下载面单文件。

         2.PC打单软件，出面单时，将包裹ID写入Redis。

         3.更新包裹表的状态和添加订单日志的更新方案调整。

         4.网页批量打单和PC批量打单要兼容,防止重复出面单。

         5.包裹撤销打印和撤销拣货功能。

   2.2.影响点

         1.包裹撤销打印和撤销拣货功能

         2.客户订单包裹->可打印，5个打印面单功能。

         3. PC端（客户端）打单功能。


   2.3. 功能描述：

 1.PC打单软件通过OSS面单地址下载面单文件很慢或者超时。
 优化方案：预先下载面单文件。开发一个Window Service 服务，部署到仓库的内网共享服务器，用于下载OSS的面单文件，并且将面单文件保存到该内网共享服务器。由于每个仓库的 地区都不一样，所以每个仓库都会部署一台内网共享服务器，在 Window Service 服务配置文件里面配置固定仓库ID，则每个仓库的Window Service 服务都会下载不同仓库的面单文件。PC软件获取面单的时候，优先从内网共享服务器获取。

2.PC打单软件，出面单的时候，会回调ERP接口，设置包裹状态和添加订单日志的时候，可能会很慢或者超时。
优化方案：不回调ERP接口。出面的时候，不直接回调ERP接口，而是将包裹ID写入Redis。Redis写入数据的速度是毫秒级别的。

3.更新包裹表的状态和添加订单日志
优化方案：几乎接近实时更新包裹状态。将包裹ID写入Redis的同时，发送一条消息到MQ消息队列里面。通过MQ消息队列实时执行的特性，可以做到接近实时更新包裹状态和添加订单日志。并且可以通过增加MQ消费端实例的数量，来提升MQ的性能，做到无限接近实时更新包裹状态和添加订单日志（开发难度高，但是数据库包裹状态的更新延迟非常小，几乎在1秒以内，前提是MQ保持稳定性）。

4.网页批量打单和PC批量打单要兼容的业务
优化方案：都要过滤掉Redis的包裹ID，避免包裹重复出面单。


5.包裹撤销打印和撤销拣货功能。

 优化方案：删除Redis里面的包裹ID，切记避免漏删除或者重复删除的情况。


6. 增加钉钉群提醒或异常监控

    1）Window Service 服务挂了或异常了，提示相关的人员。（如：下载面单服务异常）

    2）出现重复打单或Redis异常 ，钉钉提醒相关人员。（如：包裹ID：xxxx，重复打单）

    3）包裹撤销打印成功了，但是Redis没有删除包裹ID成功，提示信息等。

    4）PC端打单时，将包裹ID写入Redis失败，增加报警或者日志记录等。

   5）更新包裹表的状态和添加订单日志 失败，增加报警或者日志记录等。


7.产品建议（风险考虑）

    1.风险控制，避免出了问题仓库无法运作。（可以后端去控制） 

        1）需要考虑 上述第一点 Window Service  异常或者死机的情况如何处理。

        2）所有的面单不能重新重复下载或者重复打印的情况。

        3）上线后，是否可以指定仓库或者 有一个开关去控制，让某几个仓库人员进行试用，但是不影响主流程（需新旧兼容），没有问题后再大规范切换。

       4）假如上线后全部奔溃或者无法使用，是否有一个开关可以切换回来，但是绝对不要影响已打单的包裹，不要重复打单。

    2.确认主功能的流程不影响，涉及每个打单入口都能正常使用。

    3.假如以上情况都发生了，开发组长是否可以通过修复数据的方式进行相关数据的重置或者修复，确保仓库正常的运作，不能重复打单，切记切记。

验收标准


相关用例
历史记录  
  1. 2022-07-26 16:09:25, 由 程伟 创建。
  2. 2022-07-26 16:10:04, 由 程伟 编辑。
    修改了 最初预计，旧值为 "2"，新值为 "16"。
    修改了 预计剩余，旧值为 "2"，新值为 "16"。
    修改了 任务描述，区别为：
    002- <img src="/zentao/file-read-208000.png" alt="" />
    002+
    002- <p><img src="/zentao/file-read-208000.png" alt="" /></p>
    002+ <p><img src="{208000.png}" alt="" /></p>
  3. 2022-07-26 16:10:14, 由 程伟 编辑。
    修改了 最初预计，旧值为 "16"，新值为 "14"。
    修改了 预计剩余，旧值为 "16"，新值为 "0"。
    修改了 任务描述，区别为：
    002- <img src="/zentao/file-read-208000.png" alt="" />
    002+
    002- <p><img src="/zentao/file-read-208000.png" alt="" /></p>
    002+ <p><img src="{208000.png}" alt="" /></p>
  4. 2022-07-26 16:11:31, 由 程伟 编辑。
    修改了 最初预计，旧值为 "14"，新值为 "21"。
    修改了 预计剩余，旧值为 "0"，新值为 "21"。
    修改了 任务描述，区别为：
    002- <img src="/zentao/file-read-208000.png" alt="" />
    002+
    003+
    002- <p><img src="/zentao/file-read-208000.png" alt="" /></p>
    002+ <p><img src="{208001.png}" alt="" /></p>
    003+ <p><img src="{208000.png}" alt="" /></p>
  5. 2022-07-26 16:14:30, 由 程伟 编辑。
    修改了 最初预计，旧值为 "21"，新值为 "14"。
    修改了 预计剩余，旧值为 "21"，新值为 "14"。
    修改了 任务描述，区别为：
    002- <img src="/zentao/file-read-208001.png" alt="" />
    002+ <img src="/zentao/file-read-208000.png" alt="" />
    003- <img src="/zentao/file-read-208000.png" alt="" />
    002- <p><img src="/zentao/file-read-208001.png" alt="" /></p>
    002+ <p><img src="/zentao/file-read-208000.png" alt="" /></p>
    003- <p><img src="/zentao/file-read-208000.png" alt="" /></p>
  6. 2022-08-05 16:09:32, 由 程伟 编辑。
    修改了 任务状态，旧值为 "wait"，新值为 "closed"。
    修改了 指派给 ，旧值为 "lizhenyu"，新值为 "closed"。
    修改了 由谁关闭，旧值为 ""，新值为 "chengwei"。
    修改了 关闭原因，旧值为 ""，新值为 "cancel"。
    修改了 关闭时间，旧值为 "0000-00-00 00:00:00"，新值为 "2022-08-05 16:09:32"。
返回
所属迭代 技术研发中心 8月第 1 版本（2022年）
所属模块 /
相关需求 PC端打单卡顿的性能优化
指派给 Closed 于 2022-08-05 16:09:32
任务类型 后端
任务标签 初始
开发组
任务状态 已关闭
进度 0%
优先级 P2
关键词
抄送给
由谁创建 程伟 于 2022-07-26 16:09:25
由谁完成 暂无
由谁取消 暂无
由谁关闭 程伟 于 2022-08-05 16:09:32
关闭原因 已取消
最后编辑 程伟 于 2022-08-05 16:09:32
团队 最初预计 总计消耗 预计剩余
工时信息
最初预计 14工时
总计消耗 0工时
预计剩余 14工时
预计开始 0000-00-00
实际开始 0000-00-00
截止日期 0000-00-00