Salesforce Integration 概覽(三) Remote Process Invocation—Fire and Forget（遠端程序調用-發後即棄）

本篇參考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf

我們在上一篇講了遠端程序調用--請求和響應模式，這種模式用于處理同步的場景。當然這個場景不隻是對salesforce有要求，同時對對方的系統有很大的要求，比如并發性，實時性等等。我們在項目中除了這種同步的場景以外，異步的場景同樣經常使用。今天我們就講一下針對salesforce callout外部系統，不需要對方實時傳回消息的場景。

一. 上下文

其實通過上面的描述中我們大概已經能聯想到我們實際的應用的上下文。這裡變更一下上一篇的場景

您可以使用Salesforce跟蹤銷售線索、管理銷售管道、建立銷售機會，并捕獲将銷售線索轉換為客戶的訂單詳細資訊。但是，Salesforce系統不包含或處理訂單。在Salesforce中捕獲訂單詳細資訊後，将在遠端系統中建立訂單，該系統将管理訂單直至結束。

當您實作此模式時，Salesforce調用遠端系統來建立訂單，salesforce隻要確定封包發送過去，并且對端系統傳回一個response OK了，就可以，至于具體的訂單号，salesforce的系統不存儲也不care，不影響後續的流程性。

通過這個描述，我們就可以清楚了這個case是Opportunity Close Won建立訂單，訂單發送到外部系統以後，不用管外部系統怎麼處理，我們隻需要保證發出去對方收到就好了。

二. 問題和考慮因素

問題： 當一個事件從salesforce觸發時，如何在遠端系統中啟動流程并将所需資訊傳遞給該流程，而無需等待遠端系統的響應？

考慮因素：在基于此模式應用解決方案時需要考慮以下因素。

　　•對遠端系統的調用是否要求Salesforce在繼續處理之前等待響應？對遠端系統的調用是同步的還是異步的？

　　•如果對遠端系統的調用是同步的，那麼Salesforce是否需要将響應作為調用的同一事務的一部分進行處理？

　　•消息大小是否較小？

　　•內建是否基于特定事件的發生，例如Salesforce使用者界面中的按鈕點選，或基于DML的事件？

　　•保證Salesforce向遠端系統發送消息是一項要求嗎？

　　•遠端系統是否能夠參與Salesforce指定合同的合同優先內建？在某些解決方案變體（例如，出站消息傳遞）中，Salesforce指定遠端系統端點實作的約定。

　　•端點(endpoint)或企業服務總線（ESB）是否支援長輪詢？

　　•聲明性配置方法是否優于定制Apex開發？在這種情況下，平台事件等解決方案優先于Apex标注。

三. 解決方案

針對此種模型salesforce給我們推薦了相關的解決方案，适配度是一方面，還要考慮公司預算，對端系統的支援能力以及resource等等。

