非同步處理可透過允許每個內容更高的限制來增加延展性。非同步要求會在背景執行自己的執行緒,因此使用者可以在非同步工作在背景中執行時,繼續在用戶端執行工作。

Salesforce Lightning 平台提供各種非同步技術,可用來解決指定的使用個案。每個技術都有您在為每個使用個案選取方法時需要考量的優點與限制。

選擇實作技術時,請記住三個重要考量事項:

1. 非同步處理並非每個問題的最佳方法。嘗試將不直接需要使用者互動的任何程序視為非同步處理的良好候選項目,但有一些缺點。首先,非同步程序沒有 SLA,這表示不保證非同步程序會在設定的時間內完成。其次,沒有一致回應延遲的保證。如果非同步程序在特定時間內完成,則後續程序可能需要不同的時間完成。因此,即使使用者並未直接等待回應,如果您有後續的程序取決於回應,或您擔心過多回應時間可能導致您的資料與外部系統中的資料不同步,則非同步處理可能不適合���的案例。
2. 在 Salesforce Platform 上處理非同步要求的方式不同,因此請確保您選擇最佳方法。在 Salesforce Platform 上支援非同步處理的技術運作方式不同,有些技術是針對非常特定的使用個案所設計。
3. 如果技術在用戶端為非同步,則不一定表示所有端對端處理都會並行執行。視您所做的選擇而定,用戶端訊息有時仍會在伺服器端進行序列化。

如果您針對工作使用錯誤的技術或錯誤的技術組合,可能會發生取消非同步處理好處的非預期後果。本指南提供各種非同步使用個案的說明和建議,以及可能的缺點和反模式,以及這些建議的理由。它也會提供如何在 Salesforce Platform 上運作和監管各種非同步實作技術的洞察。

如果您要決定要使用的技術,則有一份專注的「非同步處理決策指南」(Asynchronous Processing Decision Guide) 提供一般使用個案的快速對應至最適合的技術。

Salesforce Lightning Platform 是一個全方位、 AI 驅動的平台,可將員工、獨立 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以提升生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。

此文件不涵蓋其他生態系統中的技術,例如 MuleSoft、Informatica、Commerce Cloud、Tableau 和 Marketing Cloud。

請注意,本指南專注於 Salesforce Lightning 平台內的非同步處理。如果您要尋找非同步整合模式的相關資訊,請查看「事件驅動結構」。

• **使用非同步處理之前,請確定您的使用個案符合模式。**非同步模式沒有 SLA、受限於多個管理員機制、可根據授權定義產能限制,且可能會因為配置給 Salesforce Platform 中非同步基礎結構的資源有限性而造成處理延遲。在使用者需要系統回應的情況下使用非同步處理時,請嚴重考量這些限制,才能繼續工作。
• **使用 Salesforce 進行非同步處理並非滿足無限調整需求的解決方案。**Salesforce Platform 的規模不會無限,非同步模式仍受到限制。非同步處理使用執行緒,其中包含 CPU 執行指示串流所需的內容資訊。討論串可以並列執行。任何 CPU 中可用的執行緒數目受到限制,因此平台已具備機制,以確保盡可能有效率地使用可用的執行緒。平台的 流程控制機制可防止組織耗用太多執行緒,並對其他組織造成負面影響。平台的 公平使用演算法可控制組織針對每個特定訊息類型可用的執行緒數目。
• **瞭解交易何時為真非同步。**某些結構模式的行為非同步,端對端。然而,其他程序在用戶端或瀏覽器端會以非同步的行為執行,但會序列化伺服器端要求,然後這些要求會受到同步管理員限制的約束。
• 若要從 Salesforce Platform 建立大規模輸出整合,請使用平台事件和強大的中介軟體,而非透過非同步 Apex 進行呼叫。由於平台中可用的非同步執行緒數量有限,因此透過非同步 Apex 的輸出整合有有限的延展性。如果您的組織有輸出整合,涉及大量訊息、超過可用執行緒數目,且處理時間較長,則使用非同步 Apex 將會導致延遲。
• **使用非同步處理時,請確保納入監視。**透過監視,您可以盡早偵測問題,並在發生重大效能事件之前予以更正。
• **可能造成極限負載的事件。**當您設計非同步流程時,請確定流程可以預測地管理工作量高峰和閒置。請考慮您的實作如何處理非預期的事件,例如停電,以及設計可減輕資料遺失或功能遺失的安全防護。

