概览
总体用例图
边写这篇文章，边设计这个系统，当前尚未实现，完成设计后，计划在下一个具体项目上实施。
设计思路
利用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技术实现这个功能。
