此文字已使用 Salesforce 的自動翻譯系統進行翻譯。參閱我們的 調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。

通常,當您實作 Salesforce 時,需要將其與其他應用程式整合。雖然每個整合案例都是唯一的,但開發人員和結構設計師必須解決一些常見的需求和問題。

此文件描述這些常見整合案例的策略 (模式格式)。每個模式都會描述特定案例的設計和方法,而非詳細說明特定實作。在此文件中,您會發現:

  • 解決關鍵「階層類型」整合案例的一些模式
  • 可協助判斷最適合您案例之模式的選取矩陣
  • 整合祕訣與最佳作法

用途與範圍

此文件適用於需要將 Salesforce Platform 與企業中其他應用程式整合的設計師和結構設計師。此內容是 Salesforce 結構設計師和合作夥伴成功實作的精密精簡。

若要熟悉可用於大規模採用 Salesforce 式應用程式的整合功能和選項,請參閱模式摘要和模式選取指南。在 Salesforce 整合專案的設計和實作階段期間,結構設計師和開發人員應考量這些模式詳細資料和最佳作法。

若正確實作,這些模式可讓您盡快進入生產環境,並擁有最穩定、可調整且無維護的應用程式集。Salesforce 自己的諮詢結構設計師會在結構審查期間使用這些模式作為參考點,並主動維護和改善模式。

與所有模式一樣,此內容涵蓋大部分的整合案例,但並非全部。當 Salesforce 允許使用者介面 (UI) 整合時,例如,此類整合超出此文件的範圍。

模式範本

每個整合模式皆遵循一致的結構。這可讓每個模式提供的一致資訊,並且更容易比較模式。

名稱

此模式識別碼也表示模式中包含的整合類型。

內容

模式處理的整體整合情況。「內容」提供使用者嘗試達成之目標的相關資訊,以及應用程式支援需求的行為。

問題

模式設計要解決的案例或問題 (以問題表示)。檢閱模式時,請閱讀此區段以快速瞭解模式是否適合您的整合案例。

力

使所述情況難以解決的限制與狀況。

解決方案

解決整合案例的建議方法。

草稿

UML 順序圖表,顯示解決方案如何處理案例。

結果

說明如何將解決方案套用至整合案例的詳細資料,以及其如何解決與該案例相關聯的障礙。此區段也包含因套用模式而可能發生的新挑戰。

側列

與模式相關的其他區段,其中包含重要的技術問題、模式變化、模式特定的疑慮等。

範例

描述設計模式在真實 Salesforce 案例中如何使用的端對端案例。範例說明整合目標,以及如何實作模式以達成這些目標。

模式摘要

下表列出此文件中包含的整合模式。

模式清單 remote-process-invocation--request-and-reply

模式 案例
遠端流程叫用—要求與回覆 Salesforce 會在遠端系統上叫用程序、等待該程序完成,然後根據遠端系統的回應追蹤狀態。
遠端流程叫用—觸發與忘記 Salesforce 會在遠端系統中叫用程序,但不會等待程序完成。相反地,遠端流程會接收並確認要求,然後將控制退回至 Salesforce。
批次資料同步化 系統會建立或重新整理儲存在 Lightning 平台中的資料,以反映外部系統的更新,以及從 Lightning 平台將變更傳送至外部系統時。任一方向的更新都會以批次方式進行。
遠端呼叫 儲存在 Salesforce Platform 中的資料會由遠端系統建立、取用、更新或刪除。
根據資料變更更新 UI 由於 Salesforce 資料的變更,因此必須自動更新 Salesforce 使用者介面。
資料虛擬化 Salesforce 會即時存取外部資料。這可消除在 Salesforce 中保留資料的需求,然後在 Salesforce 與外部系統之間協調資料。

模式方式

此文件中的整合模式分為三個種類:

  • 資料整合—這些模式可解決同步化兩個或多個系統資料的需求,讓兩個系統一律包含即時且有意義的資料。資料整合通常是實作最簡單的整合類型,但需要適當的資訊管理技術才能使解決方案具有永續性和成本效益。此類技術通常包括主要資料管理 (MDM)、資料管理、掌握、去除重複、資料流程設計等層面。

  • 流程整合—此種類中的模式可解決業務流程利用兩個以上應用程式完成其工作所需的需求。實作此類型整合的解決方案時,觸發應用程式必須跨流程界限呼叫其他應用程式。通常,這些模式也包含協調流程 (其中一個應用程式是中央「控制項」) 和編程 (其中應用程式是多個參與者且沒有中央「控制項」)。這些整合通常需要複雜的設計、測試和例外處理需求。此外,此類複合應用程式通常對基礎系統更具需求,因為它們通常支援長時間執行的交易,以及報告或管理流程狀態的能力。

  • 虛擬整合—此種類中的模式可解決使用者檢視、搜尋和修改儲存在外部系統中資料的需求。當您實作此類型整合的解決方案時,觸發應用程式必須呼叫其他應用程式,並與其資料即時互動。此類型的整合會移除跨系統複製資料的需求,這表示使用者一律會與最新的資料互動。

為您的系統選擇最佳的整合策略並非不簡單。有許多要考慮的層面以及可以使用的工具,有些工具比其他工具更適合某些工作。每個模式都會處理特定重要區域,包括每個系統的功能、資料量、失敗處理和交易性。

模式選取指南

選取矩陣表格會列出模式及其關鍵層面,以協助您判斷最適合整合需求的模式。模式會使用這些維度進行分類。

層面 描述
類型 指定整合的樣式:程序、資料或虛擬。
  • 程序:以程序為基礎的整合是整合兩個或多個應用程式之間功能流程處理的方式。這些整合通常涉及更高的抽象與複雜程度,特別是對於交易性和回復性。
  • 資料:資料整合是應用程式所使用資訊的整合。這些整合可以從簡單的表格插入或更新插入到需要參考完整性和複雜翻譯的複雜資料更新。
  • 虛擬:虛擬整合是 Salesforce 與位於外部系統的資料互動的地方,而無須複製 Salesforce 內的資料。此類型的整合一律會透過 Salesforce 平台中的事件觸發,例如使用者動作、搜尋或記錄更新,進而導致資料與外部來源即時整合。
時間 指定整合的樣式:程序、資料或虛擬。
  • 同步:封鎖與即時要求是要求/回應作業。結果會透過此作業立即傳回給來電者。
  • 非同步—非封鎖、以訊息為基礎的要求會由近乎即時的單向作業叫用。系統會叫用其他單向作業來傳回結果和任何錯誤。因此,呼叫者提出要求並繼續,而不會等待回應。

將 Salesforce 與其他系統整合

此表格列出模式及其關鍵層面,以協助您在從 Salesforce 整合至其他系統時判斷最適合您需求的模式。

類型 時間 考量的主要模式
流程整合 同步 遠端流程叫用—要求與回覆
流程整合 非同步 遠端流程叫用—觸發與忘記
資料整合 同步 遠端流程叫用—要求與回覆
資料整合 非同步 根據資料變更更新 UI
虛擬整合 同步 資料虛擬化

將其他系統與 Salesforce 整合

此表格列出模式及其關鍵層面,以協助您在從其他系統整合至 Salesforce 時,決定最符合您需求的模式。

類型 時間 考量的主要模式
流程整合 同步 遠端呼叫
流程整合 非同步 遠端呼叫
資料整合 同步 遠端呼叫
資料整合 非同步 批次資料同步化

中介軟體詞彙與定義

此表格列出與 middleware 相關的一些重要詞彙,以及與這些模式相關的其定義。

期限 定義
事件處理 事件處理是指在指定收件者 (「處理常式」) 處接收可識別的事件。事件處理涉及的關鍵流程包括:

  • 識別要轉送事件的位置
  • 執行該轉寄動作
  • 接收轉寄的事件
  • 採取某種適當的回應動作,例如寫入記錄、傳送錯誤或復原流程,或傳送額外的訊息

請記住,事件處理常式最終可以將事件轉送給事件消費者。

此功能與中介軟體的常見用途可以延伸至包含受歡迎的「發佈/訂閱」或「pub/sub」功能。在發佈/訂閱案例中,中介軟體會將要求或訊息路由至已啟用資料事件發行者的已啟用資料事件訂閱者。這些具有已啟用接聽者的取用者便可在發佈事件時取回事件。
在使用中介軟體的 Salesforce 整合中,中介軟體層會假設控制事件處理。它會收集所有相關事件,無論同步或非同步,並管理對所有端點 (包括 Salesforce) 的散佈。

或者,您可以透過 Salesforce 企業傳訊平台透過將 Event Bus 與平台事件搭配使用來達成此功能。
通訊協定轉換 通訊協定轉換通常是軟體應用程式,可將一個裝置的標準或專屬通訊協定轉換為適合其他裝置的通訊協定,以達成互通性。

在中介軟體環境中,特定目標系統的連線可能受通訊協定的限制。在此情況下,必須將訊息格式轉換為目標系統的格式,或將其壓縮在目標系統的格式內,以便在該處提取裝載。這也稱為隧道。
Salesforce 不支援原生通訊協定轉換,因此會假設中介軟體層或端點符合任何此類需求。
翻譯和轉換 轉換是將一個資料格式對應至另一個資料格式的功能,以確保整合的各種系統之間的互通性。通常,流程需要重新格式化路線中的訊息,以符合寄件者或收件者的需求。在更複雜的情況下,一個應用程式可以傳送其原生格式的訊息,而兩個以上的其他應用程式可以每個接收其原生格式的訊息複本。

中介程式翻譯和轉換工具通常包含為舊版或其他非標準端點建立服務面向的功能。這些服務面向允許這些端點顯示為可供服務定址。

使用 Salesforce 整合時,會假設中介軟體層或端點符合任何此類需求。 資料轉換可在 Apex 中進行編碼,但基於維護與效能考量事項,我們不建議進行編碼。
排隊與緩衝 截排和緩衝通常依賴非同步訊息傳遞,而非要求回應結構。在非同步的系統中,當目的地程式忙碌或連線能力遭到破壞時,訊息會提供暫時儲存空間。此外,大多數非同步中介軟體系統都會提供永久的儲存空間來備份訊息排列。

非同步訊息流程的主要優點是,如果接收者應用程式因任何原因而失敗,則傳送者可以繼續不受影響。傳送的訊息只會累積在訊息中,以便在收訊者重新啟動時稍後處理。
Salesforce 僅提供以工作流程為基礎的輸出傳訊形式明確排入功能。若要為其他整合案例 (包括協調流程、流程編程和服務品質) 提供真實的訊息排入,則需要中介解決方案。
同步傳輸通訊協定 同步傳輸通訊協定是指支援活動的通訊協定,其中「來電者中的單一執行緒傳送要求訊息、封鎖等候回覆訊息,然後處理回覆...等待回應的要求執行緒表示只有一個待處理的要求,或此要求的回覆管道為此執行緒專用。」
非同步傳輸通訊協定 非同步傳輸通訊協定是指支援活動的通訊協定,其中「來電者中的一個執行緒會傳送要求訊息,並為回覆設定回呼。個別的執行緒會聆聽回覆訊息。當回覆訊息到達時,回覆討論線索會叫用適當的回呼,這會重新建立來電者的內容並處理回覆。此方法可讓多個未完成要求共用單一回覆討論串。」
仲裁路由 仲裁路由是從元件到元件的複雜訊息「流程」規格。例如,許多以中介軟體為基礎的解決方案都取決於訊息列系統。雖然某些實作允許由傳訊層本身提供路由邏輯,但其他實作依賴用戶端應用程式來提供路由資訊或允許兩種範例混合。在這種複雜的情況下,中介軟體的仲裁可簡化開發、整合和驗證。 computerator [中介者] 可以確保將正確的訊息傳送給正確的消費者。」
流程 koreography 和服務協調流程 流程 koreography 和服務協調流程是「服務組成」的每種形式,其中會協調任何數量的端點和功能。

koreography 與服務協調流程之間的差異為:
  • 機構編譯可以定義為非同步方法,讓流程能夠以獨立的方式運作,移除任何由相依性所導致的問題,此行為是由沒有中央授權機構的互動個別實體群組所導致。
  • 協調流程可以定義為同步方法,允許每個微型服務實作由協調流程器指派的工作,其為由中央導航器協調個別實體獨立執行工作之行為所產生的行為。
此外,協調流程會顯示每個服務的完整行為,而作法會結合每個服務的介面行為描述。
您可以在 Salesforce 工作流程中或使用 Apex 中建立部分業務流程的 koreography。由於 Salesforce 逾時值和管理員限制,因此建議在中介軟體層中實作所有複雜協調流程,特別是在需要真正交易處理的解決方案中。
交易性 (加密、簽署、可靠傳送、交易管理) 交易性可以定義為支援全域交易的能力,其中包含針對每個必要資源的所有必要作業。交易性意味著支援所有四個 ACID 屬性 (原子性、一致性、隔離性、永續性),其中原子性會保證工作單位 (交易) 的全部或無成果。

雖然 Salesforce 本身為交易,但無法參與 Salesforce 外部起始的散佈交易或交易。因此,假設針對需要複雜且多系統交易的解決方案,會在中介軟體層中實作交易性和相關聯的回復/補償機制。
路由 路由可定義為指定從元件到元件的複雜訊息流程。在現代服務型解決方案中,此類訊息流程可根據數個條件,包括標題、內容類型、規則和優先順序。

使用 Salesforce 整合時,會假設中介軟體層或端點符合任何此類需求。訊息路由可在 Apex 中進行編碼,但基於維護與效能考量事項,我們不建議進行編碼。
解壓縮、轉換和載入 解壓縮、轉換和載入 (ETL) 是指涉及下列項目的程序:
  • 從來源系統解壓縮資料。此流程通常涉及來自多個來源系統的資料,以及關聯式與非關聯式結構。
  • 轉換資料以符合作業需求,其中可能包含資料品質層級。轉換階段通常會將一系列的規則或函數套用至從來源中提取的資料,以衍生資料以載入至最終目標。
  • 將資料載入至目標系統。目標系統可能會因資料庫、作業資料存放區、資料商店、資料倉庫或其他作業系統而有所不同。