當您為伺服器端非同步處理選取方法時,請先評估您組織的需求和可用資源。您的目標是選取最小化實作和維護成本的方法,同時確保延展性並將限制違規的可能性降到最低。此目標取決於後續章節中概述的技術考量事項,以及您小組的組成。例如,考慮您的小組中是否有 Apex 開發人員可以維護您的 Pro-code 解決方案。否則,陳述性方法會更有意義。此外,請記住,不同的 限制集可套用至不同的工具。

請考慮 Salesforce 中非同步訂購流程的使用個案。儲存訂單時,會觸發外部倉庫管理系統的訊息,其中包含如何包裝和寄送項目的特殊指示。下單的使用者不需要倉庫管理系統的立即回應,因此要求可以非同步傳送。非同步處理可讓使用者繼續工作,而且不會發生延遲。

您結構的考量事項:

• 需要多少同時程序?
• 同時流程如何相互互動?
• 每個程序內將執行多少個 SOQL 查詢?
• 每個流程內將執行多少個 DML 作業?
• 每個程序會執行多久?
• 流程對特定時間的敏感度為何?

Salesforce Platform 的 多租戶結構會區隔並同時支援許多租戶 (組織) 的不同需求。本指南涵蓋的所有非同步 Apex 方法都會在 Salesforce Platform 中的相同非同步基礎結構中執行。它們使用由兩個主要強制執行機制所管理的訊息排列架構:流程控制與公平使用。

流程控制和公平使用機制可防止單一租戶使用過多伺服器資源,且不會為剩餘的租戶留下足夠的資源。雖然瞭解這些機制的運作方式很有幫助,但您的關鍵考量應該是遵循非同步處理的最佳作法 (例如在後續章節中概述的最佳作法) 會大幅降低您遇到問題的可能性。

平台的流程控制機制可防止一個組織溢出指定的訊息類型,這會耗用太多執行緒並對其他組織造成負面影響。架構會在將新項目新增至與訊息類型相關聯的資料列前,先檢查前幾千個現有項目。如果大多數現有項目與相同的組織相關聯,且該組織也已在工作人員討論串中有項目,則新增的項目會移至該組織的後端。此流程稱為重新排列。批次 Apex 和大量 API 流程通常會發生重新排列,因為這些流程通常會同時將大量的項目插入到其列中。

平台的公平使用機制會實作以層級為基礎的系統。系統會確保 Salesforce Platform 上的每個組織都會獲得指定訊息類型的處理時間,包括「未來」、「可排列」和「批次」訊息類型。如果某個組織在等待其他組織對相同訊息類型執行工作的同時,控制指定的訊息類型,則公平使用率演算法會減少組織可用於該特定訊息類型的執行緒數目。

使用非同步 Apex 方法的好處是某些管理員限制 (例如 SOQL 查詢限制和堆疊大小限制) 較高。不過,請勿過度依賴這些方法。由於分配給非同步基礎結構的有限資源,因此使用 Future、Queueable 和批次 Apex 大量可能會導致處理延遲,這取決於合理使用與流程控制的限制。

使用非同步 Apex 的輸出呼叫會計入非同步 Apex 限制。每日限制目前為 250,000 或 200 倍的適用使用者授權數目,視何者較大而定。此限制可能是大量使用個案的問題。如果您超過限制,您的非同步 Apex 工作及其相關聯的輸出呼叫將會失敗。

此外,由於平台有有限數量的非同步執行緒可供使用,因此透過非同步 Apex 的輸出整合有有限的延展性。大量輸出整合超過可用執行緒的數量可能會有較長的處理時間並導致延遲。

