本篇參考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
我們在項目中，經常會遇見一個自定義頁面的按鈕或者一個 quick action點擊，或者頁面初始化，會對外部系統做一個 callout，然後獲取對方的數據以後做一些邏輯進行操作，這種場景實在是太常見了。這種場景通常有幾個特點：
- 實時性
- 數據量不大
- 對端響應快
當然可能還有很多的特點，這裏不多描述。salesforce針對這種我們常用的場景整理成一個集成模式，名稱爲： 遠程進程調用--請求和響應。那麼請求和響應的詳細描述是什麼，有哪些限制，針對這種集成模式有哪些解決方案，解決方案的適配度如何呢？我們接下來慢慢的描述。
一. 上下文
其實通過上面的描述中我們大概已經能聯想到我們實際的應用的上下文。這裏還是拿出來一個官方的例子去更好的進行一下描述。
您可以使用Salesforce跟蹤銷售線索、管理銷售渠道、創建銷售機會，並捕獲將銷售線索轉換爲客戶的訂單詳細信息。但是，Salesforce系統不包含或處理訂單。在Salesforce中捕獲訂單詳細信息後，將在遠程系統中創建訂單，該系統將管理訂單直至結束。
當您實現此模式時，Salesforce調用遠程系統來創建訂單，然後等待成功完成。如果成功，遠程系統會同步回覆訂單狀態和訂單號。作爲同一個transaction的一部分，Salesforce在內部更新訂單號和狀態。訂單號用作遠程系統後續更新的外鍵（External Id）。
通過這個描述，我們就可以清楚了這個case是Opportunity Close Won創建訂單，訂單號需要維護到外部系統，需要同步的call外部系統然後作爲外鍵更新到SF的訂單的記錄。
二. 問題和考慮因素
問題： 當一個事件從salesforce觸發時，如何在遠程系統中啓動（初始化）流程，將所需信息傳遞給該流程，從遠程系統接收response，然後使用該響應數據在Salesforce中進行更新？
考慮因素：在基於此模式應用解決方案時需要考慮以下因素。
- 對遠程系統的調用是否要求Salesforce在response回來之前等待響應？對遠程系統的調用是同步請求-應答還是異步請求？
- 如果對遠程系統的調用是同步的，Salesforce是否必須將response作爲與初始調用相同的事務的一部分進行處理？
- 消息大小是小還是大？
- 集成是否基於特定事件的發生，例如Salesforce用戶界面中的按鈕點擊，或基於DML的事件？
- 遠程端點（endpoint）是否能夠以低延遲響應請求？有多少用戶可能在高峯期執行此事務？
這些考慮因素很重要，會影響我們的解決方案的使用以及影響到我們當前的模式是否適用於當前的case。所以針對上述的考慮因素一定要慎重地思考。
三. 解決方案
針對此種解決方案 Salesforce提供了5種解決方案，不同的解決方案適用於不同的考慮因素點，當然有一個列表是適配度，描述當前是最好的方案還是次優的方案，當然，這個也不一定是絕對的，我們考慮集成方案的時候，除了考慮這種 best practice以外，還需要考慮 effort以及是否擁有 resource以及很多外部的因素。
| 解決方案 | 適配度 | 詳細說明 |
| 增強的外部服務來調用來調用一個REST API | BEST |
增強的外部服務允許我們以聲明方式調用外部託管的服務（不需要代碼）。當滿足以下條件時，最好使用此功能特性： •外部託管服務是RESTful服務,並且這個定義在OpenAPI 2.0 JSON格式下可用。 •請求和響應定義包含基礎的數據類型，如boolean、datetime、double、integer， String或Array(範式內容爲基礎類型)。 嵌套對象（Nested Object）類型，並且在HTTP request裏發送例如headers的參數也是支持的。 •這個Transaction可以從flow調用 |
|
Salesforce Lightning-組件或頁面以同步方式啓動 Apex SOAP或REST調用。 Salesforce classic-自定義 Visualforce頁面或按鈕以同步方式啓動 Apex SOAP調用。 如果遠程端點（endpoint）具有高延遲響應的風險,則建議使用異步調用+回調函數來避免達到同步 Government limitation. |
BEST |
Salesforce使您能夠使用WSDL並生成代理Apex Class。此類提供調用遠程服務所需的邏輯。 Salesforce還允許您使用標準的GET、POST、PUT和DELETE方法調用HTTP（REST）服務 在Visualforce頁或Lightning頁上由用戶啓動的操作隨後調用Apex Controller的操作，該操作隨後執行上述說的代理Apex類以執行遠程調用。 這種場景在Salesforce app中需要Visualforce頁面和Lightning頁面自定製。
|
| 自定義Visualforce頁面或按鈕以同步方式啓動Apex HTTP callout | BEST |
Salesforce使您能夠使用標準的GET、POST、PUT和DELETE方法調用HTTP服務。可以使用幾個HTTP類與RESTful服務集成。也可以通過手動構造SOAP消息來集成到基於SOAP的服務。不建議使用後者，因爲Salesforce可以使用wsdl生成代理類。 Visualforce頁上的用戶啓動的操作隨後調用Apex Controller的action，該操作隨後執行此代理Apex類以執行遠程調用。Visualforce頁面需要在Salesforce APP中自定義 |
| Salesforce數據更改以後通過trigger以同步方式調用一個 apex SOAP或者一個 http callout |
Suboptimal 次優 |
可以使用Apex Trigger根據數據更改執行自動化操作。 Apex代理類可以通過使用Apex Trigger作爲DML操作的結果來執行。但是，從Trigger上下文中發出的所有調用都必須從時間初始化時異步執行。因此，不建議將此解決方案用於此集成問題。此解決方案更適合於遠程進程調用Fire-and-Forget模式。 |
| Apex Batch Job以同步方式去執行 Apex SOAP或者 Http Callout |
Suboptimal 次優 |
可以從批處理作業調用遠程系統。此解決方案允許批處理遠程進程執行和處理Salesforce中遠程系統的響應。但是，給定的批處理對調用數有限制。可能觸發government limitation 給定的批處理運行可以執行多個事務上下文（通常以200條記錄爲間隔）。每個事務上下文都會重置調控器限制。 |
針對次優的方法我們通常不建議使用，除非針對這個case特別特殊。針對這五種解決方案，再擴展一下第二點中的異步調用方法。
先說一個我們最簡單的一個 callout的demo。 下面的這個代碼是最簡單的一個 callout操作，通過標準的 httprequest 的get方法獲取指定 endpoint的內容。
// Instantiate a new http object Http h = new Http(); // Instantiate a new HTTP request, specify the method (GET) as well as the endpoint HttpRequest req = new HttpRequest(); req.setEndpoint(url); req.setMethod('GET'); // Send the request, and return a response HttpResponse res = h.send(req); return res.getBody();
這種代碼和我們實際的場景可能也就缺少一個OAuth的邏輯，剩下的如出一轍。那麼如果遠程系統的 endpoint在高峯期處理的時候沒法達到低延遲響應的情況下，前端很容易假死，也很容易超時。這種情況我們就建議使用異步的 + callback方式來處理這種 高延遲的case。下面是官方推薦的代碼：
public Object startRequest() { // Create continuation with a timeout Continuation con = new Continuation(40); // Set callback method con.continuationMethod='processResponse'; // Create callout request HttpRequest req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint(LONG_RUNNING_SERVICE_URL); // Add callout request to continuation this.requestLabel = con.addHttpRequest(req); // Return the continuation return con; } // Callback method public Object processResponse() { // Get the response by using the unique label HttpResponse response = Continuation.getResponse(this.requestLabel); // Set the result variable that is displayed on the Visualforce page this.result = response.getBody(); // Return null to re-render the original Visualforce page return null; }
visualforce的調用demo可參考：https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_continuation_overview.htm
lwc的調用demo可參考：Salesforce LWC學習(十四) Continuation進行異步callout獲取數據
四. 流程草圖
1. 在Visualforce Page或者 Lightning中進行了某個操作，比如點擊了某個按鈕
2. 瀏覽器（如果是Lightning組件，則通過客戶端控制器）執行HTTP POST，該HTTP POST反過來對相應的Apex Controller執行操作（執行某個方法）。
3. controller對遠程web service進行實際的調用。
4. 來自遠程系統的響應返回到Apex Controller。Controller處理response，根據需要更新Salesforce中的數據，並reRender頁面操作。
五. 其他關鍵點
1. Error Handling考慮： 當我們在進行整體設計時，我們需要考慮錯誤處理以及數據恢復的策略。
• Error Handling：當error發生時（異常或者錯誤的code），調用者管理錯誤處理。比如頁面展示錯誤信息或者跳轉到共用頁面等等。
• Recovery：呼叫者接收到成功的response以後纔可以將數據commit到數據庫。如果失敗（連接失敗等）有必要可以重試連接
2. 冪等性（Idempotent）考慮：在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函數，或冪等方法，是指可以使用相同參數重複執行，並能獲得相同結果的函數。這些函數不會影響系統狀態，也不用擔心重複執行會對系統造成改變。
確保所調用的遠程過程是冪等的是很重要的。幾乎不可能保證Salesforce只調用一次，特別是當調用是由用戶界面事件觸發時。即使Salesforce發出一個調用，也不能保證其他進程（例如中間件）也會這樣做。構造冪等接收器的最典型方法是： 它基於使用者發送的唯一消息標識符（unique key）來跟蹤重複項(duplicate records)。Apex web service或REST必須自定義去發送唯一的消息ID。此外，在遠程系統中創建記錄的操作必須在插入之前檢查重複項，我們可以通過從Salesforce傳遞唯一的記錄ID進行檢查。如果遠程系統中存在該記錄，請更新該記錄。在salesforce的世界裏面很好理解，就是 upsert操作，我們需要創建一個外鍵，這個外鍵設置唯一即可。
3. 安全性考慮： 當我們調用遠程系統失敗以後，首先需要考慮 remote site setting是否配置了這個站點的URL，其次看一下CSP 是否配置。這兩個是項目中大部分場景都需要配置的。除此以外，對遠程系統的任何調用都必須保持請求的機密性、完整性和可用性。當我們在這種模式中使用apexsoap和HTTP調用時，我們需要考慮以下：
•默認情況下啓用單向SSL，但雙向SSL也要被self-signed 和 CA-signed 證書支持，以保持客戶端和服務器的真實性。
•Salesforce目前不支持WS-Security。
在必要時，考慮使用單向加密或數字簽名，使用Apex Crypto類方法來確保請求完整性。
•必須通過實施適當的防火牆機制來保護遠程系統。
4. 及時性以及用戶友好性：在這種模式中，及時性非常重要。通常：
•請求通常從用戶界面調用，因此該過程不能讓用戶等待（用戶期望時間最多不能超過10秒，否則會很煩的）。
•Salesforce對來自Apex的call out最多可以配置到120秒的 timeout
•及時完成遠程流程，在Salesforce超時限制和用戶期望範圍內完成。
•外部調用受Apex synchronous transaction governor限制，因此應注意降低實例化10個以上事務（每個事務運行時間超過5秒）的風險。
官方的介紹：If more transactions are started while the 10 long-running transactions are still running, they’re denied. HTTP callout processing time isn’t included when calculating this limit.
除了確保外部endpoint的性能外，減輕超時風險的選項還包括
–將callout的超時設置爲5秒
–在Visualforce或Lightning組件中使用continuation來處理長時間運行的事務
補充知識：Apex Continuations是Salesforce平臺提供的一種機制，允許您向外部Web服務發出異步長時間運行的請求。該服務支持對SOAP或restweb服務的調用，最大超時爲120秒（而標準同步調用爲10秒）。
5. 數據量考慮：此模式主要用於小容量的實時活動，因爲Apex調用解決方案的超時值較小，請求或響應的大小也最大。當批處理的場景，包含數據負載的情況下不要使用此模式。
6. 遠程系統的EndPoint 能力和標準支持：針對 endpoint的需要的能力和標準的服務取決於我們選擇的哪種解決方案
六. 常見考題
Question: Universal Containers is a global financial company that sells financial products and services including, bank accounts, loans, and insurance. UC uses Salesforce Service cloud to service their customer via calls, live chat. The support agents would open bank accounts on the spot for customers who are inquiring about UC bank accounts. UC Core banking system is the system of record for bank accounts and all accounts opened in salesforce have to be synced in real-time to the core banking system. Support agents need to inform the customers with the newly created bank account ID which has to be generated from the core banking system. Which integration pattern is recommended for this use case? Answer： Use request and reply. Question: Universal Containers wants to gather information from a third-party application to update shipping information for an order inside Salesforce. A salesperson could trigger an update and the user interface would refresh with the current status. Which are two recommended options for this when utilizing a Remote Process Invocation-Request and Reply pattern? Answer: A custom Visualforce page or button that initiates an Apex REST callout in a synchronous manner. A custom Visualforce page or button that initiates an Apex SOAP callout in a synchronous manner.
總結：篇中主要介紹了遠程進程調用--請求和響應的集成模式，這個在實際項目場景是最常用到的，所以大家理解也相對方便。篇中有錯誤歡迎指出，有不懂歡迎留言。