定义应用程序使用边界
不支持实时同步
设计这个ETL的目的是将绝大多数更改的场景纳入这个框架，实时同步有限制（很难抽象出统一的接口）。允许一定的时差，基于程序运行时的数据库数据生成数据包，而不是Change Document日志。
采用的同步方式：
- Push
SAP定义周期后台任务 - Pull
第三方系统定时调用SAP接口
缩短周期间隔，也勉强算实时。
后台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就用于判定是否发生了变更即可。那个这个框架也就可有可无了。
网友评论