雖然並非嚴格必要,但大多數成熟的 ETL 工具皆提供變更資料擷取功能。此功能可讓工具在來源系統中識別自上次解壓後變更的記錄,進而減少記錄處理量。

Salesforce 現在也支援 Change 資料擷取這是發佈代表變更 Salesforce 記錄的變更事件。透過 Change 資料擷取,用戶端或外部系統會接收 Salesforce 記錄的近乎即時變更。透過此資訊,用戶端或外部系統可以同步化外部資料存放區中的對應記錄。
長輪詢 長輪詢也稱為 Comet 程式設計,會模擬從伺服器到用戶端的資訊推送。與一般投票類似,用戶端會從伺服器連線並要求資訊。然而,當資訊無法使用時,伺服器不會傳送空白回應,而是保留要求並等待資訊可用 (事件發生)。接著,伺服器會將完整回應傳送至用戶端。接著,用戶立即重新要求資訊。用戶端持續與伺服器保持連線,因此一律等待收到回應。如果伺服器逾時,則用戶端會再次連線並重新開始。

Salesforce Streaming API 使用 Bayeux 通訊協定和 CometD 進行長輪詢。
  • Bayeux 是主要透過 HTTP 傳輸非同步訊息的通訊協定。
  • CometD 是可調整的 HTTP 型事件路由匯流,使用稱為 Comet 的 AJAX 推送技術模式。其會實作 Bayeux 通訊協定。

內容

您可以使用 Salesforce 追蹤商機、管理您的銷售管道、建立機會,以及獲取將商機轉換為客戶的訂單詳細資料。但 Salesforce 系統不會包含或處理訂單。在在 Salesforce 中收集訂單詳細資料後,系統會在遠端系統中建立訂單,該系統會管理訂單以完成。

當您實作此模式時,Salesforce 會呼叫遠端系統建立訂單,然後等待成功完成。若成功,則遠端系統會以訂單狀態和訂單編號同步回覆。作為相同交易的一部分,Salesforce 會在內部更新訂單編號與狀態。訂單編號會作為遠端系統後續更新的外部金鑰使用。

問題

當事件在 Salesforce 中發生時,如何在遠端系統中起始程序、將必要資訊傳遞至該程序、接收遠端系統的回應,然後使用該回應資料在 Salesforce 中進行更新?

力

根據此模式套用解決方案時,請考量下列因素。

  • 遠端系統的呼叫是否需要 Salesforce 等待回應,才能繼續處理?遠端系統的呼叫是同步要求回覆還是非同步要求?
  • 如果遠端系統的呼叫為同步,Salesforce 是否必須將回應作為與初始呼叫相同交易的一部分處理?
  • 訊息大小是小還是大?
  • 整合是否以特定事件 (例如按一下 Salesforce 使用者介面中的按鈕) 或以 DML 為基礎的事件為基礎?
  • 遠端端點是否能夠以低延遲回應要求?在高峰期間,有多少使用者可能執行此交易?

解決方案

此表格包含此整合問題的解決方案。

解決方案 適合 註解
外部服務叫用 REST API 呼叫 最佳 外部服務可讓您以宣告的方式叫用外部主控的服務 (無須程式碼)。符合下列條件時,最適合使用此功能:
  • 外部主控的服務為 RESTful 服務,且定義適用於 OpenAPI 2.0 或 OpenAPI 3.0 或 YAML 結構描述格式。
  • 要求與回應定義包含基本資料類型,例如布林值、日期時間、雙值、整數、字串或基本資料類型的陣列。系統支援巢狀物件類型和傳送參數,例如 HTTP 要求內的標題。
  • 您可以從流程叫用交易。
Salesforce Lightning—Lightning 元件或頁面會起始同步 Apex REST 或 SOAP 呼叫。</

如果遠端端點造成高度延遲回應的風險 (請參閱此處適用限制的最新限制文件),則建議使用非同步呼叫 (也稱為繼續),以避免達到同步 Apex 交易管理員限制。 		最佳 Salesforce 可讓您取用 WSDL 並產生產生的 Proxy Apex 類別。此類別提供呼叫遠端服務所需的邏輯。

Salesforce 也可讓您使用標準 GET、POST、PUT 和 DELETE 方法叫用 HTTP (REST) 服務。

Lightning 頁面上的使用者起始動作接著會呼叫 Apex 控制項動作,然後執行此 Proxy Apex 類別以執行遠端呼叫。Lightning 頁面需要自訂 Salesforce 應用程式。
從 Salesforce 資料變更叫用的同步觸發會執行非同步 Apex SOAP 或 HTTP 呼叫。 子最佳 您可以使用 Apex 觸發程序,根據記錄資料變更執行自動化。

Apex Proxy 類別可以使用 Apex 觸發來作為 DML 作業的結果執行。不過,從觸發內容中進行的所有呼叫必須從起始事件非同步執行。因此,此整合問題不建議使用此解決方案。此解決方案更適用於「遠端流程叫用—觸發與忘記」模式。
批次 Apex 工作會執行同步 Apex SOAP 或 HTTP 呼叫。 子最佳 您可以從批次工作撥打遠端系統的電話。此解決方案允許從 Salesforce 中的遠端系統批次遠端流程執行和處理回應。不過,指定的批次對通話數量有限制。如需詳細資訊,請參閱 管理員限制。

指定的批次執行可以執行多個交易內容 (通常為 200 筆記錄的間隔)。管理員限制會針對每個交易內容重設。

草稿

此圖說明使用 Apex 呼叫的同步遠端流程叫用。

Salesforce 呼叫遠端系統

Salesforce 呼叫遠端系統

下載圖表

在此情況下:

  • 系統會在 Lightning 頁面上起始動作 (例如按一下按鈕)。
  • 瀏覽器 (在 Lightning 元件中透過用戶端控制項) 會執行 HTTP POST,進而在對應的 Apex 控制項上執行動作。
  • 控制器會叫用遠端 Web 服務的實際呼叫。
  • 遠端系統的回應會傳回至 Apex 控制項。控制器會視需要處理回應、更新 Salesforce 中的資料,並重新呈現頁面。

在必須追蹤後續狀態的情況下,遠端系統會傳回儲存在 Salesforce 記錄中的唯一識別碼。

結果

套用與此模式相關的解決方案可允許事件起始的遠端流程叫用,其中 Salesforce 處理處理。

呼叫機制

呼叫機制取決於用來實作此模式的解決方案。

通話機制 描述
流程中內嵌的增強型外部服務

Lightning 元件或

Apex 控制項 		用於觸發遠端流程作為涉及使用者介面的端對端流程的一部分,且結果必須在 Salesforce 記錄中顯示或更新。例如,將信用卡付款提交至外部付款管道,以及付款結果會立即傳回並向使用者顯示。
Apex 觸發 主要用於使用 DML 初始事件中的 Apex 呼叫來叫用遠端程序。如需此呼叫機制的詳細資訊,請參閱模式 遠端流程叫用—觸發與忘記。
Apex 批次類別 用於批次叫用遠端程序。如需此呼叫機制的詳細資訊,請參閱模式 遠端流程叫用—觸發與忘記。

錯誤處理與復原

將錯誤處理與復原策略納入整體解決方案中是很重要的。

  • 錯誤處理—發生錯誤 (例外狀況或錯誤碼傳回給來電者) 時,來電者會管理錯誤處理。例如,一般使用者頁面上顯示的錯誤訊息或記錄到表格中需要採取進一步動作的錯誤訊息。

  • 復原—在來電者收到成功回應之前,變更不會認可至 Salesforce。例如,在收到表示成功的回應之前,資料庫中不會更新訂單狀態。如有必要,來電者可以重試作業。

識別設計考量事項

Idempotent 功能可保證重複叫用是安全的。如果未實作 idempotency,則重複叫用相同訊息可能會產生不同的結果,進而可能導致資料完整性問題。潛在問題包括建立重複的記錄或重複處理交易。

請務必確保呼叫的遠端程序為 idempotent。如果通話是由使用者介面進行,我們需要在整合層處理閒置能力,特別是如果沒有保證 Salesforce 只通話一次。

建立識別接收器的最典型方法是根據消費者傳送的唯一訊息識別碼追蹤重複項目。Apex Web 服務或 REST 呼叫必須自訂,才能傳送唯一訊息識別碼。

此外,在遠端系統中建立記錄的作業必須先檢查重複項目,才能插入。透過傳遞來自 Salesforce 的唯一記錄識別碼進行檢查。如果記錄存在於遠端系統中,請更新記錄。在大多數系統中,此作業稱為更新插入作業。

安全性考量事項

任何對遠端系統的呼叫都必須維護要求的機密性、完整性和可用性。下列安全性考量事項是以此模式使用 Apex SOAP 和 HTTP 呼叫所特有。

  • 依預設會啟用單向 SSL,但自助式簽署與 CA 簽署憑證皆支援雙向 SSL,以維護用戶端與伺服器的真實性。

  • 若要簡化您的 Apex 程式碼並簡化已驗證呼叫的設定,請在呼叫端點中指定已命名認證。

  • 請考慮使用 OAUTH 2.0 作為整合外部系統的驗證機制。

  • 如有必要,請考慮使用單向雜湊或使用 Apex Crypto 類別方法來確保要求完整性。

  • 必須透過實作適當的防火牆機制來保護遠端系統。請參閱 安全考量事項。

  • Salesforce 目前不支援 WS-Security。雖然它不會原生產生這些複雜的 WS-Security 標題,或從傳入的 WSDL 自動強制執行這些標題,但您可以透過建立自訂 Apex 類別來手動建構和實作這些標題,以處理傳入要求的 SOAP 標題和安全性權杖。

側列

無。

及時性

及時性在此模式中十分重要。通常:

  • 通常會從使用者介面叫用要求,因此程序不能讓使用者等待。
  • 針對來自 Apex 的呼叫,Salesforce 最多可設定 120 秒的逾時。
  • 遠端流程的完成會及時執行,以在 Salesforce 逾時限制內及使用者期望內完成。
  • 外部呼叫受限於 Apex 同步交易管理員限制,因此請確保降低例項化每個執行超過五秒鐘的超過 50 個交易風險。除了確保外部端點效能外,降低逾時風險的選項包括:
    • 將外部呼叫的逾時設定為五秒。
    • 在 Lightning 元件中使用繼續處理長時間執行的交易

資料量

此模式主要用於少量即時活動,因為 Apex 呼叫解決方案的逾時值很小,且要求或回應的大小上限。請勿在訊息中包含資料裝載的批次處理活動中使用此模式。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

解決方案 端點考量事項
Apex HTTP 呼叫 端點必須能夠接收 HTTP 呼叫。Salesforce 必須能夠透過公用網際網路存取端點。針對私人和安全的通訊,Salesforce 現在也已開始透過 Hyperforce 平台安全地支援 Salesforce 私人連線。請參閱 Salesforce Private Connect 以取得詳細資料。

您可以使用 Apex HTTP 呼叫,使用標準 GET、POST、PUT、DELETE 和 PATCH 方法呼叫 REST 服務。
Apex SOAP 呼叫 端點必須能夠接收 HTTP 呼叫。Salesforce 必須能夠透過公用網際網路存取端點。針對私人和安全的通訊,Salesforce 現在也已開始透過 Hyperforce 平台安全地支援 Salesforce 私人連線。請參閱 Salesforce Private Connect 以取得詳細資料。

此解決方案需要遠端系統與 Salesforce 支援的標準相容。撰寫時,Salesforce 針對 Apex SOAP 呼叫支援的 Web 服務標準為:
  • WSDL 1.1
  • SOAP 1.1
  • WSI 基本設定檔 1.1

州管理

整合系統時,金鑰對進行中狀態追蹤十分重要。有兩個選項。

  • Salesforce 會儲存遠端系統遠端記錄的主要或唯一替代金鑰。
  • 遠端系統會儲存 Salesforce 唯一記錄識別碼或其他唯一的替代金鑰。

處理整合金鑰的特定考量事項取決於包含主要記錄的系統,如下表所示。

主要 系統 描述
Salesforce 遠端系統會儲存 Salesforce RecordId 或記錄中的其他唯一替代金鑰。
遠端系統 遠端流程的呼叫會從應用程式傳回唯一金鑰,而 Salesforce 會將該金鑰值儲存在唯一記錄欄位中。

複雜整合案例

在某些情況下,此模式所指定的解決方案可能需要實作數個複雜的整合案例。這最適合使用中介軟體或讓 Salesforce 呼叫複合服務。這些情況包括:

  • 涉及複雜流程邏輯的業務流程和規則協調流程
  • 將通話及其在多個系統之通話之間的結果彙總
  • 轉換輸入與輸出訊息
  • 跨多個系統的呼叫維護交易完整性

管理員限制

如需有關 Apex 限制的資訊,請參閱《Apex 開發人員指南》中的 執行管理員和限制。

中介軟體功能

下表會醒目提示參與此模式之中介軟體系統的理想內容。

財產 必要 理想 不需要
事件處理 X
通訊協定轉換 X
翻譯和轉換 X
排隊與緩衝 X
同步傳輸通訊協定 X
非同步傳輸通訊協定 X
仲裁路由 X
流程 koreography 和服務協調流程 X
交易性 (加密、簽署、可靠傳送、交易管理) X
路由 X
解壓縮、轉換和載入 X
長輪詢 X

範例

公用事業公司使用 Salesforce,且擁有包含客戶帳單資訊的個別系統。作為訂單流程的一部分,必須在帳單系統中建立新的帳單帳戶,且 Salesforce 應在訂單啟用流程內反映帳單帳戶號碼。他們擁有現有的 Web 服務,允許建立帳單帳戶,並傳回帳單帳戶號碼作為回應。

