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	Goods	回調提供了一種減輕無序消息傳遞影響的方法。此外，它們處理這些場景。   •冪等性—若是未及時接收到確認，則出站消息將執行重試。能夠向目標系統發送多條消息。使用回調能夠確保檢索到的數據是在特定的時間點，而不是在發送消息時。 •檢索更多數據—單個出站消息只能發送單個對象的數據。回調可用於從其餘相關記錄（如與父對象關聯的相關列表）檢索數據。出站消息提供了一個惟一的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異步調用	Suboptimal	可使用Apex Trigger根據記錄數據更改執行自動化。 Apex代理類能夠經過使用Apex Trigger做爲DML操做的結果來執行。可是，從觸發器上下文中發出的全部調用都必須異步執行。
Batch apex來執行Apex SOAP或HTTP異步	Suboptimal	能夠從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範圍白名單。   •經過實施適當的防火牆機制來保護遠程系統
Platform Events	對於平臺事件，訂閱的外部系統必須可以對Salesforce流式API進行身份驗證。 平臺事件符合Salesforce組織中配置的現有安全模型。要訂閱事件，用戶須要對事件實體的讀取權限。要發佈事件，用戶須要對事件實體具備建立權限。

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