本篇參考：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等都是專案中必須要考量的。綜合考慮才是特定專案的最優解。篇中有錯誤的地方歡迎指出，有不懂歡迎留言。