此需求可透過下列方法完成。

  1. Salesforce 會從 Apex Proxy 類別中取用帳單帳戶服務 WSDL。
  2. 透過從自訂 Apex 控制器或外部服務傳送至外部 Web 服務的客戶資訊,執行 Apex Proxy 類別。
  3. 自訂控制器接著會剖析來自 Apex 呼叫的傳回值,並將該資訊儲存在 salesforce 物件上。

此範例示範:

  • 系統會使用儲存在 Salesforce 帳戶物件上的帳戶號碼來追蹤客戶的狀態。
  • 來電者後續處理回覆訊息

內容

您可以使用 Salesforce 追蹤商機、管理您的銷售管道、建立機會,以及獲取將商機轉換為客戶的訂單詳細資料。不過,作為「訂單」管理流程的一部分,必須在訂單的帳單系統中建立帳單帳戶。

當您實作此模式時,Salesforce 會呼叫遠端系統建立帳單帳戶,但不會等待通話成功完成。遠端系統可以選擇性地使用在個別交易中建立的新帳單帳戶來更新 Salesforce。

問題

當事件在 Salesforce 中發生時,如何在遠端系統中起始程序,並將必要資訊傳遞給該程序,而不必等待來自遠端系統的回應?

力

根據此模式套用解決方案時,請考量下列因素。

  • 遠端系統的呼叫是否需要 Salesforce 等待回應,才能繼續處理?對遠端系統的呼叫是同步還是非同步?
  • 如果遠端系統的通話為同步,Salesforce 是否需要將回應作為通話相同交易的一部分處理?
  • 訊息大小是否小?
  • 整合是否以特定事件 (例如按一下 Salesforce 使用者介面中的按鈕) 或以 DML 為基礎的事件為基礎?
  • 保證從 Salesforce 傳送訊息至遠端系統是否為必要條件?
  • 遠端系統是否能夠參與 Salesforce 指定契約的契約優先整合?在某些解決方案變體 (例如輸出傳訊) 中,Salesforce 會指定遠端系統端點實作的契約。
  • 端點或企業服務匯流 (ESB) 是否支援長輪詢?
  • 陳述性組態方法是否優先於自訂 Apex 開發?在此情況下,如平台事件等解決方案優先於 Apex 呼叫。

解決方案

下表包含此整合問題的解決方案。

解決方案 適合 註解
流程驅動的平台事件 最佳 以宣告的方式建立流程以實作平台事件。建議的解決方案是在從插入或更新事件叫用遠端程序時。

平台事件是您應用程式傳送和接收以採取進一步動作的事件訊息 (或通知)。平台事件可簡化傳達變更和回應變更的流程,而無須撰寫複雜邏輯。一或多個訂閱者可以聆聽同一個事件並執行動作。

例如,軟體系統可以傳送事件,其中包含印表機墨水盒的相關資訊。訂閱者可以訂閱事件來監視印表機墨水層級,並下單來取代具有較低墨水層級的墨水盒。

外部應用程式可以透過 CometD 訂閱管道來聆聽事件訊息。平台應用程式 (例如 Lightning 元件) 也可以透過 CometD 訂閱事件訊息。您也可以在此使用以 gRPC 和 HTTP/2 為基礎的 Salesforce PubSub API。

Salesforce 也支援「平台事件觸發流程」,有效建立使用 Flow Builder 介面的接聽者。當特定平台事件訊息發佈至 Salesforce Event Bus 時,此類型的流程會自動啟動。
Pub/Sub API 最佳 Pub/Sub API 是外部消費者使用 Event Bus 事件的建議方式。

gRPC 型 Pub/Sub API:
  • 支援從外部應用程式發佈和訂閱平台事件
  • 適用於適當驗證 (OAuth、JWT 或工作階段權杖)

平台事件在 Salesforce 中定義後,便可供內部與外部消費者使用。
變更 資料擷取 最佳 Change 資料擷取 (CDC) 會發佈 Salesforce 記錄中對應建立、更新、刪除和取消刪除作業變更的事件。在 Salesforce 中啟用 Change 資料擷取 (CDC) 是純粹的陳述性程序,不需要 Apex 程式碼。

通知訊息會傳送至事件匯流,用戶端可使用 Pub/Sub API 或 Apex 觸發來訂閱該匯流。以事件為導向的系統可簡化分散式企業系統之間的通訊、增加延展性,並提供即時資料。

例如,如果訂單資訊位於 ERP 系統與 Salesforce 中,您可以將訂單變更事件從 Salesforce 串流至整合應用程式。接著應用程式會同步化 ERP 系統中的變更
Omnistudio 整合程序 良好 使用 Omnistudio 整合程序,以宣告的方式自動化 Salesforce 與外部第三方應用程式之間的資料互動。「整合程序」會處理複雜的資料轉換、API 呼叫和以事件為導向的自動化,並可在單一伺服器呼叫中執行多個動作。

當執行期間不需要使用者互動,且您想要:
  • 在 Salesforce 與外部系統之間取得、轉換及傳送資料
  • 將處理移除至伺服器以改善效能與延展性
  • 在單一伺服器交易中配套多個作業
  • 針對經常存取的資訊啟用資料快取

請查看更多關於「整合程序」的詳細資料。
自訂驅動的平台事件 良好 與流程驅動的平台事件類似,但事件是由 Apex 觸發或類別所建立。您可以使用 Apex 或 API 來發佈及取用平台事件。

平台事件會透過 Apex 觸發與 Salesforce 平台整合。觸發是 Salesforce 平台上聆聽事件訊息的事件取用者。

當外部應用程式使用 API 或原生 Salesforce 應用程式使用 Apex 發佈事件訊息時,會觸發該事件的觸發。觸發會執行動作以回應事件通知。
流程驅動的輸出傳訊 適合 此類型整合的建議解決方案是在從插入或更新事件叫用遠端程序時。Salesforce 提供流程驅動的輸出傳訊功能,可將 SOAP 訊息傳送至 Salesforce 中插入或更新作業觸發的遠端系統。這些訊息會以非同步方式傳送,且獨立於 Salesforce 使用者介面。

輸出訊息會傳送至特定遠端端點。遠端服務必須能夠參與 Salesforce 提供契約的契約優先整合。

收到訊息時,如果遠端服務未以正向確認的方式回應,Salesforce 會重試傳送訊息,提供一種保證傳送的形式。
起始 Apex SOAP 或 HTTP 非同步呼叫的自訂 Lightning 元件 子最佳 此解決方案通常用於以使用者介面為基礎的案例,但需要自訂。此外,解決方案必須處理程式碼中訊息的保證傳遞。

與使用 Lightning 元件與 Apex 呼叫指定之「遠端流程叫用」—「要求與回覆」 模式解決方案類似。不同之處在於在此模式中,Salesforce 不會等待要求完成,然後再將控制權授與使用者。

接收訊息後,遠端系統會回應並指示已收到訊息,然後以非同步方式處理訊息。遠端系統會在處理訊息前先將控制回 Salesforce,因此 Salesforce 不需要等待處理完成。
Apex 觸發使 Apex SOAP 或 HTTP 非同步呼叫 子最佳 您可以使用 Apex 觸發程序,根據記錄資料變更執行自動化。

Apex Proxy 類別可以使用 Apex 觸發來作為 DML 作業的結果執行。不過,從觸發內容進行的所有通話必須以非同步方式執行。

Apex 觸發使 Apex SOAP 或 HTTP 非同步呼叫 子最佳 可從批次工作執行遠端系統的呼叫。此解決方案允許批次遠端流程執行,以及從 Salesforce 中的遠端系統處理回應。不過,指定批次內容的通話數目有限制。如需詳細資訊,請參閱「Salesforce 開發人員限制與配置快速參考」。

草稿

下圖說明 Salesforce 對遠端系統的呼叫,其中在記錄上建立或更新作業會觸發呼叫。

Salesforce 呼叫遠端系統

下載圖表

在此情況下:

  1. 遠端系統訂閱平台事件。
  2. 更新或插入會在 Salesforce 中指定的記錄集上發生。
  3. Salesforce 流程會在符合一組條件時觸發。
  4. 此流程會建立平台事件。
  5. 遠端接聽者會接收事件訊息,並將訊息放置在本機排隊上。
  6. 將訊息轉送至遠端應用程式以供處理。

在遠端系統必須對 Salesforce 執行作業的情況下,您可以實作選用的回呼作業。

結果

套用與此模式相關的解決方案可:

  • 使用者介面–起始的遠端流程叫用,可在其中向一般使用者顯示交易結果
  • DML 事件起始的遠端流程叫用,其中呼叫流程可處理交易結果

呼叫機制

呼叫機制取決於用來實作此模式的解決方案。

通話機制 描述
流程 用於流程驅動和自訂驅動的解決方案。事件會觸發 Salesforce 流程,然後可發佈平台事件以供遠端系統訂閱。
Pub / Sub API Pub/Sub API 提供發佈和訂閱平台事件的單一介面,包括即時事件監視事件,以及變更資料擷取事件。根據 gRPC 和 HTTP/2,Pub/Sub API 可有效發佈並以 Apache Avro 格式傳送二進位事件訊息。
變更 資料擷取 Salesforce Change 資料擷取 會發佈變更事件,其代表對 Salesforce 記錄進行的變更。變更包括建立新記錄、更新現有記錄、刪除記錄,以及取消刪除記錄。
Lightning 元件與 Apex 控制項 用於使用 Apex 呼叫非同步地叫用遠端程序。
流程驅動的輸出傳訊 僅用於輸出傳訊解決方案。建立與更新 DML 事件會觸發 Salesforce 工作流程規則,然後將訊息傳送至遠端系統。
Apex 觸發 用於觸發驅動的平台事件和遠端程序的叫用,使用來自 DML 初始事件的 Apex 呼叫。
Apex 批次類別 用於在批次模式中叫用遠端程序。

錯誤處理與復原

必須將錯誤處理與復原策略視為整體解決方案的一部分。最佳方法取決於您選擇的解決方案。

解決方案 錯誤處理和復原策略
流程
  • 錯誤處理—在某些情況下,流程可能無法完全處理。當程序或流程訪問失敗時,系統會將詳細電子郵件傳送給上次修改程序或流程的管理員。透過將錯誤路徑新增至所有可能失敗的元素,來修改預設行為。此行為應加強,以便在自訂行為中加入,例如建立個案或將錯誤寫入可監視與追蹤的自訂物件。
  • 復原—此情況下復原較為複雜。如果服務品質需求規定該機制,則必須建立自訂重試機制。
Apex 呼叫
  • 錯誤處理—遠端系統會關閉結束流程的叫用,因此呼叫只會處理遠端服務初始叫用中的例外狀況。例如,如果遠端呼叫未收到正向確認,則會觸發逾時事件。當提供初始叫用以進行非同步處理時,遠端系統必須處理後續的錯誤。
  • 復原—此情況下復原較為複雜。如果服務品質需求規定該機制,則必須建立自訂重試機制。
Change 資料擷取 (CDC) / Platform 事件
  • 錯誤處理 — 錯誤處理必須由遠端服務執行,因為事件有效地傳送至遠端系統以供進一步處理。由於此模式為非同步,因此遠端系統會處理訊息排列、處理和錯誤處理。此外,平台事件不會在資料庫交易中處理。因此,已發佈平台事件無法在交易中回復。
  • 復原—由於此模式為非同步,因此遠端系統必須根據服務的服務品質需求開始重試。與每個事件相關聯的重新執行識別碼為原子,並會隨著每個發佈的事件而增加。此識別碼可用來重新播放來自特定事件的串流 (例如,根據上次獲取的事件)。大量平台事件訊息會儲存 72 小時 (三天)。當您使用 CometD 用戶端訂閱管道時,您可以取回過去的事件訊息。

識別設計考量事項

平台事件只會發佈至 Bus 一次。Salesforce 端沒有重試。請 ESB 要求重新執行事件。在重新執行中,平台事件的重新執行識別碼會保持不變,ESB 可以根據重新執行識別碼嘗試重複訊息。

識別碼權限對於輸出傳訊很重要,因為其為非同步,且在未收到正向確認時會開始重試。因此,遠端服務必須能夠以無效的方式處理來自 Salesforce 的訊息。

輸出傳訊會傳送每個訊息的唯一識別碼,且此識別碼對於任何重試都會保持不變。遠端系統可以根據此唯一識別碼追蹤重複的訊息。系統也會傳送每個更新記錄的唯一記錄識別碼,並可用來防止建立重複的記錄。

「遠端流程叫用—要求」和「回覆」模式中的 無效設計考量事項也適用於此模式。

安全性考量事項

任何對遠端系統的呼叫都必須維護要求的機密性、完整性和可用性。根據您選擇的解決方案,會套用不同的安全性考量事項。

解決方案 安全性考量事項
Apex 呼叫 對遠端系統的呼叫必須維護要求的機密性、完整性和可用性。以下是此模式中使用 Apex SOAP 和 HTTP 呼叫的特定安全性考量事項。
  • 依預設會啟用單向 SSL,但自助式簽署與 CA 簽署憑證皆支援雙向 SSL,以維護用戶端與伺服器的真實性。
  • 產生 Apex Proxy 類別時,Salesforce 不支援 WS-Security。
  • 如有必要,請考慮使用單向雜湊或使用 Apex Crypto 類別方法來確保要求的完整性。
  • 必須透過實作適當的防火牆機制來保護遠端系統。
Change 資料擷取 (CDC) / Platform 事件 針對平台事件,訂閱的外部系統必須能夠驗證 Salesforce Streaming API。

平台事件符合在 Salesforce 組織中設定的現有安全性模型。若要訂閱事件,使用者需要事件實體的讀取存取權。若要發佈事件,使用者需要事件實體的「建立」權限。

請參閱 安全性考量事項。

側列

無。

及時性

及時性與忘記模式較不重要。控制會立即或在對遠端系統成功轉移的正向確認後,傳回給用戶端。使用 Salesforce 輸出傳訊時,確認必須在 24 小時內發生 (可延長為七天);否則訊息會到期。針對平台事件,Salesforce 會將事件傳送至 Event Bus,而不會等待訂閱者的確認或確認。如果訂閱者未挑選訊息,訂閱者可以使用事件回覆識別碼要求重新執行事件。大量事件訊息會儲存 72 小時 (三天)。若要取回過去的事件訊息,請使用 CometD 用戶端訂閱管道。

