主数据ETL - 02 系统设计

概览

总体用例图

ETL 用例.png

边写这篇文章，边设计这个系统，当前尚未实现，完成设计后，计划在下一个具体项目上实施。

设计思路

利用SAP的各种技术，在应用程序层面记录变更；确定变更信息需要同步的第三方系统；按各系统需求生成数据包；完成同步。
按照这个思路，设计了三大模块：

1.变更日志模块

着眼点是数据表，对SAP的表进行简单分类：

• 标准表
  • 配置表
    一般伴随TR，比如公司，工厂，库位等
  • 主数据表
    物料，供应商，客户，成本中心等
  • 业务数据表
    采购订单，生产订单，销售订单等
• 自定义表

---

不同的表，维护方式差异比较大，对应的记录变更的方式也会有差异，定义了三种变更日志格式：

• Change Document
  标准的技术，广泛存在于标准数据表，比如物料，采购订单，BOM，销售订单。

  生产订单由于变更频繁，标准不提供Change Document，但是预留了出口，可以自定义Change Document，随之而来的一个问题就是需要考虑归档，Change Document有标准的归档对象，技术上问题不大。

• Transport Request
  配置表通过TR传输，所以TR本身就是一种日志。

• 自定义日志
  按需定制，比如有些表没有CD，没有TR，可以在维护的时候生成CD，也可以简单一点写入自定义日志。

2.路由模块

根据变更日志，判定是否需要同步到特定系统，需要同步即确认了路由信息：SAP->第三方系统，放入PUSH或者PULL 队列。

队列中主要存储信息：第三方系统标识 + 接口标识 + 变更日志编号 + 时间戳

3.分发模块

分发主要考虑两个问题：数据包生成和同步方式

数据包生成

生成时机，由于场景不同，同步方式不同，数据包在不同的环节生成：

• 即时
  数据变更的同时生成
• 定时
  可能生成数据包的代价特别大，放在后台任务中定时生成
• 延迟
  在数据同步的时候生成

---

数据包的格式：全量和增量，参见 上篇 01 数据同步场景分析

同步方式

Pull和Push模式的说明，也参见上篇。

对于Pull，增量发送数据包必须要有发送顺序控制，实时推送，连续更改，不加控制可能因为推送执行顺序不同，导致两边系统数据不一致。

考虑牺牲一定的实时性要求（对第三方系统来说也无感的），推送是使用单线程的模式，只有一个消费者从Push队列中提取同步任务。后续讨论使用Event + Lock技术实现这个功能。