bjev三期数据迁移计划

2017-11-15  本文已影响0人  时代小召唤

由于二期全部都使用的sqlserver linq to sql.所以为了实现工单流程功能,在工单表中会有超多的字段，而三期引入mongodb，模型设计也有所不同，数据迁移需要单独着重考虑

迁移任务

方案

关于工单迁移 , 二期项目提供一个接口:

OrdersPagedResult GetOrders(int skip,int limit,datetime lastModifiedWhen,string orderId="");

public class OrdersPagedResult {
  public int totalCount{get;set;}
  public List<Orders> {get;set;}
}

可以通过对应 时间/单号 分批 获取到所有的工单 orders模型按照三期的标准模型转换

三期项目写一个功能页面--"从二期导入工单数据" 该页面可以输入时间和单号,并可视化的方式动态展示导入结果(websocket如果有问题 就先Loading完了展示结果 成功xxx条 失败xxx条 原因xxx)

转换的具体细节

二期工单还原回来的操作记录仅有 暂停记录 再加上一个迁移的记录 标识出这是一个迁移工单，无法还原之前的操作。
关于process可以如实还原，前提--3期页面内容不调整
转换代码统一写在二期的api项目中
二期数据最完整的以建桩意向为准,如果判断出有购车意向,则补上购车意向的process,如果判断出成功转换为工单,则添加上工单的process

工时人力:2人3天包括调试

结算单雷同
结算单数据需要建立在工单数据基础之上

工时人力:2人2天包括调试

关于系统基础数据,人员,权限等数据 由于三期沿用了 aibol框架 还用的是sqlserver 库表结构都一样,建议完全拷贝,但是牵扯到一些与其他数据打通的调试可能需要花费额外的事件(手工配置区域权限等)

工时人力:1人2天

FTP文件建议直接拷贝,保留原有目录结构,仅切换ip地址(如果有必要,没有必要刻意沿用老的ftp服务器)

工时人力:1人1天

报表数据内容看上去比较复杂,单实际内容都是已经生成好的结果,建议直接复制拷贝,并作为老报表展示,而新数据新报表则按照3期计划继续开发,完成开发后可以再行考虑是否将二期数据尝试转换成为3期报表

工时人力:1人3+x天

消息任务通知等数据结构是相同的建议直接迁移,但是由于类型定义不一致需要额外处理

工时人力:1人2天

日志内容由于是老系统日志,优先级可以靠后,但是其内容和结构本质还是和三期一样的,可以迁移,但不是必须

工时人力:1人1天

Q&A

为什么要在二期项目中做接口?不可以直接写个控制台导一下数据吗?
因为原有数据模型都在二期中有了现有的实现,业务逻辑和获取工单的 Service 都是现成的,并且集成了所有的额外数据,例如操作人等数据,都是有关联到整个系统的,另外开一个项目可能导致数据不确定的遗漏

为什么要分页还要输入时间?
为了保证数据迁移的可维护性,不能每次都要把数据库全清理了再导一次全部完整的数据吧.每次数据以修改时间为依据,增量的方式同步到三期的MongoDb数据库中.如果某个单有问题,也可以单独输入工单号来单独导入

风险和未知

具体实施顺序

建议先从基础数据入手,把用户资料 权限 等数据导入,保证能够正常登陆
然后逐步导入工单结算单数据
再导入通知消息类数据
最后导入报表等数据

数据迁移计划表

数据内容 导入方式 难点 正确状态
基础用户数据 完整迁移 无 可以正常登陆访问
角色,权限 手动 累 侧边栏操作等权限功能正常
组织结构,4S店 手动 工单数据需要安装4S店数据隔离 组织结构正确
区域 手动 累 数据隔离派工隔离等功能正常
计价策略 完整迁移+手动维护区域部分
派工策略 全新开发并导入数据
工单 接口请求转入 转换程序开发 工单流转正常
结算单 接口请求转入 转换程序开发 结算单展示正常
消息通知 完整迁移+类型批处理 需要开发控制台遍历程序修改类型 正常查看过往消息
系统模板 移除
上一篇下一篇

猜你喜欢

热点阅读