資料量

資料量考量事項取決於您選擇的解決方案。如需每個解決方案的限制,請參閱「Salesforce 限制快速參考」。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

解決方案 端點考量事項
Apex SOAP 呼叫 端點必須能夠透過 HTTP 處理 Web 服務呼叫。Salesforce 必須能夠透過公用網際網路存取端點。此解決方案需要遠端系統與 Salesforce 支援的標準相容。撰寫時,Salesforce 針對 Apex SOAP 呼叫支援的 Web 服務標準為:
  • WSDL 1.1
  • SOAP 1.1
  • WSI 基本設定檔 1.1
  • HTTP
Apex HTTP 呼叫 端點必須能夠接收 HTTP 呼叫,且可由 Salesforce 透過公用網際網路存取。

Apex HTTP 呼叫可用於使用標準 GET、POST、PUT 和 DELETE 方法呼叫 RESTful 服務。
Change 資料擷取 (CDC) / Platform 事件
  • 觸發、程序和流程可以訂閱事件。無論事件發佈的方式為何,您都可以收到事件通知。
  • 使用 CometD 訂閱來自外部用戶端的平台事件。實作您自己的 CometD 用戶端或使用 EMP Connector,這是開放程式碼的社群支援工具,可實作連線至 CometD 和聆聽管道的所有詳細資料。Salesforce 會依接收的順序,將平台事件依序傳送給 CometD 用戶端。事件通知的順序是根據事件的重新執行識別碼。

州管理

整合系統時,唯一記錄識別碼對於持續狀態追蹤十分重要。例如,如果在遠端系統中建立記錄,您有兩個選項。

  • Salesforce 會儲存遠端系統遠端記錄的主要或唯一替代金鑰。
  • 遠端系統會儲存 Salesforce 唯一記錄識別碼或其他唯一的替代金鑰。

下表列出此模式中州/省管理的考量事項。

主要 系統 描述
Salesforce 遠端系統必須將 Salesforce RecordId 或其他唯一的替代金鑰儲存在 Salesforce 記錄中。
遠端系統 Salesforce 必須將唯一識別碼的參照儲存在遠端系統中。由於流程為非同步,因此儲存此唯一識別碼不能是原始交易的一部分。

Salesforce 必須在呼叫遠端流程中提供唯一識別碼。接著遠端系統必須回電 Salesforce,以使用 Salesforce 唯一識別碼,以使用遠端系統唯一識別碼更新 Salesforce 中的記錄。

回呼會在遠端應用程式中包含特定狀態處理,以儲存 Salesforce 唯一識別碼,讓該交易在處理完成時用於回呼,或將 Salesforce 唯一識別碼儲存在遠端系統的記錄上。

複雜整合案例

此模式中的每個解決方案針對複雜的整合案例 (例如轉換和流程協調流程) 有不同的考量事項。

解決方案 考量事項
Apex 呼叫 在某些情況下,此模式所指定的解決方案需要使用中介軟體或讓 Salesforce 呼叫複合服務來實作數個最適合的複雜整合案例。這些情況包括:
  • 涉及複雜流程邏輯的業務流程和規則協調流程
  • 將通話及其在多個系統之通話之間的結果彙總
  • 轉換輸入與輸出訊息
  • 跨多個系統的呼叫維護交易完整性
Change 資料擷取 (CDC) / Platform 事件 由於事件的靜態陳述性質,因此無法在 Salesforce 中執行複雜的整合案例,例如彙總、協調流程或轉換。遠端系統或中介軟體必須處理下列類型的作業。
OmniStudio 整合程序 「整合程序」(OmniStudio) 提供伺服器端無狀態協調流程,可協調多個後端服務,同時執行複雜的陳述性資料轉換。

「整合程序」會鏈結如「HTTP 動作」、「DataRaptor Extract/Transform/Load」、「設定值」、「迴圈/If」和「矩陣」查詢等步驟,以正規化、增強、彙總和對應 UI 契約與不同 API 之間的裝載。

它們支援強大的執行階段控制,例如條件式分支、分頁、逾時、重試、部分失敗處理和繼續錯誤,以及效能最佳化,例如伺服器端快取和回應形塑。

IP 可從 OmniScript 同步叫用,或透過 REST 無周邊叫用,以啟用可重複使用的版本化「整合面向」,以隱藏管道的後端複雜性。

管理員限制

由於 Salesforce 平台的多租戶性質,輸出呼叫有其限制。限制取決於撥出通話的類型和通話的時間點。

如需套用至平台事件的限制與配置,請參閱《平台事件開發人員指南》。

可靠傳訊

可靠傳訊會嘗試解決保證將訊息傳送至個別元件不可靠遠端系統的問題。確保遠端系統接收訊息的方法取決於您選擇的解決方案。

針對 Salesforce Change 資料擷取 類型,系統會提供變更事件類型以處理特殊情況,例如在 Salesforce 應用程式伺服器中取回的變更,或處理大量變更。

在某些情況下,Salesforce 會傳送「缺口」事件,而非變更事件,以通知訂閱者錯誤,或如果無法產生變更事件。缺口事件包含標題中變更的相關資訊,例如變更類型與記錄識別碼。不包含變更的相關詳細資料,例如記錄欄位。為了更有效率地捕捉變更,「溢出」事件會針對超過某個值的單筆交易產生。如需詳細資訊,請參閱 此處。

解決方案 可靠傳訊考量事項
Apex 呼叫 Salesforce 不會明確支援可靠的傳訊通訊協定 (例如,WS-ReliableMessaging)。我們建議接收 Salesforce 訊息的遠端端點實作可靠的傳訊系統,例如 JMS 或 MQ。此系統可確保完整端對端保證傳送至最終處理訊息的遠端系統。不過,此系統不會保證從 Salesforce 傳送至呼叫的遠端端點。

必須透過對 Salesforce 的自訂來處理保證傳送。除了自訂重試邏輯外,必須實作特定的技術,例如從遠端端點處理正向確認。
Change 資料擷取 (CDC) / Platform 事件 「平台事件」會嘗試透過在 Event Bus 中暫時保留事件訊息來提供可靠的傳訊。訂閱者可以使用事件訊息的「重新執行識別碼」,透過從 Event Bus 重新播放訊息來追蹤遺漏的事件訊息。

Event Bus 是分散式系統,且沒有與交易資料庫相同的保固。因此,Salesforce 無法為事件發佈要求提供同步回應。事件會加以排入和緩衝,Salesforce 會嘗試以非同步方式發佈事件。在極少數情況下,事件訊息可能不會在初始或後續嘗試期間存在於散佈系統中。這表示事件不會傳送給訂閱者,且無法復原。

中介軟體功能

下表會醒目提示參與此模式之中介軟體系統的理想內容。

財產 必要 理想 不需要
事件處理 X
通訊協定轉換 X
翻譯和轉換 X
排隊與緩衝 X
同步傳輸通訊協定 X
非同步傳輸通訊協定 X
仲裁路由 X
流程 koreography 和服務協調流程 X
交易性 (加密、簽署、可靠傳送、交易管理) X
路由 X
解壓縮、轉換和載入 X
長輪詢 X (在平台事件中為必要)

解決方案變體—平台事件:發佈行為與交易

立即發佈平台事件訊息時,事件發佈不會遵循發佈流程的交易邊界。事件訊息可以在交易完成或即使交易失敗之前發佈。當訂閱者預期尋找發佈交易認可的資料時,此行為可能會造成問題。當訂閱者收到事件訊息時,資料可能不會顯示。若要解決此問題,請在事件定義中將平台事件發佈行為設定為「認可後發佈」。您可在平台事件定義中設定的發佈行為有:

  • 「認可後發佈」可讓事件訊息僅在交易成功認可後發佈。如果訂閱者依賴發佈交易認可的資料,請選取此選項。例如,程序會發佈事件訊息並建立工作記錄。系統會觸發訂閱事件的第二個程序,並預期會找到工作記錄。選擇此行為的另一個原因是當您不想要在交易失敗時發佈事件訊息時。
  • 「立即發佈」可在發佈呼叫執行時發佈事件訊息。如果您想要發佈事件訊息,無論交易是否成功,請選取此選項。如果發行者與訂閱者是獨立的,且訂閱者不依賴發行者認可的資料,請選擇此選項。例如,立即發佈行為適用於用於記錄的事件。透過此選項,訂閱者可能會在發行者交易認可資料之前收到事件訊息。

範例

一家電信公司想要使用 Salesforce 作為使用商機轉機會流程建立帳戶的前端。當機會已結束並成交時,系統會在 Salesforce 中建立訂單,但後端 ERP 系統是資料主要項目。訂單必須儲存至 Salesforce 機會記錄,且機會狀態已變更以表示訂單已建立。

套用以下限制。

  • 只能實作陳述性開發。
  • 機會轉換為訂單後,您不需要訂單編號的立即通知。
  • 組織擁有支援 CometD 通訊協定的 ESB,且能夠訂閱平台事件。

此範例最適合使用 Salesforce Platform 事件進行實作,但需要 ESB 訂閱平台事件。

在 Salesforce 端:

  • 建立流程以起始平台事件 (例如,當機會狀態變更為「結束成交」時)。
  • 建立發佈機會詳細資料的新平台事件。

在遠端系統端:

  • ESB 會使用 CometD 通訊協定訂閱 Salesforce Platform 事件。
  • ESB 會收到一或多個通知,指出機會要轉換為訂單。
  • ESB 會將訊息轉送至後端 ERP 系統,以便建立訂單。
  • 在 ERP 系統中建立訂單後,個別的執行緒會使用 SessionId 作為驗證權杖回呼至 Salesforce。此回呼會以訂單編號和狀態更新機會。您可以使用記錄的模式解決方案來執行此回呼,例如 Salesforce Platform 事件、Salesforce SOAP API、REST API 或 Apex Web 服務。

此範例示範以下事項。

  • 實作非同步叫用的遠端程序
  • 端對端保證傳送
  • 後續回呼至 Salesforce 以更新記錄的狀態

內容

您將 CRM 實作移至 Salesforce,且想要:

  • 從目前的 CRM 系統中解壓縮和轉換帳戶、連絡人和機會,並將資料載入至 Salesforce (初始資料匯入)。
  • 每週 (進行中) 從遠端系統將客戶的帳單資料解壓縮、轉換和載入至 Salesforce。
  • 每週 (進行中) 從 Salesforce 解壓縮客戶活動資訊,並將其匯入內部部署資料倉庫。

問題

您要如何將資料匯入 Salesforce 並匯出 Salesforce 的資料,考慮到這些匯入和匯出可能會在營業時間中干擾一般使用者作業,並涉及大量資料?

力

根據此模式套用解決方案時,需要考量各種因素:

  • 資料是否應儲存在 Salesforce 中?若否,則結構設計師可以並應考慮其他整合選項 (例如,遮罩)。
  • 如果資料應儲存在 Salesforce 中,是否應針對遠端系統中的事件重新整理資料?
  • 資料是否應依排程重新整理?
  • 資料是否支援主要業務流程?
  • 是否有受 Salesforce 中此資料可用性影響的分析 (報告) 需求?

解決方案

下表包含此整合問題的各種解決方案。

解決方案 適合 資料主要資料 註解
透過第三方 ETL 工具複製 最佳 遠端系統 外部系統需要將大量資料傳送至 Salesforce 的位置,請利用協力廠商 ETL 工具,讓您能夠對來源資料執行變更資料擷取。

工具會回應來源資料集中的變更、轉換資料,然後呼叫 Salesforce 大量 API 來核發 DML 陳述式。如果記錄數目較少,則也可以使用 Salesforce REST API 來實作此動作。
透過第三方 ETL 工具複製 良好 Salesforce 利用協力廠商 ETL 工具,讓您針對 ERP 和 Salesforce 資料集執行變更日期資料擷取。

在此解決方案中,Salesforce 是資料來源,您可以使用個別資料列的時間/狀態資訊來查詢資料並篩選目標結果集。這可透過使用大量 API 2.0 或標準 REST API (如果記錄數量較少) 來實作。
資料匯入精靈和 Data Loader 適合 Salesforce/外部系統 「資料匯入精靈」和 Data Loader 可用來匯入、匯出和移轉資料。雖然 Data Loader 指令也可以指令檔,以自動匯入和匯出資料,但指令行介面僅適用於 Windows。這些工具都不是資料整合策略的建議基礎。他們應改為補充您的資料管理與維護策略。

如需 Data Loader 的詳細資訊,請參閱 此處。
遠端呼叫 子最佳 遠端系統 遠端系統可以使用其中一個 API 呼叫 Salesforce,並在發生時對資料執行更新。不過,這會造成兩個系統之間有大量的持續流量。

應更重視錯誤處理和鎖定。此模式可能會造成持續更新,這可能會影響一般使用者的效能。
遠端流程叫用 子最佳 Salesforce Salesforce 可能會呼叫遠端系統,並在發生時對資料執行更新。不過,這會造成兩個系統之間有大量的持續流量。

應更重視錯誤處理和鎖定。此模式可能會造成持續更新,這可能會影響一般使用者的效能。

草稿

下圖說明此模式中的事件順序,其中 Salesforce 是資料主要資料。

下載圖表

下圖說明近乎即時的事件後續同步化,其中 Salesforce 是資料主要資料。

結果

您可以在下列情況下將外部來源的資料與 Salesforce 整合:

  • 外部系統是資料主要資料—Salesforce 是單一來源系統或多個系統所提供資料的取用者。在此情節下,在將資料匯入 Salesforce 之前,擁有彙總資料的資料倉庫或資料 Mart 很常見。
  • Salesforce 是資料主要資料—Salesforce 是特定實體的記錄系統,Salesforce Change 資料擷取 用戶端應用程式可以通知 Salesforce 資料的變更。

