本篇參考：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 發後即棄的模型相關的知識，感興趣的可以查看官方文檔進行夯實。篇中有錯誤歡迎指出，有不懂歡迎留言。