由于二期全部都使用的sqlserver linq to sql.所以为了实现工单流程功能,在工单表中会有超多的字段，而三期引入mongodb，模型设计也有所不同，数据迁移需要单独着重考虑
迁移任务
- 工单基础数据 包括流程节点process 暂停记录
- 结算单
- 系统基础数据,包括人员,权限,区域,组织结构等
- 图片文件 FTP 数据
- 报表数据
- 消息任务通知
- 系统日志
方案
关于工单迁移 , 二期项目提供一个接口:
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店 | 手动 | 工单数据需要安装4S店数据隔离 | 组织结构正确 |
| 区域 | 手动 | 累 | 数据隔离派工隔离等功能正常 |
| 计价策略 | 完整迁移+手动维护区域部分 | ||
| 派工策略 | 全新开发并导入数据 | ||
| 工单 | 接口请求转入 | 转换程序开发 | 工单流转正常 |
| 结算单 | 接口请求转入 | 转换程序开发 | 结算单展示正常 |
| 消息通知 | 完整迁移+类型批处理 | 需要开发控制台遍历程序修改类型 | 正常查看过往消息 |
| 系统模板 | 移除 |