在一般的 Salesforce 整合案例中,實作小組會執行下列其中一項:

  • 在來源資料集上實作變更資料擷取。
  • 在中間的內部部署資料庫中實作一組支援的資料庫結構 (稱為控制表格)。

接著,ETL 工具會用於建立會:

  1. 閱讀控制表以判斷工作的上次執行階段,並取用其他所需的控制值。
  2. 使用上述控制值作為篩選條件,並查詢來源資料集。
  3. 套用預先定義的處理規則,包括驗證、增強等等。
  4. 使用 ETL 工具的可用連接器/轉換功能來建立目的地資料集。
  5. 將資料集寫入至 Salesforce 物件。
  6. 如果處理成功,請更新控制表格中的控制值。
  7. 如果處理失敗,請使用可啟用重新啟動與結束的值更新控制表格。

備註:我們建議您在 ETL 工具可存取的環境中建立控制表格和相關聯的資料結構,即使 Salesforce 無法存取。這可提供足夠的彈性。Salesforce 應視為此流程中的發言者,而 ETL 基礎結構就是中心。

若要讓 ETL 工具充分利用資料同步化功能,請考量下列事項:

  • 將 ETL 工作鏈結並排序,以提供一致的流程。
  • 使用兩個系統中的主要索引鍵比對傳入資料。
  • 使用特定的 API 方法來僅取用更新的資料。
  • 如果在「主要 - 詳細資料」或對應關係中匯入子系記錄,請使用來源的父系金鑰將匯入的資料分組,以避免鎖定。例如,如果您要匯入連絡人資料,請務必依父系帳戶金鑰將連絡人資料分組,以便在一個 API 呼叫中載入單一帳戶的連絡人數目上限。無法分組匯入的資料通常會導致在 API 呼叫內容中載入第一個連絡人記錄,而該帳戶的後續連絡人記錄會失敗。
  • 任何匯入後處理 (例如觸發) 都應只選擇性地處理資料。
  • 如果您的案例涉及大量資料,請遵循此 Trailhead 模組中的最佳作法 使用大量資料進行部署的最佳作法
    • .

錯誤處理與復原

必須將錯誤處理與復原策略視為整體解決方案的一部分。最佳方法取決於您選擇的解決方案。

錯誤位置 錯誤處理與復原策略
使用 Change 資料擷取 從 Salesforce 讀取
  • 錯誤處理—必須在遠端服務中執行錯誤處理,因為事件有效地傳送至遠端系統以供進一步處理。由於此模式為非同步,因此遠端系統會處理訊息排列、處理和錯誤處理。此外,系統不會在資料庫交易中處理「變更資料擷取」事件。因此,已發佈事件無法在交易中回復。
  • 復原—由於此模式為非同步,因此遠端系統必須根據服務品質的服務需求來起始重試。與每個 Change 資料擷取 事件相關聯的重新執行識別碼為原子,並會隨著每個發佈的事件而增加。此識別碼可用於從特定事件重新執行串流 (例如,根據上次成功捕捉的事件)。大量平台事件訊息會儲存 72 小時 (3 天)。當您使用 CometD 用戶端訂閱管道時,您可以取回過去的事件訊息。
使用第三方 ETL 系統從 Salesforce 讀取
  • 錯誤處理—如果在讀取作業期間發生錯誤,請實作與基礎結構無關的錯誤重試。在重複失敗的情況下,應在 ETL 作業內容中實作使用控制表格/錯誤表格的標準處理,以:
    • 記錄錯誤
    • 重試讀取作業
    • 如果失敗,則終止
    • 傳送通知
  • 復原—重新啟動 ETL 流程,以從失敗的讀取作業復原。
如果作業成功但有失敗的記錄,則立即重新啟動或後續執行工作應解決問題。在此情況下,延遲的重新啟動可能是更好的解決方案,因為它允許時間來分級並更正可能導致錯誤的資料。
寫入 Salesforce
  • 錯誤處理—寫入作業期間發生的錯誤可能是應用程式中因素的組合所導致。API 呼叫會傳回包含下方所列資訊的結果集。此資訊應用於重試寫入作業 (若有必要)。
    • 記錄識別資訊
    • 成功/失敗通知
    • 每個記錄的錯誤集合
  • 復原—重新啟動 ETL 流程,以從失敗的讀取作業復原。
如果作業成功但有失敗的記錄,則立即重新啟動或後續執行工作應解決問題。在此情況下,延遲的重新啟動可能是更好的解決方案,因為它允許時間來分級並更正可能導致錯誤的資料。
外部主要系統 錯誤應根據主要系統的最佳作法處理。

安全性考量事項

任何對遠端系統的呼叫都必須維護要求的機密性、完整性和可用性。根據您選擇的解決方案,會套用不同的安全性考量事項。

  • 需要至少具有「僅 API」使用者權限的 Lightning 平台授權,才能允許已驗證的 API 存取 Salesforce API。
  • 我們建議使用標準加密來保護密碼存取的安全。
  • 當呼叫 Salesforce API 時,請使用 HTTPS 通訊協定。您也可以視需要透過內部部署安全性解決方案將流量代理至 Salesforce API。

請參閱 安全考量事項。

側列

無。

及時性

在此模式中,及時性並不重要。不過,必須特別小心設計介面,讓所有批次流程都以指定的批次期間完成。

如同所有以批次為導向的作業,我們強烈建議您在批次處理期間特別注意隔離來源和目標系統。在營業時間內載入批次可能會造成一些爭議,導致使用者的更新失敗,或者更重要的是,批次載入 (或部分批次載入) 失敗。

針對擁有全域營運的組織,可能無法同時執行所有批次流程,因為系統可能會持續使用中。在這些情況下,可以使用使用記錄類型和其他篩選條件的資料區隔技術來避免資料爭用。

州管理

您可以使用兩個系統之間的替代索引鍵來實作狀態管理。如果您需要跨 Salesforce 實體的任何類型交易管理,建議您使用 Apex 使用「遠端呼叫」模式。

標準樂觀記錄鎖定會在平台上發生,使用 API 進行的任何更新都需要編輯記錄的使用者重新整理記錄並起始其交易。在 Salesforce API 內容中,樂觀鎖定意指以下流程:

  • Salesforce 不會維護特定使用者編輯記錄的狀態。
  • 讀取時,它會記錄資料的取用時間。
  • 如果使用者更新記錄並予以儲存,Salesforce 會檢查其他使用者是否在同時間更新記錄。
  • 如果記錄已更新,則系統會通知使用者已進行更新,且使用者應在繼續進行其更新的過程中,先取回記錄的最新版本。

中介軟體功能

用來實作此模式的最有效外部技術為傳統 ETL 工具。選擇的中介軟體工具必須支援 Salesforce 大量 API。

中介軟體工具支援 getUpdated() 函數很有幫助,但不重要。此函數提供在 Salesforce 平台上與標準變更資料擷取功能最接近的實作。

下表會醒目提示參與此模式之中介軟體系統的理想內容。

財產 必要 理想 不需要
事件處理 X
通訊協定轉換 X
翻譯和轉換 X
排隊與緩衝 X
同步傳輸通訊協定 X
非同步傳輸通訊協定 X
仲裁路由 X
流程 koreography 和服務協調流程 X
交易性 (加密、簽署、可靠傳送、交易管理) X
路由 X
解壓縮、轉換和載入 X
長輪詢 X (Salesforce Change 資料擷取 需要)

範例

公用事業公司使用以主要機器為基礎的批次流程,將潛在客戶指派給個別銷售代表和小組。此資訊必須每晚匯入 Salesforce。

客戶已決定使用商業上可用的 ETL 工具,在來源表格上實作變更資料擷取。解決方案的運作方式如下:

  • 類似 Cron 的排程器會執行批次工作,將潛在客戶指派給使用者和小組。
  • 批次工作執行並更新資料後,ETL 工具會使用變更資料擷取來識別這些變更。ETL 工具會從資料存放區彙總變更。
  • ETL 連接器使用 Salesforce REST API 將變更載入至 Salesforce。

內容

您可以使用 Salesforce 追蹤商機、管理您的銷售管道、建立機會,以及獲取將商機轉換為客戶的訂單詳細資料。Salesforce 系統會在內部建立訂單,然後將該資料推送至外部帳單系統以供佈建和啟用。帳單訂單由外部 (遠端) 系統管理。當帳單系統狀態上的訂單或帳單實體變更時,該遠端系統需要更新 Salesforce 中的訂單狀態。

問題

遠端系統如何與 Salesforce 連線和驗證,以通知 Salesforce 外部事件、建立記錄和更新現有記錄?

力

根據此模式套用解決方案時,需要考量各種因素:

  • 遠端呼叫 Salesforce 的目的為使用以事件為導向的結構通知 Salesforce 在外部發生的事件嗎?或者是為了對特定記錄執行 CRUD 作業?如果您使用以事件為導向的結構,則事件產生者 (遠端程序) 會與 Salesforce 事件取用者分離。
  • 對 Salesforce 的呼叫是否需要遠端流程等待回應,才能繼續處理?遠端呼叫至 Salesforce 一律為同步要求回應,雖然遠端流程可能會捨棄回應,如果其不需要模擬非同步呼叫。
  • 每個交易是否會針對單一 Salesforce 物件或多個相關物件進行作業?
  • 訊息的格式為何 (例如,SOAP 或 REST,或兩者皆透過 HTTP)?
  • 訊息大小是否相對較小或較大?
  • 如果遠端系統支援 SOAP,則遠端系統是否能夠參與契約優先方法,其中 Salesforce 會規定契約嗎?此為使用 SOAP API (提供預先定義的 WSDL) 時所需。
  • 是否需要交易處理?
  • 您對 Salesforce 中自訂的容忍程度為何?

解決方案

此表格包含此整合問題的各種解決方案。

解決方案 適合 註解
複合 API 最佳 Salesforce 提供基本上是 REST API 的複合 API,並支援複合要求。遠端系統可將其用於:
  • 單一通話最多可傳送 25 個要求。
  • 用於使用 JSON 要求在 Salesforce 組織中查詢、建立和修改資料。

同步 API—在進行 API 呼叫後,遠端用戶端應用程式會等待,直到收到服務的回應為止。

交易/認可行為—依預設,如果某些記錄標記為錯誤,則複合 API 不會允許部分成功。您可以將「全部或無所有一切」標記為 false 來變更,這將允許部分成功。

錯誤處理:適當的錯誤處理應檢查回應內文,而不只是 HTTP 狀態代碼。複合端點會以 200 HTTP 狀態代碼回應,即使在回應內文中顯示其中一個子要求失敗且交易必須回復。
REST API 最佳 無障礙—Salesforce 提供遠端系統可用來:
  • 發佈事件以通知您的 Salesforce 組織
  • 查詢您組織中的資料
  • 建立、更新和刪除資料
  • 取得您組織的相關中繼資料

同步 API—在進行 API 呼叫後,遠端用戶端應用程式會等待,直到收到服務的回應為止。

REST API 遵循根據登入使用者的設定檔在 Salesforce 中設定的物件級和欄位級安全性。

REST 會將資源 (實體/物件) 顯示為 URI,並使用 HTTP 動詞定義這些資源的 CRUD 作業。不同於 SOAP,REST API 不需要預先定義的契約、使用 XML 和 JSON 進行回應,且有寬鬆的輸入。REST API 輕量型,提供與 Salesforce 互動的簡單方法。其優點包括輕鬆整合與開發,且是與行動應用程式和 Web 應用程式搭配使用的絕佳選擇。

交易/認可行為—依預設,會將每個記錄視為個別交易,並分別認可。一個記錄變更失敗不會導致其他記錄變更回復。此行為可以變更為「全部或無」行為。使用 REST API 複合資源,在一個 API 呼叫中進行一系列更新。

大量資料—任何包含超過 2,000 筆記錄的資料作業均是「大量 API 2.0」成功準備、執行及管理使用「大量」架構非同步工作流程的理想候選項目。
大量 API 2.0 大量作業最佳 大量 API 2.0 是 Salesforce 的現代化、簡化的 API,用於處理大規模資料作業。REST 型大量 API 2.0 提供程式設計選項,可在您的 Salesforce 組織中非同步地插入、更新插入、查詢或刪除大型資料集。當您需要將大量資料載入 Salesforce 或對組織的資料執行大量查詢時,其設計目的為效率。

不同於大量 API 1.0,「大量 API 2.0」一律會並列處理批次,且不支援序列模式。這表示:
  • 記錄會同時在多個執行緒之間處理
  • 批次之間的處理訂單沒有保證
  • 效能較高,但鎖定爭用也有潛力

「大量 API 2.0」中的每個批次都會作為其自己的交易處理。這表示:
  • 成功的批次獨立認可
  • 失敗的批次不會影響成功的批次
  • 依預設,所有工作之間都不會有「全部或無所有一切」行為

雖然 SOAP API 也可以用於處理大量記錄,但當資料集包含數十萬到數百萬筆記錄時,其會變得較不最佳。這是由於其相對高負擔和較低的效能特性。
  • 以事件為導向的結構—平台事件的定義方式與您定義 Salesforce 物件的方式相同。透過大量 API 2.0 發佈事件與建立 Salesforce 記錄相同。僅支援建立和插入作業。批次內的事件會在批次工作處理時非同步地發佈至 Salesforce Event Bus。
Pub/Sub API 最佳 Pub/Sub API 是外部發行者在 Event Bus 上發佈事件的建議方式。

Pub/Sub API 是 gRPC 型 API,允許外部系統發佈平台事件。Pub/Sub API:
  • 支援從外部應用程式發佈和訂閱平台事件
  • 適用於適當驗證 (OAuth、JWT 或工作階段權杖)

平台事件在 Salesforce 中定義後,便可供內部與外部消費者使用。
平台事件 最佳 平台事件的定義方式與您定義 Salesforce 物件的方式相同。平台事件可以使用不同的機制發佈,例如 REST API、大量 API 和 SOAP API。

透過 REST API 發佈事件與建立 Salesforce 記錄相同。

端點格式:POST /services/data/vXX.X/sobjects/EventName__e/
  • Content-Type:application/json
  • 驗證:承載者權杖 (OAuth)