針對大量使用個案,請考慮這些替代方法。具有這些方法的 API 呼叫會計入每日 API 要求限制,此限制明顯高於每日非同步 Apex 限制。因此,這些方法更容易調整。不過,請注意,任何 CPU 可處理的同時要求數量仍有實體限制。

• **中介排程提取。**使用中介軟體以排程的方式提取資料,而非透過非同步 Apex 推送資料,以避免與大量輸出整合工作相關聯的延遲。中介軟體 (例如 MuleSoft Anypoint Platform) 可以同步方式使用原生 SOAP API 或 REST API,因此可能會導致少量延遲。中繼軟體也可以針對大量資料使用原生大量 API。

• **透過平台事件通知提取中繼軟體。**您可以使用平台事件來執行輸出整合,而不是強制執行 Future、Queueable 或批次非同步 Apex。平台事件可以提供輸出資訊,或指示中介軟體工具透過原生 API 提取必要資訊並將其傳送至最終目的地。這些方法皆不受非同步 Apex 所需的延遲影響。不過,平台事件限制仍適用。

透過可排入排列的 Apex,您可以非同步地執行涉及大量資料庫作業或外部 Web 服務呼叫的 Apex 程序。若要使用 Queueable Apex,請實作「Queueable 介面」,然後將工作新增至 Apex 工作排隊。此方法可確保非同步 Apex 工作在其專屬的隔離執行緒中在背景中執行,且不會延遲主要 Apex 邏輯的執行。當系統資源變為可用時,會執行每個已排列的工作。

Apex 代表非同步 Apex 的進化。其提供未來 Apex 方法無法使用的功能,包括:

• **工作識別碼:**當您透過叫用 System.enqueueJob 方法提交工作時,方法會傳回新工作的識別碼。您可以使用此識別碼來識別您的工作。若要監視其進度,請在 Salesforce 設定中檢視 Apex 工作頁面,或查詢 AsyncApexJob 物件。
• **支援非原始類型:**可排列類別可包含非原始資料類型的成員變數,例如 sObject 或自訂 Apex 類型。
• **工作鏈支援:**您可以透過從執行中工作開始第二個工作,將「可排列」工作鏈結在一起。此技術可協助您處理涉及流程相依性的案例。
• **最大深度控制:**您可以設定具有最大堆疊深度的「可排列」工作,以確保工作鏈結束時不會發生非預期的遞迴。
• **取消重複簽名:**可排列的工作會提供選擇性簽章,以偵測並移除重複工作。
• **可設定的延遲:**您可以定義最多 10 分鐘的延遲,才能執行「可排列」工作。
• **交易完成者:**您可以將後續動作順序附加至「可排列」工作,並根據結果採取相關動作。例如,交易完成者最多可以將因未處理的例外而失敗的可排列工作重新排列五次。

Salesforce 使用以列為基礎的架構來處理非同步流程。用來平衡跨組織的要求工作量。若要確保您的組織能盡可能有效率地使用此列:

• 避免直接從由大量一般使用者活動或整合 API 呼叫所產生的動作中將 Future 或 Queueable 方法加以排隊。此方法會快速耗盡每日非同步 Apex 限制,導致嚴重的業務影響。
• 請避免針對每個同步動作將多個非同步動作加入排隊。當從單一同步動作建立多個非同步方法時,非同步活動通常會同時執行,進而造成列鎖定爭用和/或列鎖定逾時錯誤。
• 請避免將大量的 future 或 Queueable 方法新增至非同步排列。
• 請確保 future 與 Queueable 方法會盡快執行。未來方法執行所花費的時間愈長,其後的要求可能會延遲到該方法的到來。若要確保批次工作快速執行,請將 Web 服務呼叫時間最小化、調整未來方法中使用的查詢,並最佳化任何其他物件自動化,包括流程產生器程序、工作流程規則、流程和 Apex 觸發。
• 大規模測試您的非同步方法。使用產生您預期處理方法數目上限的環境。此測試可協助判斷您在生產環境中是否會遇到效能問題或限制。也請考量對累積每日限制的影響。
• 使用批次 Apex,而非 future 或 Queueable 方法來處理大量記錄。批次 Apex 可以處理針對數千筆記錄執行的複雜、長時間執行程序,並可排程在更多資源可用時段執行。

