本篇參考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
我們在做salesforce的集成的實施的時候，不可避免地要和其他系統進行交互。因爲一個稍微大一點的企業也很少會將公司的所有的內容和數據都放在salesforce一個平臺。所以涉及到集成的時候，如何去選，怎麼去做，也變得很重要。我們在做項目的時候，不可能大項目還是小項目涉及到集成，第一件事想的就是：好啊，那我暴漏一個restful接口吧或者我寫一個 http callout來訪問你們吧。對於實施人員來說，按時並且高質量交付肯定是重中之重，對於自己來說，多掌握一些集成知識以及方法論可以讓你在涉及到多個系統之間操作時更加遊刃有餘，而不是 100%的走自定義接口這個“正確”但是不一定高效的方案。
一. 通過關鍵要素確定官方推薦的集成模式
我們在考慮集成方案以前，通常需要評估以下幾個要素（不一定全面，但是基本是做集成都需要思考,比如數據量等）
Source / Target： 這個很好理解，salesforce系統針對某個表或者某個功能是作爲源系統還是目標系統。這個定義關係到數據流向性以及以哪個系統作爲MDM，不同的設置也可能考慮不同的effort，比如是否需要中間件等等。
Timing： 實時性更會影響方案的選擇。你的這個集成要求是同步還是異步
Type： 指定集成的樣式：流程、數據或可視化。
•基於流程的集成可以定義爲跨兩個或多個應用程序集成功能流處理的方法。這些集成通常涉及更高級別的抽象和複雜性，尤其是事務性和回滾，涉及到編排情況下還需要引入中間件。這些類型的集成通常需要複雜的設計、測試和異常處理需求。此外，此類複合應用程序通常對底層系統的要求更高，因爲它們通常支持長時間運行的事務以及報告和/或管理流程狀態的能力。
•數據集成可以定義爲應用程序所使用信息的集成。這些集成可以是簡單的表插入或upsert，也可以是需要引用完整性和複雜轉換的複雜數據更新。數據集成通常是要實現的最簡單的集成類型，但需要適當的信息管理技術才能使解決方案具有可持續性和成本效益。這些技術通常包括主數據管理（MDM）、數據治理、主控、重複數據消除、數據流設計等方面；
•可視化集成可定義爲Salesforce能夠與駐留在外部系統中的數據交互，而無需在Salesforce內複製數據的集成。此類集成始終通過Salesforce平臺的事件觸發，例如，用戶操作、工作流、搜索、更新記錄，從而實現與外部源的實時數據集成。
針對上述三個因素可以做出來一個矩陣圖來決定滿足什麼樣的要素應該選擇哪種或者哪些集成模式。
我們實際項目中用到最多的就是數據集成，其次是基於流程的集成。篇中介紹了好幾種的集成模式，篇中上面的連接中包含這幾種模式的所有的詳細介紹，感興趣的小夥伴可以先行理解，後續也會針對每個集成模式整理一篇博客，不過都是照本宣科了，還是建議自行查看。
二. 中間件的使用場景和介紹
先想象一下，我們在實際工作中最常用到的中間件的場景有哪些呢？我們先簡單的以一個UML用例圖作爲引子。
我們在項目中使用到的中間件的場景通常有兩個： 編排 & error handling
編排：SFDC的數據庫的表和外部系統肯定有差距，而且複雜場景可能層級結構也不一樣，這個時候就涉及到數據的編排，通過中間件轉換成符合對端系統的結構。
errror handling：涉及到多個系統的集成，那麼錯誤處理就是不可逃避的話題。如果兩個系統相對簡單，可以不用使用到中間件，但是如果這兩個系統處理特別複雜，不同場景需要進行不同的處理，可能還要涉及到不斷的輪詢監聽訂閱等等操作，這個時候使用中間件作爲錯誤處理的中轉站是最好不過了。比如 SFDC端通過 push topic或者platform event去進行數據的推送，外部系統需要接收和同步。這種scenario就特別適合引入中間件。中間件負責輪詢訂閱，如果涉及到不同的error進行相關的記錄或者二次操作或者其他操作等等。正確訂閱到編排好制定的結構發送到其他下游系統即可。
當然，涉及到集成的項目，中間件除了使用在以上的常用場景以外，還可以做很多的事情，官方文檔的描述如下：
| 術語 | 定義和描述 |
| 事件處理 |
事件處理是在指定接收者（“處理者”）處接收可識別事件。事件處理涉及的關鍵流程包括：
這個中間件的特性我們通常應用於廣播訂閱(publish / subscription)模型下。在發佈/訂閱場景中，中間件將請求或者消息從事件發佈服務器(publisher)路由到事件訂閱服務器（subscriber）。這些具有監聽器的消費者(consumer)可以在事件發佈時檢索這些事件。
這裏舉一個例子進行描述。salesforce針對 Account是 MDM，Account的數據需要接近實時的方式去同步給下游的三個系統，下游的三個系統都需要根據Salesforce的Account變化所推送的數據更新自己相關的內容。這裏 salesforce使用了 PushTopic或者 Change Data Capture，這個時候就需要引入中間件。中間件的工作就是作爲訂閱者訂閱salesforce發佈的 pushtopic，然後監聽檢索salesforce發的事件，然後進行響應以後轉發給下游的三個系統。 |
| 協議轉換 |
協議轉換 通常是一種軟件應用程序，它將一個設備的標準或專有協議轉換爲適用於另一個設備的協議，以實現互操作性。在中間件的上下文中，到特定目標系統的連接可能受到協議的約束。在這種情況下，需要將消息格式轉換爲目標系統的格式或封裝在目標系統的格式中，在目標系統中可以提取有效負載。 Salesforce不支持本地的協議轉換，因此假定中間件層或endpoint都能滿足任何此類需求。 |
| 翻譯與轉換 |
轉換是將一種數據格式映射到另一種數據格式的能力，以確保集成的各種系統之間的互操作性。通常，這需要在發送途中重新格式化報文的消息，以符合發送方以及接收方的要求。在更復雜的情況下，一個應用程序可以以自己的本機格式發送消息，而另外兩個或多個應用程序可能各自以自己的本機格式接收消息的副本。中間件轉換和轉換工具通常包括爲遺留或其他非標準端點創建服務外觀的能力；這使得這些端點看起來是服務可尋址的。 在Salesforce集成中，假設中間件層或endpoint滿足任何此類需求。數據轉換可以在Apex中進行編碼，但出於維護和性能考慮，我們不建議這樣做。 當然在實際的工作場景中，我們也需要去實際的case by case的分析是否需要引入中間件，如果只是爲了轉換格式，並且對接的上下游都高可定製化，我們也可以通過 apex進行編碼處理，這樣也省了中間件的成本。如果通過apex來做，我們就需要考慮到其他的隱性的成本，比如 error handling，可擴展性等等。 |
| 排隊和緩衝 |
排隊和緩衝通常依賴於異步消息傳遞，而不是請求-響應體系結構。在異步系統中，當目標程序繁忙或連接受損時，消息隊列提供臨時存儲。此外，大多數異步中間件系統提供持久存儲來備份消息隊列。異步消息處理的主要好處是，如果接收方應用程序因任何原因失敗，發送方可以繼續不受影響；發送的消息只是在消息隊列中累積，以便在接收方重新啓動時進行後續處理。 Salesforce僅以基於workflow的outbound message的形式提供顯式排隊功能。如果針對其他集成場景（包括編排、流程編排、服務質量等）提供真正的消息隊列，需要一箇中間件解決方案。 |
| 同步傳輸協議 |
同步傳輸協議指的是支持以下活動的協議：“調用者中的單個線程發送請求消息，block住，等待消息返回，然後處理response…” 等待響應的請求線程意味着只有一個未完成的請求，或者此請求的回覆通道對此線程是專用的。 |
| 異步傳輸協議 | 異步傳輸協議是指支持活動的協議，其中“調用者中的一個線程發送請求消息併爲應答設置回調”。一個單獨的線程偵聽回覆消息。當回覆消息到達時，回覆線程調用相應的回調，該回調重新建立調用方的上下文並處理回覆。這種方法允許多個未完成的請求共享一個回覆線程。 |
| 中介和路由 | 中介路由是從組件到組件的複雜消息“流（flow）”的規範。舉個例子，許多基於中間件的解決方案依賴於消息隊列系統。雖然一些實現允許由消息傳遞層本身提供路由邏輯，但另一些實現依賴於客戶機應用程序來提供路由信息或允許這兩種範例的混合。在這種複雜的情況下，中介（中間件的一部分）簡化了開發、集成和驗證。 |
| 流程編排和服務編排 |
流程編排和服務編排是“服務組合”的每一種形式，其中協調了任意數量的端點和功能。編排和服務編排的區別在於： •流程編排可以定義爲“由一組相互作用的個體實體產生的行爲，沒有中央權威。” •服務編排可以定義爲“由中央指揮協調獨立執行任務的各個實體的行爲而產生的行爲。” 此外，“服務編排顯示每個服務的完整行爲，而流程編排結合了每個服務的接口行爲描述。” 業務流程編排的一部分可以在Salesforce工作流中構建，也可以使用Apex。由於Salesforce超時值和Government limitation（特別是在需要真正事務處理的解決方案中），我們建議在中間件層實現所有複雜的業務流程。 |
| 事務性（加密、簽名、可靠傳遞、事務管理） | 事務性可以定義爲支持全局事務的能力，該全局事務包含針對每個所需資源的所有必要操作。事務性意味着對所有四個ACID（原子性、一致性、隔離性、持久性）屬性的支持，其中原子性保證工作單元（事務）的所有結果或無結果。雖然Salesforce本身是事務性的，但它不能參與分佈式事務或在Salesforce之外發起的事務。因此，假設對於需要複雜、多系統事務的解決方案，事務性（以及相關的回滾/補償機制）可以在中間件層實現。 |
| 路由 | 路由可以定義爲指定從組件到組件的複雜消息流。現代服務、基於內容的服務、基於規則的解決方案的數量和類型。在Salesforce集成中，假設中間件層或端點（endpoint）滿足任何此類需求。消息路由可以在Apex中進行編碼，但出於維護和性能考慮，我們建議可以使用中間件。 |
| ETL（提取、轉換和加載） |
Extract, transform, and load（ETL）是指涉及以下內容的過程： •E: 從源系統提取數據。通常，涉及多個關係型系統和非關係型數據源。 •T: 轉換數據以滿足運營需求，包括數據質量級別。轉換階段通常將一系列規則或函數應用於從源提取的數據，以導出數據以加載到最終目標。 •L: 將數據加載到目標系統中。目標系統可能與數據庫、操作數據存儲、數據集市、數據倉庫或其他操作系統存在很大差異。 大多數成熟的ETL工具都提供了變更數據捕獲功能，但這並不是絕對必要的。此功能用於工具識別源系統中自上次提取以來已更改的記錄，從而減少記錄處理量。Salesforce現在還支持Change Data Capture(可看前一節)。通過CDC，客戶機或外部系統幾乎實時地接收Salesforce記錄的變更。這允許客戶端或外部系統同步外部數據存儲中的相應記錄。 |
| 長輪詢 |
長輪詢，也稱爲Comet編程，模擬從服務器到客戶端的信息推送。與普通輪詢類似，客戶端連接服務器並從服務器請求信息。但是，如果信息不可用，服務器將保留請求並等待信息可用（事件發生），而不是發送空響應。然後，服務器向客戶端發送一個完整的響應。然後，客戶機立即重新請求信息。客戶端持續維護與服務器的連接，因此它總是等待接收響應。如果服務器超時，客戶端將再次連接並重新啓動。Salesforce Streaming API使用Bayeux協議，Comet用於長輪詢。 •Bayeux是一種主要通過HTTP傳輸異步消息的協議。 •Comet是一種可擴展的基於HTTP的事件路由總線，它使用一種稱爲Comet的AJAX推送技術模式。它實現了Bayeux協議。 |
很巧合的是，我們的新項目就是salesforce使用 Streaming API的 push topic，下游系統需要接近實時的同步數據，因爲下游系統不支持長輪詢，這個時候就需要中間件。考慮中間件的幾個特性中就有 事件處理，翻譯轉換以及長輪詢。不同項目不同場景不同複雜度會有不同的思考和設計。如果需要引入中間件，考慮一下官方的介紹中哪些是讓你不得不或者使用以後會有很大的性能提升的原因。
三. Salesforce的幾個集成模式的簡單介紹
我們在圖一中可以看到Salesforce建議的集成模式，那他們大概什麼意思，什麼場景使用呢？ 後續針對每個集成模式都會有一個博客來介紹，本篇只是基於一個high level的介紹，語言好的小夥伴可以直接查看上面的文檔，裏面擁有官方推薦的全量文檔信息。
1. Remote Process Invocation—Request and Reply遠程進程調用--請求和響應： Salesforce調用遠程系統上的進程，等待該進程完成，然後根據遠程系統的響應跟蹤狀態。
這個在實際場景中是經常用到的，salesforce call外部系統並且等待結果返回，並根據結果做相關的處理，這個過程是同步進行的，要求服務器端立刻返回信息。
舉個例子：
一家公司，他使用Salesforce的 Sales Cloud進行 Opportunity的管理。當 Opportunity狀態爲 Close Won的時候，需要生成一條訂單信息，但是這個訂單信息的訂單號需要由外部系統來生成，針對這種場景，我們就需要使用 請求和響應的模式，同步的等待訂單號結果回來以後，生成我們的訂單數據。
2. Remote Process Invocation—Fire and Forget遠程進程調用-發後即棄： Salesforce調用遠程系統中的進程，但不等待進程完成，而是由遠程進程接收並確認請求，然後將控制權交回Salesforce。
這個在實際場景中同樣經常用到的，salesforce call外部系統，區別上面的模式即爲這個模式call出去獲取一個call成功的狀態即可，並不要求response立馬返回就可以做其他的事情。舉個例子：
Salesforce系統和外部系統進行交互，外部系統沒法提供一個實時的 rest api,他的操作時間可能是10分鐘操作一次，這樣沒法通過同步來搞回來，因爲這個超過了 callout的 time limit，我們可能需要 call出去，外部系統如果收到了就會返回一個response,我們也可以在暴露一個 restful api,後續他們搞定以後，將response調用給salesforce系統。這種case下，結果不是及時的返回，salesforce只要保證發出去即可。
3. Batch Data Synchronization 批量數據同步：批處理的方式來實現 SF->外部或者外部->SF數據的一致性。
舉個例子：
外部系統每晚通過ETL等方式將Lead批量導入到SF端。
4. Remote Call-in： 存儲在Lightning Platform中的數據由遠程系統創建、檢索、更新或刪除。
舉個例子：
一個公司，他的銷售都是通過手機移動端去進行相關的業務操作，比如拜訪客戶等等。通過IOS/Android或者企業微信等作爲前臺操作數據，操作的數據都是SF端的信息，通過標準的rest api即可實現 客戶端作爲入口。
5. UI Update Based on Data Changes：Salesforce用戶界面必須由於Salesforce數據的更改而自動更新。
舉個例子：業務要求當一個 end user訪問某個頁面時，在這個頁面停留的過程中，如果salesforce的數據庫關鍵字段更改以後，end user不需要刷新頁面的情況下，也可以實時的看到最新的數據庫的值，而不是最開始加載的值。
6. Data Virtualization 數據可視化： Salesforce實時訪問外部數據。這樣就不需要在Salesforce中保存數據，然後在Salesforce和外部系統之間協調數據。這個在實際的工作中還是很可能遇見的，比如一個系統的數據很重要也很龐大，不允許或者不需要存儲在外部的系統，並且還需要展示在salesforce系統中，展示的數量不多。
舉個例子：
一家制造公司使用Salesforce來管理Opportunity。客戶服務代理希望訪問來自後臺ERP系統的實時訂單信息，以獲得客戶的360度視圖，而無需在ERP中學習和手動運行報告。因爲訂單信息存儲在ERP系統，不想將這部分數據同步到salesforce，也想查看相關數據信息，便可以使用此種集成模式。
總結：
本篇只是雜談，簡單的寫一下集成項目中中間件的特性以及什麼場景下使用，集成中salesforce推薦的幾種集成模式。篇中還沒有詳細的描述集成模式因爲內容特別多，後續每個集成模式爭取都抽出一個章節進行講解。本篇只是說一下這些概念以及滿足什麼特點應該選擇哪個集成模式。概念性內容多，實際性內容建議大家自行查看上面的官方文檔先自行了解。篇中有錯誤歡迎指出，有不懂歡迎留言。