透過大量 API,僅支援建立和插入作業。批次內的事件會在批次工作處理時非同步地發佈至 Salesforce Event Bus。

由於「平台事件」是 SObject,因此支援標準 SOAP API 作業。
SOAP API 適合 無障礙—Salesforce 提供 SOAP API,可讓遠端系統用於:
  • 發佈事件以通知您的 Salesforce 組織
  • 查詢您組織中的資料
  • 建立、更新和刪除資料
  • 取得您組織的相關中繼資料
  • 執行公用程式以執行管理工作

同步 API—在進行 API 呼叫後,遠端用戶端應用程式會等待,直到收到服務的回應為止。不支援對 Salesforce 進行非同步呼叫。

產生的 WSDL—Salesforce 針對遠端系統提供兩個 WSDL:
  • 企業 WSDL - 提供 Salesforce 組織特有的強型 WSDL。
  • 合作夥伴 WSDL - 包含不適用於 Salesforce 組織的寬鬆輸入 WSDL。

安全性—執行 SOAP API 的用戶端必須具有有效的登入並取得工作階段,才能執行任何 API 呼叫。API 遵循根據登入使用者的設定檔在 Salesforce 中設定的物件級和欄位級安全性。

交易/認可行為—依預設,如果某些記錄標記為錯誤,則每個 API 呼叫都允許部分成功。這可以變更為「全部或無所有一切」行為,如果發生任何錯誤,則所有結果都會回復。無法跨多個 API 呼叫來跨越交易。若要克服此限制,單一 API 呼叫可能會影響多個物件。
Apex Web 服務 子最佳 Apex 類別方法可作為 Web 服務方法向外部應用程式公開。此方法是 SOAP API 的替代方法,通常僅在必須符合下列其他需求時使用。
  • 需要完整的交易支援 (例如,在一個交易中建立帳戶、連絡人和機會)。
  • 認可之前,必須先在 Salesforce 端套用自訂邏輯。

使用 Apex Web 服務的好處必須根據需要在 Salesforce 中維護的其他程式碼加權。

不適用於平台事件,因為在消費者處的交易預先插入邏輯不適用於 以事件為導向的結構。若要通知 Salesforce 組織事件已發生,請使用 SOAP API、REST API 或大量 API 2.0。
Apex REST 服務 子最佳 Apex 類別可以公開為對應至特定 URI 且具有定義的 HTTP 動詞 (例如 POST 或 GET) 的 REST 資源。

您可以使用 REST API 複合資源,在單一交易中執行多個更新。

不同於 SOAP,用戶端不需要耗用服務定義/契約 (WSDL) 並產生用戶端停用。遠端系統只需要能夠形成 HTTP 要求並處理傳回的結果 (XML 或 JSON)。

不適用於平台事件,因為在消費者處的交易預先插入邏輯不適用於 以事件為導向的結構。若要通知 Salesforce 組織事件已發生,請使用 SOAP API、REST API 或大量 API 2.0。

草稿

下列圖說明當您使用 REST API 來從外部事件通知,或 SOAP API 來查詢 Salesforce 物件時,實作此模式時的事件順序。使用 REST API 時,事件的順序相同。

透過 SOAP API 遠端系統查詢 Salesforce

透過 REST API 通知 Salesforce 事件的遠端系統

結果

在以事件為導向的結構中,遠端系統會使用 SOAP API、REST API 或大量 API 2.0 呼叫至 Salesforce 以將事件發佈至 Salesforce Event Bus。發佈事件會通知所有訂閱者。事件訂閱者可以位於 Salesforce Platform (例如流程或 Lightning 元件) 的 Apex 觸發。事件訂閱者也可以是 Salesforce Platform 的外部使用者,例如 CometD 訂閱者。

當直接使用 Salesforce 物件時,與此模式相關的解決方案允許:

  • 遠端系統會呼叫 Salesforce API 來查詢資料庫並執行單一物件作業 (建立、更新、刪除等)。
  • 可呼叫 Salesforce REST API 複合資源的遠端系統,以執行一系列物件作業。
  • 遠端系統可呼叫可支援多物件交易作業和自訂前/後處理邏輯的自訂建立 Salesforce API (服務)。

呼叫機制

呼叫機制取決於用來實作此模式的解決方案。

呼叫機制 描述
SOAP API 遠端系統使用 Salesforce Enterprise 或合作夥伴 WSDL 產生用戶端固體,進而用來叫用標準 SOAP API。
REST API 遠端系統必須先進行驗證,才能存取任何 Apex REST 服務。遠端系統可以使用 OAuth 2.0 或使用者名稱和密碼驗證。在任一情況下,用戶端必須以適當的值設定授權 HTTP 標頭 (可透過 SOAP API 的登入呼叫取得 OAuth 存取權杖或工作階段識別碼)。

接著,遠端系統會產生具有適當動詞的 REST 叫用 (HTTP 要求),並處理傳回的結果 (支援 JSON 和 XML 資料格式)。
Apex Web 服務 遠端系統會耗用自訂的 Apex Web 服務 WSDL,以產生用戶端固體,進而用於叫用自訂 Apex Web 服務。
Apex REST 服務 根據 REST API,系統會使用 @RestResource、@HttpGet 和 @HttpPost 註釋來定義資源 URI 和適用的動詞。
大量 API 2.0 「大量 API 2.0」是以 REST 為基礎的 API,因此會套用與 REST API 相同的呼叫機制。
叫用流程的 REST API 使用 REST API 呼叫自訂可叫用動作端點以叫用自動啟動流程。

錯誤處理與復原

必須將錯誤處理與復原策略視為整體解決方案的一部分。

  • 錯誤處理—所有遠端呼叫方法 (標準或自訂 API) 都需要遠端系統來處理任何後續錯誤,例如逾時和重試的管理。中間軟體可用來提供錯誤處理與復原的邏輯。
  • 復原—如果服務品質需求規定該機制,則必須建立自訂重試機制。在此情況下,確保設計特性完全相符十分重要。平台事件可讓訂閱者使用重新執行識別碼,在發佈這些訊息後的特定期間內提取訊息。

識別設計考量事項

Idempotent 功能可保證重複叫用是安全的,不會造成負面影響。如果未實作 idempotency,則重複叫用相同訊息可能會產生不同的結果,可能導致資料完整性問題,例如建立重複的記錄、重複處理交易等。

遠端系統必須在發生錯誤或逾時的情況下管理多個 (重複) 呼叫,以避免重複插入和冗餘更新 (特別是在下游觸發和工作流程規則觸發時)。雖然您可以在 Salesforce 中管理某些情況 (特別是自訂 SOAP 和 REST 服務的情況),但我們建議遠端系統 (或中間軟體) 管理錯誤處理和無效設計。

安全性考量事項

根據選擇的模式解決方案,會套用不同的安全性考量事項。在所有情況下,平台都會使用登入使用者的存取權 (例如設定檔設定、共用規則、權限集等)。此外,設定檔 IP 限制可用來限制特定 IP 位址範圍的 API 存取權。

解決方案 安全性考量事項
SOAP API alesforce 支援 Secure Sockets Layer v3 (SSL) 和 Transport Layer Security (TLS) 通訊協定。加密的金鑰長度必須至少為 128 位元。

遠端系統必須使用有效的認證登入,才能取得工作階段識別碼。如果遠端系統已具有有效的工作階段識別碼,則可以呼叫 API,而無須明確登入。這會用於此文件稍早說明的回呼模式,其中先前的 Salesforce 輸出訊息包含工作階段識別碼和記錄識別碼以供後續使用。

我們建議呼叫 SOAP API 的用戶端快取並重複使用工作階段識別碼以最大化效能,而非為每個呼叫取得新的工作階段識別碼。
REST API 我們建議遠端系統建立 OAuth Trust 以進行授權。接著,可以使用 HTTP 動詞對特定資源進行 REST 呼叫。您也可以使用可能以其他方式取得的有效工作階段識別碼進行 REST 呼叫 (例如,透過呼叫 SOAP API 或透過輸出訊息提供),

我們建議呼叫 REST API 的用戶端快取並重複使用工作階段識別碼以最大化效能,而非為每個呼叫取得新的工作階段識別碼。
Apex Web 服務 我們建議遠端系統建立 OAuth Trust 以進行授權。
Apex REST 服務 我們建議遠端系統建立 OAuth Trust 以進行授權。
大量 API 2.0 我們建議遠端系統建立 OAuth Trust 以進行授權。

請參閱 安全考量事項。

側列

無。

及時性

SOAP API 和 Apex Web 服務 API 是同步的。套用下列逾時:

  • 工作階段逾時—如果根據 Salesforce 組織的工作階段逾時設定沒有活動,則工作階段逾時。
  • 查詢逾時—每個 SOQL 查詢的個別逾時限制為 120 秒。

資料量

資料量考量事項取決於您選擇的解決方案和通訊類型。

解決方案 通訊類型 限制
SOAP API 或 REST API 同步
  • SOAP 登入—SOAP 登入要求大小限制為 10 KB 或更少。每個使用者每小時最多可對 login() 函數進行 3,600 次呼叫。如果您超過此限制,API 會傳回錯誤。
  • 建立、更新、刪除—遠端系統一次最多可建立、更新或刪除 200 筆記錄。可進行多個呼叫來處理總共超過 200 筆記錄,但每個要求大小限制為 200 筆記錄
  • BLOB 資料—您可以使用「SObject 基本資訊」、「SObject 列」或「SObject 集合 REST」資源,在 Salesforce 標準物件中插入或更新 BLOB 資料。針對「SObject 基本資訊」或「SObject 列」資源,上載的檔案大小上限為 ContentVersion 物件 2 GB,所有其他符合資格的標準物件 500 MB。使用「SObject 集合」資源時,單一要求中所有檔案的總大小上限為 500 MB。
  • 查詢結果大小 — 依預設,在查詢結果物件 (批次大小) 中傳回且在 query() 或 queryMore() 呼叫中傳回的列數會設定為 500。傳回的列數上限為 2,000 列。您可以明確設定批次大小,但不保證要求的批次大小將是實際的批次大小。這是為了發揮最大效能。若要傳回的列數超過批次大小,請使用 queryMore() API 呼叫重複進行多個批次。可能會套用其他規則,以取得詳細資訊。
  • 事件訊息 — 事件訊息大小上限為 1 MB。使用 Salesforce API 發佈事件會計入您的標準 API 限制。
大量 API 2.0 非同步 「大量 API 2.0」已針對非同步匯入和匯出大型資料集進行最佳化。

任何包含超過 2,000 個記錄的資料作業都是「大量 API 2.0」成功準備、執行及管理使用「大量」架構的非同步工作流程的理想候選項目。記錄少於 2,000 個的工作應涉及 REST (例如複合) 或 SOAP 中「大量處理」的同步呼叫。

提交批次要求和相關聯的資料時,大量 API 2.0 為同步。資料的實際處理會以非同步方式進行。如需有關 API 和批次處理限制的詳細資訊,請參閱「限制」。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

解決方案 端點考量事項
SOAP API 遠端系統必須能夠根據 Salesforce 預先定義的訊息格式,實作可呼叫 Salesforce SOAP API 的用戶端。

遠端系統 (用戶端) 必須參與契約優先實作,其中契約由 Salesforce 提供 (例如,Enterprise 或合作夥伴 WSDL)。
REST API 遠端系統必須能夠實作叫用 Salesforce (定義的 REST 服務) 並處理 XML 或 JSON 結果的 REST 用戶端。
Apex Web 服務 遠端系統必須能夠實作可叫用預先定義格式 SOAP 訊息的用戶端,如 Salesforce 所定義。

遠端系統必須參與程式碼優先實作,其中契約會在實作 Apex Web 服務後由 Salesforce 提供。每個 Apex Web 服務都有自己的 WSDL。
Apex REST 服務 套用與 REST API 相同的端點考量事項。

州管理

整合系統時,金鑰對於進行中狀態追蹤而言很重要,例如,如果在遠端系統中建立記錄,則支援對該記錄進行中的更新。有兩個選項:

  • Salesforce 會儲存遠端系統遠端記錄的主要或唯一替代金鑰。
  • 遠端系統會儲存 Salesforce 唯一記錄識別碼或其他唯一的替代金鑰。在此同步模式中處理整合索引鍵有特定考量事項。
主要 系統 描述
Salesforce 在此情節下,遠端系統會儲存 Salesforce RecordId 或記錄中的其他唯一替代金鑰。
遠端系統 在此情節下,Salesforce 會將唯一識別碼的參照儲存在遠端系統中。由於程序為同步,因此金鑰可以使用外部識別碼欄位作為相同交易的一部分提供。

複雜整合案例

此模式中的每個解決方案在處理複雜的整合案例 (例如轉換和流程協調流程) 時有不同的考量事項。

解決方案 考量事項
SOAP API 或 REST API SOAP API 和 REST API 提供物件的簡單交易。複雜的整合案例 (例如彙總、協調流程和轉換) 無法在 Salesforce 中執行。這些情況必須由遠端系統或中介軟體處理,而中介軟體是偏好的方法。
Apex Web 服務或 Apex REST 服務 自訂 Web 服務可提供跨物件功能、自訂邏輯和更複雜的交易支援。應謹慎使用此解決方案,且您應一律考量中介軟體是否適合任何轉換、協調流程和錯誤處理邏輯。

管理員限制

由於 Salesforce 平台的多租戶性質,因此使用 API 時有一些限制。

解決方案 限制
SOAP API、REST API 和自訂 Apex API
  • API 要求限制—Salesforce 針對每 24 小時期間的 API 呼叫數量套用限制。限制取決於 Salesforce 版本類型與授權數目。例如,Unlimited Edition 每 24 小時會為每個 Salesforce Platform 授權提供 5,000 個 API 要求。如需詳細資訊,請參閱 Salesforce 開發人員限制與配置快速參考。
  • API 查詢游標限制—使用者一次最多可開啟 10 個查詢游標。否則,會釋出 10 個游標中最舊的游標。如果遠端應用程式嘗試開啟已釋出的查詢游標,則會產生錯誤。例如,如果共用整合使用者認證,則必須考量查詢游標的上限。在可能的情況下,中介軟體應先完成完整查詢,再執行其他查詢 (以序列方式執行),或者每個應用程式應使用指定的整合使用者。或者,中介軟體可能需要以「循環」模式在多個使用者之間執行要求。
  • 通話限制—請參閱建立、更新和查詢限制的「資料量」側列。