使用排程的 Apex,以在 Cron 運算式所定義的指定時間和重複頻率執行。雖然透過 Cron 運算式排程 Apex 的動作是非同步的程序,但基本程式碼會在工作開始時同步執行。排程的 Apex 非常適用於每日或每週維護工作。

• 您一次只能擁有 100 個排程的 Apex 工作。若要避免此限制,請考慮使用排程所觸發的流程來叫用 Apex 程式碼,而非使用排程的 Apex。
• 如果您計畫從觸發排程類別,請特別小心。您必須能夠保證觸發不會新增超過限制的排程類別。特別考慮 API 大量更新、匯入精靈、透過使用者介面進行的大量記錄變更,以及一次可更新多個記錄的所有個案。
• 針對需要在未來排程最多 10 分鐘的一次性工作,請使用延遲的「可排列」工作。此方法不會計入 100 個排程工作限制。
• 排程的 Apex 會在具有同步限制的同步環境中執行。
• 考量排程工作的執行時間。長時間執行的工作可能會與下一個排程工作的開始時間重疊。
• Salesforce 會排程類別在指定的時間執行。實際執行可能會根據服務可用性延遲。排程在服務維護停機期間執行的工作,將排程在服務備份後執行。
• 使用 System.scheduleBatch 來排程批次工作,而不是只用於建立批次工作的已排程工作。

以往,從在同步 Apex 交易內容中執行的 Apex 方法 (例如 Visualforce 控制項或 Lightning 元件控制項) 進行的同步呼叫受限於長時間執行要求的 Apex 同時限制。自 Winter ’19 起,同步呼叫將不再視為長時間執行。儘管 Apex 繼續功能最初是作為同步呼叫的解決方案而建立,進而導致長時間執行要求,但其也提供一些額外優點。

• 單一同步動作最多可執行三個繼續動作。先前的繼續動作必須先完成,才能執行新的繼續動作。
• 每個繼續動作最多可執行三個呼叫,並行執行。
• 當繼續動作執行的所有呼叫完成時,平台會叫用繼續回呼方法來處理結果。

雖然持續項目會與原始同步動作不同步執行,但 Apex 持續項目與其他非同步 Apex 技術 (例如 future 方法、可排列或批次) 之間仍有關鍵差異。主要差異包括:

• 繼續項目並不會以任何方式排入排隊。
• 繼續不會影響每日非同步 Apex 執行限制。
• 繼續將應用程式伺服器上的執行緒內容從粗體 Apex 平台執行緒切換為僅執行呼叫的輕量型執行緒。為了執行最多可執行 120 秒的呼叫,繼續功能可大幅節省應用程式伺服器記憶體。
• 一開始,只能從 Visualforce JavaScript 遠端呼叫執行繼續。不過,在 Summer ‘19 中,繼續項目正式新增至 Lightning 元件架構,因此不需要 Visualforce。

平台事件是 Salesforce Platform 實作的純粹以事件為導向結構。您可以在「事件驅動結構的結構設計師指南」中找到與此類型結構相關聯之元件的詳細資料。

平台事件和平台事件觸發/流程通常是執行非同步 Apex 的絕佳替代方案。它們也是叫用平台外處理的好方法。例如,您可以���用 Amazon Web Services (AWS) 事件轉送和平台事件的組合,在 AWS Lambda 中叫用無伺服器運算功能。執行相對快速且沒有任何呼叫的工作 (平台事件觸發或流程無法執行) 是平台事件/觸發或事件/流程組合的絕佳候選項目。

透過 認可後發佈發佈至 Bus 的事件會依序傳送,且可以在個別的同步化內容中由觸發或流程大量處理。內容為同步,會強制執行所有同步管理員限制。請謹慎選擇平台事件觸發/流程批次大小,以避免達到限制。

