本篇參考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
前兩篇博客講了一下遠程進程調用的場景。今天我們描述一下 批量數據同步的模式。
一. 上下文
公司曾經使用其他的CRM平臺，然後和其他的上下游系統進行數據的交互以及集成來保證多方數據的一致性。公司現在正在將CRM實施從原有系統轉移到Salesforce，並希望有以下的操作：
•從當前CRM系統中提取和轉換 Account / Contact / Opportunity等，並將數據加載到Salesforce（初始數據導入）。
•每週從遠程系統提取、轉換客戶Billing數據，並將其加載到Salesforce中（正在進行）。
•每週從Salesforce提取客戶Activity信息並將其導入內部數據倉庫（正在進行）。
•需要考慮salesforce作爲主數據變化，其他系統接收。其他系統作爲主數據變化，salesforce同樣數據一致性（數據複製）
二. 問題和考慮因素
問題： 如何將數據導入到Salesforce以及將數據從Salesforce導出到其他系統，同時考慮到這些導入和導出可能會在工作時間干擾最終用戶的操作，並涉及大量數據？
考慮因素： 當基於這種模式應用解決方案時，需要考慮各種各樣的因素：
•大量的數據是否應存儲在Salesforce中？
•如果數據應存儲在Salesforce中，是否應刷新數據以響應遠程系統中的事件？（外部數據是否爲主還是salesforce爲主？）
•是否應定期刷新數據？
•數據是否支持主要業務流程？
•Salesforce中是否存在受此數據可用性影響的分析（報告）需求？
三. 解決方案
針對解決方案的選擇，我們首先需要知道誰作爲主數據，salesforce作爲主數據，同步給外部系統以及 外部系統作爲主數據，同步給salesforce針對大數據量有不同的解決方案，詳情如下表格
|
解決方案 |
適配程度 |
誰作爲主數據 |
comments |
|
Salesforce Change Data Capture |
Best |
Salesforce |
Salesforce更改數據會發送更改數據的事件，這些事件表示對Salesforce記錄的更改操作。訂閱端捕獲的事件包括創建新記錄、更新現有記錄、刪除記錄和取消刪除記錄。 通過CDC，下游系統可以接收Salesforce記錄的近實時更改，並在外部數據存儲中同步相應的記錄。CDC負責複製的連續同步部分。它發佈Salesforce新記錄和更改記錄的數據增量。更改數據捕獲需要一個集成應用程序來接收事件並在外部系統中執行更新。詳情可以查看此博客： salesforce零基礎學習（一百零五）Change Data Capture |
|
通過第三方ETL工具進行復制 |
Best |
外部系統 |
利用第三方ETL工具，該工具允許您針對源數據運行變更數據捕獲。該工具對源數據集中的更改做出反應，轉換數據，然後調用Salesforce Bulk API來發出DML語句。這也可以使用salesforcesoapi實現。當然大數據量，我們傾向於用 bulk API來實現（dataloader也基於bulk api） |
|
通過第三方ETL工具進行復制 |
Good |
Salesforce |
利用第三方ETL工具，允許您針對ERP和Salesforce數據集運行變更數據捕獲。在這個解決方案中，Salesforce是數據源，您可以使用各行的時間/狀態信息來查詢數據並過濾目標結果集。這可以通過將SOQL與SOAP API和query（）方法一起使用，或者通過使用SOAP API和getUpdated（）方法來實現。 |
|
Remote call-in |
Suboptimal |
外部系統 |
遠程系統可以使用其中一個api調用Salesforce，並在數據發生時執行更新。但是，這會導致兩個系統之間的通信量相當大。應該更加強調錯誤處理和鎖定。這種模式有可能導致持續更新，從而影響最終用戶的性能。 |
|
Remote process invocation |
Suboptimal |
Salesforce |
Salesforce可以調用遠程系統，並在數據發生時執行更新。但是，這會導致兩個系統之間的通信量相當大。應該更加強調錯誤處理和鎖定。這種模式有可能導致持續更新，從而影響最終用戶的性能。 |
這裏做一個引申。我們除了遵循是否 best practice以外，還需要進行多方面的考慮，比如項目所能負擔的成本以及是否有可使用的resource等等。比如針對Change Data Capture，官方只是幾個表免費，如果超過了指定的數量，需要有額外的開支。這些在我們選擇方案的時候都需要進行考慮的。
四. 流程草圖
1.針對外部系統作爲主數據，官方的一個集成方案的草圖，通過ETL來實現
2. 針對salesforce作爲主數據，官方的一個集成方案的草圖，通過CDC來實現
五. 其他關鍵點
我們可以在以下情況下將外部來源的數據與Salesforce集成：
•外部系統是數據主系統，Salesforce是單源系統或多個系統提供的數據的使用者。在這種情況下，通常會有一個數據倉庫，在將數據導入Salesforce之前對數據進行聚合。
•Salesforce是數據主系統，Salesforce是特定表（實體）的SOR（system of record）
在典型的Salesforce集成場景中，實施團隊執行以下操作之一：
•對源數據集實施CDC。
•在中間的、內部數據庫中實現一組支持的數據庫結構，稱爲控制表。然後使用ETL工具創建程序，這些程序將進行以下的步驟：
1.讀取控制表以確定作業的上次運行時間，並提取所需的任何其他控制值。
2.使用上述控制值作爲過濾器並查詢源數據集。
3.應用預定義的處理規則，包括驗證、改進等。
4.使用ETL工具的可用連接器/轉換功能創建目標數據集。
5.將數據集寫入Salesforce對象。
6.如果處理成功，則更新控制表中的控制值。
7.如果處理失敗，請使用允許重新啓動和退出的值更新控制表。
注意：我們建議您在ETL工具可以訪問的環境中創建控制表和關聯的數據結構，即使Salesforce的訪問權限不可用。這提供了足夠的彈性。對於ETL工具從數據同步能力獲得最大效益，請考慮以下內容：
•對ETL作業進行鏈接和排序，以提供一個連貫的過程。
•使用兩個系統的主鍵匹配傳入數據（unique key）。
•使用特定的API方法僅提取更新的數據。
•如果導入主詳細信息或查找關係中的子記錄，請在源位置使用其父項對導入的數據進行分組，以避免鎖定。
•任何導入後處理，如trigger，只能選擇性地處理數據。
總結：篇中主要介紹了批量數據同步的模式，我們在使用這個模式之前，需要先確保數據是否要落入到數據庫以及誰是 MDM，以誰爲主，數據從哪來到哪去，不同的點需要不同的設計方式。當然，除了best practice以外，effort以及resource等都是項目中必須要考量的。綜合考慮纔是特定項目的最優解。篇中有錯誤的地方歡迎指出，有不懂歡迎留言。