大量 API 2.0 請參閱 資料量側列以取得詳細資訊。
平台事件
  • 事件通知限制—標準量平台事件每小時最多可發佈 100,000 個事件。針對以大量用量為基礎的平台事件,每小時最多可發佈 250,000 個事件。若要監視大量事件用量,請使用 REST API 限制資源。
  • 事件訊息大小限制—事件訊息大小上限為 1 MB。使用 Salesforce API 發佈事件會計入您的標準 API 限制。

可靠傳訊

可靠的傳訊嘗試解決保證將訊息傳送至遠端系統的問題,其中個別元件本身可能無法可靠。Salesforce SOAP API 和 REST API 是同步的,且本身並不提供任何可靠傳訊通訊協定的明確支援 (例如,WS-ReliableMessaging)。

我們建議遠端系統實作可靠的傳訊系統,以確保成功管理錯誤和逾時情況。從外部系統發佈平台事件取決於 Salesforce API,因此 SOAP API 和 REST API 適用相同的考量事項。

中介軟體功能

此表格會醒目提示參與此模式的中介軟體系統所需的內容:

財產 必要 理想 不需要
事件處理 X
通訊協定轉換 X
翻譯和轉換 X
排隊與緩衝 X
同步傳輸通訊協定 X
非同步傳輸通訊協定 X
仲裁路由 X
流程 koreography 和服務協調流程 X
交易性 (加密、簽署、可靠傳送、交易管理) X
路由 X
解壓縮、轉換和載入 X (適用於大量/批次)

範例

印刷用品與服務公司使用 Salesforce 作為前端來建立和管理印表機耗材與訂單。代表印表機的 Salesforce 資產記錄會定期更新為來自內部部署印表機管理系統 (PMS) 的列印用量統計資料 (墨水狀態、紙張層級),該系統會定期監視用戶端網站上的印表機。達到設定的值 (例如低墨水狀態或低/空白紙張等級低於 30%) 時,會通知多個對事件感興趣的應用程式/程序 (變數),傳送電子郵件或 Chatter 警示,並建立「訂單」記錄。PMS 會儲存 Salesforce 識別碼 (Salesforce 是資產記錄主要資料)。

適用以下限制:

  • PMS 可以參與契約優先整合,其中 Salesforce 會提供契約,而 PMS 會作為 Salesforce 服務的用戶端 (消費者) (透過企業或合作夥伴 WSDL 定義)。
  • Salesforce 中不應該有自訂開發。

此範例最適合使用 Salesforce SOAP API 或 REST API 來發佈事件,以及 Salesforce 中的陳述性自動化 (流程)。使用平台事件的主要原因是訂閱者數目為變數和非限數;不過,若要對如訂單等有限記錄清單進行簡單更新,請使用 SOAP 或 REST API 來更新記錄。

在 Salesforce 中:

  • 在 Salesforce 中定義平台事件,以包含來自 PMS 的通知資料。
  • 建立由印表機事件通知觸發的流程。流程會更新印表機資產並建立訂單 (使用自動啟動流程)。
  • 下載 Enterprise 或合作夥伴 WSDL,並將其提供給遠端系統。

在遠端系統中:

  • 從 Enterprise 或合作夥伴 WSDL 建立用戶端設定檔。
  • 使用整合使用者的認證來驗證 Salesforce (透過 OAuth Web 伺服器或承載者權杖流程)。
  • 在印表機狀態事件時,PMS 會呼叫 API 以建立印表機狀態平台事件 (包含印表機用量統計資料)。Salesforce Event Bus 會通知流程訂閱者和所有其他訂閱者。

當您使用平台事件時,Event Bus 可讓您針對大量平台事件重新執行 72 小時的事件。使用中介軟體解決方案發佈這些事件有助於在發佈端納入錯誤處理。不過,如果需要更高的可靠性,您可以在訂閱端實作錯誤處理。

此範例示範下列事項:

  • Salesforce 同步 API 用戶端 (消費者) 實作。
  • 回呼至 Salesforce 以發佈平台事件 (符合先前涵蓋的要求/回覆平台事件模式)。

內容

您使用 Salesforce 來管理客戶個案。客戶服務代表與正在處理個案的客戶通話。客戶進行付款,且客戶服務代表需要從付款處理應用程式查看 Salesforce 應用程式內的即時更新,表示客戶已成功支付訂單的未償還金額。

問題

當事件在 Salesforce 中發生時,如何在 Salesforce 使用者介面中通知使用者,而無須重新整理畫面並可能遺失工作?

力

根據此模式套用解決方案時,需要考量各種因素:

  • 處理的資料是否需要儲存在 Salesforce 中?
  • 可建立自訂使用者介面層來檢視此資料嗎?
  • 使用者是否擁有叫用自訂使用者介面的存取權?

解決方案

此整合問題的建議解決方案是使用平台事件,以確保在 Salesforce 中近乎即時發生的事件。「平台事件」提供與任何 Salesforce 物件無關的結構化彈性裝載。其也會透過 72 小時的重新執行時段來確保主題具有永久性。這可確保事件可供使用,即使離線取用者稍後可供使用。此解決方案由下列元件所組成:

  • Apex 觸發或具有邏輯的流程,可在主題上發佈平台事件
  • 允許您從 Apex 觸發或流程發佈事件的主題
  • Bayeux 通訊協定的 JavaScript 型實作 (目前為 CometD),可供使用者介面使用
  • Lightning 元件
  • 作為靜態資源包含的 JavaScript 程式庫

草稿

下圖說明如何實作串流 API 將通知串流至 Salesforce 使用者介面。這些通知是由 Salesforce 中的記錄變更觸發。

資料變更觸發 Salesforce 中的 UI 更新

結果

福利

套用與此模式相關的解決方案具有下列優點:

  • 無須撰寫自訂輪詢機制
  • 無須使用者起始的回饋意見迴圈

不支援的需求

此解決方案有下列限制:

  • 不保證傳送通知。
  • 不保證通知的順序。
  • 大量 API 所做的記錄變更不會產生通知。

安全性考量事項

遵循標準 Salesforce 組織級安全性。建議您使用 HTTPS 通訊協定來連線至串流 API。請參閱 安全性考量事項

側列

最佳解決方案涉及在 Salesforce 中建立自訂使用者介面。您必須考量適當的使用者介面容器,以用於呈現自訂使用者介面。支援的瀏覽器會列在《串流 API 開發人員指南》中

範例

一家電信公司使用 Salesforce 來管理客戶個案。客戶服務經理想要在其其中一位客戶服務代表成功結束個案時收到通知。

實作此模式所指定的解決方案時,客戶應:

  • 建立 Apex 觸發 PushTopic,當個案儲存為「已結束」且「解決方式」為「成功」時,傳送平台事件。
  • 建立可供客戶服務經理使用的自訂使用者介面。此使用者介面訂閱 Event Bus 以取用平台事件。
  • 在自訂使用者介面中實作邏輯,顯示該經理客戶服務代表產生的警示。

內容

您可以使用 Salesforce 追蹤商機、管理您的銷售管道、建立機會,以及獲取將商機轉換為客戶的訂單詳細資料。不過,Salesforce 並非包含或處理訂單的系統。訂單由外部 (遠端) 系統管理。但銷售代表想要在 Salesforce 中檢視和更新即時訂單資訊,而無須學習或使用外部系統。

問題

在 Salesforce 中,如何檢視、搜尋和修改儲存在 Salesforce 之外的資料,而不將資料從外部系統移至 Salesforce?

力

根據此模式套用解決方案時,需要考量各種因素:

  • 您想要在 Salesforce 中建立陳述式/點選輸出整合或 UI 模擬?
  • 您是否有大量不想要複製到 Salesforce 組織中的資料?
  • 您是否需要一次存取少量遠端系統資料?
  • 您是否需要即時存取最新資料?
  • 您是否將資料儲存在雲端或後端辦公系統中,但想要在 Salesforce 組織中顯示或處理該資料?
  • 您是否有資料落地考慮要將特定類型的資料儲存在 Salesforce 中?

解決方案

下表包含此整合問題的各種解決方案。

解決方案 適合 註解
Salesforce Connect 最佳 使用 Salesforce Connect 可從外部來源存取資料以及您的 Salesforce 資料。從 SAP、Microsoft、Oracle 和其他雲端型系統 (例如 Snowflake) 等系統即時提取資料,而無須在 Salesforce 中複製資料。

Salesforce Connect 會將外部系統中的資料表對應至您組織中的外部物件。外部物件與自訂物件類似,但其會對應至 Salesforce 組織外部的資料。Salesforce Connect 使用與外部資料的即時連線,讓外部物件始終處於最新狀態。存取外部物件會從外部系統即時提取資料。

Salesforce Connect 可讓您:
  • 查詢外部系統中的資料。
  • 在外部系統中建立、更新和刪除資料。
  • 透過清單檢視、詳細資料頁面、記錄摘要、自訂索引標籤和版面配置存取外部物件。
  • 定義外部物件與標準或自訂物件之間的關係,以整合不同來源的資料。
  • 對外部資料執行報告 (有限制)。
  • 在 Salesforce 行動應用程式上檢視資料。

若要使用 Salesforce Connect 存取儲存在外部系統上的資料,您可以使用下列其中一個轉接器:

  • Odata 2.0 轉接器或 Odata 4.0 轉接器 — 連線至任何 Odata 2.0 或 4.0 產生者公開的資料。
  • 跨組織轉接器—連線至儲存在另一個 Salesforce 組織中的資料。跨組織轉接器使用標準 Lightning 平台 REST API。不同於 Odata,跨組織轉接器可直接連線至其他組織,而不需要中介 Web 服務。
  • 透過 Apex 建立的自訂轉接器—如果 Odata 與跨組織轉接器不適合您的需求,請使用 Apex 連接器架構開發您自己的轉接器。
要求與回覆 子最佳 使用 Salesforce Web 服務 API 進行臨時資料要求,以存取及更新外部系統資料。此解決方案包含下列方法:

使用 Salesforce SOAP API。自訂頁面或按鈕會以同步方式起始 Apex REST/SOAP 呼叫。在 Salesforce 中,您可以取用 WSDL 並產生產生的 Proxy Apex 類別。此類別提供呼叫遠端服務所需的邏輯。頁面上的使用者起始動作接著會呼叫執行此 Proxy Apex 類別的 Apex 控制項動作來執行遠端呼叫。頁面需要 Salesforce 應用程式的自訂。

使用 Salesforce REST API。自訂頁面或按鈕會以同步方式起始 Apex HTTP 呼叫 (REST 服務)。在 Salesforce 中,您可以使用標準 GET、POST、PUT 和 DELETE 方法叫用 HTTP 服務。

如需此解決方案的詳細資訊,請參閱 遠端流程叫用—要求與回覆。

草稿

下圖說明如何使用 Salesforce Connect 使用 Odata 轉接器從外部系統提取資料。

在此情況下:

  1. 瀏覽器會執行 AJAX 呼叫,進而在對應的外部物件轉接器上執行動作。
  2. 轉接器會將動作翻譯為 Odata 要求,並透過整合和服務層向遠端系統提出 HTTP GET 要求。
  3. 遠端系統會透過整合與服務層級將 JSON 回應傳回至 Salesforce。
  4. 回應會從 Odata 翻譯為外部物件,並呈回瀏覽器。

結果

套用與此模式相關的解決方案可讓使用者介面起始的叫用,以便對一般使用者顯示交易的結果。

呼叫機制

呼叫機制取決於用來實作此模式的解決方案。

通話機制 描述
外部物件 Salesforce Connect 會將 Salesforce 外部物件對應至外部系統中的資料表。Salesforce Connect 會依需求即時存取資料,而非將資料複製到您的組織。即使資料儲存在您的組織之外,Salesforce Connect 仍提供與 Lightning 平台的流暢整合。外部物件適用於 Salesforce 工具,例如全域搜尋、對應關係、記錄摘要和 Salesforce 行動應用程式。外部物件也可供 Apex、SOSL、SOQL 查詢、Salesforce API,以及透過中繼資料 API、變更集和封裝的部署使用。
照明元件 用於觸發遠端流程作為涉及使用者介面的端對端流程的一部分,且結果必須在 Salesforce 記錄中顯示或更新。例如,可將信用卡付款提交至外部付款的流程,並立即傳回向使用者顯示的付款結果。從使用者介面事件觸發的整合通常需要建立自訂 Lightning 元件。

錯誤處理

請務必將錯誤處理納入整體解決方案中。發生錯誤 (例外情況或錯誤碼傳回給來電者) 時,來電者會管理錯誤處理。Salesforce Connect 驗證程式是可執行一些常見查詢和通知錯誤類型與失敗原因的免費工具。

福利

使用 Salesforce Connect 解決方案的一些優點包括:

  • 此解決方案不會耗用 Salesforce 中的資料儲存空間。
  • 使用者不必擔心在外部系統與 Salesforce 之間定期同步化資料。
  • 可透過 Odata 或跨組織轉接器,或透過自訂 Apex 轉接器使用最少程式碼,快速達成的陳述性設定。
  • 使用者可以存取外部資料,其功能與外部物件形式的自訂物件大致相同。
  • 能夠使用全域搜尋在連線的外部系統中執行聯合搜尋。
  • 能夠執行從雲端和內部部署來源存取外部資料的報告。請參閱下方的報告考量事項。

Salesforce Connect 考量事項

Salesforce Connect 解決方案有下列考量事項:

安全性考量事項