• 當事件發佈在 Event Bus 上時,這些事件便可供消費者使用。在事件觸發 (Apex 或流程) 的情況下,這些事件會分派至應用程式層級上的可用同步執行緒 (每個事件觸發/流程一個執行緒)。請注意,此程序沒有 SLA。
• 當將發佈作業新增至排列時,排列流程的結果會儲存在 Database.SaveResult 物件中。這些項目只會指示排列作業是否成功。若要取得透過 Event Bus 發佈的事件最終結果,請實作 Apex 發佈回呼。透過此額外資訊,您可以決定進一步的動作,例如嘗試重新發佈失敗的事件。
• 雖然平台事件不受限於與非同步 Apex 相同的限制,但它們有自己的 管理員限制集。如果您遇到限制的問題,您可以啟用 增強型事件用量度量,以判斷特定事件是否使用的配置超出預期。如果您在事件觸發上需要更大的輸送量,請考慮使用 平行訂閱來同時處理事件,而非在單一串流中處理。透過並列訂閱,您可以調整 Apex 平台事件觸發的規模,以處理大量事件。並行訂閱適用於自訂大量平台事件,但不適用於標準事件或變更事件。
• 平台事件有兩個發佈行為的選項:
  • 立即發佈:在最終資料庫認可之前,事件會在交易期間立即發佈。以此方式發佈的事件不保證會依順序發佈。
  • 認可後發佈:事件會在成功認可資料庫交易時發佈。以此方式發佈的事件保證會依順序發佈。

針對使用個案 (例如記錄) 使用「立即發佈」很有幫助,無論交易是否成功且認可,或失敗且回復,您都會在其中發佈記錄事件。您可以立即發佈由平台事件觸發所耗用的平台事件。接著平台事件觸發會將資料庫列鎖定與發佈該資料列的交易進行競爭。在立即發佈平台事件前,請先徹底檢閱所有設計,以確保避免此情況。

非同步流程提供低程式碼替代方式給非同步 Apex。如同其他形式的非同步處理,當資源可用時會在背景中執行。非同步流程也沒有 SLA,且可能會有無法預測的等待時間。

排程路徑是以 Cron 觸發為基礎,可在特定時間執行。它們會在建立、更新或刪除記錄時執行,並讓您能更精確地控制何時執行相對於記錄變更的自動化。(範例:在工作到期前一小時將電子郵件傳送給使用者。)不同於 Apex future 方法,此方法限制為同步交易中建立的最多 50 個方法,已排程流程動作目前沒有每個交易的最多排入限制。然而,已排程路徑定義中有一個批次大小組態,允許某些控制已排程路徑流程執行處理的記錄數量。

非同步路徑可新增至記錄觸發流程。它們會在背景中執行,且不會延遲原先觸發流程的交易執行。您可以使用非同步路徑來執行長時間執行中的作業,或任何您想要在自己的時間執行的作業。非同步路徑可協助避免在您需要更新非觸發流程之記錄相關記錄值時發生的混合 DML 錯誤。

**備註:**輸出傳訊是舊版功能,平台事件 (如上一節中所述) 是更現代化的方法,提供更大的彈性。「平台事件」是 Salesforce 針對以事件為導向的整合所建議的模式。

輸出訊息透過 SOAP API 提供非同步輸出通訊的方式。在 Salesforce 中設定時,輸出訊息定義會產生可由外部 Web 服務提供者所取用的 SOAP WSDL。輸出訊息可以從工作流程規則、流程產生器程序或 Lightning 儲存後流程觸發觸發。輸出 SOAP 訊息最多可包含 100 個通知。每個通知都包含物件識別碼,以及相關聯的 sObject 資料參照。若基本物件中的資訊在通知排入排隊後但在通知傳送前變更,則只會傳送最新的資料,而不會傳送中繼變更。

當輸出訊息接聽者 (您使用產生的 WSDL 設定的 Web 服務) 收到訊息時,會使用包含的工作階段識別碼資訊呼叫 Lightning 平台 API 來更新 Salesforce 中觸發輸出訊息的記錄。

