本篇參考：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工具進行複制 | 外部系統 | 利用第三方ETL工具，該工具允許您針對源資料運作變更資料捕獲。該工具對源資料集中的更改做出反應，轉換資料，然後調用Salesforce Bulk API來發出DML語句。這也可以使用salesforcesoapi實作。當然大資料量，我們傾向于用 bulk API來實作（dataloader也基于bulk api） | |
| Good | 利用第三方ETL工具，允許您針對ERP和Salesforce資料集運作變更資料捕獲。在這個解決方案中，Salesforce是資料源，您可以使用各行的時間/狀态資訊來查詢資料并過濾目标結果集。這可以通過将SOQL與SOAP API和query（）方法一起使用，或者通過使用SOAP API和getUpdated（）方法來實作。 | ||
| Remote call-in | Suboptimal | 遠端系統可以使用其中一個api調用Salesforce，并在資料發生時執行更新。但是，這會導緻兩個系統之間的通信量相當大。應該更加強調錯誤處理和鎖定。這種模式有可能導緻持續更新，進而影響最終使用者的性能。 | |
| Remote process invocation | 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等都是項目中必須要考量的。綜合考慮才是特定項目的最優解。篇中有錯誤的地方歡迎指出，有不懂歡迎留言。
作者：zero
部落格位址：http://www.cnblogs.com/zero-zyq/
本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接
個人下載下傳了一些相關學習的PDF檔案，如果需要下載下傳請通路百度雲 點選此處通路 密碼：jhuy
如果文章的内容對你有幫助，歡迎點贊~
為友善手機端檢視部落格，現正在将部落格遷移至微信公衆号：Salesforce零基礎學習，歡迎各位關注。