本篇參考：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推薦的幾種整合模式。篇中還沒有詳細的描述整合模式因為內容特別多，後續每個整合模式爭取都抽出一個章節進行講解。本篇只是說一下這些概念以及滿足什麼特點應該選擇哪個整合模式。概念性內容多，實際性內容建議大家自行檢視上面的官方文件先自行了解。篇中有錯誤歡迎指出，有不懂歡迎留言。