• 輸出訊息不會透過執行活動 (例如 future methods、Queueable Apex、Batch Apex、Bulk API 等) 的 Salesforce 以列為基礎非同步基礎結構處理。記錄會改為儲存在 OutboundMessage 物件本機。訊息會透過本機排程的背景流程分派和重試。
• 當起始自動化 (例如儲存後流程觸發) 執行輸出訊息動作時,系統不會同步傳送訊息。而是會保留在 OutboundMessage 物件中,直到成功傳送或在 24 小時後捨棄傳送失敗為止。
• 若要避免輸出訊息的迴圈無限,請確保更新物件的使用者沒有「傳送輸出訊息」權限。

「電子郵件轉個案」通常會以同步方式運作。處理輸入「電子郵件轉個案」要求的同步執行緒限制為四個。處理常式的同步格式會維持與接收電子郵件的輸入 Salesforce 郵件伺服器 (MTA) 連線。不過,「電子郵件轉個案」可以非同步處理的原因有:

• 「電子郵件轉個案」受限於執行緒限制,尤其是每個應用程式伺服器的處理常式執行緒總數為 10 個:同步處理的四個執行緒,非同步處理的六個執行緒。
• 如果同步電子郵件處理常式超過 15 秒的執行時間,則該特定電子郵件服務地址會在 30 分鐘內標記為非同步。該服務地址的後續處理常式要求會產生 MessageTypeName = MAILCATCHER_EMAIL_TO_CASE 的訊息,以及電子郵件內容的參照。
• 如果已針對特定組織和服務地址使用同步執行緒,則該服務地址的其他要求會以非同步方式排入排隊。
• 如果同步處理的電子郵件發生錯誤,例如列鎖定逾時,則系統會以非同步方式儲存並排入該要求。
• 若沒有可用的同步處理常式執行緒,則要求會以非同步方式排入排隊。

• 當您設定「電子郵件轉個案」時,有取消複製選項,但在處理電子郵件之後,它不會取消複製附件。此復原可節省資料庫中的空間,但不會減少電子郵件處理時間。不過,您可以針對訊息處理實作自訂 Apex 電子郵件轉個案處理常式來改善效能。此實作不會影響任何管理員限制,但會在將任何內容認可至資料庫之前,授與處理常式電子郵件訊息及其所有附件的存取權。此存取權可讓您計算所有包含的附件的檢查總和,並捨棄您認為不必要的任何項目,包括重複項目、已知的簽章圖片或不需要的檔案類型。
• 將電子郵件附件認可至 Salesforce Files 會負責大部分的電子郵件處理時間。隨著連絡人的回覆回應增加,而電子郵件鏈越大,每封電子郵件的處理時間也會越來越長。如果未選取「僅以新內容回覆」電子郵件選項,則電子郵件鏈會隨著每次回覆而成長。因此,我們建議您使用 Apex 電子郵件轉個案處理常式,並使用在處理時實作附件重複取消的邏輯。
• 儘管在處理中叫用 Apex 觸發,但「電子郵件轉個案」處理常式仍排除在同時 Apex 限制之外。

若要非同步處理大量記錄,請考慮使用下列其中一個方法。

您可以使用批次 Apex 建立涉及數千筆記錄的複雜且長時間執行程序。批次 Apex 會透過將您的記錄集分割並處理成可管理的區塊來進行操作。例如,您可以建立每晚執行的歸檔解決方案,並將超過特定日期的記錄新增至歸檔。或者,您可以建立資料清除作業,以每晚檢視所有帳戶和機會,並根據一組預先定義的條件執行任何必要的更新。

