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