主数据ETL - 03 监听Change Document

2018-11-02 本文已影响0人 rootbin

定义应用程序使用边界

设计这个ETL的目的是将绝大多数更改的场景纳入这个框架，实时同步有限制（很难抽象出统一的接口）。允许一定的时差，基于程序运行时的数据库数据生成数据包，而不是Change Document日志。

采用的同步方式：

缩短周期间隔，也勉强算实时。

后台Push时，因为后台任务资源限制，实际同步间隔可能远大于定义的间隔。

Change Document 是非常不错的监听对象，但也存在一定的限制：

数据同步和Change Document写入(监听点)肯定是异步的，自定义的同步操作，不能影响标准程序的性能。
由于SAP的代码是个“黑盒”
Change Document生成的时候，不能确保业务相关的数据写入到了数据库，而Push是异步任务，无法同步等待。
- 若基于Change Document 数据生成数据包，还原每一个更改操作，可以不考虑业务数据是否写入数据库，但这种模式实现起来复杂，而且不稳定；
- 另一种基于数据库的最新数据，必须确认相关业务数据是否写入成功，这个其实不是很好实现。如果强制等待，大量更改时性能会有问题。

定时同步时，可以通过延迟同步的方式来解决，无论Pull或者Push。比如设定最近三分钟内的Change Document不同步，由下一次同步任务处理。

后来了解到Change Document可以绑定标准的Business Object对象，但是并不减少工作量，不如直接自己写代码实现。

这是设想中的同步模式，实时Push，后来想想数据的一致性有问题，放弃了实时推送的想法。时序图就不改了，Step 8略有变更，原来可以在Change Document生成时触发，现在调整到了周期后台任务触发，其他处理逻辑不变。

ETL时序.png

对于实时触发，不纳入这个框架。可以直接在相关增强中实现，基于运行时的最新数据推送即可。

现在再想一下，既然不是实时的，就不用Push模式，全部使用Pull，Change Document就用于判定是否发生了变更即可。那个这个框架也就可有可无了。