解決方案	适配度	詳細介紹
基于流程驅動的Platform Event	Best	此種方式不需要額外的自定義工作。Platform Event是應用程式發送和接收的事件消息（或通知），以采取進一步的操作。Platform Event簡化了傳遞更改和響應更改的過程，而無需編寫複雜的邏輯，我們可以通過 Process 或者 Flow去釋出事件。一個或多個訂閱端可以偵聽同一事件并執行操作。
基于自定義驅動的 platform events	Good	和基于流程驅動的 Platform Event類似，差別就是Event需要由Apex或者 Trigger進行觸發
Workflow驅動的 outbound messaging	Goods	Salesforce中不需要定制就可以實作出站消息傳遞。對于這種類型的內建，建議的解決方案是從insert或update事件調用遠端程序。Salesforce提供了工作流驅動的出站消息傳遞功能，允許将SOAP消息發送到由Salesforce中的插入或更新操作觸發的遠端系統。這些消息是異步發送的，并且獨立于Salesforce使用者界面。 Outbound message被發送到特定的遠端端點。遠端服務必須能夠參與Salesforce提供契約的contract-first內建。在收到消息後，如果遠端服務沒有以肯定的确認做出響應，Salesforce将重試發送消息，進而提供一種保證傳遞的形式。outbound message發送的消息的順序是按照順序的。 詳情可以參看：https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_understanding.htm
Outbound messaging and callbacks		回調提供了一種減輕無序消息傳遞影響的方法。此外，它們處理這些場景。 •幂等性—如果未及時接收到确認，則出站消息将執行重試。可以向目标系統發送多條消息。使用回調可以確定檢索到的資料是在特定的時間點，而不是在發送消息時。 •檢索更多資料—單個出站消息隻能發送單個對象的資料。回調可用于從其他相關記錄（如與父對象關聯的相關清單）檢索資料。出站消息提供了一個唯一的SessionId，您可以将其用作身份驗證令牌，用soapapi或restapi對回調進行身份驗證和授權。執行回調的系統不需要單獨向Salesforce進行身份驗證。然後可以使用任一API的标準方法來執行所需的業務功能。此變體的典型用法是Salesforce向遠端系統發送出站消息以建立記錄。回調使用在遠端系統中建立的記錄的唯一鍵更新原始Salesforce記錄。
自定義Lightning元件或Visualforce頁啟動Apex SOAP或HTTP異步調用	Suboptimal	此解決方案通常用于基于使用者界面的場景，但需要定制。此外，解決方案必須處理代碼中消息的有保證傳遞。類似于遠端程序調用請求和應答模式解決方案，該解決方案指定使用Visualforce頁面或Lightning元件以及Apex callout。不同之處在于，在這種模式中，Salesforce不會等到請求完成後才将控制權交給使用者。 接收到消息後，遠端系統響應并訓示接收到消息，然後異步處理消息。遠端系統在開始處理消息之前将控制權交回Salesforce；是以，Salesforce不必等待處理完成。（實際項目中可能采用最多的情況）
從Salesforce資料更改調用的Trigger執行Apex SOAP或HTTP異步調用		可以使用Apex Trigger根據記錄資料更改執行自動化。 Apex代理類可以通過使用Apex Trigger作為DML操作的結果來執行。但是，從觸發器上下文中發出的所有調用都必須異步執行。
Batch apex來執行Apex SOAP或HTTP異步		可以從batch apex中對遠端系統調用。此解決方案允許批處理遠端程序執行和批處理Apex作業，這些作業執行Apex SOAP次優調用或HTTP異步調用，以處理Salesforce中遠端系統的響應。但是，對于給定的批處理上下文，調用的次數是有限制的。

 四. 流程草圖

1.遠端系統訂閱了這個 Platform Event

2.salesforce一組記錄新增或者修改

3.trigger觸發

4. 這個process觸發了platform event

5.遠端系統偵聽器接收事件消息，并将消息放在本地隊列中

6.排隊應用程式将消息轉發給遠端應用程式進行處理。

在遠端系統必須對Salesforce執行操作的情況下，可以實作可選的回調操作。

五. 其他關鍵點

1. 調用機制

調用機制取決于為實作此模式而選擇的解決方案。應用與此模式相關的解決方案可以：

•使用者界面–啟動的遠端程序調用，其中事務的結果可以顯示給最終使用者

•DML事件啟動的遠端程序調用，調用程序可以處理事務的結果

 針對這兩個實際的方式我們可以選擇以下的調用場景

調用機制	描述
Process Builder	用于流程驅動和定制驅動的解決方案。事件觸發Salesforce程序，然後該程序可以釋出平台事件以供遠端系統訂閱。
Lightning元件或Visualforce和Apex Controller	用于使用Apex callout異步調用遠端程序。
Workflow rules	僅用于outbound message解決方案。建立和更新DML事件觸發Salesforce工作流規則，然後該規則可以向遠端系統發送消息。
Apex triggers	用于trigger驅動的Platform Event和遠端程序調用，由DML來啟動事件的Apex調用。
Apex batch classes	用于在批處理模式下調用遠端程序。

 2.Error處理和恢複。針對一個內建項目， error handling & recovery是特别核心的需要考慮的點。針對選擇的解決方案列出了推薦的處理方式。

	Error處理和恢複戰略