此模式的解決方案應遵循標準 Salesforce 組織級安全性。建議您使用 HTTPS 通訊協定來連線至任何遠端系統。如需詳細資料,請參閱 安全性考量事項

如果您使用 Odata 連接器,請確定您瞭解 Odata 外部資料來源上跨站台要求偽造 (CSRF) 的特殊行為、限制及建議。如需詳細資訊,請參閱 Salesforce Connect — OData 2.0 與 4.0 轉接器的 CSRF 考量事項。

側列

無。

及時性

及時性在此模式中十分重要。請記住下列幾點:

  • 通常會從使用者介面叫用要求,因此程序不能讓使用者等待。
  • 視外部系統的可用性和連線而定,可能需要很長的時間才會取回外部資料。Salesforce 具有可設定的 120 秒逾時上限值,可等待外部系統的回應。
  • 遠端流程的完成應及時執行,並在 Salesforce 逾時限制內及使用者期望內完成。

資料量

此模式主要用於少量即時活動,因為 Apex 呼叫解決方案的逾時值很小,且要求或回應的大小上限。請勿在訊息中包含資料裝載的批次處理活動中使用此模式。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

解決方案 端點考量事項
Salesforce Connect Odata API — 使用開放式資料通訊協定存取儲存在 Salesforce 之外的資料。外部資料必須透過 Odata 產生者公開。

其他 API—當其他可用的轉接器不適合您的需求時,請使用 Apex 連接器架構來開發您自己的自訂轉接器。自訂轉接器可以從任何來源取得資料。例如,某些資料可透過呼叫從網際網路中提取,而其他資料則可透過程式設計方式進行操作甚至產生。

連線至 Salesforce — 使用 Lightning 平台 REST API 存取儲存在其他 Salesforce 組織中的資料。

透過中介軟體連線

透過中間軟體連線—Salesforce Connect 合作夥伴生態系統已與 Salesforce 密切合作,確保其中間軟體門戶從服務中公開 OData 端點,以便 Salesforce 無須撰寫額外程式碼即可與其連線。
要求與回覆 Apex SOAP 呼叫 -

端點必須能夠透過 HTTP 接聽網路服務通話。

Apex HTTP 呼叫 -

端點必須能夠接收 HTTP 呼叫。

您可以使用 Apex HTTP 呼叫,使用標準 GET、POST、PUT 和 DELETE 方法呼叫 RESTful 服務

州管理

整合系統時,金鑰對於進行中狀態追蹤十分重要。例如,如果記錄是在遠端系統中建立的,則記錄通常需要某種識別金鑰來支援進行中的更新。有兩種儲存金鑰的選項。

  • Salesforce 會儲存遠端記錄的主要或唯一替代金鑰。
  • 遠端系統會儲存 Salesforce 唯一記錄識別碼或其他唯一的替代金鑰。在此同步模式中處理整合索引鍵有特定考量事項。
主要系統 描述
Salesforce 遠端系統會儲存 Salesforce 記錄識別碼或記錄中的其他唯一替代金鑰。
遠端系統 遠端流程的呼叫會從應用程式傳回唯一金鑰,而 Salesforce 會將該金鑰值儲存在唯一記錄欄位中。

複雜整合

在某些情況下,此模式所指定的解決方案可能需要實作複雜的整合案例。這些情況通常會使用中介軟體解決。

  • 將通話及其在多個系統之通話之間的結果彙總
  • 轉換輸入與輸出訊息
  • 跨多個系統的呼叫維護交易完整性
  • Salesforce 與外部系統之間的其他流程協調流程活動

管理限制

不同的轉接器適用不同的限制。如需詳細資料,請參閱 Salesforce Connect 的 一般限制。

中介軟體功能

下表會醒目提示參與此模式之中介軟體系統的理想內容。

財產 必要 理想 不需要
事件處理 X
通訊協定轉換 X
翻譯和轉換 X
排隊與緩衝 X
同步傳輸通訊協定 X
非同步傳輸通訊協定 X
仲裁路由 X
流程 koreography 和服務協調流程 X
交易性 (加密、簽署、可靠傳送、交易管理) X
路由 X
解壓縮、轉換和載入 X
長輪詢 X

外部物件關係

外部物件支援標準對應關係,其使用 18 個字元的 Salesforce 記錄識別碼來關聯相關記錄。不過,儲存在您 Salesforce 組織之外的資料通常不會包含這些記錄識別碼。因此,外部物件有兩種特殊類型的對應關係:外部對應和間接對應。

此表格摘要列出可供外部物件使用的關係類型。

關係 允許的子物件 允許的父系物件 比對記錄的父系欄位
對應 標準、自訂、外部 標準、自訂 18 個字元的 Salesforce 記錄識別碼
外部對應 標準、自訂、外部 外部 外部識別碼標準欄位
間接對應 外部 標準、自訂 選取具有「外部識別碼」和「唯一」屬性的自訂欄位

Salesforce Connect—OData 2.0 與 4.0 轉接器的高資料量考量事項

如果您的組織在存取外部物件時達到比率限制,請考慮在相關聯的外部資料來源上選取「高資料量」選項。這麼做會略過大多數的比率限制,但有一些特殊行為與限制適用。如需詳細資訊,請參閱 Salesforce Connect 的 高資料量考量事項

Salesforce Connect—OData 2.0 與 4.0 轉接器的用戶端驅動與伺服器驅動分頁

Salesforce Connect 外部資料的查詢通常會有分成較小批次或頁面的大型結果集。您可決定要由外部系統 (伺服器驅動) 或由 Salesforce Connect 的 Odata 2.0 或 4.0 轉接器 (用戶端驅動) 控制分頁行為。外部資料來源的「伺服器驅動分頁」欄位會指定要使用用戶端驅動或伺服器驅動分頁。如果您在外部資料來源上啟用伺服器驅動分頁,Salesforce 會忽略要求的頁面大小,包括預設 queryMore() 批次大小為 500 列。外部系統傳回的頁面會決定批次,但每個頁面不能超過 2,000 列。不過,Salesforce Connect 的 Odata 轉接器限制仍適用。

範例

製造公司使用 Salesforce 來管理客戶個案。客戶服務工作人員想要從後端辦公室 ERP 系統存取即時訂單資訊,以取得客戶的全方位檢視,而無須在 ERP 中學習並手動執行報告。

實作此模式所指定的解決方案時,您應:

  • 使用 Odata 端點設定外部資料來源。您的遠端應用程式可能包含對 Odata 的原生支援。針對其他應用程式,主要整合廠商 (例如 Dell Boomi、Informatica、Jitterbit、MuleSoft 和 Progress Software) 已在 Salesforce Connect 上與 Salesforce 合作建立轉接器。
  • 直接或透過中介軟體解決方案,將 Salesforce Connect 指向 Odata 端點。
  • 將您的外部資料庫表格與 Salesforce 中的外部物件同步化。當使用者存取包含這些外部物件資料的頁面時,Salesforce Connect 會對後端應用程式進行即時呼叫。

開發人員文件

Trailhead

若要成為企業產品組合的有效成員,所有應用程式都必須建立並與相關的安全性機制整合。現代 IT 策略採用內部部署與雲端型服務的組合。

雖然整合雲端對雲端服務通常專注於 Web 服務和相關聯的授權,但連線內部部署和雲端服務通常會導致增加的複雜性。本節說明安全性工具、技術和 Salesforce 特定的考量事項。

反向 Proxy 伺服器

反向 Proxy 是位於 Web 伺服器前方的伺服器,並將用戶端 (例如網頁瀏覽器) 要求轉送至這些 Web 伺服器。反向 Proxy 通常會實作以協助提升安全性、效能和可靠性。

這是一種 Proxy 伺服器類型,代表一個用戶端從一或多個伺服器提取資源。這些資源接著會傳回至用戶端,就如同從 Proxy 伺服器本身來源一樣。不同於正向 Proxy,其為相關用戶端連絡任何伺服器的中介,反向 Proxy 是用戶端連絡其相關聯伺服器的中介。

在 Salesforce 實作中,此類服務通常會透過外部門戶產品提供。例如,可以使用開放原始碼選項,例如 Apache HTTP、lighttpd 和 nginix。商業產品包括 IBM WebSeal 和 Computer Associates SiteMinder。這些產品可以輕鬆設定為代表內部要求者 Proxy 並管理所有輸出 Salesforce 要求。

加密

某些企業需要選取的交易或資料欄位,才能在內部部署與雲端式應用程式的組合之間加密。如果您的組織必須遵循其他合規性需求,您可以實作替代方案,包括:

  • 內部部署的商業加密管道服務,包括 Salesforce 自己的、CipherCloud、IBM DataPower、Computer Associates。針對每個解決方案,透過傳送和接收加密裝載,或在執行 HTTP(S) 要求之前加密或解密特定資料欄位時,系統會在交易邊界叫用加密引擎。

  • 雲端型選項,例如 Salesforce Shield Platform Encryption。Shield Platform Encryption 為您的資料提供全新一層的安全性,同時保留重要的平台功能。您選取的資料會使用進階金鑰衍生系統靜態加密。您可以比以往更安全地保護資料。如需詳細資訊,請參閱 Salesforce 線上說明。

專業的 WS-* 通訊協定支援

為了滿足安全性通訊協定的需求 (例如 WS-*),我們建議這些替代項目。

  • Security/XML Gateway—將 WS-Security 認證 (IBM WebSeal 或 Datapower、Layer7、TIBCO 等) 插入至交易串流本身。此方法不需要變更應用程式層級 Web 服務或來自 Salesforce 的 Web 服務叫用。您也可以在整個 Salesforce 安裝中重複使用此方法。不過,它需要額外的設計、組態、測試和維護,才能將適當的 WS-Security 注入至現有的安全性門戶方法。

  • 傳輸層級加密—使用雙向 SSL 和 IP 限制來加密通訊管道。雖然此方法不會自行直接實作 WS-* 通訊協定,但會保護內部部署應用程式與 Salesforce 之間通訊管道的安全,而無須傳遞使用者名稱和密碼。也不需要變更 Salesforce 產生的類別。不過,可能需要某些內部部署 Web 服務修改 (應用程式本身或中介軟體/ESB 圖層)。

  • Salesforce 自訂開發—透過 WSDL2Apex 公用程式將 WS-Security 標題新增至輸出 SOAP 要求。這會從用於叫用內部服務的 WSDL 檔案產生類似 Java 的 Apex 類別。雖然此方法不需要對 DMZ 中的後端 Web 服務或其他元件進行變更,但需要:

    • 增加的建立和測試工作量
    • 手動編碼 WS-Security 屬性的相對複雜和手動流程 (包括 Apex 程式碼內的 XML 序列化)
    • 更高的長期維護工作量

備註:不建議使用最後一個選項,因為其複雜性以及此類整合需要根據 Salesforce 定期更新的定期檢閱的風險。

其他安全性考量事項

  • 已命名認證:為了保護並簡化對外部系統的已驗證 API 呼叫,已命名認證會在定義中指定呼叫端點的 URL 及其必要驗證參數。若要簡化您的 Apex 程式碼並簡化已驗證呼叫的設定,請指定已命名認證作為呼叫端點。如需詳細資料,請參閱 此處。

  • OAUTH 2.0 2.0 是業界標準的授權架構,允許使用者將其受保護資源的有限存取權授與第三方應用程式,而無須共用其認證 (例如密碼)。使用者不會直接交換密碼,而是批准存取權杖要求,應用程式接著會使用此權杖來從資源伺服器存取使用者的資料。此流程會將用戶端應用程式與使用者的身分與密碼分開,提供存取資源的暫時、範疇特定「金鑰」來增強安全性。如需詳細資訊,請參閱 此處。

  • 私人連線:當您將 Salesforce 組織與第三方雲端服務上主控的應用程式整合時,能夠安全地傳送和接收 HTTP/s 流量十分重要。透過私人連線,透過設定 Salesforce 組織與 AWS Virtual Private Cloud (VPC) 之間的完整受管理網路連線,來提高 Amazon Web Services (AWS) 整合的安全性。接著,透過連線而非透過公用網際網路路由您的跨雲端流量,以降低外部安全性威脅的暴露。私人連線可透過稱為 AWS PrivateLink 的功能與 AWS 合作。「私人連線」為雙向:您可以起始輸入與輸出流量。透過輸入連線,您可以使用標準 API 將流量傳送至 Salesforce。透過輸出連線,您可以透過如 Apex 呼叫、外部服務和外部物件等功能,將流量傳送至 Salesforce。如需 VPC 的詳細資訊,請參閱 此處。

Salesforce Event Bus 搭配 Platform Events、Change 資料擷取 (CDC) 和 Pub/Sub API 可讓企業建立以事件為導向的樣式結構 (EDA)。

EDA 會將事件訊息取用者 (訂閱者) 與事件訊息產生者 (發行者) 分離,讓規模與彈性更大。此文件涵蓋特定模式,作為比較和對比相關替代項目或選項的現有模式結構的一部分。不過,取得事件驅動結構的整體瞭解,以及模式如何互動,可協助您選取符合您需求的正確模式。

Khalid Mohammed 是 Salesforce 專業服務的傑出結構設計師領導者。自從 2015 年加入 Salesforce 後,他利用企業應用程式和結構方面的豐富專業知識,在 Salesforce 任職前經過許多客戶轉型。Khalid 負責交付結構委員會,並且獲認可為認證技術結構設計師領導者。

Gulal Kumar 是 Salesforce 的「軟體工程結構設計師」,專注於資料與整合結構。他在整合和 API、現代化計畫、安全性和 AIML 計畫方面擁有超過 20 年的經驗,提供豐富的專業知識。Gulal 一直致力於推進業務轉型計畫、增強安全性和彈性、促進傑出結構,並領導跨各種網域的 AIML 計畫。

Sushant 是 Salesforce 的技術結構設計師,專門處理 Salesforce 平台的解決方案結構和端對端傳遞。他在平台管理、應用程式開發、整合和 DevOps 方面擁有豐富的專業知識,曾領導跨產業的許多客戶轉換計畫。Sushant 致力於促進卓越傳遞和可調整的結構成果。