本篇參考：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推薦的幾種內建模式。篇中還沒有詳細的描述內建模式因為内容特别多，後續每個內建模式争取都抽出一個章節進行講解。本篇隻是說一下這些概念以及滿足什麼特點應該選擇哪個內建模式。概念性内容多，實際性内容建議大家自行檢視上面的官方文檔先自行了解。篇中有錯誤歡迎指出，有不懂歡迎留言。
作者：zero
部落格位址：http://www.cnblogs.com/zero-zyq/
本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接
個人下載下傳了一些相關學習的PDF檔案，如果需要下載下傳請通路百度雲 點選此處通路 密碼：jhuy
如果文章的内容對你有幫助，歡迎點贊~
為友善手機端檢視部落格，現正在将部落格遷移至微信公衆号：Salesforce零基礎學習，歡迎各位關注。