定義應用程序使用邊界

不支持實時同步

設計這個ETL的目的是將絕大多數(shù)更改的場景納入這個框架，實時同步有限制（很難抽象出統(tǒng)一的接口）。允許一定的時差，基于程序運行時的數(shù)據(jù)庫數(shù)據(jù)生成數(shù)據(jù)包，而不是Change Document日志。

采用的同步方式：

• Push
  SAP定義周期后臺任務
• Pull
  第三方系統(tǒng)定時調(diào)用SAP接口

縮短周期間隔，也勉強算實時。

后臺Push時，因為后臺任務資源限制，實際同步間隔可能遠大于定義的間隔。

實時同步的問題

Change Document 是非常不錯的監(jiān)聽對象，但也存在一定的限制：

• 數(shù)據(jù)同步和Change Document寫入(監(jiān)聽點)肯定是異步的，自定義的同步操作，不能影響標準程序的性能。
• 由于SAP的代碼是個“黑盒”
  Change Document生成的時候，不能確保業(yè)務相關的數(shù)據(jù)寫入到了數(shù)據(jù)庫，而Push是異步任務，無法同步等待。
  • 若基于Change Document 數(shù)據(jù)生成數(shù)據(jù)包，還原每一個更改操作，可以不考慮業(yè)務數(shù)據(jù)是否寫入數(shù)據(jù)庫，但這種模式實現(xiàn)起來復雜，而且不穩(wěn)定；
  • 另一種基于數(shù)據(jù)庫的最新數(shù)據(jù)，必須確認相關業(yè)務數(shù)據(jù)是否寫入成功，這個其實不是很好實現(xiàn)。如果強制等待，大量更改時性能會有問題。

定時同步時，可以通過延遲同步的方式來解決，無論Pull或者Push。比如設定最近三分鐘內(nèi)的Change Document不同步，由下一次同步任務處理。

后來了解到Change Document可以綁定標準的Business Object對象，但是并不減少工作量，不如直接自己寫代碼實現(xiàn)。

處理流程

這是設想中的同步模式，實時Push，后來想想數(shù)據(jù)的一致性有問題，放棄了實時推送的想法。時序圖就不改了，Step 8略有變更， 原來可以在Change Document生成時觸發(fā)，現(xiàn)在調(diào)整到了周期后臺任務觸發(fā)，其他處理邏輯不變。

ETL時序.png

對于實時觸發(fā)，不納入這個框架。可以直接在相關增強中實現(xiàn)，基于運行時的最新數(shù)據(jù)推送即可。

現(xiàn)在再想一下，既然不是實時的，就不用Push模式，全部使用Pull，Change Document就用于判定是否發(fā)生了變更即可。那個這個框架也就可有可無了。