Apex Callout	錯誤處理—遠端系統不處理對結束程序的調用，是以callout隻處理遠端服務初始調用中的異常。例如，如果沒有收到來自遠端調出的肯定确認，則會觸發逾時事件。當初始調用被傳遞給異步處理時，遠端系統必須處理随後的錯誤。 恢複處理—在這種情況下，恢複更為複雜。如果服務品質要求要求，則必須建立自定義重試機制。
Outbound messaging	錯誤處理—由于此模式是異步的，是以遠端系統将處理錯誤處理。對于出站消息傳遞，Salesforce會在逾時時間内（最多24小時）未收到肯定的确認時啟動重試操作。必須在遠端服務中執行錯誤處理，因為消息以“Fire And Forget”的方式有效地傳遞給遠端系統。 恢複—由于此模式是異步的，系統必須根據服務的服務品質要求啟動重試。對于出站消息傳遞，如果在逾時時間内（最多24小時）未收到來自出站偵聽器的肯定确認，Salesforce将啟動重試。重試間隔随時間呈指數增長，從15秒間隔開始，到60分鐘間隔結束。通過向Salesforce支援部門提出請求，可以将逾時時間延長到7天，但自動重試時間限制為24小時。24小時後所有失敗的郵件都将放入隊列中，管理者必須監視此隊列中超過24小時傳遞期限的任何郵件，并在必要時手動重試。
Platform Events	錯誤處理—必須由遠端服務執行錯誤處理，因為事件被有效地傳遞給遠端系統進行進一步處理。因為此模式是異步的，是以遠端系統處理消息隊列、處理和錯誤處理。此外，平台事件不會在資料庫事務中處理。是以，已釋出的平台事件無法在事務中復原。 恢複—由于此模式是異步的，遠端系統必須根據服務的服務品質要求啟動重試。與每個事件關聯的 replay ID是原子的，并且随着每個已釋出事件的增加而增加。此ID可用于重放特定事件的流（例如，基于上次成功捕獲的事件）。高容量平台事件消息存儲72小時（三天）。使用CometD用戶端訂閱通道時，可以檢索過去的事件消息。

 3.安全注意事項： 對遠端系統的任何調用都必須保持請求的機密性、完整性和可用性。根據您選擇的解決方案，應用不同的安全考慮。

	安全考慮
Apex callouts	•對遠端系統的調用必須保持請求的機密性、完整性和可用性。以下是在這種模式中使用apexsoap和HTTP調用的安全注意事項。 •預設情況下啟用單向SSL，但自簽名和CA簽名證書都支援雙向SSL，以保持用戶端和伺服器的真實性。 •Salesforce在生成Apex代理類時不支援WS-Security。在必要時，考慮使用APEX密碼類方法使用單向散列或數字簽名，以確定請求的完整性。 •必須通過實施适當的防火牆機制來保護遠端系統。
Outbound Messaging	對于出站消息傳遞，預設情況下啟用單向SSL。但是，雙向SSL可以與Salesforce出站消息傳遞證書一起使用。以下是一些額外的安全注意事項。 •用于遠端內建伺服器的Salesforce伺服器IP範圍白名單。 •通過實施适當的防火牆機制來保護遠端系統
	對于平台事件，訂閱的外部系統必須能夠對Salesforce流式API進行身份驗證。 平台事件符合Salesforce組織中配置的現有安全模型。要訂閱事件，使用者需要對事件實體的讀取權限。要釋出事件，使用者需要對事件實體具有建立權限。

總結：篇中主要介紹了 Fire and Forget 發後即棄的模型相關的知識，感興趣的可以檢視官方文檔進行夯實。篇中有錯誤歡迎指出，有不懂歡迎留言。

作者：zero

部落格位址：http://www.cnblogs.com/zero-zyq/

本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接

個人下載下傳了一些相關學習的PDF檔案，如果需要下載下傳請通路百度雲 點選此處通路 密碼：jhuy

如果文章的内容對你有幫助，歡迎點贊~

為友善手機端檢視部落格，現正在将部落格遷移至微信公衆号：Salesforce零基礎學習，歡迎各位關注。