本篇參考：https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
本篇部落格介紹 Remote Call-In 內建模式，一言以蔽之：此種模式用于存儲在Lightning Platform中的資料由遠端系統建立、檢索、更新或删除
先說一下針對 salesforce的 callout 以及 call in 。 簡單的來說, callout就是 salesforce call外部系統。 Call in 就是外部系統 call salesforce。此模式用于 外部系統 call salesforce的場景。
一. 上下文
我們在salesforce中走着sales cloud的流程，從 lead 轉換到 Account Opportunity，對Opportunity進行追蹤。當赢單以後建立訂單。 但是訂單由外部（遠端）系統管理。當訂單通過其處理階段時，遠端系統需要更新Salesforce中的訂單狀态。
上述的場景是官方的一個sample，當然除了這個場景以外，我們實際項目中這種例子比比皆是。
比如針對國内的項目，特别是銷售或者零售相關的操作，很多操作都是基于平闆或者手機進行操作，然後實時或者點指定按鈕同步到salesforce端，這種都屬于 Remote Call-In的場景。
二. 問題和考慮因素
問題： 遠端系統如何與Salesforce連接配接并進行身份驗證，以通知Salesforce外部事件、建立記錄和更新現有記錄？
考慮因素：
- 遠端調用Salesforce的目的是使用事件驅動系統結構通知Salesforce外部發生的事件嗎？或者目的是對特定記錄執行操作？如果使用事件驅動系統結構，則事件生産者（遠端程序）将與Salesforce事件使用者分離。
- 對Salesforce的調用是否要求遠端程序在繼續處理之前等待響應？對Salesforce的遠端調用始終是同步的request-reply，但是如果不需要遠端程序來模拟異步調用，則遠端程序可以放棄響應。
- 每個事務是針對單個Salesforce對象還是針對多個相關對象進行操作？
- 消息的格式是什麼（例如，通過HTTP的SOAP或REST，或兩者）？
- 消息大小是相對較小還是較大？
- 如果遠端系統支援SOAP，那麼遠端系統是否能夠參與契約優先(contract-first)方法？在使用SOAP API的地方，這是必需的，為此提供了預定義的WSDL。
- 是否需要進行transaction處理？
- 對Salesforce定制的容忍程度如何？是否有足夠的資源去做 salesforce的自定制
三. 解決方案
基于上述的問題和考慮因素，salesforce推薦了相關的解決方案，詳情如下表格所示
| 解決方案 | 适配程度 | Comments |
| SOAP API | Best | Salesforce提供了一個标準的SOAP API，遠端系統可以使用該API進行以下操作： –釋出事件以通知您的Salesforce組織 –查詢組織中的資料 –建立、更新和删除資料 –擷取組織的中繼資料 –運作實用程式以執行管理任務 •同步API發出API調用後，遠端用戶端應用程式将等待，直到收到來自服務的響應。不支援對Salesforce的異步調用。 •生成的WSDL Salesforce為遠端系統提供了兩個WSDL： –企業WSDL提供特定于Salesforce組織的強類型WSDL。 –合作夥伴WSDL包含一個松散類型的WSDL，它不是特定于Salesforce組織的。 •安全執行SOAP API的用戶端必須具有有效的登入名，并獲得會話以執行任何API調用。API尊重Salesforce中基于登入使用者配置檔案配置的對象級和字段級安全性。 •事務/送出行為預設情況下，如果某些記錄标記有錯誤，則每個API調用都允許部分成功。這可以更改為“全部或無”行為，如果發生任何錯誤，将復原所有結果。不可能跨多個API調用跨事務。為了克服這個限制，一個API調用可以影響多個對象。 •批量資料—任何包含2000條以上記錄的資料操作都是Bulk API 2.0成功準備、執行和管理使用批量架構的異步工作流的理想選擇。少于2000條記錄的作業應該涉及REST（例如，複合）或SOAP中的“批量化”同步調用。 •事件驅動架構平台事件的定義方式與Salesforce對象的定義方式相同。通過soapi釋出事件與建立Salesforce記錄相同。僅支援建立和插入操作。 |
| REST API | Salesforce提供了一個标準的REST API，遠端系統可以使用該API： •REST API與SOAP API-REST将資源（實體/對象）公開為URI，并使用HTTP謂詞定義對這些資源的CRUD操作。與SOAP不同，restapi不需要預定義的契約，使用XML和JSON進行響應，并且具有松散的類型。restapi是輕量級的，它提供了一種與Salesforce互動的簡單方法。它的優點包括易于內建和開發，是與移動應用程式和web應用程式配合使用的最佳選擇。 •安全執行REST API的用戶端必須具有有效的登入名，并獲得會話以執行任何API調用。API尊重Salesforce中基于登入使用者配置檔案配置的對象級和字段級安全性。 •事務/送出行為預設情況下，每個記錄都被視為一個單獨的事務并分别送出。一個記錄更改失敗不會導緻其他記錄更改復原。此行為可以更改為“全有或全無”行為。使用restapi複合資源在一個API調用中進行一系列更新。 •REST複合資源使用這些REST API資源在單個API調用中執行多個操作。也可以使用一個調用的輸出作為下一個調用的輸入。請求的所有響應主體和HTTP狀态都在單個響應主體中傳回。整個請求都算作一個符合API限制的調用。 •批量資料—任何包含2000條以上記錄的資料操作都是批量API 2.0成功準備、執行和管理使用批量架構的異步工作流的理想選擇。少于2000條記錄的作業應該涉及REST（例如，複合）或SOAP中的“批量化”同步調用。 •事件驅動架構平台事件的定義方式與Salesforce對象的定義方式相同。通過restapi釋出事件與建立Salesforce記錄相同。僅支援建立和插入操作。 | |
| Apex web services | Suboptimal | Apex類方法可以作為web服務方法公開給外部應用程式。此方法是SOAP API的替代方法，通常僅在必須滿足以下附加要求的情況下使用。 •需要全面的事務支援（例如，在一個事務中建立帳戶、聯系人和機會）。 •在送出之前，必須在Salesforce端應用自定義邏輯。使用apexweb服務的好處必須與Salesforce中需要維護的額外代碼進行權衡。不适用于Platform Event，因為使用者處的事務預插入邏輯不适用于基于事件驅動的體系結構。要通知Salesforce組織發生了事件，請使用SOAP API、REST API或Bulk API 2.0。 |
| Apex REST services | Apex類可以公開為映射到特定uri的REST資源，并使用針對它定義的HTTP謂詞（例如POST或GET）。您可以使用restapi複合資源在單個事務中執行多個更新。Apex REST服務與SOAP不同，它不需要客戶機使用服務定義/約定（WSDL）并生成客戶機存根。遠端系統隻需要能夠形成HTTP請求并處理傳回的結果（XML或JSON）。不适用于Platform Event，因為使用者處的事務預插入邏輯不适用于基于事件驅動的體系結構。要通知Salesforce組織發生了事件，請使用SOAP API、REST API或Bulk API 2.0。 | |
| Bulk API 2.0 | Optimal for bulk operations | bulkapi2.0基于REST原理，并針對加載或删除大型資料集進行了優化。它與restapi具有相同的可通路性和安全行為。任何包含超過2000條記錄的資料操作都是BulkAPI2.0成功準備、執行和管理利用Bulk架構的異步工作流的理想選擇。少于2000條記錄的作業應該涉及REST（例如，複合）或SOAP中的“批量化”同步調用。bulkapi2.0允許客戶機應用程式通過送出Salesforce在背景處理的大量批來異步查詢、插入、更新、更新或删除大量記錄。相比之下，soapi針對一次更新少量記錄的實時客戶機應用程式進行了優化。盡管SOAP-API也可以用于處理大量記錄，但當資料集包含數十萬到數百萬條記錄時，它就變得不太實用了。這是由于其相對較高的開銷和較低的性能特點。 •事件驅動架構平台事件的定義方式與Salesforce對象的定義方式相同。通過批量API 2.0釋出事件與建立Salesforce記錄相同。僅支援建立和插入操作。批處理作業處理時，批進行中的事件将異步釋出到Salesforce事件總線 |
四. 流程草圖
下圖說明了在使用RESTAPI（用于外部事件的通知）或SOAP API（用于查詢Salesforce對象）實作此模式時的事件序列。使用restapi時，事件的順序是相同的。
下圖為SOAP API流程
下圖為REST API流程
五. 其他關鍵點
1.調用機制：調用機制取決于為實作此模式而選擇的解決方案。
| 調用機制 | 描述 |
| 遠端系統使用Salesforce企業或合作夥伴WSDL生成客戶機存根，這些存根反過來用于調用标準soapapi。 | |
| 遠端系統必須在通路任何Apex REST服務之前進行身份驗證。遠端系統可以使用OAuth 2.0或使用者名/密碼身份驗證。在任何一種情況下，客戶機都必須使用适當的值設定授權HTTP頭（OAuth通路令牌或會話ID可以通過對soapapi的登入調用獲得）。然後，遠端系統使用适當的動詞生成REST調用（HTTP請求），并處理傳回的結果（支援JSON和XML資料格式）。 | |
| Apex web service | 遠端系統使用定制Apex web服務WSDL來生成客戶機存根，這些存根反過來用于調用定制Apex web服務。 |
| Apex REST service | 根據restapi，資源URI和适用的謂詞是使用@RestResource、@HttpGet和@HttpPost注釋定義的。 |
| bulkapi2.0是一個基于REST的API，是以應用了與restapi相同的調用機制。 | |
| REST API to invoke Flow | 使用restapi調用自定義invocable操作端點以調用自動啟動的流。 |
2.Error Handling & Recovery
內建就涉及到握手操作以及通過 token或者session等授權資訊進行SOQL Query或者資料的DML操作。以國内為例。因為salesforce在國内沒有伺服器，并且通路很慢，基于SOAP / REST 标準的API都是同步操作，很容易經常碰到逾時現象，除此以外，我們還要考慮DML的程式問題或者 validation rule / trigger等 addError的行為。針對 Error Handling以及 Recovery官方建議如下：
錯誤處理—所有遠端調入方法、标準或自定義API都要求遠端系統處理任何後續錯誤，例如逾時和重試管理。必要情況下可以引入中間件，中間件可用于提供錯誤處理和恢複的邏輯。
恢複—如果服務品質要求要求，則需要建立自定義重試機制。在這種情況下，確定幂等設計特性非常重要。Platform Event使訂閱者能夠在消息釋出後的特定時間段内使用replay ID擷取消息
3.幂等性考慮：幂等函數功能保證重複調用是安全的，不會産生負面影響。如果未實作幂等性，則對同一消息的重複調用可能會産生不同的結果，可能會導緻資料完整性問題，例如，建立重複記錄、重複處理事務等。在發生錯誤或逾時的情況下，遠端系統必須管理多個（重複）調用，以避免重複插入和備援更新（尤其是在觸發下遊觸發器和工作流規則時）。雖然可以在Salesforce中管理其中一些情況（特别是在定制SOAP和REST服務的情況下），但我們建議遠端系統（或中間件）管理錯誤處理和幂等設計。
4.及時性以及資料量
及時性：SOAP API 以及Apex Web service API都是同步的操作，遵循着以下的 timeout limitation
Session timeout ：根據Salesforce組織的會話逾時設定，如果沒有活動，會話将逾時（不一定100%的貼近，比如session setting設定的2小時，有時候即使超過2小時也不會會話逾時，有可能3、4小時以後才會逾時，不絕對，但是要遵循最壞情況的處理原則）
Query timeout：每一個SOQL的查詢有一個獨立的120秒的限制。
資料量：資料量的考慮需要取決于我們采用了哪個方案，可以看一下下面的表格
| 通信類型 | 限制點 | |
| SOAP API或者REST API | 同步 | SOAP Login： SOAP login request 大小要限制在10K以内。每個人每小時調用 login函數最多3600次，如果超過了這個限制，就會報錯 Create/ Update/ Delete：一次操作最多操作200條資料。如果操作資料超過了200條，需要多個call，但是需要保證每個call最多200條資料 Query Results Size： 通過調用 query()以及queryMore預設是500，最多可以2000. Event Message—最大事件消息大小為1 MB。使用Salesforce API釋出事件将也計算在标準API限制中。 |
| Bulk API适用于操作數量超過2000條的情況，如果操作的數量超過了2000條，最好使用 bulk，而不是 SOAP/REST |
六： 常見考題
Universal Containers (UC) has integrations developed between Salesforce and back-end ERP applications. During peak load, UC is getting an error at the integration layer indicating, "Login Rate Exceeded". Which two recommendations would mitigate this issue?
Use a different user for each integration.
Cache the session ID to avoid a login call.
一個user1小時有最多3600次 login調用的限制，如果出現了 Login Rate Exceeded問題，要麼使用其他的賬号，要麼成功登入以後存儲session 資訊，減少 login方法的調用
總結：篇中主要介紹了Remote Call in內建模式的相關知識，這個內建模式實際場景也經常用到。篇中有錯誤地方歡迎指出，又不懂歡迎留言。
作者：zero
部落格位址：http://www.cnblogs.com/zero-zyq/
本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接
個人下載下傳了一些相關學習的PDF檔案，如果需要下載下傳請通路百度雲 點選此處通路 密碼：jhuy
如果文章的内容對你有幫助，歡迎點贊~
為友善手機端檢視部落格，現正在将部落格遷移至微信公衆号：Salesforce零基礎學習，歡迎各位關注。