• 批次 Apex 最適合處理大量資料,因為非同步 Apex 的限制高於同步 Apex。批次 Apex 在處理每個批次更多項目的情況下,其執行效率也更高,因為其使用的大量作業會造成較少的額外負擔。因此,若要避免觸發流程控制機制,並避免耗盡每日非同步 Apex 限制,請勿建立範圍小或處理時間快速的批次。
• 避免直接從由大量一般使用者活動或整合 API 呼叫所產生的動作中將批次工作加以排隊。此方法會快速耗盡彈性到列。如果您計畫從觸發叫用批次工作,則必須保證觸發不會新增超過限制的批次工作。
• 批次 Apex 限制為最多五個同時執行緒,這會限制其輸送量比未來方法或 Queueable Apex 要多。
• 涉及大量資料的批次工作理想情況下應排程在離峰時段執行,以為需要即時或近乎即時回應的流程釋放資源。
• 當您呼叫 System.scheduleBatch 時,平台會將您的工作排程在您指定的時間執行。實際執行會在該時間或之後進行,視服務可用性而定。
• 排程器會在系統環境中執行。所有類別都會執行,無論已排程執行的使用者是否擁有執行類別的權限。
• 所有排程的 Apex 限制都適用於使用 System.scheduleBatch 排程的批次工作。批次工作已排入排隊後 (狀態為「保留」或「已排隊」),所有批次工作限制都會套用,且該工作不再計入排程的 Apex 限制。
• 針對具有循環排程的批次工作,如果在新工作開始執行時,上一個工作仍在執行,請考量正確的行為。
• 從同步 Apex 交易中建立的批次工作會使用 彈性指標。在任何時候,彈性指標限制為最多 100 個項目。如果交易嘗試新增更多項目,則平台會產生錯誤,且不會提交批次工作。
• 批次工作的呼叫和其他非交易作業必須遵循 idempotent 設計考量事項。批次工作在 Salesforce 服務維護停機時間保留在排隊前排入排隊。服務停機時間結束且系統資源可用後,即會執行已排序的批次工作。如果批次工作在停機時正在執行,則批次執行會在服務還原後回復並重新啟動。由於執行方法可以執行多次,因此任何非交易作業 (例如呼叫) 都可以重試。
• 請考慮設定批次工作以產生 BatchApexErrorEvent 事件,以處理錯誤和例外情況。

排程觸發流程是排程在指定的時間和重複的頻率 (每日、每週或一次) 執行動作的流程,以對記錄批次執行動作。(範例:更新狀態為每晚上午 2 點「未完成」的所有個案欄位。)「排程的流程」會透過 Cron 觸發機制執行,並大量處理。

• 排程觸發流程會針對每個叫用執行 200 筆記錄,但如果有超過 200 筆記錄,則會使用多個同時執行緒執行。
• 排程所觸發的流程會在具有同步限制的同步環境中執行。
• 目前無法控制每個排程流程叫用的已處理記錄數目。如果執行的記錄超過 200 個,則會有同時 Apex 錯誤的實際危險。

「大量 API」以 REST 原則為基礎,並針對使用大型資料集最佳化。您可以使用它來非同步地插入、更新、更新插入、查詢或刪除許多記錄,並稍後再處理結果。Salesforce Platform 會在背景中處理要求。相反地,SOAP API 和 REST API 使用同步要求,並針對一次更新幾筆記錄的即時用戶端應用程式最佳化。您可以使用這兩個 API 來處理許多記錄,但當資料集包含數十萬個記錄時,這些 API 會變得較不實用。大量 API 的非同步架構是為了讓處理數千到數百萬筆記錄的資料變得簡單且有效率。

使用「大量 API」最簡單的方法是啟用此功能,以在使用 CSV 檔案的 Data Loader 中處理記錄。透過 Data Loader,您不需要撰寫自己的用戶端應用程式。但有時,獨特的需求需要撰寫自訂應用程式。

Salesforce Platform 提供兩個大量 API。

• 大量 API 2.0 是較新的 API。其提供簡化且易於使用的工作流程,也是增強的重點。
• 原始 大量 API 仍受完整支援,但不再增強。我們建議您盡可能使用大量 API 2.0。

如需有關 API 限制的詳細資訊,請參閱 大量 API 限制和 大量 API 2.0 限制。

在 Salesforce Platform 上建立或考慮非同步處理時,請參閱此指南。最好瞭解您可用的完整選項範圍,以及這些選項如何符合您的特定使用個案。在對任何現有結構進行變更之前,請務必先徹底評估您目前的橫向,特別是當您目前的解決方案運作良好時。