# architect 決策指南 (decision-guides) - Full Documentation ## 概觀 企業通常會將資料儲存在 Salesforce 和其他外部資料湖中,例如 Snowflake、Google BigQuery、Databricks、Redshift 或雲端儲存空間,例如 Amazon S3。在不同來源系統中將資料分隔,對於想要充分利用資料功能的公司來說,這是一個挑戰。 處理整合多個資料湖之間資料的結構設計師會面對關於如何最佳整合該資料的重要結構決策。Data 360 提供多個資料整合選項,每個選項都有不同的優點與缺點。 本指南提供評估哪個模式最適合您在整合資料時的延遲、成本、可擴展性、管治和複雜性需求的架構,協助您選擇何時使用資料提取、零複製資料聯合或混合式方法。此指南也會協助您在不同方法之間進行選取,這些方法皆滿足不同的需求。 將外部資料湖集與 Data 360 整合需要仔細考量資料新鮮度、管治與管道效率之間的權衡。例如,使用「零複製」資料聯合即時查詢可將資料的最新度最大化,但在您在網路上移動更多資料時,可能會降低銷售管道效率。因此,針對大多數的實作,在多雲湖區生態系統中結合取用與聯合是最佳的路徑。此混合式方法可確保可調整、受管理、可互通的結構,可順暢地支援低延遲的作業工作量,例如即時個人化和詐騙偵測,以及分析工作量,例如法規報告和歷程記錄趨勢分析。此決策指南將協助您瞭解如何瀏覽這些權衡,並選取正確的策略。 ## 接待時間 - **Data Caption:**將資料複製到 Salesforce Data 360,建立受管理的標準資料模型。需要執行以下動作時的理想選擇: - **建立全方位的 Customer 360:**將不同的來源統一並轉換為單一信任的設定檔。 - **符合嚴格的法規規範:**建立可稽核的集中複本,可在其中密切控制資料存取與歷程。 - **零複製聯合:**即時查詢外部來源,無須重複,並啟用即時個人化、即時顯示面板和快速來源上線。有兩個主要選項,其中包含您必須平衡的權衡: - **即時與快取 (加速查詢):**適用於外部資料平台 (例如 Snowflake、Google BigQuery、Redshift 或 Databricks) 中資料的互動式分析和即時顯示面板。將處理推送至來源系統,以避免資料重複的速度變慢且成本高。 - **檔案聯合:**最適用於在雲端資料湖中對資料進行的大規模批次處理和 AI 模型訓練 (S3、ADLS)。透過直接以開放式表格格式查詢檔案,以解除鎖定 ETL 和資料科學工作負載的大量資料集,以避免成本高昂且速度緩慢的取用。 - **混合型號:**使用聯合功能來混合「統一設定檔」採取,以獲得最新效果、支援 Omni-Channel 參與、Agentforce 驅動的動作和 AI/ML 訓練。 ### 重要考量事項 - **混合結構:**經常需要混合資料採取和資料聯合。 - 針對標準資料模型和核心管理,在重要資料上使用「資料取用」。 - 透過「零複製」將所有其他資料聯合,以將建立和維護取用資料銷售管道的作業負擔降到最低。 - **Data Capture Frequency Matters:**根據業務價值、延遲需求和營運複雜度選擇頻率。 - 針對具有時效性的工作流程 (個人化、即時顯示面板、Agentforce 動作) 使用即時。 - 適用於中度緊急流程 (行銷活動、營運報告) 的近乎即時。 - 歷程記錄或低速資料集的批次。 - **將聯合模式與延遲與效能比對:**選擇最符合您存取模式以及更新性、效能與成本需求的資源。 - 將「即時查詢」用於低延遲十分重要的作業顯示面板和即時個人化。 - 當查詢頻繁但略有延遲的結果可接受時,請使用快取 (加速查詢),以平衡效能與成本。 - 將檔案聯合用於大規模、輸送量繁重的分析或批次工作負載,其非常適用於歷史或較不敏感的時間資料集。 - **使管治與資料落地需求保持一致:** - 在集中化監管十分重要時,請使用採取。 - 在接受去中心化監管的情況下使用聯合,同時在外部來源強制執行嚴格監管。「零複製」遵循如列層級安全性 (RLS) 和資料遮蔽等來源層級原則。 - **為高價值工作流程排定取用優先順序:**選擇性地套用至重要流程,例如身分解析、監管報告和作業啟用。 - **成本與複雜性驅動決策:**即時採取可能高成本且複雜。結構設計師應將上線、儲存和轉換資料的成本與直接透過零複製查詢資料的成本加權。 選擇正確的整合模式 (「資料」、「零複製」或「混合式」方法) 會直接影響多重雲端平台的延遲、管治、營運效率和成本。此決策會決定如何可靠且大規模地提供即時洞察、AI 驅動的啟用和個人化參與。 ## 產品比較 此表格提供 Salesforce Data 360 中「資料取用」與「零複製」模式的技術比較,專注於功能、權衡和優點,以及企業使用個案和成果。結構設計師可以使用此作為設計混合式多雲端資料平台的參考,以平衡效能、成本和合規性。
模式類型 模式/工具 益處 考量事項 成果
資料取用 即時:透過具有 CDC 支援的「取用 API」進行子秒延遲。連續串流銷售管道。 - 立即洞察
- 適用於低延遲作業和個人化使用個案的理想選擇
- 支援以事件為導向的工作流程		 - 高成本
- 複雜結構
- 需要低延遲來源系統
- 大量來源會造成過度串流導致飽和的銷售管道
- I/O 密集
- 考慮選擇性欄位和篩選條件以減少超額		 Agentforce:
- 即時詐騙警示、零售個人化、營運警示
Analytics:
- 子秒顯示面板、KPI 監視
合規性:
- 持續更新受監管工作流程的客戶記錄
串流: 透過原生連接器每 1–3 分鐘進行一次微批次採取 - 平衡成本與新鮮度
- 比即時更簡單的結構
- 支援增量更新		 - 輕微延遲
- 可能不適用於重要子秒決策
- 批次大小會影響記憶體/計算
- I/O 為中度
- 最適用於可預測的重複更新模式
- 考慮視窗彙總以減少處理負載		 Agentforce:
- 及時的行銷活動觸發、近乎即時的參與
Analytics:
- 建議引擎、近乎即時的顯示面板
合規性:
- 含稽核性的頻繁更新
批次:透過連接器或 API 排程大量載入。支援物件儲存和 ETL/ELT 銷售管道。 - 大量資料集的成本效益
- 易於實作
- 可靠的歷程記錄分析		 - 資料延遲
- 不適用於時效操作
- 載入期間的 I/O 密集
- 網路輸送量可能會成為大型檔案的瓶頸
- 最適用於歷程記錄彙總或監管報告工作流程		 Agentforce:
- 資訊支援票證 (Jira/ServiceNow),彙總工作流程
Analytics:
- 歷程記錄分析、趨勢評估
抱怨:
- 法規報告、病患/索賠資料彙總
零複製 即時查詢:對外部系統進行直接查詢;結構描述即讀;無資料重複 - 最大新鮮度
- 儲存空間負擔率最小;支援即時營運洞察		 - 相依於來源效能
- 高查詢量可能會影響延遲
- 適用於具有述詞推送和彙總以將 I/O 最小化查詢的理想選擇
- 避免對大量資料集進行未篩選的查詢		 Agentforce:
- 適應即時活動的動態工作流程
Analytics:
- 作業顯示面板、即時報告
合規性:
- 遵循來源的列層級安全性與遮蔽
加速查詢 (快取): 聯合查詢的快取本機複本。可設定 15 分鐘到 7 天。最佳化查詢執行 - 減少延遲
- 比重複即時查詢的成本更低
- 改善頻繁存取模式的效能		 - 需要快取管理
- 延遲時間取決於快取間隔
- 最適用於高頻率查詢
- 不適用於次要決策		 Agentforce:
- 用於快速決策的預先彙總參與度量
Analytics:
- BI 顯示面板、區隔、分析報告
合規性:
- 具有稽核記錄的一致監管顯示面板
檔案聯合:直接存取物件存放區或湖中大型歷史資料集 (S3、Iceberg、Google BigQuery、Redshift)。 - 處理大規模資料集
- Data 360 中的儲存空間下限
- 支援 AI/ML 工作量		 - 唯讀
- 查詢效能取決於外部系統輸送量
- 針對批次繁重、輸送量密集型工作最佳化
- 不適用於即時顯示面板		 Agentforce:
- (非典型 — 批次繁重)
Analytics:
- ML/AI 訓練、歷程記錄分析、Peta 位元的規模報告
合規性:
- 無重複的外部資料集受管理存取權
## Data 360 整合模式 ### 資料匯入 若要使用資料取用,則資料會實際複製到 Data 360 並完全受管理,與資料保留在來源的「零複製」不同。在 Data 360 內進行轉換的計算,進而允許集中管理和稽核。 #### 資料取用個案 在 Salesforce Data 360 中使用資料取用來儲存標準、受管理的資料集,以達成合規性和作業控制。當需要完整控制、稽核和可追溯性時,請使用採取。適用於監管或高價值的工作流程,其中集中運算與管治十分重要。 在建立身分解析、監管報告、任務關鍵 AI 驅動工作流程和客戶參與的信任基礎上,最適合使用「採取」。 資料取用概觀 #### 資料取用方法 系統會根據您使用的連接器,用來取用資料。某些連接器提供各式各樣的方法,而其他連接器僅在批次或串流模式中運作。請參閱 [Data 360:Data 360 連接器及其可用方法的完整清單的整合和連接器](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5)。 - **即時** - 使用串流管道或 Change 資料擷取 (CDC) 進行子秒取用。 - 最適用於具有時效性的工作流程 (詐騙偵測、個人化、作業顯示面板)。 - 在 Data 360 內推送轉換和彙總,以減少下游 I/O 並最佳化運算用量。使用增量 CDC 將資料混亂降到最低。 - **串流** - 每 1–3 分鐘以小量增量排列。 - 平衡最新與成本,適用於行銷活動協調流程、近乎即時的參與和作業報告。 - 使用微批次控制 I/O 峰值。盡可能彙總來源的資料,以減少傳輸量並最佳化儲存空間。 - **批次 (已排程載入)** - 大型資料集 (每小時、每日、每週) 會定期採取。 - 針對歷程記錄資料集、法規報告和合規性使用個案,具有成本效益且可靠性。 - 確保在與來源儲存空間相同的區域中計算地區設定,以達到效能與成本最佳化。 #### 結構設計師手冊 - **使用個案取得資料** - **產生 Customer 360 統一設定檔:**建立客戶身分與屬性的單一事實來源。 - **維護法規合規性資料集:**強制執行敏感資料的監管、歷程和稽核能力。 - **集中行銷活動協調流程:**確保行銷、銷售和服務皆可從一致且信任的資料集中作業。 - **設計作法** - 針對歷程記錄或低延遲容忍的需求 (例如歸檔報告或定期快照) 偏好採取批次。 - 使用 CDC 或串流 API 來維持作業與個人化工作流程的最新狀態,確保近乎即時更新。 - 透過套用增量負載 (而非重新載入整個資料集),以最佳化成本和效率來控制儲存和運算成長。 - 透過運算本地性和增量處理來讓取用管道保持一致,以減少網路 I/O。在 Data 360 內套用轉換,以避免不必要地移動原始資料。 - **成本考量事項** - **即時提取:**計算和管道成本最高;對於高價值且具時間敏感性的工作流程 (例如個人化、作業顯示面板或 Agentforce 驅動的動作) 而言是正確的。 - **串流吸收:**仲裁運算和儲存成本;適用於經常更新,可容忍輕微延遲,例如行銷活動協調流程或營運報告。 - **批次接收:**較低的運算成本、可預測的儲存空間;適用於歷程記錄資料集或低頻率更新。使用特定連接器可免費從 Salesforce 組織中取用批次資料。 - **重新整理模式:**選取「增量重新整理」模式可減少整體耗用和計算成本。我們建議盡可能使用增量重新整理,以最佳化所有採取類型的效率。 - 成本也會受到來源至 Data 360 的 I/O 量影響。最佳化批次大小、分割和區域對齊方式可降低傳輸成本並改善效能。 - **行業案例** - **財務:**瞭解客戶 (KYC)、防洗錢 (AML) 和詐騙偵測所需的資料集,其中可稽核性與合規性是無法協商的。 - **醫療照護:**針對病患身分解析和 HIPAA 規範的記錄,針對取用,啟用安全且統一的檢視。 - **零售:**將銷售點 (POS)、電子商務和忠誠度計畫資料合併至統一設定檔以進行區隔和個人化 - **電信:**使用標準、受管理的訂閱者資料支援流失預防和使用量分析。 #### 資料取用方法決策條件
功能 即時快取 串流捕取 批次提取
延遲與新鮮度 透過具有 Change 資料擷取 (CDC) 支援的「取用 API」來進行子秒延遲。提供連續串流管道。最適用於低延遲作業使用個案。 每 1–3 分鐘透過原生連接器進行每個 1–3 個批次的採取。支援增量更新。預期略有延遲。 預期資料延遲。已排程大量載入。定期攝取 (每小時、每日、每週)。不適用於具有時效性的作業。
主要使用個案 適用於低延遲作業和個人化使用個案的理想選擇。用於具有時效性的工作流程。支援以事件為導向的工作流程。用於即時詐騙警示和作業警示。 適用於中度緊急的程序。用於行銷活動協調流程、近乎即時的參與和作業報告。用於及時觸發行銷活動。 針對大量資料集具有成本效益。可靠以進行歷程記錄分析。用於歷程記錄彙總或監管報告工作流程。最適用於歷程記錄或低速資料集。
結構複雜性和 I/O 高成本且複雜的結構。需要低延遲來源系統。I/O 密集。大量來源會造成飽和的銷售管道。 比即時更簡單的結構。I/O 為中。最適用於可預測的重複更新模式。批次大小會影響記憶體/計算。 實作簡單。載入期間的 I/O 密集。網路輸送量可能會成為大型批次的瓶頸。
成本考量事項 計算和管道成本最高。僅適用於高價值且具有時效性的工作流程。 仲裁計算和儲存成本。提供平衡成本與新鮮性的方法。適用於可承受輕微延遲的頻繁更新。 計算成本和可預測的儲存空間降低。建議用於歷程記錄資料集或低頻率更新。透過 Salesforce 內部銷售管道可免費使用。
設計作法 使用增量 CDC 將資料混亂降到最低。篩選並使用選擇性欄位來減少超額。 使用微批次控制 I/O 峰值。請考慮使用視窗彙總來減少處理量。 將此項目加入歸檔報告或定期快照。確定在與來源儲存空間相同的區域中計算地區設定,以最佳化成本。
### 零複製資料聯合 #### 零複製使用個案 使用「零複製」來即時查詢外部系統,而無須資料重複,以啟用大型或暫時資料集的靈活性、新鮮性和可調整存取權。最適用於即時顯示面板、探索分析、AI/ML 模型訓練,以及直接透過 Salesforce Data 360 進行即時客戶參與。 零複製資料聯合概觀 #### 零複製方法 使用「零複製」時,結構設計師必須在三個可用的資料聯合方法之間進一步決定,每個方法都會在更新性、效能和成本之間提供自己的權衡。 - **即時查詢** - 直接針對外部系統 (Snowflake、Google BigQuery、Redshift、Databricks 等) 執行查詢,而不會重複資料。 - 當可向下推送述詞和彙總時最佳化,可將資料在網路上的移動降到最低,並降低 Salesforce Data 360 計算上的 I/O。 - 最適用於即時洞察和低延遲作業顯示面板。取決於外部系統的效能。 - **快取 (加速查詢)** - 在 Salesforce Data 360 中暫時儲存聯合資料的快取複本。 - 透過可設定的持續時間 (分鐘到天) 來減少經常存取資料集的重複查詢成本和延遲。 - 系統不會永久複製或完全管理資料;系統會透過來源的排程重新整理來管理最新狀態。 - **檔案聯合** - 提供物件存放區中大規模資料集的直接唯讀存取權 (例如 S3、GCS with Iceberg)。 - 最適用於 AI/ML 工作負載、歷程記錄分析和 petabyte 規模報告,而無須移動資料。 - 查詢效能取決於物件格式、分割和網路 I/O。若未最佳化,大型掃描可能會產生大量的 I/O。 #### 結構設計師手冊 - **使用個案** - **即時個人化與自適應工作流程:**隨著客戶行為變更,提供動態優惠、建議和 Next Best Action。 - **即時顯示面板與作業分析:**直接從外部倉庫強化業務關鍵的顯示面板和 KPI。 - **使用大型外部資料集進行 AI/ML 模型訓練:**使用檔案聯合,無須移動即可利用資料湖和倉庫的 petabyte 級資料。 - **行業案例** - **零售/媒體:**透過聯合點閱串流或內容互動資料來啟用個人化建議和即時客戶參與。 - **財務:**透過查詢外部倉庫,而不重複敏感資料,以近乎即時執行詐騙偵測和風險評分。 - **技術/企業:**支援跨雲端報告、IT 服務顯示面板和作業分析,其中資料集位於多個系統中。 - **設計作法** - **即時查詢** - 當新鮮度十分重要時,用於高 QPS、低延遲的查詢。 - 將述詞和彙總推送至外部系統,以減少網路上的資料混亂。 - 避免進行不必要掃描大量資料的查詢;請考慮裁切分割與篩選。 - **檔案聯合** - 在物件存放區中存取 petabyte 級資料集,而無須取用。 - 將物件儲存空間保持在與 Salesforce 計算相同的雲端區域中,以將延遲和輸出成本降到最低。 - 使用分割的資料欄格式 (Parquet/ORC) 和推送式篩選條件來減少 I/O 和網路傳輸。 - 利用查詢和述詞推送功能來篩選和彙總來源的資料,減少資料移動。 - 除非有必要,否則請避免跨區域資料存取,因為這會增加 I/O、延遲和成本。 - **快取 (加速查詢)** - 快取經常存取的資料集以平衡成本與效能。 - 設定重新整理間隔以平衡更新與查詢成本。 - **合規性:**透過利用列層級安全性 (RLS) 並直接在聯邦系統內遮蔽原則,強制執行來源管理。以下是統一 RLS 和跨平台遮蔽的最佳作法。 - **使用集中化企業識別碼:**將 Salesforce Data 360 中的使用者與實體對應至與外部系統中身分對應的唯一集中企業識別碼。 - **Align 安全性原則:**確保聯合系統中根據對應的身分套用列層級安全性與遮蔽原則。這可在查詢外部資料時保留合規性。 - **標準化身分結構描述:**在所有資料來源之間維護一致的身分屬性 (電子郵件、使用者識別碼、客戶識別碼等),以避免不相符和存取違規。 - **成本考量事項** - **即時查詢:**每查詢付費模型—在外部湖家計算中產生的成本,且可以高 QPS 激增。最適用於價值大於成本變異性的清新度關鍵使用個案。 - **加速查詢 (快取):**透過減少對來源系統的點擊次數,降低查詢成本 (相較於 Live Query),但會增加填入和重新整理快取的批次資料取用成本。最適用於經常存取的資料集。 - **檔案聯合:**「物件商店」中資料的最便宜儲存選項,但查詢成本取決於檔案大小、分割和裁切。最適用於 Petabyte 級的歷程記錄或大量資料。 #### 零複製方法決策條件
決策點 即時查詢 快取 (加速查詢) 檔案聯合
資料來源位置 外部資料湖 (Snowflake、Google BigQuery、Redshift、Databricks)。 外部資料湖 (Snowflake、Google BigQuery、Redshift、Databricks) 物件存放區或雲端資料湖 (S3、ADLS、GCS),通常使用如 Iceberg 等開放式表格格式。
用途/使用個案 互動式分析與即時顯示面板的理想選擇。最適用於即時個人化和動態工作流程。 最適用於查詢頻繁但略過時的結果可接受時。適用於 BI 顯示面板與區段。 最適用於大規模批次處理和 AI/ML 模型訓練。適用於歷程記錄分析和 petabyte 級報告。
新鮮度/延遲性 最新度最大;查詢會直接即時執行。支援次要決策。 可接受略過時的結果。更新性取決於快取間隔,可設定為 15 分鐘到 7 天。 針對批次繁重、輸送量密集型工作最佳化。不適用於即時顯示面板。
存取模式 適用於不常見或臨時查詢。用於高 QPS (每秒查詢)、低延遲查詢,其中重新整理十分重要。 最適用於高頻率讀取情況。改善頻繁存取模式的效能。 唯讀存取權。適用於不需要採取的 petabyte 級資料集。
效能驅動因素 高度依賴外部來源系統的效能。當可將述詞和彙總向下推送至來源時,已最佳化。 與重複的即時查詢相比,減少延遲。效能取決於快取管理和間隔。 效能取決於物件格式、分割和外部系統輸送量。使用分割的資料欄格式 (Parquet/ORC)。
成本影響 每查詢付款模式。外部湖家計算產生的成本。對於不常見的查詢而言,成本效益高,但成本可能會因每秒高查詢量 (QPS) 量而高峰。 比重複即時查詢的成本更低。減少重複查詢外部來源的需求。新增快取儲存空間和重新整理負擔。 最便宜的儲存空間選項。查詢成本取決於檔案大小與分割。
重要考量事項 避免未經篩選的查詢不必要地掃描大量資料。 需要快取管理。不適用於次要決策。 查詢效能主要依賴透過分割和述詞推送功能表進行最佳化。
### 混合式方法 混合式結構可讓結構設計師將重要資料集固定在 Data 360 中,以進行集中管理,同時運用聯合查詢以獲得最新狀態、減少重複,並可擴充存取大型外部資料集。此方法會平衡 I/O、計算地區設定、成本和合規性需求。 #### 混合式使用個案 使用混合式方法來結合資料取用和零複製,以提供即時且可採取動作的洞察,以達到平衡的管治、新鮮性和營運效率。針對需要可追蹤性、RLS 和遮蔽的高價值、受監管的資料集,並針對最新性和效能為關鍵的暫時或大量資料集使用同盟。 混合式方法概觀 #### 結構設計師手冊 - **使用個案** - **Omni-Channel 參與:**將歷程記錄客戶資料與即時行為混合在一起,以提供一致且感知內容的體驗。 - **AI/ML 銷售管道:**針對精密設計的標準資料集訓練模型,同時使用來自外部來源的原始或即時訊號來增強模型。 - **混合合規性和靈活性需求:**對敏感資料套用嚴格的監管,但聯合以獲得營運靈活性。 - **行業案例** - **零售:**針對身分解析與設定檔統一,請使用採取;針對即時優惠與個人化,請使用聯合。 - **醫療照護:**透過採取來維護金級病患記錄,同時聯合 IoT 裝置串流和感應器資料以取得立即內容。 - **金融服務:**將受監管的資料匯入合規管理湖,同時聯合外部查詢以進行詐騙偵測和風險監視。 - **設計作法** - ** 含採取的節點管理:**將高價值或受監管的資料匯入標準模型,以確保 Trust 與合規性。 - **使用聯合提升新鮮度:**讓外部湖舍提供即時或大規模的資料存取,而不會重複。 - **餘額成本與績效:**設定檔工作量以決定要採取的項目與聯合的項目,以將不必要的儲存空間或查詢成本降到最低。 - **套用階層管理:**強制執行集中化管治,同時利用聯邦系統自己的安全性控制 (例如 RLS、遮蔽)。 - 設計混合式銷售管道時,請確保對歷程記錄資料集進行增量式採取,並將彙總或篩選推送至聯合來源,以最佳化 I/O 和運算用量。 - **成本考量事項** - 將合規性或關鍵資料與必要時的同盟結合,以最佳化總成本與效能。 - 當混合採取和聯合時,考量 I/O 和計算散佈。若要減少重複查詢來源系統中的運算成本,請針對高讀取率且經常存取的聯合資料集使用快取 (加速查詢)。 ## 使用個案決策指南 以下是常見的原型,說明如何套用此邏輯。 1. **「單一事實來源」架構類型:集中與控管** - **案例:**您需要為整個全球企業建立合規性的統一 Customer 360 設定檔。資料來自十幾個不同的系統,必須遵循嚴格的 GDPR 和 CCPA 法規,並且會作為所有行銷和服務互動的信任來源。 - **建議模式:****Data Capture.**優先順序為監管、Trust 和控制。在 Data 360 中將資料提取是建立可完全稽核且與來源系統隔離的標準設定檔的唯一方法。 2. **「即時洞察」架構類型:不移動分析** - **案例:**您的資料科學小組需要對 Snowflake 中大量且不斷更新的交易表格執行探索查詢。同時,您的管理小組想要由相同資料提供的即時 BI 顯示面板。每天移動 petabyte 的資料速度太慢且成本太高。 - **建議模式:****零複製聯邦.**優先順序為速度、靈活性和大規模成本效益。「零複製」可讓您利用現有資料倉庫的強大功能來進行即時查詢,而不會造成資料重複的負擔和延遲。 3. **「混合智慧」架構類型:管理核心、聯合邊緣** - **案例:**您想要使用來自資料湖的即時行為訊號 (例如點擊網站) 來增強受管理且已採取的客戶設定檔。您需要核心設定檔的穩定性,但需要即時資料的立即性才能提供即時個人化功能。 - **建議模式:****混合式方法。**使用「資料取用」建立客戶資料的穩定、受管理核心。接著使用「零複製」將波動式即時「邊緣」資料聯合在一起,並在查詢時間聯結,以取得完整且即時的檢視。 ## 前進路徑 企業資料策略不再是關於選擇單一整合模式,而是關於在可互通資料生態系統內架構受控制的彈性。根據業務需求為每個來源資料系統選取正確的資料整合方法,通常會導致混合式方法,結合資料取用和資料聯合的優勢。 - 將任務關鍵且受管理的資料集用於合規性、身分解析和營運工作流程,以便在 Salesforce Data 360 中移入。 - 透過「零複製」聯合資料,以進行即時、探索性和 AI 驅動的分析,而無須重複儲存空間。 Hyperforce 上的 Salesforce Data 360 提供多區域彈性與延展性。具有 Iceberg 表格的 open lakehouse 可與 Snowflake、Databricks 和 S3 Iceberg 等平台進行運算分隔和互通,形成真正可互通的多雲資料生態系統的基礎。 隨著資料生態系統的發展,會持續平衡新鮮度、成本、效能和合規性,以維持結構靈活性。透過使用聯合存取權來統一獲取的受管理資料,讓您的平台有未來考量。這可在雲端、區域和業務網域之間啟用即時情報、AI 啟用和企業規模個人化。 一體適合所有解決方案不適合大多數企業。最佳策略會將正確的模式對應至正確的業務驅動因素。 ## 關於作者 Yugandhar Bora 是 Salesforce 的「軟體工程結構設計師」,專門在「資料與情報應用程式」平台內進行資料結構。他負責領導企業結構審查委員會 (EARB) 計畫,專注於資料管理和統一資料模型,同時為自動平台佈建解決方案做出貢獻。 Jan Fernando 是 Salesforce 首席結構設計師辦公室的首席結構設計師。他於 2012 年加入 Salesforce,從入門生態系統中獲得豐富的經驗。在加入首席結構設計師辦公室之前,他在平台組織中花費了十多年的時間,在該組織領導了數項關鍵技術轉型。 ## 概觀 Salesforce Data 360 是以 Hyperforce 為基礎建立的資料平台,可將 Salesforce 和外部資料統一為每個客戶或帳戶的全方位清晰、完整且值得信賴的檢視。 由於合併和收購、區域營運、功能性分隔或歷史原因,企業經常經營多個 Salesforce 組織。結構設計師不僅必須決定單一「首頁組織」與多組織組態之間,還必須決定是否要佈建多個獨立 Data 360 例項、使用 Data Cloud One 統一單一例項下的組織,或使用 Data 360 之間的資料共用 (Data 360 至 Data 360 資料共用) 協同合作獨立 Data 360 例項之間。這些選擇會影響監管、合規性、成本、延遲,以及組織調整 AI 和跨組織平台功能的能力。 Data 360 會在收到 Data 360 授權的任何生產組織上自動佈建。Data Cloud One 是 Salesforce 的多組織連線結構,允許單一「首頁組織」主控 Data 360 例項,而其他 Salesforce 組織連線為「伴侶組織」。選擇哪個組織擁有 Data 360 授權,進而成為 Data 360 首頁組織,是具有長期後果的關鍵結構性決定。 您佈建 Salesforce Data 360 的方式是一個基本的結構決策,因為這會決定企業如何統一客戶資料、強制執行管治,並在整個組織中啟用關鍵平台功能,特別是 AI、Agentforce 和分析。將組織叢集固定至單一 Data 360 可提供統一的資料模型、集中管理和企業範圍 AI 整備,同時讓「伴侶組織」能夠存取共用中繼資料與功能,如同資料在本機一樣。相反地,當法規、規範或自治需求阻止集中化時,多個獨立 Data 360 例項適合,而 Data 360 組織之間的「資料共用」可在這些例項之間啟用選擇性、零複製協同合作。 針對結構設計師,此決策十分重要。它會定義控制資料管理的人員、資料所在位置、平台功能的啟用方式,以及未來整合和 AI 倡議如何順利擴展。即使是目前沒有 Data 360 的組織,透過開發策略來在未來新增 Data 360 存取權,來為您的結構進行未來的驗證也十分重要。Salesforce 在 Sales、Service、Marketing、Commerce、Industry 和 Agentforce 之間的功能會越來越以 Data 360 為基礎。想要使用這些平台功能的組織必須佈建自己的 Data 360,或連線至共用的 Data 360 作為伴隨組織。 此指南可協助結構設計師設計佈建策略,以平衡簡單性、企業範圍的一致性、合規性與可擴展性,確保組織可以自信地為 Customer 360、AI 和跨平台創新運用 Data 360。這可協助您決定如何選取要佈建 Data 360 的組織,以及如何在 Data 360 組織之間選擇 Data Cloud One 和 Data 360 組織之間的資料共用,協助您奠定堅實的基礎,將業務推向以 Data 360 為中心的未來。 --- ## 佈建考量事項 每個佈建選項 (無論是選擇 Data Cloud One 和 Data 360 組織之間的資料共用,或是將哪個組織指定為「首頁組織」) 都應根據下列跨部門考量事項進行評估:
考量事項 重要原因 範例案例
資料落地與合規性 決定儲存與處理資料的位置。法規規則可能需要特定的區域或多個例項。 一個全球銀行在位於法蘭克福的 Salesforce 組織上提供 Data 360 租戶,以達成 GDPR 規範,並在維吉尼亞州的組織上為其美國部門提供另一個租戶。
管治與安全性 誰擁有及管理 Data 360?保單是否應集中管理,或由每個業務單位委派? 具有強大中央 IT 的跨國公司建立由傑出中心管理的專屬「居家組織」。
自動與集中化 不同的主管可能想要資料的個別擁有權。自動化偏好多個 Data 360;集中化偏好 Data Cloud One。 具有獨立子公司的控股公司可讓每個 BU 執行自己的 Data 360。
延遲與效能 影響查詢速度與體驗,特別是跨區域連線至 Data 360 租戶的「伴隨組織」。 倫敦的銷售小組查詢來自美國 Data 360 租戶的資料可能會看到較高的延遲。
整合複雜性 更多 Data 360 租戶 = 更多管道、API 和中介軟體。合併可簡化整合。 經銷商透過合併至 Data Cloud One 組態,避免建立 10 個 ETL 管道。
零複製資料來源區域 Zero Copy 連接器可能具有跨區域存取需求,可限制 Data 360 可位於哪個區域。 一家公司在 AWS eu-west-1 區域中有 Snowflake 例項。他們可以使用「零複製」將資料聯結至其區域中的 Data 360,但無法使用「零複製」聯結至美國區域中的 Data 360。
私人連線跨區域相容性 在某些情況下,私人連線支援取決於資料來源是否位於與 Data 360 租戶相同的區域。 一家公司在其想要透過零複本連線的 aws-east-1 區域中擁有 Snowflake 例項。只有在 Data 360 首頁組織位於相同區域時,他們才能建立「私人連線」網路連線。
成本與授權 每個 Data 360 租戶都會增加成本。合併至較少的例項可最佳化支出。 醫療照護提供者透過採用 Data Cloud One 而非多個獨立 Data 360 例項來減少授權成本。
未來延展性 今天佈建的選擇為成長奠定基礎。 SaaS 公司從單一 Data 360 例項開始,但計畫在購買 Salesforce 組織的子公司時擴展至 Data Cloud One。
企業範圍 AI 整備 AI 功能和 Agentforce 在每個組織中都需要連線的 Data 360 租戶。佈建決策會影響 AI 模型在整個企業中訓練和啟用的方式。 一家金融服務公司在 Data Cloud One 中統一資料,讓其 Einstein AI 模型能夠存取企業範圍的客戶資料。
### 重要考量事項 --- ## 區段 1:佈建 Data 360 – 選擇主要組織 ### 1.1 什麼是 Data 360 首頁組織? 當您購買 Data 360 授權時,Data 360 例項會佈建在與該授權相關聯的 Salesforce 組織中。此組織稱為 Data 360 首頁組織。 顯示 Data 360 首頁組織的決策圖 「首頁組織」是您 Data 360 例項的安克圖。這是下列位置: - 系統會管理 Data 360 儲存和計算 (在佈建時選取的區域中)。 - 套用管理、管治和安全性原則。 - 系統會執行資料取用、調和、身分解析、區隔和啟用。 在多組織案例中,首頁組織會管理其他 Salesforce「伴侶」組織的中心 Data 360 例項。 首頁組織為何重要: - 它會決定 Data 360 例項的地理位置。 - 它會決定擁有與管理 Data 360 例項的人員。「Data 360 首頁組織」中的管理員可以存取在「Data 360」中採取的所有資料。 - 它會控制 Data Cloud One 組態中的「伴隨組織」連線。 - 這會為您的企業資料策略奠定基礎,稍後變更會很困難且具有破壞性。 ### 1.2 決策:現有組織或新組織作為主要組織? 第一個重大決定是要在現有生產組織中佈建 Data 360 還是建立新的專屬組織作為「首頁組織」。 將現有組織與新組織顯示為主要組織的決策圖 #### 選項 A:在現有組織中佈建 Data 360 **最適用於:**具有單一 Salesforce 組織的客戶,或已擁有大多數業務執行所在主要集中組織的多組織客戶。 顯示現有組織中 Data 360 佈建的圖表 - **優點**: - 最簡單的路徑:Data 360 會佈建在 CRM 資料已存在的位置。 - 立即存取本機「銷售」、「服務」和「行銷」資料。 - 不需要額外的整合。 - 管理的授權與環境愈少。 - 加速提早採用、試用版和生產使用個案。 - **缺點**: - 可繼承現有組織的監管或技術債務。 - 如果沒有單一「主要組織」,則選取一個「主要組織」可能會產生擁有權討論。 - 與組織位置繫結的績效;可能與企業範圍的落地需求不相符。 - 如果多個業務單位使用不同的組織,如果未與 Data Cloud One 配對,則本機佈建可能會導致分割。 **範例:** 具有一個 Salesforce 組織的 SaaS 公司會在該組織中佈建 Data 360,以統一客戶訂閱與支援資料。 #### 選項 B:在新的專用組織中佈建 Data 360 **最適用於:**擁有多個 Salesforce 組織且無法符合單一主要組織的客戶,或擁有強大「傑出中心」(CoE) 模式的企業。 顯示新專屬組織中 Data 360 佈建的圖表 - **優點**: - 管理的清除圖表,沒有繼承的組織複雜性。 - 集中控制多個行業。 - 根據合規性需求彈性選擇區域。 - 作為中立的「共用服務」組織,不與一個業務單位繫結。 - 針對未來 Data Cloud One 結構進行設定 (具有多個伴侶組織的「居家組織」)。 - **缺點**: - 客戶必須授權新的 Salesforce 組織來佈建 Data 360。 - 透過 Data Cloud One 伴隨連線將組織連線至 Data 360 所需的其他整合。 - 可新增管理負擔 (使用者管理、安全性、身分)。 - 與現有生產組織中的佈建相比,時間轉換值的速度較慢。 **範例:** 一個跨國金融服務公司建立一個專屬的「首頁組織」來佈建 Data 360。所有業務單位組織 (零售、財富、商業銀行業務) 透過 Data Cloud One 連線為「伴侶組織」。 #### 決策條件
考量事項 現有組織作為首頁組織 (偏好預設值) 將新組織作為首頁組織 (替代)
簡化 建立於現有使用者和資料結構以加速設定;Data 360 預設會與「首頁組織」整合。 需要授權和設定新的 Salesforce 組織,以及額外的管理負擔。
時間對價值 立即使用本機 CRM 資料。 延遲 ramp;需要整合。
管治 繼承現有組織的基本管理模式 - 現有使用者和權限集。如果組織已是中心,則可能可以這麼做。 清除管治狀況;適用於 CoE 主導的模型。
合規性 與現有組織區域繫結的住所。 選取與現有組織無關區域的彈性。
效能 本機 CRM 查詢的最佳效能。 取決於「伴隨組織」的連線,無論是與其他組織的相同區域或跨區域。
未來延展性 如果與 Data Cloud One 配對,則運作良好;如果選擇錯誤的組織,則較難稍後進行排班。 使用 Data Cloud One 輕鬆調整規模;設計以保持中立性。
成本 增量成本降低。 來自其他環境的高額負擔率。
### 1.3 建議 一般原則是,建議使用現有的主要組織作為您的「首頁組織」,以儘量減少初始工作並加速採用。只有在您的長期管理或合規策略需要時,才能建立新的專屬首頁組織。針對擁有「傑出中心」(COE) 的大型企業,建立新的專屬「首頁組織」是常見的選擇。 **單一組織環境** 在您現有的生產組織中佈建 Data 360。這可最大化簡易性和立即值。這可避免不必要的整合負擔。 **多個組織環境** 您可以選擇其中一個主要組織 (通常是您大多數業務執行所在的組織,或已作為集中式 CRM 的組織),以作為「首頁組織」。這可減少複雜性、最小化設定工作,並讓您快速實現 Data 360 的價值。使用現有的主要組織也會避免管理新環境的成本和整合工作。 **何時考慮新的專用居家組織** 如果您的組織擁有強大的傑出中心 (CoE),且想要與業務單位組織分開管理。如果由於合規性或組織限制,沒有單一現有組織適合。在這些情況下,建立新的「首頁組織」可提供彈性和中立性,但時間轉換價值會變慢。 --- ## 區段 2:多組織策略與 Data Cloud One ### 2.1 多組織挑戰 企業經常營運多個 Salesforce 組織,這不是極端個案,而是規則。截至 2024 年 2 月,約 19,000 位 Salesforce 客戶已執行一個以上的 Salesforce 組織。 為什麼會發生此情況? - **併購和併購:**新收購的公司有自己的 Salesforce 例項。 - **區域作業:**針對歐盟、北美洲、亞太區等個別組織,通常可滿足資料落地法律。 - **功能分隔:**不同的業務單位 (例如 Retail Banking、Wealth Management、Insurance) 會維持自己的組織以保持自主性。 - **法規或安全性隔離:**基於合規性原因,某些產業必須以邏輯方式建立不同的組織。 - **歷史/技術原因:**隨著時間的推移,客戶會自然累積多個組織。 每個原因都個別有意義,但一起建立資料的分割。若沒有統一層,每個組織只會有客戶的部分檢視。 架構挑戰:如何將跨組織的資料統一為單一事實來源,同時遵循合規性、管治與自主性需求? --- ### 2.2 什麼是 Data Cloud One? Data Cloud One 是 Salesforce 的多組織連線結構,允許多個 Salesforce 組織共用單一 Data 360 例項。這是具有多個 Salesforce 組織的企業建議模式。 在任何 Data Cloud One 叢集中,將一個 Salesforce 組織指定為「主要組織」,主控 Data 360 例項。其他 Salesforce 組織會以「伴侶組織」形式連線,從「首頁組織」的 Data 360 中取用統一的資料和中繼資料。 顯示 Data Cloud One 結構的圖表 #### Data Cloud One 的運作方式
  1. 資料獲取與統一 (主要組織)
  2. 資料空間結構
  3. 中繼資料共用
    「伴侶組織」會從「首頁組織」接收中繼資料定義,包括資料模型物件 (DMO)、統一設定檔結構描述、已計算洞察、區段等。這些項目原生顯示在「伴侶組織」內,就如同是本機資產,但實際上會連結至「首頁組織」。
  4. 要在「居家組織」中執行的工作與工作伴侶組織
    5. 「首頁」與「伴侶組織」的功能存取權不同。「伴侶組織」無法採取或統一資料,且依賴「首頁組織」以供採取、建模和統一。伴侶組織可以存取 Data 360 資料,以增強 Data 360 技術提供的平台功能,並可在共用的信任資料上建立本機洞察、區段和流程。在未來願景中,他們也可以存取啟用功能。
    能力 住家組織 伴侶組織
    「連線」 設定連接器、建立資料串流,或將資料採取或聯合 ✅ ❌
    協調與統一 建立並執行資料轉換和身分解析 ✅ ❌
    使用資料空間和權限來保護資料的安全管理 ✅ ✅
    區段與預估建立區段、洞察和 Einstein Studio 模型 ✅ ✅
    啟用隨處的啟用、資料動作 ✅ ✅
    平台功能提示詞產生器、流程、報告、增強等 ✅ ✅
    Data 360 增強功能 Prospecting Center、Sales 和 Service Cloud 功能、Agentforce 等 ✅ ✅
  5. 平台功能比對
    從使用者和產生者的角度來看,一旦共用中繼資料,首頁與伴侶組織在使用 Salesforce 平台功能方面有一些功能差異。支援的功能清單可在「伴侶組織」的 Data 360 功能 中找到。
  6. 消耗模型
    所有「伴侶組織」活動 (查詢、區段執行、Data 360 觸發流程、AI 用量、Einstein Trust 層記錄等) 都會從「首頁組織」中耗用 Data 360 點數。耗用流程只有一種方式:系統會集中化、計費和根據「居家組織」的信用分配追蹤信用額。不過,您可以逐層細分以查看每個個別組織在 Digital Wallet 中使用的信用額。
  7. 設計原則:水平建構
    Data Cloud One 設計為 Salesforce 平台的水平建構,類似於 Sandbox。目標是讓 Salesforce 發行中的每個新功能都能在「首頁」與「伴侶組織」中運作,而無需額外設定。這可確保 Data Cloud One 不僅是資料結構的選擇,也是未來的 Salesforce 平台基礎元素。
--- ### 2.3 決策:多個獨立 Data 360 與一個共用 Data 360 (Data Cloud One) 具有多個組織的企業必須選擇 Data 360 在其生態系統中的位置和方式。他們想要在每個組織中佈建獨立 Data 360,還是使用 Data Cloud One 在單一「首頁組織」之下統一組織? #### 選項 A:多個獨立 Data 360 每個 Salesforce 組織都會佈建自己的 Data 360 例項。 **優點**: - **自治**:每個業務單位或區域都控制自己的 Data 360。 - 每個組織中的 **簡化**:管理、安全性和自訂項目已本地化。 - **法規合規性**:當需要嚴格的法規分隔時很實用 (例如,資料不能跨境)。 **缺點**: - **資料孤島:**Customer 360 無法跨組織達成。 - **成本愈高**:每個例項都需要授權、管理與整合。客戶最終會多次採取相同的來源資料,以在多個不同的組織中達成完整的 C360 檢視。 - **重複工作:**必須在每個 Data 360 中重複身分解析、區隔和增強。 #### 選項 B:一個共用 Data 360 (Data Cloud One 叢集) 單一 Data 360 會佈建在「首頁組織」,其他的 Salesforce 組織會連線為「伴侶組織」。 **優點**: - **單一事實來源 (SSOT):**所有組織皆共用相同的統一資料模型。 - **成本效率:**只需管理一個 Data 360 授權與基礎結構。 - **統一管理:**系統會集中套用原則、安全性和合規性控制。 - **跨組織增強:**「伴侶組織」可以存取協調的設定檔、洞察和區段。 - **AI 整備:**企業範圍資料集可更完善地訓練和啟用 AI 模型。 - **未來證明:**新增「伴隨組織」很簡單,不需要新增 Data 360。 **缺點**: - **其他準備:**需要規劃組織對首頁組織的連線。 - **延遲考量事項:**不同區域中的「伴侶組織」會看見較慢的查詢速度。 - **複雜管理:**如果每個組織的自訂需求都非常不同,則細微的管理可能很複雜。 #### 選項 C:多個 Data Cloud One 叢集 在某些情況下,管治、合規性或其他業務需求可能會使將每個組織分組在一起變得不實用。這可能會導致需要實作混合式解決方案,其中企業會營運數個 Data 360,每個項目皆為不同「伴隨組織」叢集的「首頁組織」。 #### 範例: 多國企業擁有多個區域的 Salesforce 組織,包括歐洲、美國和亞洲。為了遵循區域資料落地法規,他們為每個個別區域佈建一個 Data 360。 #### 決策條件
考量事項 多個獨立 Data 360 一個共用 Data 360 (Data Cloud One )
自主 每個組織或業務單位的高自主性。 集中化治理,每個組織的自主權降低。
合規性 當需要嚴格分隔時很實用 (例如,地區法律)。 當落地允許集中化時效果最佳。
成本 授權與管理成本較高。 更具成本效益;多個組織的一個授權。
管治 分割;各組織的原則不同。 組織之間集中的一致原則。
資料集中 每個組織都有自己的檢視;沒有 Enterprise 360。 統一的資料集,無重複。
AI/Analytics 限制為每個組織的資料。 更準確的企業範圍模型。
複雜性 要管理的例項越多,整合越多。 更簡單的結構,更少移動組件。
效能 最適用於組織內使用個案。 「伴侶組織」存取權可能會導致延遲。
--- ### 2.4 建議 **偏好的模式:****Data Cloud One** 預設為具有已連線多組織企業的「伴侶組織」的單一「首頁組織」。 這會建立企業範圍 Customer 360、簡化監管並最佳化成本。 **使用多個 Data 360 的時機:** 只有在合規性、居住權或組織自主權嚴格要求時。例如,由於法規,歐洲作業必須與美國作業保持完全分開。 **如何在 Data Cloud One 中選擇「首頁組織」:** 從考量其中一個主要組織開始,通常是大多數業務執行所在的組織。在其中佈建 Data 360 可將複雜性降到最低,並將早期價值最大化。 只有在沒有現有組織適合的情況下,請考慮建立由「傑出中心小組」管理的專屬「首頁組織」。 **一般原則:** 在多組織環境中,將 Data 360 的數量降到最低。將 Data Cloud One 作為預設模式,以減少重複項目、啟用 AI 整備並簡化管治。 --- ## 區段 3:Data 360 組織之間的多個 Data 360 與資料共用 ### 3.1 Data 360 組織之間的資料共用為何? 雖然 Data Cloud One 是大多數企業的建議方法,但在某些情況下,客戶可能需要佈建多個 Data 360 例項。一旦有多個 Data 360 存在,其間的統一不會自動發生。 Data 360 到 Data 360 資料共用可讓客戶在 Data 360 例項之間共用特定物件,而無須重複或自訂管道。這是專為跨 Data 360 協同合作所設計的零複製中繼資料共用機制。 #### 運作方式 - 每個 Data 360 都佈建在自己的「首頁組織」中。 - 管理員可以建立資料共用,即他們想要共用的特定物件分組。 - 所選資料的存取權會與目標組織的 Data 360 共用,其中物件會如同在本機定義一樣顯示。基本資料會保留在來源 Data 360 中;只有存取權會共用。 - 標記未共用。僅原始物件可供使用;目標組織必須視需要重新套用任何監管、作業或 AI 標記。 #### 與 Data Cloud One 的主要差異 - 在 Data Cloud One 中,多個「伴侶組織」共用單一 Data 360 例項。平台功能 (Agentforce、Prospecting Center、Tableau Next 等) 都會在相同的基本資料上執行,以確保一致性。 - 在 Data 360 組織之間使用資料共用時,每個組織都有自己的 Data 360。如組織 A 和組織 B 中的 Agentforce 等功能會在其本機例項上獨立作業。不會自動進行共用,必須建立有意的資料共用,才能僅針對特定物件協同合作。 --- ### 3.2 Data 360 組織之間資料共用的使用個案 **區域合規性:** 一個跨國零售商在歐盟提供一個 Data 360,在美國提供另一個 Data 360。Data 360 至 Data 360 資料共用可讓公司彙總洞察 (例如,忠誠度 KPI),以便與美國總部共用,而原始資料仍保留在本機。 **業務單位協同合作:** 集團會針對「零售」和「保險」執行個別的 Data 360。Data 360 之間的資料共用可讓使用者存取單一的權威資料來源,而無須移動或複製。透過 Data 360 組織之間的資料共用,保險組織會收到零售的「高價值客戶」區段,用於鎖定目標的交叉銷售行銷活動。 **併購:** 父系公司取得附屬公司,並擁有自己的 Data 360。有了兩個可管理的例項,保留短期資料孤立可保留資料安全性和 SSOT 完整性。同時,兩個 Data 360 例項之間共用資料,可在轉換期間進行必要的協同合作。 **聯邦執行顯示面板:** 跨大陸的跨國公司會為每個區域佈建個別 Data 360。主管想要聯合的每季績效檢視。每個區域 Data 360 都會與「執行組織」共用彙總的已計算洞察,以啟用企業範圍報告。 #### Data 360 組織之間資料共用的優點與缺點
因素 優點 缺點
資料落地 支援區域分隔,同時啟用協同合作。 不會移除管理多個 Data 360 的需求。
資料重複 複製零;無重複物件。 需要刻意選取要包含在每個資料共用的物件。
管治 共用是明確且有意的 (物件級)。 沒有標記或原則流程;目標組織必須重新套用監管。
複雜性 啟用不集中化的選用協同合作。 需要管理多個 Data 360 和資料共用。
AI/Analytics 可進行區域 AI/分析;洞察可在組織之間共用。 除非有意共用資料,否則不會有企業範圍 AI。
平台功能 每個組織的 Data 360 技術支援的功能會獨立執行。 無自動共用 — 若未經仔細設計,則可能有重複的風險。
成本 可能會減少 ETL 銷售管道的需求。 多個 Data 360 仍會產生成本。耗用資料查詢和資料共用的信用額。
#### 決策條件
考量事項 Data Cloud One (偏好用於多組織) Data 360 組織之間的資料共用
單一事實來源 ✅ 是,所有組織皆共用相同的 DC。 ∗ 否—每個 Data 360 都有自己的資料模型。
合規性 僅在落地允許集中化時才適用。 當住所法禁止集中化時為必要。
管治 集中化,一致。 聯合;有意共用物件層級。
複雜性 移動組件愈少,愈簡單。 ore complex — 需要組態資料共用和多個 Data 360。
AI/Analytics 企業範圍 AI 模型。 區域 AI;洞察可選擇性共用。
平台功能 「共用資料 360」表示所有功能在「首頁 + 伴侶」之間一致運作。 功能會在每個 Data 360 中獨立執行;共用必須明確。
### 3.3 最佳作法 **如果您的企業有多個 Data 360:** - 在 Data 360 組織之間使用資料共用來跨組織協同合作,而不是建立自訂銷售管道或重複資料。 - 透過建立「資料共用」,並將其授與目標組織來共用特定物件 (DMO、已計算洞察、區段)。 - 請注意,標記未共用—接收組織必須重新套用標記 (例如,監管、分類、AI 增強)。 **使用 Data 360 組織之間的資料共用時機:** - 符合防止集中化的法規需求。 - 維護業務單位自主性,同時啟用選擇性協同合作。 - 提供跨多個區域的聯合主管顯示面板。 - 橋接無法立即合併的 M&A 案例。 **小心設計** 共用必須是刻意且物件特定的。避免過度共用—讓「資料共用」符合業務與合規需求。將 Data 360 至 Data 360 資料共用視為同盟策略,而不是取代 Data Cloud One。 --- ## 摘要
  1. 每個組織都應規劃存取 Data 360
  2. 思考企業範圍,而不是逐個組織
  3. 最小化資料孤立
  4. 如果您必須執行多個 Data 360,請刻意設計
  5. 提前計畫管理與擁有權
  6. 避免短期快速鍵
這些佈建選擇十分重要,因為 Salesforce 平台正在發展為 Data 360 First 模型,其中從客戶區隔到 AI 工作人員奠基的每個功能都將依賴此模型。您今天採取的決策將為企業統一客戶資料的效率、您可以快速採用新 Salesforce 功能,以及您如何確信在整個業務中擴充 AI 的基礎。若要成功,您必須謹慎佈建、儘量減少重複項目、符合合規性需求、刻意管理,並思考長期。最終,佈建 Data 360 是將資料、AI 和 CRM 作為一個凝聚式平台一起運作的第一步。 # ## 關於作者 Kunal Goyal 是 Salesforce 的產品管理部門主管,專注於進階化 Data 360 中的多組織結構和延展性。自 2017 年起,他負責多個專注於跨組織協同合作和多租戶系統設計的計畫和產品。Kunal 是 Data 360 最佳作法結構商機之一,也是 Data Cloud One、設定、佈建和管理員體驗的產品擁有者。 Erin Wagner Tidwell 是 Data 360 的主要技術作者和內容設計師。她從 2013 年開始在 Salesforce 工作。她致力於透過清楚、一致且準確的技術文件和應用程式內通訊,讓 Data 360 更容易理解和使用。 Yugandhar Bora 是 Salesforce 的「軟體工程結構設計師」,專門在「資料與情報應用程式」平台內進行資料結構。他負責領導企業結構審查委員會 (EARB) 計畫,專注於資料管理和統一資料模型,同時為自動平台佈建解決方案做出貢獻。 Samarpan Jain 是 Salesforce 的首席結構設計師,專門處理 Commerce Cloud、平台整合和跨組織結構。他是 Salesforce 最長期的員工之一,負責主要計畫,包括政府客戶的資料落地合規性與 Data 360 用量歸屬系統。 ## 指南概觀 本指南將協助您評估 Salesforce 平台上非同步處理需求的正確方法。它會解釋每個方法,並詳細說明每個方法的優勢與限制。大多數方法與產品功能一致,但某些方法在協調中使用多個功能。此指南包含使用個案來醒目提示每個方法的使用時機。 非同步處理為您的結構提供兩個主要優點。首先,由於非同步程序有較高的管理員限制,因此會增加擴充性。其次,非同步要求會在自己的執行緒中執行,因此使用者可以在非同步工作在背景中執行時執行其他工作。 請注意,本指南專注於在 Salesforce Platform 內選擇非同步處理技術。其他可協助您決策流程的資源會列在「[資源」區段中](#資源)。 ## 此指南範疇中的產品
Salesforce Platform Salesforce Lightning Platform 是一個全方位、 AI 驅動的平台,可將員工、獨立 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以提升生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。
此文件不涵蓋其他生態系統中的技術,例如 MuleSoft、Informatica、Commerce Cloud、Tableau 和 Marketing Cloud。 ## 接待時間 - **使用非同步處理之前,請確定您的使用個案符合模式。**非同步模式沒有 SLA、受限於多個管理員機制、可根據授權定義產能限制,且可能會因為配置給 Salesforce Platform 中非同步基礎結構的資源有限性而導致處理延遲。在使用者需要系統回應的情況下使用非同步處理時,請考量這些限制,才能繼續進行其工作。 - **使用 Salesforce 進行非同步處理並非滿足無限調整需求的解決方案。**Salesforce Platform 不會無限規模,非同步模式受到限制。非同步處理使用執行緒,其中包含 CPU 執行指示串流所需的內容資訊。討論串可以並列執行。任何 CPU 中可用的執行緒數目受到限制,因此平台已具備機制,以盡可能有效率地使用其可用的執行緒。平台的 [流程控制機制](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals#流程控制)可防止組織耗用太多執行緒,並對其他組織造成負面影響。平台的 [公平使用演算法](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals#公平使用)也控制組織針對每個特定訊息類型可用的執行緒數目。 - **會考量造成極度負載的事件。**當您設計非同步流程時,請確定流程可以預測地管理工作量高峰和閒置。請考慮您的實作如何處理非預期的事件,例如停電,以及設計可減輕資料遺失或功能遺失的安全防護。 ## 產品比較 此表格概述使用 Salesforce 進行非同步處理的可用工具。請參閱此表格,在決策流程期間檢閱每個工具的主要特性。請參閱「[使用個案](#使用個案)」和「[決策點](#決策點)」,以協助為您的結構選擇正確的工具。
方法 描述 所需技能 授權與限制
可排序的 Apex 用於涉及長時間執行資料庫作業或外部 Web 服務呼叫的流程。Apex 提供工作識別碼、支援非原始類型和工作鏈等功能。 專業程式碼 授權數量會增加限制。
批次 Apex 透過分割記錄集並將其處理成可管理區塊,建立複雜且長時間執行流程,其中涉及數百萬筆記錄。 專業程式碼 授權數量會增加限制。
已排程 Apex 在由 Cron 運算式定義的排程時間執行 Apex。雖然透過 Cron 運算式排程 Apex 的動作是非同步的程序,但基本程式碼會在工作開始時同步執行。 專業程式碼 授權數量會增加限制。
Apex 繼續呼叫 從在同步交易內容中執行的 Apex 方法執行呼叫。 專業程式碼 否
非同步路徑 (記錄觸發流程) 執行您要在自己的時間執行的作業。請避免在您更新非觸發流程記錄相關記錄值時發生的混合 DML 錯誤。 低程式碼 授權的數量與類型可增加限制。
排程路徑 (認可流程後) 在觸發事件後動態排程的時間執行,例如建立、更新或刪除記錄時。 低程式碼 授權的數量與類型可增加限制。
已排程流程 在特定時間和重複的頻率 (每日、每週或一次) 在背景中執行流程,以對記錄批次執行動作。 低程式碼 授權的數量與類型可增加限制。
平台事件觸發 寬鬆將 Salesforce 與外部系統配對,並在 Salesforce Platform 內非同步元件之間通訊。 低程式碼 + 專業程式碼 大量平台事件使用個案需要附加元件授權
變更資料取取 認可資料庫交易後,以非同步方式來捕捉和處理變更事件。 專業程式碼 需要附加元件授權,才能將比例大於基準配置。
大量 API 以非同步方式插入、更新、更新插入、查詢或刪除許多記錄,之後再處理結果。 專業程式碼 有一些限制。
Lightning 動作 允許 Lightning 頁面與伺服器互動,而無須強制使用者完全重新整理頁面。 低程式碼 否
## 決策點 此表格包含當您決定要使用哪個非同步工具時要考量的要點概觀。
所需技能 此指南中概述的部分工具需要程式碼,而其他工具則可以宣告的方式進行設定。當您考量您的選項時,請思考小組成員擁有的技能集。請記住,即使開發人員可用於您的初始實作 (例如透過實作合作夥伴),您可能需要在未來修改您的解決方案。如果您的維護小組缺少開發人員,低程式碼選項可能更適合。
強制執行的平台限制類型 決定套用至執行的 限制類型。當您設計解決方案時,請仔細思考交易量和頻率會如何計入每日所選方法的管理員限制。計算每天會發生的執行次數。請確保計算的值在與您所選工具相關聯的限制之內。
延遲 決定處理結果在平台中可用的速度。針對某些方法,變更將近乎立即,而對於其他方法,變更可能為分鐘或小時。
## 使用個案 當您選取用於非同步處理的工具時,請先評估您組織的需求和可用資源。您的目標是選取最小化實作與維護成本的工具,同時確保延展性並將限制違規的可能性降到最低。此目標取決於先前概述的技術考量事項,以及您小組的組成。 請考量 Salesforce 中的非同步訂購流程。儲存訂單時,會觸發外部倉庫管理系統的訊息,其中包含如何包裝和寄送項目的特殊指示。下單的使用者不需要倉庫管理系統的立即回應,因此要求可以非同步傳送。非同步處理可讓使用者繼續工作,而無須等待回應。 針對此使用個案,您可能會考慮使用 Apex 進行實作。只有在您的小組中有可維護 Pro-code 解決方案的 Apex 開發人員時,此方法才會運作。否則,陳述性方法更有意義。此外,請記住,不同工具適用的不同集合的 [限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)。 此表格會在最左側欄中列出常見使用個案,後面加上描述。*第一個選項*欄提供用來滿足此類使用個案的最典型方法,以及第一個選項方法的理由。請使用此作為分析的起點,因為「第一個選項」方法可能有不適用於您使用個案的限制。
使用個案 描述 第一個選項方法 理由
高效能批次處理 必須有效率地處理數千筆或數百萬筆記錄的自動化 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
資料清除工作 定期執行或隨選執行,可清除資料的工作。範例包括消除重複、地址驗證或資料合併。 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
夜間累計工作 在工作日結束時計算累計資料的工作。 批次 Apex 批次 Apex 提供豐富的 API,可用於與平台的介面以及原始速度。
記錄觸發邏輯 執行邏輯以回應記錄更新。 變化 請參閱我們的伴侶決策指南,記錄觸發事件自動化。其中包含非同步使用個案的決策樹狀結構,包括可排列的 Apex、批次 Apex、已排程的流程、非同步路徑流程和變更資料擷取。
透過物件圖表串聯更新 允許使用者的儲存動作快速完成,將串聯更新延後至其他物件以非同步執行。 可排序的 Apex Apex 具有強大的鏈結功能,可讓邏輯將更新鏈結分為一系列非同步交易。
記錄特定排程處理 在未來,記錄特定的動態日期 (例如結束日期前 3 天) 自動化。 含已排程路徑的 流程 已排程路徑為流程提供獨特的優勢,因為當記錄的資料變更時,平台會自動處理這些路徑的排程、取消和重新排程。
並列叫用多個慢速外部服務 在同步執行期間,會並列叫用多個外部服務,以最佳化整體執行時間。 Apex 繼續呼叫 允許多個慢速執行的呼叫並行執行,可將完成工作整體時間最小化。
從外部系統移轉記錄的資料 從外部系統將大量記錄移至 Salesforce Platform。一次性或定期排程的流程。 大量 API 這是資料移轉最有效率且易於限制的方法。
在外部系統上執行其他邏輯 通知平台上事件的外部系統,然後允許該系統非同步處理事件的觸發式模式。 平台事件或 變更資料 發布子模型最適用於此處,並允許外部系統在準備好時處理事件。如需此模式的詳細資料,請參閱「事件驅動結構」。
「使用個案」表格是每個使用個案最合適方法的指引。不過,您需要驗證 First Choice 技術是否符合您使用個案的特定需求。尤其是,判斷所選方法是否可以遵循您組織的管理員限制。 在您為使用個案找出候選方法後,[非同步處理基本概念指南](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals)可協助您完整檢查解決方案。 ## 資源 這些其他資源可協助您的決策流程: - 深入瞭解每個平台非同步技術:[非同步處理基礎知識](/docs/architect/zh-tw/fundamentals/guide/async-fundamentals) - 選擇記錄觸發的 Apex 和流程:[記錄觸發事件自動化](/docs/architect/zh-tw/decision-guides/guide/record-triggered) - 非同步整合模式的相關資訊:[事件驅動的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven) # 針對以事件為導向的結構使用正確的工具和模式 ## 概觀 以事件為導向的結構支援事件的有效生產與耗用,其會傳達系統或應用程式狀態變更。這些結構可啟用系統之間的彈性連線,並支援流程,以及跨系統運作的近乎即時更新。雖然事件驅動結構的優點很容易看見,但實作詳細資料並非總是如此明確。您在以事件為導向的結構模式中需要考量哪些功能?這些模式可解決哪些特定問題?解決方案適用的特殊考量事項為何,以及處理解決方案的最佳模式為何? 本指南呈現使用 Salesforce 技術時,用來建立最佳事件驅動結構的模式。其中也會討論 Salesforce 提供的撤銷工具,並提供用於選取使用個案的工具建議。如需有關涉及 Salesforce 的資料層級整合資訊,請參閱我們的「[資料整合決策指南](/docs/architect/zh-tw/decision-guides/guide/data-integration)」。 ## 接待時間 - **針對不需要要求同步回應的流程,使用以事件為導向的結構。**本指南概述的模式是針對資料的一致性、可擴展性和重複使用所設計,這有助於隨著您組織的應用程式環境發展將技術債務降至最低。(如需詳細資訊,請參閱 [Well-Architected - 輸送量](/docs/architect/zh-tw/well-architected/guide/reliable#輸出)。) - **如果 MuleSoft 或其他 Enterprise Service Bus (ESB) 解決方案是您現有的基礎,請盡可能使用它。**這些解決方案是針對支援以事件為導向的結構模式而打造,並具有強大的功能,可讓您在整個企業中重複使用整合。 - **將 Pub/Sub API 用於任何未來的發佈/訂閱模式,而非使用其他 API (包括串流 API) 建立您自己的事件處理常式。**現在 Pub/Sub API 已廣泛可用,請將其用於任何新的發佈/訂閱模式。計畫在可行時使用其他平台 API (例如串流 API 或自訂 Apex 服務) 將現有事件通訊移轉至 Pub/Sub API。 - **平台事件和變更資料取得 (CDC) 是發佈其他系統需要取用的記錄和欄位變更的偏好機制。**我們不建議針對新實作使用 PushTopic 和一般事件。Salesforce 會繼續支援目前功能內的 PushTopic 和一般事件,但不會計畫進一步投資此技術。 ## 範疇中的產品
Salesforce Platform Salesforce Platform 是一個全方位、 AI 驅動的平台,可將員工、自主 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以增強生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。
MuleSoft MuleSoft 是 Salesforce 領先的整合平台,可讓組織在內部部署和雲端環境之間連線應用程式、資料和裝置。MuleSoft 是一個平台,可讓 IT 平台在系統之間解除鎖定資料、開發可調整整合和自動化架構,並快速建立不同的連線體驗。
## 決策點 針對需要近乎即時通知的情境、分配大量或複雜訊息的處理負載,以及整合如 IoT 和行動裝置等系統,這些情況都建議使用事件驅動結構 (EDA)。然而,EDA 不應針對需要立即同步的人類回應的流程進行實作,因為其設計用於非同步執行。如果來源資料變更的頻率太少,以至於簡單的模式 (例如批次處理) 足夠,則其也不適用。 ### 使用事件驅動結構的時機 以下是一些常見的案例,通常適合以事件為導向的結構:
決策點指引
近乎即時的通知以事件為導向的結構模式 (例如發佈/訂閱、對應和串流) 可能在多個應用程式需要近乎即時地通知狀態變更或記錄更新的情況下運作良好。
平行處理如發佈/訂閱等模式可能在大量資料或高度複雜訊息需要在多個系統之間分配處理負載的情況下運作良好。
大量讀取「傳送的訊息」和「排隊」模式通常用於組織遇到高峰的情況,且產生的訊息量可能超過訂閱者立即處理訊息的能力。
大量寫入在許多情況下,「串流」與「排入排入」模式可以順利運作,其中組織在產生的訊息數量上漲。
將相同資料傳送至不同的系統雖然發佈/訂閱通常是需要將相同資料傳送至多個系統的組織相當常見的解決方案,但此處涵蓋的大多數模式都可處理此問題。請務必仔細檢閱這些項目以找出最合適的項目。
頻繁導入新系統或裝置發佈/訂閱、串流和排入類型模式通常適用於整體橫向傾向為流動的情境,且會定期新增新的系統和裝置。在此情節下,新系統或裝置只需要成為 Event Bus 的訂閱者,或關聯到某個指南,才能開始接收訊息,而不需要自訂點對點整合。
IoT 裝置由於 IoT 裝置通常會提供頻繁的更新,且在某些情況下也會產生一系列訊息,因此當將其整合至 IT 環境時,「串流」與「排隊」模式通常會運作良好。
離線行動裝置與系統行動裝置需要在具有低品質或不存在網際網路存取權的區域中工作,或在傳送訊息時可能為離線的系統,這些裝置將受益於「排隊」模式,其能夠在重新上線後連線至其排隊,並再取回任何相關訊息。
大多數的大型組織擁有複雜的 IT 環境,其系統組合具有不同的功能。您的組織有可能或可能擁有不支援以事件為導向之整合的舊版系統。您可能也會在事件驅動的整合沒有意義的情況下使用個案,即使系統會支援這些個案 (例如,SFTP 檔案從第三方傳輸)。如果您回溯了一步,並查看整個組織的 IT 環境,您可能會使用混合的模式來支援不同的案例,就像其他結構解決方案一樣。當您決定使用以事件為導向的整合方法,請將其視為工具箱中的另一個工具。它可且應用於正確的案例中,但並非要對每個系統強制執行的方法。開發全方位整合策略可協助您判斷本指南中所述模式何時可能或可能不適當。 ### 不使用事件驅動結構的時機 許多案例都需要以事件為導向的結構,在某些案例中,即使以事件為導向的結構並非最適合,它們仍會運作。但在某些情況下,無法使用以事件為導向的結構。以下是一些決策點問題,可協助您識別這些情況:
決策點要詢問的指引/問題
業務需求[使用事件驅動結構時](#使用事件驅動結構的時機) 區段中所述的任何功能是否有真正的業務需求?
技術需求您設計的整合是否符合不同的模式,例如資料虛擬化、批次或要求/回覆?換句話說,您是否正在嘗試將正方形指標置於圓洞中?
需要人類等待回應的流程任何涉及人類從目標系統等待回應的整合不適合以事件為導向的結構,因為其專為非同步執行而設計,且無法保證回應時間。在實作技術解決方案之前,請先考量此類流程是否對您的組織最佳。如需詳細資訊,請參閱 [Well-Architected - 流程設計](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)。
經常變更來源資料如果來源系統中的資料變更不常見,因此有足夠的定期更新,您可能可以使用 [批次模式] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) 來簡化結構,而非以事件為導向的模式。
實作需求大多數解決方案中涉及的系統是否支援以事件為導向的結構?將以事件為導向的結構與不支援它們的系統 (例如升級、自訂或中介軟體) 搭配使用時,需要什麼?符合這些需求需要付出多少精力?
訊息結構穩定性您的訊息結構需要變更的頻率為何?哪些系統會受到此類變更的影響,以及補救流程會是什麼?
組織管理您是否具備了監管結構,以確保所有利害關係人都瞭解並能夠考量訊息結構、觸發和其他結構和流程相關決策的變更?
必要技能集您的工作人員是否擁有事件驅動結構的經驗,他們會知道如何支援它們嗎?
## 使用個案 各種以事件為導向的結構模式。某些是一般用途模式,可套用在沒有事件驅動以外任何特殊需求的使用個案中;例如,請參閱 [Well-Architected - Interoperability](/docs/architect/zh-tw/well-architected/guide/composable#互通性)。其他模式適用於此處討論的特定使用個案,例如涉及大量資料的整合,或需要更長訊息保留的情境。 ### 模式概略 下表比較此文件中所列模式的屬性。當您需要識別指定使用個案的潛在模式時,請將其作為快速參考。
模式近乎即時唯一訊息複製保固交付減少訊息大小轉換資料
發佈 / 訂閱✓✓✓
透鏡圖✓✓✓
傳送的訊息✓✓✓✓
串流✓✓✓
排隊✓✓✓
### 事件驅動結構的工具 Salesforce 提供多種工具來協助您解決以事件為導向的使用個案。此表格包含可用工具的概觀概觀。
工具描述必要技能
MuleSoftAnypoint 平台使用 API 圖層來啟用資料整合的平台。專業程式碼
Salesforce Pub/Sub 連接器適用於 Pub/Sub API 的連接器,此連接器提供發佈和訂閱平台事件、即時事件監視事件和變更資料擷取事件的單一介面。專業程式碼
MuleSoft Anypoint JMS 連接器針對實作 Java 訊息服務 (JMS) 規格的任何訊息服務,此連接器可將訊息傳送與接收至任何訊息服務的列和主題。專業程式碼
MuleSoft Anypoint Apache Kafka 連接器可在 Apache Kafka 與企業應用程式和服務之間移動資料的連接器。專業程式碼
MuleSoft Anypoint Solace 連接器使用 JCSMP Java SDK 的原生 API 整合,適用於 Solace PubSub+ 事件經紀人的連接器專業程式碼
MuleSoft Anypoint MQ 連接器可讓客戶在其應用程式之間執行進階非同步傳訊的多租戶雲端傳訊服務。專業程式碼
MuleSoft Anypoint MQTT 連接器符合通訊協定 v3.x 的 MQTT (Message Queuing Telemetry Transport) MuleSoft 擴充功能。專業程式碼
MuleSoft Anypoint AMQP 連接器此連接器可讓您的應用程式使用 AMQP 0.9.1 相容的經紀人來發佈和取用訊息。專業程式碼
MuleSoft Anypoint 事件驅動 (非同步) API產業無效的語言,透過將以事件為導向的 API 分隔成事件、管道和運輸層級來支援發佈。專業程式碼
MuleSoft Anypoint MQ可讓客戶在應用程式之間執行進階非同步傳訊的多租戶雲端傳訊服務。專業程式碼
MuleSoft Anypoint 資料串流可在 MuleSoft Anypoint 中發佈和訂閱串流資料的架構。專業程式碼
Salesforce PlatformHeroku 上的 Apache Kafka提供 Apache Kafka 作為服務的 Heroku 附加元件,並將完整的平台整合至 Heroku 平台。專業程式碼
變更資料取取變更事件記錄會將變更發佈至 Salesforce 記錄。變更包括建立新記錄、更新現有記錄、刪除記錄,以及取消刪除記錄。低程式碼對 Pro-code
輸出訊息更新 Salesforce 中的欄位值時,傳送 XML 訊息至外部端點的動作。低程式碼
平台事件包含自訂事件資料的安全且可調整訊息。低程式碼對 Pro-code
Pub/Sub API可啟用平台事件訂閱、變更 資料擷取 事件和/或即時事件監視事件的 API。專業程式碼
事件轉送啟用要從 Salesforce 傳送至 Amazon EventBridge 的平台事件和變更資料擷取事件。請注意,事件轉送只會連線至 AWS Eventbridge。低程式碼
### 發佈/訂閱 當重要記錄在核心應用程式內變更狀態時 (例如,訂單的狀態從「正在處理」移至「已出貨」),多個其他系統可能需要近乎即時的通知來執行其各自的工作。當這些變更量很高且訊息很複雜時,會產生特定業務需求,使傳統點對點整合變得繁重且難以維護。為每個相依應用程式建立脆弱且自訂的連線會導致技術負債,並阻礙組織快速擴展。需要強大的整合方法來管理這些頻繁的資料同步化,而無須將來源系統直接連接至每個耗用系統。 #### 發佈/訂閱模式 下圖說明一般發佈/訂閱模式,其中多個發行者和訂閱者透過 Event Bus 共用資料。此基礎模式是可在本指南其餘部分找到的更具體模式基礎。此模式的一些重要特性包括: - 發行者與訂閱者之間沒有直接連線。發行者只需將訊息傳送至 Event Bus,便可將訊息廣播至想要聆聽訊息的任何其他系統。 - 相同的系統可以是發行者與訂閱者。 - 系統可以發佈或訂閱多種類型的事件。 - 如同本指南中所有的模式,發佈/訂閱模式屬於一般整合模式種類,稱為遠端程序叫用 (RPI) 或簡單[「觸發忘記」。](/docs/architect/zh-tw/fundamentals/guide/integration-patterns#遠端流程叫用--觸發與忘記) 此層級 2 圖顯示發佈/訂閱模式的範例,其中包含多個發行者、多個訂閱者,以及透過 Event Bus 中的管道傳送的多個事件。在此模式中,相同的系統可以是發行者和訂閱者,且系統可以訂閱多個事件。 #### 與發佈/訂閱模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftAnypoint 平台專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint JMS 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Solace 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint 事件驅動 (非同步) API專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
輸出訊息*低程式碼流程與工作流程規則無24 小時已定義使用者每則訊息 100 個通知
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API、Apex、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送**低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*Salesforce 會在目前的功能中繼續支援輸出訊息,但不打算進一步投資此技術。 **事件轉送只會連線至 AWS Eventbridge
### 透鏡圖 當組織需要將立即更新傳送至大量用戶端應用程式 (例如推送通知或 SMS 訊息) 至行動裝置時,為每個單一收件者建立唯一傳輸的傳統程序會迅速變成可擴充性瓶頸。在此案例中,核心業務需求是將單一資訊 (例如帳戶警示或重要服務變更通知) 快速且高效能地散佈至多個端點應用程式。滿足此需求的簡化方法涉及透過單一路由訊息,這會作為所有耗用系統事件資訊的中心點。此方法可減少管理多個個別訊息複本的需求,藉此改善效能。 #### 透鏡圖 透過「下拉式」模式,訊息會透過單一訊息列傳送至一或多個目的地 (亦即聆聽用戶或訂閱者)。訂閱者會從其自己的唯一複本取用同一則訊息,而不是從其中的同一則訊息。(請注意,雖然這可改善效能,但也會使驗證特定訂閱者是否收到訊息變得更難。) 此層級 3 文件與實作圖表顯示了對外模式的範例。 此圖表描述當透過使用者互動、流程或批次工作修改記錄時,發佈並寫入單一排隊的事件。 訂閱者系統有多個服務會從訊息排隊接收相同的事件。 #### 與顯示模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint JMS 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Solace 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 Apex、API、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
### 傳送的訊息 某些事件案例的特點為訊息量大幅流入,可能會壓倒同步化和轉換程序的容量,或處理和轉換事件資料所需的複雜多步驟邏輯。 某些範例包括: - **季節性量高峰:**線上零售商在其產品的選擇「季節性」時,可能會遇到數量高峰。當大量客戶同時進行購買時,產生的事件數量可能暫時超過同步化和轉換流程的容量。請參閱 [Well-Architected - 資料處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)以取得詳細資訊。 - **個案或索賠管理:**以服務為基礎的公司在中斷期間,可能會遇到個案或索賠數量的激增。 - **複雜資料轉換:**需要複雜邏輯來轉換訊息的組織通常會擔心事件的產生速度比其轉換的速度快。 #### 傳送的訊息模式 此模式可解決訊息產生速度超過可轉換的挑戰。其可確保可安全地處理大量訊息和必要的資料操作,將串流訊息平台整合到專屬元件中,並將訊息處理邏輯分段。 「傳送的訊息」模式可透過將訊息處理邏輯分段至多個元件來運作: - 一個元件會處理訊息路由,決定必要轉換和最終目的地。 - 個別的元件集會處理訊息轉換的不同層級 (例如,欄位對應、物件關係等)。 - 最後一個元件會撰寫最後修改後的訊息。 此層級 3 文件與實作圖表顯示流程流程範例,適用於傳送訊息模式,其中包含發行者、訂閱者和訊息。 訊息會分割成多個部分,這些部分會個別轉換,然後在傳送給訂閱者前重新組合。 #### 與傳送訊息模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API,Apex 流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
### 串流 某些產生者會產生連續的事件串流。常見範例為媒體串流,其中涉及自然發生為離散事件的使用者互動。多個系統必須同時回應相同的使用者行為,而不會封鎖核心串流體驗。 請考量音樂串流平台的事件。這些可能包括: - 追蹤已啟動/已暫停/已略過事件 - 聆聽包含時間戳記的工作階段事件 - 播放清單建立/修改事件 - 社交共用事件 - 下載以供離線聆聽 #### 串流模式 在「串流」模式中,訂閱者會存取每個事件串流,並以接收的確切順序處理事件。每個訊息串流的唯一複本會傳送給每個訂閱者,讓您能夠傳送訂閱者特定的內容,並識別哪些訂閱者會收到哪些串流。 此層級 3 文件與實作圖表顯示串流模式的範例,此模式描述正在發佈的事件串流。正在聆聽串流的訂閱者會接收串流並相應地處理。 #### 與串流模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint 資料串流專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
Pub/Sub API專業程式碼Pub/Sub API 或 API,Apex 流程Pub/Sub API3 天已定義使用者1 MB
#### 串流事件訂單管理 為了讓串流有意義,其所有事件及其相關聯的訊息都必須以正確的順序顯示。如果您在來自不同系統的串流中來源資料,則必須納入其他訂購邏輯作為設計流程的一部分。 ### 排隊 查詢使用個案很普遍。範例包括: - **低品質的網際網路連線:**Field Service 組織或其他組織,其中具有行動裝置的小組需要在品質不佳或間斷網際網路存取權的區域中工作,會受益於將這些裝置上應用程式連線至其中的排隊,並在恢復連線時取回任何相關訊息。 - **訊息緩衝:**當訊息量有時超過訂閱者的處理容量,且延遲增加不會產生額外的問題時,可能會有用於緩衝來儲存過多訊息並避免資料遺失。 - **運輸管理:**需要監視車隊的物流組織可以使用此模式,以近乎即時檢視每部車輛正在使用的路線,並確保司機的效率盡可能高。 - **IoT 裝置:**製造商經常使用產生快速資料串流的系統,而這些串流可能會對其他系統造成下游影響。此模式可用來識別在發生跨多個系統的災難性失敗之前,需要人類介入的事件序列。 #### 列入模式 生產人員會在「排隊」模式中,傳送訊息給排隊,這些排隊會保留訊息,直到訂閱者將訊息提取為止。大多數訊息排列會遵循先進先出 (FIFO) 順序,並在取出訊息之後刪除每則訊息。每個訂閱者都有獨一無二且需要額外的設定步驟,但仍可保證傳送並識別哪些訂閱者接收了哪些訊息。 此層級 3 文件與實作圖表顯示列出模式的範例,此模式描述在修改記錄時發佈的事件,並寫入至列出。訂閱者會從相關聯的列出接收事件的複本,並對自己的記錄進行適當的更新。 #### 與排入模式相關的工具
事件流程與行為裝載考量事項
可用的工具必要技能發佈透過訂閱透過重複執行期間裝載結構裝載限制
MuleSoftMuleSoft Anypoint MQ專業程式碼APIAPI已設定已定義使用者無
Salesforce Pub/Sub 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint Apache Kafka 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQ 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint MQTT 連接器專業程式碼APIAPI已設定已定義使用者無
MuleSoft Anypoint AMQP 連接器專業程式碼APIAPI已設定已定義使用者無
Salesforce PlatformHeroku 上的 Apache Kafka專業程式碼API,Heroku Postgres 中的記錄變更無1-6 週已定義使用者已定義使用者
變更資料取取低程式碼對 Pro-code記錄變更Apex、API、Lightning Web 元件 (LWC)3 天預先定義1 MB
平台事件低程式碼對 Pro-codeAPI、Apex、流程Apex、API、Flow、LWC3 天已定義使用者1 MB
Pub/Sub API專業程式碼Pub/Sub API 或 API、Apex、流程Pub/Sub API3 天已定義使用者1 MB
事件轉送*低程式碼平台事件、變更資料擷取API3 天已定義使用者1 MB
*事件轉送只會將資料傳送至 AWS Eventbridge
#### 記憶體與儲存空間管理 由於「排隊」模式的非同步性質,因此在將訊息新增至排隊與該訊息提取之間可能會有較長的延遲。達號需要記憶體或儲存空間來保留其訊息,因此其無法無限成長,這表示如果在達號中累積足夠的訊息,則無限離線的訂閱者可能會造成失敗。如果訂閱者處理時間過長,則訊息緩衝可能會產生相同的效果,進而導致大量訊息堆積在他們的排隊中。若要減少這些風險,請針對所有訊息排列執行完整的儲存空間需求分析,並視需要設計流程,在未在設定的時間內或當訊息達到預先決定的容量時清除並停用訊息。 ## 非功能考量事項 ### 從點對點整合移轉 即使您完全相信以事件為導向的結構適合您的組織,您仍可能會從已經擁有大量點對點整合的環境開始。為專案獲得資金來一次取代所有整合可能很困難,甚至可能無法直接將以事件為導向的結構與一些舊版系統搭配使用。在這些案例中,您可以先轉換最關鍵業務的應用程式,然後在其在未來專案中更新或取代時轉換其他系統,以逐步移轉至較寬鬆的架構。此方法可讓您輕鬆將新應用程式新增至 Event Bus,並讓整體 IT 環境在隨著系統持續新增的時間保持可調整和彈性。 ### 寬鬆連接系統中的權衡 身為結構設計師,我們知道每個結構都有權衡。以事件為導向的結構也不例外。雖然充滿寬鬆連接系統的環境可高度調整和彈性,但還需要考量一些權衡因素: - **整體整合策略:**無論您決定要使用的工具和模式為何,請務必從建立策略開始,以瞭解資料如何在組織的各個系統之間共用。此策略應包含您組織的資料目標、資料可共用的方式和使用模式,以及資料來源、目標、結構和擁有權與存取需求。 - **舊版系統的支援:**您的組織可能有舊版系統,只是不支援以事件為導向的結構模式。雖然可能會建立因應措施 (例如,使用透過訂閱事件,然後透過不同的資料傳輸方式將輸出傳送至目標系統作為逐步解說的流程),但您可能想要在此個案中考慮其他整合方法。 - **訊息的結構變更:**一旦發行者與訂閱者之間定義並同意初始訊息結構,可能會難以變更,特別是當訂閱者為外部使用者時。有數種方法可以解決此問題。您可以使用版本化端點,但請確保為每個版本定義並傳達明確的生命週期,以便您的開發人員不必同時維護太多版本。如果 Heroku 上的 Apache Kafka 屬於您的橫向,您也可以考慮使用結構描述登錄或類似工具,但請確保橫向中的其他系統也支援 (並使用)。 - **缺少發行者與訂閱者之間的可視性:**在大多數以事件為導向的結構模式中,發行者不會知道其訂閱者的狀態。因此,如果發行者在所有訂閱者離線時傳送重要訊息,則訊息可能不會傳送。您可以使用重新執行功能來解決此問題,或針對所有重要訊息新增在個別伺服器上執行的冗餘訂閱者。 - **效能瓶頸:**隨著以事件為導向的結構擴展,如果發生過多發行者嘗試同時傳訊太多訂閱者,則 Event Bus 可能會成為訊息傳送的瓶頸。您可以透過增加分配至 Event Bus 的記憶體和處理資源,或使用多個 Event Bus 並列處理不同類型的訊息來解決此問題。 ## 相關最佳作法 ### 實作事件驅動的結構 實作以事件為導向的結構之前,請考量您是否真的需要先使用一個架構。上一節描述適用於每個事件驅動結構模式的常見業務案例。您也可以在 [Well-Architected - Interoperability](/docs/architect/zh-tw/well-architected/guide/composable#互通性) 中深入瞭解。檢閱實作以事件為導向的結構時要考量的挑戰,以判斷您考量的模式是否最適合您特定的使用個案。 請注意,雖然本指南涵蓋的大多數案例涉及整合,但以事件為導向的結構也可以用來透過使用平台事件在單一 Salesforce 組織內傳送訊息,例如。設計使用平台事件作為內部傳訊系統的程序時,請務必記住任何適用的[事件分配限制](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 ### 避免使用反模式 事件驅動結構的反模式通常來自使用事件作為 Salesforce 組織內內部通訊的因應措施。常見的反模式包括: - **從與相同事件物件相關聯的 Apex 觸發發出事件:**這會導致無限觸發迴圈。 - **在 DML 交易完成前,從 Apex 發佈事件:**如果交易失敗並回復,任何具有「立即發佈」發佈行為的已發佈事件都不會包含在回復行為中。 - **在流程中發佈事件以協調後續的自動化:**在多個自動化之間協調邏輯的最佳方法是使用 [子流程](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm)或 [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm)。 - **建立執行階段相依性:**若未採取適當的[步驟](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8)去除執行階段相依性,請勿發佈事件以協助封裝之間通訊。 - **不必要的大型裝載:**提出要求時,最好在裝載中傳送及接收盡可能少量的資料。使用者的每個動作都可能產生多個要求,因此有效處理這些要求十分重要。傳送超過必要的資料會造成傳輸速度變慢且處理時間增加。 - **未選擇性處理應用程式事件:**當有多個元件正在聆聽應用程式事件時,開發人員應確保事件處理常式只會在實際需要且實用時執行。例如,在 Lightning 主控台中,未聚焦的索引標籤中包含的元件仍可聆聽,即使它們不可見。開發人員可以使用各種技術,例如使用背景公用程式項目作為唯一接聽者,或呼叫 getEnclosingTabId() 來判斷元件的此例項是否包含在焦點索引標籤內,以確保每個事件僅在預期的時間處理。 - **使用「平台事件」不正確發佈行為:**「平台事件」有兩種發佈行為—「立即發佈」和「認可後發佈」。將即時平台事件用於使用個案 (例如「記錄」) 相當有用,無論交易是否成功與認可,您都會在其中發佈記錄事件。不過,對於即時平台事件,請特別小心使用「立即發佈」。事件可以在相同交易內由訂閱者耗用,並導致列鎖定或其他競爭狀況。 ### 設計有效的事件 實作以事件為導向的結構時,成功的關鍵之一是設定事件本身設計方式的標準。細節會根據您組織的使用個案而有所不同,但以下是一些一般原則: - **決定事件裝載的最佳結構。**較小的訊息大小會減少處理時間,但以大量訊息轟炸訂閱者可能會造成效能瓶頸。您可能需要迭代裝載大小與結構,以找到正確的平衡。MuleSoft 和類似的 ESB 工具能夠在與您的事件相關聯的訊息中設計自訂裝載,這可協助您視覺化資料結構,以改善訂閱者端的效能。(如需詳細資訊,請參閱 [Well-Architected - API Management](/docs/architect/zh-tw/well-architected/guide/composable#api-管理)。) - **考量您的程序端對端。**確定您未建立任何「無限迴圈」案例,這在首展整合後可能難以追蹤。範例為兩個系統在更新記錄時發佈事件,同時聆聽彼此的事件,這兩個系統在處理時會觸發其他已發佈事件。 您可以透過將邏輯新增至兩個系統來修正此類型的反模式,以確保由於耗用事件而進行的變更不會導致發佈新的事件。您也應確保記錄所有事件、其相關聯的觸發,以及可能受影響的下游系統。在設計工作階段期間,請使用此文件作為參考,以協助盡早抓住無盡的迴圈和類似情況。(如需詳細資訊,請參閱 [Well-Architected - 流程設計](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)。) - **在系統之間使用常見命名慣例。**一致的命名慣例是所有軟體開發 (包括以事件為導向的結構) 的最佳作法。花時間記錄事件名稱、結構、相關聯物件和錯誤處理流程的一組標準,以確保系統之間的一致性。(如需詳細資訊,請參閱 [Well-Architected - 設計標準](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準)。) ## 資源
模式資源
發佈/訂閱Salesforce 結構良好 - 輸出量
Salesforce 結構良好 - 資料處理
Salesforce 結構良好 - 互通性
部落格貼文:使用事件轉送達成結構效率
部落格貼文:公告 Pub/Sub API 廣泛可用
部落格貼文:從 RESTful 移至 Eventful
部落格貼文:以事件為導向的結構與非同步 API 規格
影片:發佈 / 訂閱模式逐步解說
透鏡圖部落格貼文:如何在平台事件傳送限制內工作
影片:透鏡模式逐步解說
傳送的訊息影片:傳送訊息模式逐步解說
串流部落格貼文:針對 Salesforce 中的大量寫入進行設計
影片:串流模式逐步解說
文件:在 Mule 應用程式中串流
排隊部落格貼文:針對 Salesforce 中的大量寫入進行設計
部落格貼文:如何使用事件的 API 設計付款結構
影片:列入模式逐步解說
## 概觀 現代 Salesforce 結構越來越多地由非同步處理提供技術支援;這不是為了便利起見,而是作為規模的策略需求。近年來,我們看見越來越多的公司面臨資料量激增、涉及多個接觸點的複雜整合,以及 24/7/365 執行之自發系統的崛起。所有這些項目都會推動結構設計師設計非同步優先的系統。 Salesforce 上的非同步處理通常意味著根據管理員限制和複雜度進行設計。這些限制會作為保護欄和結構限制,協助產生大量安全且可調整的系統。雖然沒有平台限制可直接管理複雜性,但[設計模式](https://refactoring.guru/design-patterns)可協助降低風險。在內部,Salesforce 經常會推動平台的邊界,進一步測試新功能並自動化複雜的業務流程。我們建立了一個以步驟為基礎的非同步處理架構,用於透過任意數量的步驟執行非同步工作。每個步驟都可以透過共用的監管控制項和完整的作業可視性,透過集中化記錄來獨立執行、重試和重新啟動。此文件概述其主要結構元件:Apex 和完成者、排程流程、Apex 游標、可叫用動作,以及與 Slack 的整合。這些元件一起提供模組化、可調整且可觀察的結構,適合不斷演進的企業需求。 ## 重要道具 - 現代 Salesforce 結構應採用非同步優先方法,以達成規模、彈性和營運透明度。 - 將複雜工作拆分為可獨立執行的步驟,可實現可預測的效能、更安全的重試、檢查、回復和模組化演進,而無須重新設計核心工作流程。 - 此架構為單一和過時的批次工作、鏈結非同步呼叫和深度巢狀流程提供可調整的替代方案,並針對在 Salesforce 內必須水平調整且不需要在平台外協調流程的大量工作量所建立。 - 決定性與可觀察的執行可透過集中化記錄與管治來確保進度追蹤、SLA 監視、失敗診斷和稽核層級透明度。 - 針對企業層級的嚴格性設計,包括統一管理、合規性,以及跨長期執行業務流程的分散式州控制。 ## 平台最佳作法 檢閱需求前,以下是使用此類架構的時機注意事項與秘訣。最重要的是,請考量哪個系統是單一事實來源。如果您的 Salesforce 組織最少依賴外部資料,但需要從數百筆到數百萬筆記錄進行調整,請考慮使用步驟型非同步架構。 在下列情況下,**請**使用此架構: - 要採取動作的大多數 (或全部) 資訊已存在於您的 CRM 中。 - 維護「解壓縮負載」(ETL) 工作以協調外部資料的預先或進行中成本太高。 - 您必須在設定的排程中延後處理大量 Salesforce 記錄。 - 您可以將處理細分為離散步驟。例如,您可以建立階層式或以樹狀目錄為基礎的記錄集,特別是當資料量在階層或樹狀目錄下拉式時。 在下列情況下**,請勿**使用此架構: - 建立或更新記錄需要立即重新計算。 - 整合是具有挑戰性的,因為外部系統主控記錄更新的主要資料。(請考慮使用大量 API 將更新的資料推送至 Salesforce。) 考慮到這些作法,讓我們檢閱我們的需求並開始建立。 ## 細分需求 請思考問題陳述式: > 若工作需要每日執行,請檢查某些記錄是否符合預先建立的條件,以便進一步處理。若已完成,請開始處理工作。處理記錄可能表示從多個外部系統提取資料以執行計算。工作中的步驟應透過 Slack 通知人員處理的記錄已準備好檢閱。步驟也應根據第一輪通知後的可設定的延遲,將通知升級至角色階層中的經理和上層。 此問題涉及數個不同的步驟,其中某些步驟可獨立進行。有許多方法可以分割工作。以下是一個分組: - 排程器。 - 處理記錄的步驟介面和實作 (無論處理類型為何)。 - 組織步驟的處理器。 - 排程器呼叫的「Apex 可叫用」。 - 通知件。我們使用 [Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html)。 - 片語「可設定的延遲」中隱藏一些複雜性。稍後我們會在此文章中檢閱此複雜性。 以下是內建架構的意見圖: 顯示流程排程器、Apex 非同步處理和不同可能步驟實作的結構圖 現在,拆分圖表並開始建立部分。 ## 透過已排程流程排程 「排程的流程」為排程機制提供數個優點: - 「排程的流程」可以封裝並部署為中繼資料。這不適用於透過 Apex (或透過「排程的工作」頁面排程的工作)。 - 對於需要呼叫的架構而言,「等候」元素十分重要。透過在流程中使用,在架構的「可叫用」部分中不需要呼叫。 - 排程細微性符合需求:「排程的流程」的最短間隔為每日。如果您需要更高的頻率 (例如每小時),請針對此需求重新考量「排程流程」。 設定「已排程流程」時的其他考量事項為環境關聯。叫用 Apex 動作前,請新增評估 `{!$Api.Enterprise_Server_URL_100}` 變數的「決策」元素。這可確保工作只會在預期的環境中執行,例如 UAT 和「生產」。此模式很重要,因為在 SDLC 期間,Sandbox 會經常重新整理或新建立,且如果沒有明確的環境檢查,則「排程的流程」可能會無意中在架構不適用於執行的環境中執行。在「決策」元素中使用 `contains` 運算子,可讓設定對未來的 Sandbox 建立或 URL 變更具有彈性。 最後,考慮架構應如何捕捉失敗。當流程呼叫任何「動作」時,請一律新增錯誤路徑;例如,您可以將錯誤導向至 [Nebula Logger 的](https://www.nebulalogger.com/)「新增記錄項目」動作。Nebula Logger 會將記錄寫入至自訂物件,因此客戶應注意記錄資料會耗用組織儲存空間—依預設,記錄會儲存在組織內 14 天,然後再清除;此保留期間是可設定的。Nebula Logger 也使用「平台事件」發佈記錄,因此記錄項目會與主要資料處理交易獨立儲存,這可確保即使主要的「流程」或 Apex 動作回復,也會抓取失敗。當考慮新增記錄架構時,客戶應評估預期的記錄量與保留需求。 以下是流程的外觀: 包含是否要執行「決策」元素的「排程流程」,允許呼叫的「暫停」元素,以及與「雲端記錄器」錯誤路徑一起呼叫的「Apex 可叫用」動作 讓我們繼續進行 Apex 程式碼的第一部分,且已滿足排程需求。 ## 建立步驟介面 定義 `Step` 介面: ```java public interface Step { void execute(); void finalize(); String getName(); Boolean shouldRestart(); } ``` 針對此文章,`step` 介面會顯示為外部類別以瞭解。架構本身是彈性的,小組可以使用他們偏好的任何 Apex 封裝模式來組織介面及其實作,只要所有「步驟」類別皆參照相同的介面即可。 我們介面中定義的方法有一些注意事項: - 雖然目前沒有引數,但當我們傳遞 `State` 類別 (或介面) 以在訂單重要時在步驟之間協調資料時,`execute` 會改善。 - `getName` 可以傳回 `System.Type` 值,而非 `String`。目標是讓協調流程層能夠記錄步驟名稱,而無須顯示其他內容。 以下是顯示這些組件如何相容的第一個具體實作。稍後只有一個例外,我們建議使用 Queueable Apex 在 Apex 中實作非同步處理;通常不需要批次 Apex (且不建議使用 `@future` 方法)。Apex 快速啟動,且搭配 Apex 游標,比批次 Apex 有許多優點。 ### Apex 游標類似實作 [Apex 游標](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm)提供傳統批次 Apex 模型的現代替代方案。與「批次」處理類似,游標實作可以分部 (每批次最多 2,000) 提取記錄。然而,游標允許在單一交易內進行多個取用,以在大量作業中啟用大幅提升的輸送量。 當採用游標作為此架構的一部分時,小組應注意目前的測試與模擬限制。測試中的游標行為可能與生產行為不同,因此設計避免依賴游標內部的測試策略,並改為在邊界驗證協調流程邏輯十分重要。隨著平台的發展,這些領域將持續改善,但核心指引仍會維持:相較於許多使用個案的批次 Apex,游標提供更高的效能和更少的協調流程負擔。 若要在系統提供的游標與您自己的程式碼之間定義清楚的邊界,我們建議在實作 `Step` 介面時建立類似游標的表示。請思考一下此程式碼: ```java public inherited sharing abstract class CursorStep implements Step { private static final Integer MAX_CHUNK_SIZE = 2000; protected Cursor cursor; private Integer chunkSize = System.Limits.getLimitDMLRows(); private Integer position = 0; protected abstract Cursor getCursor(); protected abstract void innerExecute(List records); public abstract String getName(); public virtual CursorStep withChunkSize(Integer chunkSize) { this.chunkSize = chunkSize; return this; } public void execute() { this.cursor = this.cursor ?? this.getCursor(); this.cursor.setFetchesPerTransaction(this.getFetchesPerTransaction()); List records = new List(); if (this.shouldAdvance()) { records = this.cursor.fetch(this.position, this.chunkSize); this.position += this.chunkSize; } this.innerExecute(records); } public virtual void finalize() { Logger.info('finished cursor step for ' + this.getName()); } public virtual Boolean shouldRestart() { return this.position < this.cursor.getNumRecords(); } protected virtual Integer getFetchesPerTransaction() { Integer maxRecordsPerFetchCall = 2000; if (this.chunkSize < maxRecordsPerFetchCall) { return this.chunkSize; } // Integer division rounds down // which is perfect for our use-case return this.chunkSize / maxRecordsPerFetchCall; } protected virtual Boolean shouldAdvance() { return true; } } ``` 記下 `Cursor` 類別。Apex 游標是 `Database.Cursor` 的例項,但我們的 `Cursor` 實作可讓我們靈活處理游標的缺點。以下是實作: ```java public virtual without sharing class Cursor { private static final Integer MAX_FETCHES_PER_TRANSACTION = Limits.getLimitFetchCallsOnApexCursor(); @TestVisible private static Integer maxRecordsPerFetchCall = 2000; private Integer cursorNumRecords; private Integer fetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION; private final Database.Cursor cursor; public Cursor( String finalQuery, Map bindVars, System.AccessLevel accessLevel ) { try { this.cursor = Database.getCursorWithBinds(finalQuery, bindVars, accessLevel); } catch (FatalCursorException e) { Logger.newEntry( System.LoggingLevel.WARN, 'Error creating cursor. This can happen if there' + ' are no records returned by the query: ' + e.getMessage() ); } } public Cursor setFetchesPerTransaction(Integer possibleFetchesPerTransaction) { // Handle accidental round downs from Integer division if (possibleFetchesPerTransaction == 0) { return this; } if (possibleFetchesPerTransaction > MAX_FETCHES_PER_TRANSACTION) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Fetches per transaction: ' + possibleFetchesPerTransaction + ' exceeded platform max fetches per transaction: ' + MAX_FETCHES_PER_TRANSACTION + ', defaulting to platform max' ); possibleFetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION; } this.fetchesPerTransaction = possibleFetchesPerTransaction; return this; } @SuppressWarnings('PMD.EmptyStatementBlock') protected Cursor() { } public virtual List fetch(Integer start, Integer advanceBy) { if (this.getNumRecords() == 0) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Bypassing fetch call, no records to fetch' ); return new List(); } Integer localStart = start; List results = new List(); while ( Limits.getFetchCallsOnApexCursor() < this.fetchesPerTransaction && results.size() < this.getNumRecords() && localStart < start + advanceBy ) { Integer actualAdvanceBy = this.getAdvanceBy(localStart, advanceBy); results.addAll(this.cursor?.fetch(localStart, actualAdvanceBy) ?? new List()); localStart += actualAdvanceBy; } return results; } public virtual Integer getNumRecords() { this.cursorNumRecords = this.cursorNumRecords ?? this.cursor?.getNumRecords() ?? 0; return this.cursorNumRecords; } protected Integer getAdvanceBy(Integer start, Integer advanceBy) { Integer possibleFetchSize = Math.min(advanceBy, this.getNumRecords() - start); if (possibleFetchSize > maxRecordsPerFetchCall) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Fetch size: ' + possibleFetchSize + ' exceeded platform max fetch size of ' + maxRecordsPerFetchCall + ', defaulting to max fetch size' ); possibleFetchSize = maxRecordsPerFetchCall; } else if (possibleFetchSize < 0) { possibleFetchSize = 0; } return possibleFetchSize; } } ``` 對於本文的其餘部分,我們會在參照 Apex 類別時省略 `sharing` 宣告。在實際上,請確保透過或不透過共用明確使用最上層類別,以符合您的物件模型和權限。 另請注意,我們的 `Cursor` 實作會委派至平台 `Database.Cursor`,接下來會討論其他優點。 首先,以下是對應的測試: ```java @IsTest private class CursorTest { @IsTest static void itCapsAdvanceByArgument() { String accountName = 'helloWorld!'; insert new Account(Name = accountName); String query = 'SELECT Name FROM Account WHERE Name = :bindVar0'; Map bindVars = new Map{ 'bindVar0' => accountName }; Cursor instance = new Cursor(query, bindVars, System.AccessLevel.SYSTEM_MODE); Assert.areEqual(1, instance.getNumRecords()); Assert.areEqual(accountName, instance.fetch(0, 1000).get(0).get('Name')); Assert.areEqual(1, System.Limits.getApexCursorRows()); } @IsTest static void itCapsMaxRecordsPerFetchCall() { Cursor.maxRecordsPerFetchCall = 20; Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1; List accounts = new List(); for (Integer i = 0; i < oneMoreThanMaxFetch; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Exception ex; List results; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ); try { results = instance.fetch(0, oneMoreThanMaxFetch); } catch (System.InvalidParameterValueException e) { ex = e; } Assert.areEqual(null, ex?.getMessage()); Assert.areEqual(2, Limits.getFetchCallsOnApexCursor()); Assert.areEqual(oneMoreThanMaxFetch, results.size()); } @IsTest static void itFetchesMultipleTimesPerTransactionWhenMoreThanMaxFetch() { Cursor.maxRecordsPerFetchCall = 20; List accounts = new List(); Set expectedFetchNames = new Set(); for (Integer i = 0; i < Cursor.maxRecordsPerFetchCall + 1; i++) { String accountName = 'Fetch' + i; expectedFetchNames.add(accountName); accounts.add(new Account(Name = accountName)); } insert accounts; Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1; Cursor instance = new Cursor( 'SELECT Name FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ); List results = instance.setFetchesPerTransaction(2).fetch(0, oneMoreThanMaxFetch); Assert.areEqual(Cursor.maxRecordsPerFetchCall + 1, results.size()); Assert.areEqual(2, Limits.getFetchCallsOnApexCursor()); Set actuallyFetchedNames = new Set(); for (Account account : (List) results) { actuallyFetchedNames.add(account.Name); } Assert.areEqual(expectedFetchNames, actuallyFetchedNames); } @IsTest static void itFetchesMultipleTimesPerTransaction() { Cursor.maxRecordsPerFetchCall = 1; insert new List{ new Account(Name = 'One'), new Account(Name = 'Two') }; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(2); List results = instance.fetch(0, 2); Assert.areEqual(2, instance.getNumRecords()); Assert.areEqual(2, results.size()); results = instance.fetch(2, 1); Assert.areEqual(0, results.size()); } @IsTest static void fetchesCorrectAmountOfRecords() { List accounts = new List(); for (Integer i = 0; i < 10; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(10); List results = instance.fetch(0, 2); Assert.areEqual(2, results.size(), '' + results); Assert.areEqual(1, Limits.getFetchCallsOnApexCursor()); } @IsTest static void doesNotExceedPlatformMaxFetch() { List accounts = new List(); for (Integer i = 0; i < 101; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Test.startTest(); Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(100); Integer counter = 0; List results; while (counter <= 100) { results = instance.fetch(counter, counter + 1); counter++; } Test.stopTest(); Assert.areEqual(101, counter); Assert.areEqual(0, results.size()); } } ``` 透過將 `CursorStep` 實作設 `Cursor` 為虛擬`Database.Cursor`,當實作不需要重複處理大型記錄集時,可在沒有實作的情況下作業,類似於在批次中傳回 `System.Iterable` Apex 而非 Apex。`Database.QueryLocator`範例如下: ```java public abstract class CursorLikeImplementation extends CursorStep { private final Cursor cursorLike; public CursorLikeImplementation(List previouslyRetrievedRecords) { this.cursorLike = new CursorLike(previouslyRetrievedRecords); } public override String getName() { return CursorLikeImplementation.class.getName(); } public override Cursor getCursor() { return this.cursorLike; } private class CursorLike extends Cursor { private final List records; public CursorLike(List records) { super(); this.records = records; } public override List fetch(Integer position, Integer chunkSize) { // clone, to keep the underlying list type List clonedRecords = this.records.clone(); clonedRecords.clear(); for (Integer i = position; i < this.getAdvanceBy(position, chunkSize); i++) { clonedRecords.add(this.records[i]); } return clonedRecords; } public override Integer getNumRecords() { return this.records.size(); } } } ``` 請注意,由於此類別也是抽象類別,因此會將 `innerExecute` 的具體實作保留給子類別。 `CursorLike` 內部子類別也有替代項目。如果您知道類似此步驟的具體版本不會通過其他管理員限制,您可以從 `CursorLike.fetch` 傳回 `this.records`,並覆寫父系 `CursorStep.shouldRestart()` 以傳回 false。這可讓您重複處理僅限於每個非同步交易 12 MB Apex 堆疊限制的清單。 ### 其他可能以步驟為基礎的實作 我們以游標為基礎的實作可讓我們在分頁大量資料時有足夠的彈性。同時,`Step`介面可讓我們彈性描述和壓縮各種步驟。 請思考流程式步驟: ```java public virtual class FlowStep implements Step { private final Invocable.Action specificFlow; private Boolean shouldRestart = false; public FlowStep(String specificFlowName, Map inputs) { this.specificFlow = Invocable.Action.createCustomAction('flow', specificFlowName); this.specificFlow.setInvocations(new List>{ inputs }); } public void execute() { List results = this.specificFlow.invoke(); for (Invocable.Action.Result result : results) { if (result.isSuccess()) { Map outputParams = result.getOutputParameters(); Object potentialShouldRestartValue = outputParams.get('shouldRestart'); // Flow does not enforce Booleans being initialized // so a null check is sadly necessary here if (potentialShouldRestartValue != null) { this.shouldRestart = this.shouldRestart || Boolean.valueOf(potentialShouldRestartValue); } } else { List errorMessages = new List(); for (Invocable.Action.Error error : result.getErrors()) { errorMessages.add( 'Error code: ' + error.getCode() + ', error message: ' + error.getMessage() ); } Logger.error( 'An error occurred within your auto-launched flow:\n' + String.join(errorMessages, '\n\t') ); } } } public virtual void finalize() { Logger.info(this.getName() + ' finished processing'); } public String getName() { return FlowStep.class.getName() + ':' + this.specificFlow.getName(); } public Boolean shouldRestart() { return this.shouldRestart; } } ``` 由於「流程」無法傳回符合 Apex 定義類型的輸出參數,因此在使用前,我們會先檢查是否有 `shouldRestart` 輸出參數。 某些步驟可能為功能標記。您可以實作邏輯來決定要包含哪些步驟,或針對停用的功能使用 no-op 步驟。[空白物件模式](https://refactoring.guru/introduce-null-object)是降低協調流程層內複雜性的常見方法: ```java @SuppressWarnings('PMD.EmptyStatementBlock') public class NoOpStep implements Step { // The null object pattern is commonly implemented // as a singleton to reduce memory consumption public static final NoOpStep SELF { get { SELF = SELF ?? new NoOpStep(); } private set; } public void execute() { } public void finalize() { } String getName() { return NoOpStep.class.getName(); } Boolean shouldRestart() { return false; } } ``` 我們現在有幾個要處理的建構區塊。讓我們看一下負責逐步解說步驟的協調流程層。 ## 建立步驟處理器 處理器是結構中的轉換點。我們必須決定誰定義要初始化哪些步驟以及何處。選項包括: - 讓處理器定義哪些步驟會對應至業務邏輯。此選項很簡單,但為了可讀性,其調整程度不佳。 - 使用自訂中繼資料 (CMDT) 定義對應。「中繼資料關係」欄位不支援 `ApexClass`,這會將類別名稱拼字寬鬆地與您的業務流程設定配對。您可以將欄位設為選項清單,並驗證類型是否存在 (`Type.forName()` 或查詢 `ApexClass`),以降低管理員風險,但由於 CMDT 記錄不支援觸發,因此會在執行階段進行驗證。此路線可測試,但管理員只能在生產環境中建立 CMDT 記錄—請小心進行。 - 定義記錄的對應。非管理員可以設定步驟,但部署會變得較困難,且環境可能會漂移。請謹慎進行。 在 [Clean Code 中](https://www.oreilly.com/library/view/clean-code-a/9780136083238/)有關如何處理此特定複雜性的著名引文: > 此問題的解決方法是將 `switch` 陳述式 [用於建立物件] 埋藏在抽象工廠的地下室,而不要讓任何人看見它。 考慮到這一點,而且由於我們目前的步驟數量已定義正確,且不太可能成長,因此步驟處理器也可以成為步驟的工廠。這可以使用列舉來驅動切換陳述式: ```java public enum StepType { TYPE_ONE, TYPE_TWO, TYPE_THREE, TYPE_FOUR // etc ... } ``` 然後,針對我們的 `StepProcessor`: ```java public StepProcessor implements System.Queueable, System.Finalizer, Database.AllowsCallouts { private final List steps = new List(); private Step currentStep; public StepProcessor setSteps(List stepTypes) { for (StepType type : stepTypes) { switch on type { WHEN TYPE_ONE { this.addTypeOneSteps(); } WHEN TYPE_TWO { this.addTypeTwoSteps(); } // ... etc } } this.cleanSteps(); return this; } public void execute(System.QueueableContext context) { this.currentStep = this.currentStep ?? this.steps.remove(0); if (context != null) { System.attachFinalizer(this); Logger.setAsyncContext(context); } Logger.info('Executing step ' + this.currentStep.getName()); try { this.currentStep.execute(); } catch (Exception e) { Logger.exception('Unexpected exception', e); } Logger.info('Finished executing step ' + this.currentStep.getName()); Logger.saveLog(); } public void execute(System.FinalizerContext context) { Logger.info('Executing finalizer for step ' + this.currentStep.getName()); Logger.setAsyncContext(context); switch on context?.getResult() { when UNHANDLED_EXCEPTION { // see the note below about this logging paradigm Logger.warn( 'Failed to run on step' + this.currentStep, context?.getException() ); } when else { this.currentStep.finalize(); if (this.currentStep.shouldRestart()) { this.kickoff(); } else if (this.steps.isEmpty() == false) { this.currentStep = this.steps.remove(0); this.kickoff(); } else { Logger.info('Finished executing steps'); } } } Logger.info( 'Finished executing finalizer for step ' + this.currentStep.getName() ); Logger.saveLog(); } public String kickoff() { return this.steps.isEmpty() ? null : System.enqueueJob(this); } private void cleanSteps() { for (Integer reverseIndex = this.steps.size() - 1; reverseIndex >= 0; reverseIndex--) { if (this.steps[reverseIndex] instanceof NoOpStep) { this.steps.remove(reverseIndex); } } } private void addTypeOneSteps() { this.steps.addAll( new List { new ExampleCursorStepOne(), new ExampleCursorStepTwo() } ); } private void addTypeTwoSteps() { this.steps.addAll( new List { new FlowStep(' ExampleInvocableName', new Map( 'exampleParameter' => true) ), new ExampleCursorStepThree() } ); } } ``` 顯示的工廠方法 (例如 `addTypeOneSteps()`) 可以委派如功能標記等疑慮;`cleanSteps()` 會對收集的步驟執行一次性檢查,以確保在真正非同步化之前沒有任何「空白」步驟。如下所示: ```java private Step getStepOrDefault(String customPermissionName, Step defaultStep) { if (System.FeatureManagement.checkPermission(customPermissionName)) { return defaultStep; } return NoOpStep.SELF; } ``` 自在「排程的流程」區段中提及「Nubula Logger」後,我們尚未討論錯誤處理。這是因為 `System.Finalizer` 可讓我們全面說明所有錯誤狀況的記錄,而無須在每個步驟中新增特定錯誤處理。每個 `Step` 都專注於執行,同時我們會記錄和取消任何不滿的路徑,使其在單元測試中出現。這支援安全迭代和生產層級警示 (針對所有 WARN 和 ERROR 記錄使用 [Slack Logger for Nebula](https://github.com/jongpie/NebulaLogger/tree/main/nebula-logger/plugins/slack) 外掛程式)。 關於錯誤記錄的一個注意事項:將步驟例項傳送至記錄訊息會假設在記錄中會顯示的內容有某種 Trust 層級。Apex 類別的預設 `toString()` 包含訊息中的所有靜態與例項級內容。這可能是可取的,或者可能會洩露敏感資訊。雖然此處的重點並非記錄和安全性,但請注意,對於某些系統,遵循如 `Step` 的介面也可能涉及強制覆寫 `toString()`。 ```java public interface Step { void execute(); void finalize(); String getName(); Boolean shouldRestart(); String toString(); } ``` 這種方法會讓每個物件建立者負責決定允許列印的項目,這可能是可取的。 在記錄層級:在 `StepProcessor` 層級,我們使用 `INFO`,即最高的非錯誤層級。當您在應用程式中更精確時,記錄層級應隨之減少。個別步驟可能會使用 `DEBUG` 作為概況資訊,並將 `FINE`、`FINER` 和 `FINEST` 保留為更詳細的輸出。記錄是一種藝術與科學,但遵循這些原則有助於讓記錄保持一致且實用。 ### 處理步驟處理器內的額外複雜性 繼續之前,讓我們簡要思考一下讓步驟處理器主控步驟用途邏輯的決定。在大型程式碼庫中,請考慮將 `StepProcessor` 設為虛擬或抽象,並讓子類別識別特定步驟以建立適當的關注分隔。 ## Apex 可叫用層 排程器最終會叫用 Apex。設定剩餘完成後,「可叫用 Apex」區段可決定應執行的步驟,並將 `List` 傳送至處理器: ```java public class DailyJobExecutor { @InvocableMethod(label='Execute Daily Job') public static void executeJob() { Logger.info('Executing daily Job'); List correspondingTypes = new List(); // based on [business logic], determine which step types // should be included for any daily invocation if (correspondingTypes.isEmpty() == false) { try { new StepProcessor().setSteps(correspondingTypes).kickoff(); } catch (Exception ex) { Logger.exception('Error starting job', ex); } } } Logger.saveLog(); } ``` 這是方程的一個簡單部分,使用記錄、資料或邏輯來決定要執行的步驟類型。「可叫用動作」很簡單,因為我們在其他位置壓縮了複雜性。我們也保護您免受非預期的例外狀況,並且讓每個組件容易進行隔離測試。 ## 處理呼叫 Slack 前的延遲 [Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html) 超出此文章的範圍,但需要重新查看一個潛在的問題:根據可設定的延遲在角色階層中向上通知人員。在紙本上,這很簡單,您可能會在 `StepProcessor` 中考量 `System.enqueueJob(this)`。使用 [System.AsyncOptions](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_AsyncOptions.htm),我們的初始傾向是使用 `enqueueJob` 超額來滿足此需求。 不過,目前透過 `System.AsyncOptions.MinimumQueueableDelayInMinutes` 延遲的上限為 10 分鐘。由於需求為 120 分鐘,因此仍有一些選項。天真的方法可能如下所示: ```java public class ExampleDelayedNotifier implements Step { private final List notifications = new List(); private final Slack.BotClient botClient = Slack.App .getAppByKey('some-slack-app-key') .getBotClientForTeam('slack team id'); // account for the initial delay, // so 120 - 10 = 110 private Integer delayMinutes = 110; public void execute() { if ( this.delayInMinutes > 0) { return; } Integer maximumAllowedCallouts = 100; while (this.notifications.isEmpty() == false && maximumAllowedCallouts > 0) { this.botClient.chatPostMessage(this.notifications.remove(0)); maximumAllowedCallouts--; } } public void finalize() { this.delayInMinutes -= 10; } public String getName() { return ExampleDelayedNotifier.class.getName(); } public Boolean shouldRestart() { return this.delayInMinutes > 0 || this.notifications.isEmpty() == false; } } ``` 實際上,延遲會傳遞至此類別,因為延遲是以組態為導向。 除非您確定只會有一個延遲通知類型,否則我們不建議使用此方法。它會在開始前耗用 11 個額外的非同步工作 (如果延遲增加,則會耗用更多工作)。該成本適用於一個工作,而不適用於許多工作。您也需要將方法新增至 `Step` 介面,讓每個步驟都能告知處理器重新啟動前要等待的時間,進而增加雜訊。 這讓我們有兩個有趣的可能性: - 如果您已在適當的時間間隔排程輪詢工作,則可以將延遲的步驟插入現有工作架構。您也應確定指定延遲達到 15 分鐘後 (Apex 排程 CRON 運算式的最短重新整理間隔為 15 分鐘)。這與可叫用 Apex 範例大致相符;排程會改為透過 Apex 執行。換句話說,您可以重複使用相同的基於 `Step` 的結構,根據「開始之後」時間戳記處理記錄,並根據選項清單或多重選擇選項清單對應回先前顯示的 `StepType` 列舉值來決定要使用的步驟。 - 或者,如果您喜歡定義額外 Apex 類別,請使用 `System.scheduleBatch()` 返回批次 Apex (不同於支援內部類別的 Queueable Apex,批次 Apex 類別必須是外部類別)。 請思考批次 Apex 範例。雖然我們一般建議使用「可排列 Apex」以獲得彈性和控制能力,但這是一種批次 Apex 仍是最高的個案: ```java public class DelayedNotifier implements Database.Batchable { private final StepProcessor processor = new StepProcessor(); public Iterable start(Database.BatchableContext bc) { return new List(); } @SuppressWarnings('PMD.EmptyStatementBlock') public void execute(Database.BatchableContext bc, Object scope) { // we don't need to actually do anything in execute, // we just need to start up the processor in finish } public void finish(Database.BatchableContext bc) { try { // you can imagine Notifier as an elided, // simpler version of the naive implementation // we showed above, now only focused on sending messages this.processor.setSteps(new List{ new Notifier() }).kickoff(); } catch (Exception ex) { Logger.exception('Unexpected error', ex); } finally { Logger.saveLog(); } } } ``` 然後,在 `StepProcessor` 中,想像一下先前顯示的 `addTypeOneSteps()` 方法已更新為此延遲步驟: ```java public StepProcessor implements System.Queueable, System.Finalizer, Database.AllowsCallouts { // .... unchanged top of class elided private void addTypeOneSteps() { this.steps.addAll( new List { new ExampleCursorStepOne(), new ExampleCursorStepTwo(), new DelayedNotifierStep() } ); } // ... private class DelayedNotifierStep implements Step { private final DelayedNotifier delayedNotifier = new DelayedNotifier(); // again — in practice this value would also be passed in private final Integer delayInMinutes = 120; public void execute() { System.scheduleBatch( this.delayedNotifier, 'Delayed notifier: ' + System.now().getTime(), this.delayInMinutes ); } public void finalize() { Logger.debug('Nothing to finalize, batch scheduled'); } public String getName() { return DelayedNotifierStep.class.getName(); } public Boolean shouldRestart() { return false; } } } ``` 雖然我們通常不建議這麼多跳轉,但此步驟延遲會變成另一個可重複使用的建構區塊。在 Apex 允許較長的延遲之前,這也代表產生此效果的最簡單方式 (如同所述,不需要輪詢機制)。 ## 結論 我們已使用物件導向設計來滿足需求,並建立了一個可調整規模的系統,同時平衡建立與維護的長期成本。雖然步驟宣告和例項化最終可能會超出其在 `StepProcessor` 中的位置,但此處沒有額外的技術負債。透過 `FlowStep`,管理員與開發人員可以共同決定何時無程式碼或 Pro-code 解決方案最有意義。 透過在 Apex 的 Queueable 架構中使用 `System.Finalizer` 介面,並與 Nebula Logger 搭配使用,我們建立了可測試的強大系統,即使未來的步驟缺乏明確的記錄,也會警示我們發生非預期的失敗。對於我們而言,此系統會成功地縮小數字,並降低成本和複雜性。它也為我們提供了對實際工作負載下 Apex 游標行為的寶貴洞察,協助我們精簡方法,同時改善功能本身。 透過將複雜、大量的工作量拆分成模組化執行步驟,以步驟為基礎的非同步處理架構架構可將平台限制轉換為工程優點,以實現企業規模的可預測效能、可觀察性與管治。步驟可以由管理員和開發人員設定,在任一情況下,步驟作者都可以安全地專注於觀察基本的平台管理員限制 (例如 DML 列,以及檢取的查詢列),而不必擔心如何調整每個步驟。 ## 繼續路徑 若要在企業實作之間作業並採用此模式,結構設計師應: - **評估現有自動化**以識別非同步協調流程可協助改善效能並增強可觀察性的區域。 - 透過明確的處理目標和離散的作者點 (例如流程或 Apex),將大型程序**分成**離散、獨立執行的步驟。 - **定義並分組步驟類型**,以加速跨業務單位的步驟重複使用與標準化。 - 使用新流程或現有自動化來 **試用方法**。您可能會驚訝地發現您在步驟內可免費找到多少個極端個案、關注您的內建記錄和可觀察性! ## 關於作者 James Simone 是 Salesforce 的首席軟體工程師,在平台上擁有十多年的經驗。他曾是 Salesforce 客戶和產品擁有者,在轉為開發之前,從 2019 年開始在 [Apex 的樂趣](https://www.joysofapex.com/)中撰寫有關 Salesforce 的技術深入分析。他先前曾在 [Salesforce 開發人員部落格](https://developer.salesforce.com/content-archive?authors=James%20Simone&content-type=Blogs&language=English)以及 [Salesforce Engineering 部落格](https://engineering.salesforce.com/author/james-simone/)上發佈文章。 ## 指南概觀 想要在 Salesforce Platform 上建立表單?您擁有多個選項,可跨越整個低程式碼到專業程式碼連續。代表低程式碼的是 Lightning 應用程式產生器中的「動態表單」和 Flow Builder 中的畫面流程。在連續的中間停留的功能是使用 LWC 擴充畫面流程,並使用 OmniStudio 建立面向客戶的表單。而代表 Pro-code 是 LWC 架構及其不斷成長的基本元件庫。 選項很好,但如何判斷哪一個 (或哪個組合) 是正確的選項?這就是此指南的開頭。 ## 重要道具 - **Takeaway #1:建立 Lightning 頁面的建立/編輯/檢視版面配置時,請使用「動態表單」。**您可能注意到此指南的比較表中缺少版面配置。繼續進行時,設定記錄詳細資料頁面的建議方法是使用 Lightning 應用程式產生器中的「動態表單」。請參閱「[版面配置](#版面配置-1)」一節,以取得為何我們預期不會進一步增強版面配置的詳細資訊。 - **Takeaway #2:如果您只需要為一個物件建立建立或編輯表單,請從 Lightning 頁面和「動態表單」開始。**這是在 Salesforce 平台上建立表單的最簡單方法。它也提供一些額外功能,例如控制欄位可視性的功能。如果您的需求較進階,請繼續閱讀。畫面流程、OmniStudio 或 Lightning Web 元件 (LWC) 可能更適合。 - **Takeaway #3:如果您要建立多頁表單或精靈,且沒有嚴格的 UX 或品牌需求,請從「畫面流程」開始。**畫面流程提供線性瀏覽架構,可協調多個表單。您可以使用 LWC 建構您自己的架構來在表單之間瀏覽,但我們建議讓「流程」為您執行繁重的工作,讓您可以專注於表單本身,而不必擔心[表單狀態](/docs/architect/zh-tw/well-architected/guide/engaging#表單)。 - **Takeaway #4:如果您需要 *表單後面的*其他邏輯或動作,請使用「畫面流程」、「OmniStudio」或 LWC。**這三種工具皆可讓您的解決方案執行建立或編輯單一記錄以外的工作。「更多」可能是更進階的邏輯,例如分支或迭代,或者可能是更多動作,例如與外部系統整合、傳送電子郵件或將通知推送至使用者的行動應用程式。 - **Takeaway #5:取得複雜的 UX 需求?需要動態處理可視性以外的項目?使用 LWC 或 Omniscript。**如果您的需求可以透過簡單主題與以欄為基礎的版面配置來達成,您可以直接在低程式碼產生器中建立表單。如需更精細地控制表單樣式,您需要 LWC 的最終彈性。如果您是 Industries 客戶,且需要像素完美的品牌標識或具有複雜階層資料,請使用 OmniStudio,這可讓您建立可處理複雜業務邏輯和資料轉換的消費者評分表單。 - **Takeaway #6:如果您需要測試自動化,請從 Lightning Web 元件開始。**您可以針對任何 LWC 撰寫單元測試,無論您計畫內嵌的位置為何。這可讓您建立更強大的測試策略,其中可能包含含有多筆記錄的大量測試和負數測試。[請參閱 Salesforce Well-Architected - 測試策略](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略),以取得建立測試的詳細資訊,協助您瞭解表單是否符合功能與非功能需求。 請記住,您的選擇不必是/或 - 您可以結合多個選項的功能。例如,如果您需要 Flow 的內建瀏覽系統以及 LWC 提供的完整樣式彈性,請同時使用。 ## 使用 Salesforce 建立表單的工具 下表概述使用 Salesforce 建立表單的可用工具,以及其必要技能和授權考量事項。稍後我們將深入瞭解每個工具支援的特定功能,以及如何在點擊型工具和程式碼型工具之間選擇 (以及何時結合這些工具):
所需技能 其他授權需求
動態表單 低程式碼 否
畫面流程 低程式碼 否
OmniStudio 低程式碼 + 專業代碼 需要產業封裝
畫面流程 + Lightning Web 元件 低程式碼 + 專業代碼 否
Lightning Web 元件 專業代碼 否
## 決策點概觀 下表包含在選擇產品時要考慮的決策點概觀,以及您應對每個決策點提出的問題。在本指南的其餘部分,我們將深入探討這些主題。
物件影響 決定您的表單要針對單一物件作業,還是需要針對多個物件作業。
表單範圍與瀏覽 判斷表單上的所有欄位是否會邏輯地符合單一畫面,或使用者是否應能夠在多個畫面之間瀏覽。
位置 識別您要內嵌表單的位置,可從 Salesforce 應用程式中的某一處到行動應用程式,甚至是外部網站。
控制項 識別使用者與您的表單互動時,需要在背景執行的動作或邏輯,包括資料轉換和與外部系統的整合。
驗證 判斷是否有超出 Salesforce 所提供標準系統層級驗證的任何額外輸入驗證需求。
安全性 決定您的表單在執行特定作業前是否應檢查使用者的存取權、您是否要控制可存取表單的人員,以及您是否要控制可內嵌表單的位置。
互動設計 識別應在表單中觸發動態回應的互動類型或條件。
樣式 決定所需樣式和 CSS 的精密層級。
版面配置 根據資料欄、索引標籤、可重複顯示資料區塊的能力,識別表單版面配置需求。
翻譯 決定您的表單是否需要本地化為其他語言。
UI 測試自動化 判斷您的 DevOps 程序是否需要您的表單來進行自動單元測試或自動端對端測試
度量 識別您想要追蹤表單用量的方式,包括頁面檢視、花費在表單上的時間量、完成率和成功率
封裝與部署 決定您要如何在建立表單後散佈或部署表單。
以下是我們在比較表格中使用的詞彙及其定義: - **可用:**與基本考量事項一起運作。 - **非理想:**可以運作,但不是最佳工具。 - **藍圖:**預估在未來 12 個月 (2025 年 6 月) 內的支援。 - **未來**:估計在未來 12 個月後的支援。 - **不可用:**未來 12 個月內沒有計畫支援此功能。 ## 決策點逐步解說 如同承諾,讓我們開始深入瞭解「動態表單」、「畫面流程」、「OmniStudio」、「含內嵌 LWC 的畫面流程」與 LWC 架構本身之間的各種比較點和功能差異。 ### 物件影響 如果您的表單針對單一 Salesforce 物件執行,我們比較的任何工具都會運作。使用跨物件或物件不符的形式,情況會變得更複雜。透過物件無效,我們指不會對應至任何 Salesforce 物件的輸入。或許您的表單代表您要傳送至外部服務的資料結構,例如 Stripe 或 DocuSign。或者,您在表單中使用數個輸入來計算值,然後將該值認可至資料庫。 #### 要詢問的問題: - 表單會對哪些物件進行操作? - 是否只是一個物件,還是有多個物件? - 您是否使用特定的物件 (例如帳戶、連絡人、機會、商機和個案),或您的表單也需要與其他物件搭配使用?
單一物件 Cross-Object 物件解析
動態表單 可用 可用 不提供
畫面流程 可用 可用 可用
OmniStudio 可用 可用 可用
畫面流程 + LWC 可用 可用 可用
LWC 可用 可用 可用
針對跨物件和物件不相符的形式,Flow 和 OmniStudio 皆是固定的選項。流程畫面中提供的元件本質上為不明智,因此您可以在背景中選擇要如何處理該資料。例如,使用在單一表單中輸入的資料建立多個背景記錄,或使用資料執行其他動作,例如產生 Chatter 貼文、傳送 Slack 訊息、傳送電子郵件或連線至外部服務。 針對簡單的個案,使用現有的 LWC 元件 (例如 Lightning 可以是降低所需程式碼以提供強大的解決方案的一個簡單方法。不過,針對涉及多個物件的情境,流程可提供所有物件的全方位控制,並移除開發人員探索複雜關係和相依性的需求。 OmniStudio 會更進一步地處理事項,且完全為物件感知—它會將使用者看到的表單與基本資料模型分開。OmniStudio 會改為使用如「[資料對應工具](https://help.salesforce.com/s/articleView?id=sf.os_dataraptors.htm&type=5)」和「[整合程序](https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_integration_procedures_48334.htm&type=5)」等工具來操作基礎 JSON,然後將其對應至 Salesforce 物件 (或外部資料)。「資料對應器」和「整合程序」是將您的 OmniStudio 表單與 Salesforce 內部和外部資料連線至 Salesforce 的兩個關鍵元件。使用拖放元素,您可以使用外部系統中的複雜階層資料,然後根據資料需要移至的位置,將資料轉換為符合您的需求。它們也允許您使用公式對陣列或資料清單執行數學和邏輯,如同 Apex。 [OmniStudio 整合_OmniStudio 整合_](/docs/architect/zh-tw/reference-diagrams/guide/omnistudio-integrations) ### 表單範圍與瀏覽 如果您可以從單一畫面表單取得所有使用者輸入,請從「動態表單」開始。然而,雖然記錄頁面中的「動態表單」可以使用「路徑」功能,以寬鬆地代表您業務流程中的各個階段,但可能不適合您大多數的使用個案。 #### 要詢問的問題: - 您是否需要單一畫面,或使用者需要在多個畫面之間瀏覽才能完成工作? - 您是否要讓使用者看見視覺化說明其填寫表單流程的進度? - 您的使用者是否需要以特定順序填寫每個畫面上的資訊,或者他們是否可以視需要在畫面之間來回移動?
單一畫面 多螢幕表單 進度指標 在步驟/畫面之間跳轉瀏覽
動態表單 可用 不提供 可用 不提供
畫面流程 可用 可用 可用 不提供
OmniStudio 可用 可用 可用 可用
畫面流程 + LWC 可用 可用 可用 可用
LWC 可用 不是理想 不是理想 不是理想
如果您需要的功能比「動態表單」所提供的更多,則 Flow、OmniStudio 和 LWC 之間的選擇也會取決於其他幾個問題: - 您的小組擁有哪些技能?針對更具管理力的組織,建議您從「流程」開始。如果您有 Industries 解決方案,且您的小組已熟悉 OmniStudio,且您的專案具有嚴格的 UX 需求,請從 OmniStudio 開始。 - 在表單底部顯示瀏覽列是否可以?如果畫面流程和 Omniscript 瀏覽體驗是不想要的 UX,請傾向 LWC。 - 表單後面必須發生什麼事?如果您需要管理員可設定的行為,請建立流程,或針對基本變更 (例如變更欄位標籤) 建立 Omniscript。否則,針對複雜的多物件關係,請建立 Omniscript 或 LWC。 - 如果您選擇 Flow 或 OmniStudio,您可能仍需要建立 LWC 以達成正確的 UX。如果您已經建立 LWC 來正確設定表單的樣式,請考慮是否過度[將該元件內嵌在流程中](https://developer.salesforce.com/docs/platform/lwc/guide/use-flow-embed-component.html)。 另一方面,如果您的解決方案看起來像精靈,使用者可在多個畫面之間瀏覽,請考慮使用 Flow 或 OmniStudio。流程與 OmniStudio 隨附內建的瀏覽模型,因此您無須建立和維護串連的 LWC。瀏覽為線性,具有正向動作、反向動作,以及用來儲存表單的機制以供稍後使用。如果表單符合您的目的,您也可以使用非線性瀏覽來建立表單。如需使用畫面流程的最佳範例,請查看 Salesforce Lab 的「[數位商店稽核」](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkOtUAL)封裝。 OmniStudio 透過提供標準瀏覽中呈現表單中「步驟」的進度指標,提供重要的瀏覽優勢。此步驟檢視會自動顯示使用者在指定多步驟表單上的位置。不同於「流程」,其可讓使用者按一下表單的各個步驟,在畫面之間進行跳轉。 無論您是建立單螢幕或多螢幕表單,請確保表單已[簡化](/docs/architect/zh-tw/well-architected/guide/engaging#表單),讓使用者能夠輕鬆瀏覽。 ### 位置 如果您將表單內嵌在標準 Lightning 記錄頁面中,我們比較的任何工具都會運作,但請注意「動態表單」目前僅適用於桌上型電腦。不過,如果您想要提供讓使用者從其他位置存取表單的體驗,您可能需要考慮其他選項。 #### 要詢問的問題: - 使用者是否需要透過桌上型電腦、行動裝置或兩者存取表單? - 使用者是否應能夠透過公用程式列從應用程式中的任何位置存取表單? - 您是否要使用快速動作讓使用者填寫表單而不必離開目前所在的頁面? - 您的表單是否必須在外部網站上可供使用?
Lightning 記錄頁面 Lightning 首頁或應用程式頁面 Aura Experience Cloud 網站 LWR Experience 雲端網站 內嵌 Snap 公用程式列 物件特定動作 全域動作 Salesforce 行動應用程式** Field Service Mobile Mobile SDK 外部網站與應用程式 自訂 LWC
動態表單 可用 不提供 不提供 不提供 不提供 不提供 不提供 不提供 可用 不提供 不提供 不提供 不提供
畫面流程 可用 可用 可用 可用 可用 可用 可用 藍圖 可用 適用*** 不提供 藍圖 可用
OmniStudio 可用 可用 可用 不提供 不提供 可用 不提供 不提供 可用 不提供 不提供 可用 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用 藍圖 可用 不提供 不提供 不是理想 可用
LWC 可用 可用 可用 可用 可用 可用 藍圖 藍圖 可用 藍圖 藍圖 可用 可用
*流程可內嵌在 LWR Experience Cloud 網站中,但有您必須記住的考量事項。
**Salesforce 行動應用程式支援流程和 LWC,但 Salesforce 行動應用程式不支援您可以內嵌流程和 LWC 的所有方式。例如,行動裝置支援物件特定動作,但公用程式列項目不支援。
***Field Service 行動應用程式不支援許多最新的「流程」功能,因為其設計來自較舊的「流程引擎」和「畫面流程執行階段」,其有特殊修改讓其離線運作。
由於它們需要記錄內容,因此只有 Lightning 記錄頁面支援「動態表單」。不過,Experience Cloud 頁面不支援「動態表單」。此限制已存在,因為 Experience Cloud 不使用「動態表單」相依的基礎架構:Lightning 頁面。我們正在根據 Experience Cloud 中「動態表單」的要求來評估此項目。 您可以建立需要記錄內容的流程或全域運作的流程。因此,您可以在各種位置內嵌流程。針對記錄相關流程,這可能是 Lightning 記錄頁面、Experience Cloud 記錄頁面、物件特定動作或「動作與建議」部署。針對全域流程,這可能是公用程式列、其他 Lightning 或體驗產生器頁面、Snap 或外部應用程式。目前不支援將流程作為全域動作,但您可以將流程包含在 Aura 元件中作為因應措施。 OmniStudio 可讓您建立可編輯的 FlexCard 和 Omniscript,您幾乎可將其放置在您可以放置流程的任何位置。不過,雖然可編輯,但無法封裝。 LWC 支援高度的可重複使用性,因為您正在建立可透過 Salesforce、社群甚至在開放程式碼專案中的中繼資料與目標相關聯的元件。LWC 元件也可以透過 [Lightning Out](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lightning_out) 內嵌在您自己的網站內。 [在外部網站上 Lightning Out _在外部網站上 Lightning Out_](/docs/architect/zh-tw/reference-diagrams/guide/lightning-out-on-external-sites) Lightning Web 元件目前不支援作為快速動作 (物件特定或全域動作),但您可以將 LWC 封裝在 Aura 元件中作為因應措施 (就像您使用流程一樣)。LWC 元件也可以使用 [Lightning 流程](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) 元件啟動流程。 OmniStudio 優於透過 OmniOut 功能向外部網站公開內容。透過 OmniStudio 和 OmniOut,您可以將 OmniScript 表單和 FlexCard 元件編譯為標準元件,並在第三方網站或應用程式中將其在平台外執行。 目前 Mobile SDK 範本中未正式支援本指南涵蓋的任何格式技術。如果 Mobile SDK 對您的使用個案至關重要,您最好在行動應用程式中原生建立表單或建立 Visualforce 頁面,同時牢記 Salesforce 結構正確的 [尺寸規格](/docs/architect/zh-tw/well-architected/guide/engaging#尺寸規格)指引。 **路線圖備註:**Mobile SDK 小組正在主動支援 Visualforce 頁面中的 LWC。 ### 控制項 如果您需要使用表單中的值來建立或更新記錄,則「動態表單」十分適用。針對任何超出這些功能,您需要利用 Flow、OmniStudio 或 LWC。這些功能可能包含決策或迭代的層級,或使用表單中的輸入產生 Slack 貼文或電子郵件。 #### 要詢問的問題: - 您希望在背景執行的動作或邏輯為何? - 您的資料模型是否包含階層資料? - 您的表單是否需要在單一交易內或跨多個交易完成其作業? - 您是否需要與外部系統整合? - 您對可重複使用性和模組性有何需求?
記錄與動作 階層資料管理 在一個交易內作業 跨多個交易作業 整合 模組設計與重複使用 封裝
動態表單 不提供 不提供 不提供 不提供 不提供 不提供 可用
畫面流程 可用 藍圖 可用 可用 可用 可用 可用
OmniStudio 可用 可用 可用 可用 可用 可用 不提供
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用 可用
流程提供標準動作以張貼至 Slack、傳送電子郵件和與 Quip 文件互動,因此您不需要撰寫程式碼來進行這些作業。LWC 透過使用與 [使用者介面 API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) 互動的電線轉接器,提供與單一記錄和相關物件的豐富互動。當使用 [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html) 的電線時,LWC 也可以與多個記錄互動。 [透過電線轉接器進行 LWC 互動 _Lightning Web 元件透過電線轉接器進行互動_](/docs/architect/zh-tw/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters) 如上所述,OmniStudio 使用整合程序和資料對應器,輕鬆地將外部和內部的資料提取並轉換至 Salesforce。由於您可以使用許多免程式碼函數,因此可使資料集以各種層級的關係壓平並展開。 **路線圖備註:**流程即將支援更新插入記錄集合的功能,以及管理階層資料。 流程、OmniStudio 和 LWC 皆與 Apex 整合,因此您可以輕鬆地填補選擇的任何解決方案中的任何間隙。例如,如果您需要從 LWC 篩選記錄,您可以一律使用 Apex 的電線轉接器來建立複雜的 SOQL 查詢。如果您因按一下情節而感到困惑,請將 Flow 或 OmniStudio 視為適用於伺服器端需求的 Apex 控制項可行替代方案。 此處的次要問題是您要立即認可動作,還是將動作延後至表單的特定部分。如果您使用多頁表單,這特別有用。流程可讓您輕鬆地從多個表單 (流程畫面) 結合輸入,並在精靈 (流程) 中稍後使用這些輸入來執行一些作業。事實上,我們建議以這種方式設計流程—在結尾執行動作—以防使用者在畫面之間反向跳轉,變更其回答。 #### 控制作業 交易和 [管理員限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)是 Salesforce Platform 的一種生活方式。如果您的使用個案相當簡單,則控制特定作業發生的交易並不重要。不過,有一些使用個案會讓您想要將多個作業合併到單一 [交易中](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#交易),而非在多個交易之間執行。一些範例: - **回復或不回復**:這就是問題。假設您的表單在背景建立多個記錄。如果第三個記錄無法建立,是否應回復前兩個記錄?如果您的每個動作彼此獨立,請隨時在個別的交易中執行這些動作。不過,如果這些項目相依,且您希望其中一個失敗也回復其他項目,請在單一交易中實作。如果您的表單在「流程」中,您可以使用「錯誤」路徑中的「回復」元素來回復交易並確保資料完整性。 - **對管理員限制的下游影響**:尤其是當您的表單建立或更新記錄時,請考量該作業的下游影響為何。根據此記錄變更,會觸發哪些程序、工作流程規則、流程觸發、Apex 觸發或儲存順序中的其他項目?這些集合變更會如何影響在該交易中耗用的管理員限制?如果特定記錄變更會造成許多影響您限制的下游變更,請考慮將該記錄變更隔離至其自己的交易。 - **批次處理**:即使是在 UI 內容中,您也可能需要同時批次多個更新。假設您的多畫面表單重複處理大量記錄。請等到您收集所有記錄的更新,然後提交一個要求來更新所有記錄,而不是在每個畫面之後認可記錄更新。 當您使用「動態表單」建立或編輯記錄時,您只會執行一個作業,且該作業一律是淨新交易的開始。 建立畫面流程時,您可以大幅控制在指定交易中發生的狀況。畫面與本機動作會作為交易之間的邊界。以下是在畫面流程結構中如何管理交易的概況摘要。 1. 一般使用者與畫面互動,然後按一下「**下一步**」。 2. 用戶端會使用輸入將要求張貼至 API。 3. API 接收要求,且會開啟交易與資料庫連線。API 接著呼叫流程引擎來叫用要求。 4. 「流程」引擎會在流程定義中接管並遵循適當的路徑,直到它達到「畫面」或「本機動作」節點為止。接著引擎會將該節點的相關資訊傳回給 API。 5. API 會建立一個回應物件,其中包含要呈現的下個畫面的詳細資料,並將該物件傳回給用戶端。此時系統會認可資料庫變更 (追蹤 [儲存訂單執行](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作)),並關閉資料庫連線和交易。 6. 用戶端使用 API 回應來呈現下一個畫面讓使用者互動。 7. 從步驟 1 重複此步驟。 換句話說,畫面會「中斷」交易。發生此情況時,系統會認可任何待處理動作或 DML、結束先前的交易,並開始新的交易。
多畫面流程 正確的設計是您在指定交易中分組的作業。讓我們逐步解說一些範例。
具有個別交易的畫面流程
在左側,您可以看見在多個畫面收集輸入的流程,然後在一個交易中執行數個動作。
右側的流程會在個別的交易中執行每個作業。
「流程」小組最近導入新元素:如果在一系列資料庫作業中單一作業失敗,則「回復記錄」元素可讓您回復整個交易。
具有多個建立記錄的畫面流程

假設您的流程會建立記錄、更新記錄,然後建立更多記錄,如右側的下一個流程所示。
在此情節下,如果前兩個元素成功,而最後一個元素失敗,則前兩個 DML 作業仍會建立並更新這些記錄,而第三個 DML 作業則不會。
含回復的畫面流程
透過使用「回復記錄」元素,如果所有三個作業都必須同時進行,您可以確保整個交易都會回復,如左側的最終流程所示。 如需詳細資料,請查看「[交易中的流程](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm)」和「[交易中的流程大量處理](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm)」。Salesforce Well-Architected 的「自動化」區段也會深入瞭解此 [資料處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)。 您從 LWC 控制交易的能力取決於 LWC 用來執行其作業的基本服務。如果您使用 Lightning 記錄格式基本元件,則在提交表單後,基本作業 (建立或更新記錄) 會在獨立交易中發生。 一般而言,這些規則適用於: - 每個 UI API 呼叫都會隔離為其自己的交易。 - 如果您需要在單一交易中執行多個作業,請將輸入傳送至伺服器端技術,例如 Apex 控制項或流程。該技術適用的一般交易規則。 #### 外部整合 Flow、OmniStudio 和 LWC 都支援平台事件 (適用於以 [事件為導向的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven)) 和 API 整合。除了自訂 Apex 程式碼外,Flow 與 OmniStudio 都支援整合 API 的陳述性機制。 如果您需要連線至 MuleSoft API 或 RPA 機器人,請使用 MuleSoft Services。這會產生「外部服務」。 [透過 MuleSoft _External 整合 (透過 MuleSoft API 和 RPA 機器人) 的外部整合_](/docs/architect/zh-tw/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots) 如果 API 有 OpenAPI 結構描述,請建立「外部服務」。 [透過 OpenAPI 的外部整合 透過 OpenAPI 結構描述對 API 的*外部整合*](/docs/architect/zh-tw/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas) 否則,請使用「流程」中的「HTTP 呼叫」功能,或使用 OmniStudio 中的「HTTP 動作」。流程的 HTTP 呼叫由「外部服務」提供技術支援。 [透過 HTTP 的外部整合 _透過 HTTP 的外部整合_](/docs/architect/zh-tw/reference-diagrams/guide/external-integrations-via-http) OmniStudio 提供一組豐富的整合功能,可透過「整合程序」呼叫外部系統,並使用「資料對應器」轉換資料。(如需詳細資訊,請參閱 [物件影響](#物件影響)) 無論您是使用自訂 Apex 還是外部服務來實作,呼叫都是呼叫。以下是您需要瞭解的事項。 1. 呼叫可能需要很長的時間。 2. 當同步執行呼叫時,呼叫會在資料庫交易開啟時執行。 3. 如果您有待處理的資料庫作業,Salesforce 不會讓您保持資料庫交易開啟狀態。 要記住的主要限制是所謂的「**_髒交易」_**的危險,其中您執行建立、更新或刪除作業,然後在相同的交易中執行呼叫。由於上述考量事項 #3 不允許使用此模式,這當然存在於考量事項 #1 與 #2 之故。 在「流程」中,您可以透過中斷交易來解決此限制。請記住,畫面與本機動作都會重新導入瀏覽器內容,這會中斷交易。雖然您在使用外部呼叫時可以使用畫面和本機動作,但我們建議在可叫用進階設定中啟用「交易控制」。「交易控制」是可叫用動作的功能,可讓您在進行呼叫之前自動結束交易。您可以透過在叫用動作的「進階」區段中選取「一律開始新的交易」來啟用「交易控制」。 透過呼叫進行外部整合 LWC 對交易造成的呼叫影響較不複雜。一般而言,您會使用 Lightning 資料服務 (LDS) 執行資料作業,然後使用 Apex 控制項進行外部呼叫。此設計可保護您免受雜亂的交易,因為 LDS 呼叫在自己的交易中會與 Apex 呼叫分開分隔。 _如需有關 Apex 呼叫、外部服務和一般資料整合功能的深入指引,請參閱《與 Salesforce 整合資料的[結構設計師指南](/docs/architect/zh-tw/decision-guides/guide/data-integration)》。_ #### 可重複使用性和模組性 「動態表單」不支援重複使用。每個「動態表單」都會繫結至特定物件的特定 Lightning 記錄頁面 (雖然您可以將該 Lightning 記錄頁面指派給多個應用程式、設定檔等)。 就像您可以撰寫要在多個其他元件之間使用的文件庫、公用程式和元件一樣,您可以在使用 **_子流程_**的功能建立流程時套用類似的設計模式。將您的流程儲存在較小的模組化分類中,然後使用「子流程」元素從其他流程呼叫流程。如果您的設計需要此流程,您可以建立一個流程,此流程可獨立且作為另一個流程的子流程有用。 OmniStudio 本身為模組化而建立。「資料對應器」、「Omniscript」、「FlexCard」和「整合程序」皆獨立建立,且可以互換運作。此外,FlexCard 可以建立為 LWC 元件,這些元件可內嵌在其他 LWC、Omniscript、記錄頁面和 Experience Cloud 網站中。 畫面流程、Omniscript 和 LWC 皆可建立以重複使用,並內嵌在各種位置,包括外部網站和 Lightning Out 應用程式。當您將解決方案設計為可[編譯](/docs/architect/zh-tw/well-architected/guide/composable)時,您會得到其他優點,例如適應性和穩定性。 ### 驗證 用於建立或更新記錄的所有技術皆遵循系統層級驗證,無論是傳統驗證規則還是內建於 Apex 觸發中的自訂驗證。無論您使用哪種技術來執行記錄變更,每個變更都會通過儲存順序。這表示除了驗證規則之外,記錄變更也會由任何數量的儲存前或儲存後流程、觸發、升級規則、指派規則等處理。如果您尚未準備好,請務必將 Apex 加入書籤並熟悉 Apex [執行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)。 #### 要詢問的問題: - 您的表單是否有系統層級驗證以外的其他需求? - 您是否需要在表單中動態將欄位設定為必要或唯讀?
遵循系統層級驗證 此表單特有的自訂欄位級驗證 自訂欄位級驗證
動態表單 可用 不提供 不提供
畫面流程 可用 不提供 藍圖
OmniStudio 可用 可用 可用
畫面流程 + LWC 可用 可用 可用
LWC 可用 可用 可用
流程畫面或 Omniscript 步驟上的輸入本質上為未繫結,因此表單本身不會原生遵循與特定物件相關聯的系統級驗證。然而,您用來建立或更新記錄的任何值都會由儲存順序處理,這表示這些值會通過物件的系統級驗證。不過,請注意,並非所有畫面流程元件都支援輸入驗證。自 Summer '24 起,不支援輸入驗證的剩餘畫面元件為選項按鈕、選項清單、多重選擇選項清單、核取方塊群組和選項對應。 如同版面配置,「動態表單」可讓您在頁面層級設定必要性與唯讀狀態。不過,您無法覆寫系統層級設定。 流程提供自訂表單輸入驗證的彈性。雖然某些檢查是在用戶端執行 (例如標記遺失的必要欄位或不相容的值),但用戶端驗證不會阻止使用者嘗試瀏覽。實際驗證會在伺服器上進行。當使用者按一下「**下一步」** 時,流程會將輸入傳送至伺服器進行驗證。如果任何輸入傳回為無效,則會封鎖瀏覽,並顯示適當的錯誤。伺服器會透過檢查: 1. 輸入的必要性設定,或輸入的值是否與基本資料類型相容。 2. 該輸入的自訂驗證:多個標準元件 (「核取方塊」、「貨幣」、「日期」、「日期/時間」、「長文字區域」、「數字」、「密碼」和「文字」) 支援每個畫面的自訂驗證。提供布林值公式運算式和錯誤訊息,以在未符合公式運算式時顯示。 3. 基本元件的自訂驗證:如果您要為流程建立自訂 LWC,請將您自己的驗證程式碼新增至 validate() 方法。 OmniStudio 透過「[設定錯誤」](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) 動作,搭配「[條件檢視」](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) 和「[傳訊」](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5) 元件,提供豐富的錯誤和驗證處理功能。 在 LWC 端,大多數基本元件都會執行自己的用戶端驗證。例如,Lightning 記錄格式遵循系統層級需求,但不遵循頁面層級需求。針對您的自訂元件,您可以 Build Your Own 驗證機制。 需要使用者輸入資料的欄位應在表單中提前顯示。在提交表單前,請盡可能在用戶端驗證使用者輸入。如需簡化表單的更多最佳作法,請參閱 Salesforce Well-Architected - 參與中的[表單](/docs/architect/zh-tw/well-architected/guide/engaging#表單)指引。 ### 安全性 一般而言,安全性是一個複雜的主題,當涉及建立表單時,您可能甚至不會考慮到許多考量事項。在基礎層級,您會想要確保表單在正確的內容中執行,且使用者擁有使用其基本資料所需的權限。但除此之外,您也可能想要採取額外的措施來清除 Rich Text 欄位中潛在的惡意程式碼或 URL、防止特定使用者完全無法存取表單,或限制管理員未來可能內嵌表單的位置類型。選擇工具之前,請務必徹底記錄您的安全性需求。Salesforce 結構正確的 [安全性原則範本](/docs/architect/zh-tw/resources/guide/security-policy-template)包含此類型文件的原則。 #### 要詢問的問題: - 表單是否應在執行某些作業前檢查使用者的存取權? - 您應該消毒使用者輸入嗎? - 您想要控制可以存取表單的人員嗎? - 您想要控制表單的內嵌位置嗎?
提升使用者權限 控制擁有存取權的人員 限制允許的位置
動態表單 不提供 可用 不提供
畫面流程 可用 可用 不提供
OmniStudio 不提供 可用 不提供**
畫面流程 + LWC 可用 可用 不提供
LWC 適用* 可用 可用
*需要 Apex
**雖然 Omniscript 無法具有指定的目標位置集,但 FlexCard 可以。
#### 提升使用者權限 當在 **_使用者環境中_**執行某些作業時,Salesforce 會強制執行一系列的存取檢查,包括根據您組織的共用規則驗證欄位級安全性、CRUD 權限和記錄存取權。例如,只有在使用者能夠更新個案、適當的欄位級安全性,以及對問題記錄的存取權時,才能執行個案更新表單。但如果您希望使用者能夠在使用*您*的表單時執行特定作業,而不是透過任何其他表單或互動,該怎麼辦?這就是 **_系統內容_**的開頭。 系統內容是提升執行中使用者在工作階段期間權限的方式,因此使用者不需要 (例如,更新「個案」物件的存取權) 才能成功完成個案更新表單。這對於未經驗證的社群特別有用。您可以將表單設定為在系統環境中執行,而不是授與來賓使用者潛在危險的技能。 當然,系統內容是雙邊形的劍,您只能在需要時使用。當表單在系統環境中執行時,每個單一 CRUD 作業都會略過物件和欄位級安全性和共用,而不只是您關注的特定作業。另請注意,系統內容並不影響 Salesforce 將執行動作使用者視為何,也就是您在「上次修改者」欄位中看到的名稱。針對您的表單執行的每個作業 (例如個案更新),執行動作使用者是執行使用者,即使表單在不同內容中執行也是如此。 「動態表單」、「Omniscript」與 LWC」一律在使用者環境中執行,無法覆寫此行為。 畫面流程依預設會在使用者環境中執行,但您可以將其設定為在系統環境中執行。您可以選擇流程應授與所有資料的存取權,還是仍應強制執行如共用的記錄級存取權。 - 如果您將 Lightning 元件內嵌在在系統環境中執行的流程中,則流程不會覆寫元件的內容。如果您需要略過使用者存取檢查,我們建議您使用流程來執行這些作業,並將適當的資料傳送至 Lightning 元件或傳送出來。某些立即可用的元件 (例如「對應」) 無法在系統環境中作業。 - 如果您的流程呼叫 Apex 動作,則需要瞭解一些細微差別。如果 Apex 類別設定為繼承共用,則無論流程設定為何,它都會在共用的系統環境中執行。如果類別沒有明確的共用宣告,則無論流程設定為何,類別都會在系統環境中執行,而不會共用。如果類別設定為共用或不共用,則它會這麼做,並覆寫流程的內容。 **使用 Experience Cloud 網站在系統環境中查詢記錄:** 如果您在 Experience Cloud 網站 (**特別是未經驗證**) 上的系統環境中執行流程,建議您僅將特定欄位儲存在「取得記錄」元素中。當您使用「流程」並將「取得記錄」元素的結果傳遞至子流程、可叫用動作或 Lightning 元件時,可透過瀏覽器的開發人員工具檢查該物件中的所有欄位。這可能會讓您可能不想要的 Experience Cloud 網站使用者可以使用欄位。透過在「取得記錄」元素中指定特定欄位,您可以確保僅顯示正確的欄位,即使系統內容已啟用也是如此。 請注意,Omniscript 邏輯是在用戶端執行,這可讓攻擊者使用瀏覽器的開發人員工具修改 Omniscript 的預期執行*,並*檢視整合程序、資料對應器和 Apex 方法呼叫的回應。當您使用 Omniscript 時,建議盡可能在伺服器端執行業務邏輯,並在透過 [@InvocableMethod 註釋](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5)公開的任何 Apex 方法上實作輸入驗證規則。 **消毒輸入:** 若要保護您的組織免受惡意執行動作的影響,也請考慮輸入消毒。假設您在可公開存取的表單上有輸入,可對應至您組織中的 Rich Text 欄位。您可能會想考慮使用自動化方式去除任何可能隱藏惡意 URL 的 HTML。一般而言,在表單層級實作此消毒並不理想,因為您可以讓任意數量的來源寫入這些欄位。我們建議建立「快速欄位更新流程」(儲存前) 或在物件上使用現有的 Apex 觸發來刪除或修改任何可能輸入在表單中的潛在 HTML。 **_最佳作法:_** - _除非您需要針對特定作業提升執行中使用者的存取權,否則請讓流程在其預設內容中執行。_ - _基於安全考量,請避免在系統環境中為來賓使用者執行流程。建立具有有限欄位存取權的權限集,以改為指派給 Experience Cloud 網站的來賓使用者設定檔。_ - _在 Experience Cloud 網站上查詢系統內容執行流程中的記錄時,請僅將您需要的欄位儲存在「取得記錄」元素或「可叫用動作」中。_ - _如果流程執行各種作業,且並非所有作業都需要增強的存取權,請使用子流程來區隔應在系統環境中執行的作業。_ - _如果您計畫將表單內嵌在外部網頁中,請考慮使用快速欄位更新流程或 Apex 觸發來清理使用者輸入,以移除 HTML,以避免惡意執行動作的任何潛在網路釣魚攻擊。_ #### 其他備註: - 依預設,Omniscript、FlexCard 和 LWC 會在使用者環境中執行。 - LWC 預設會在使用者環境中執行,流程則會在使用者環境中執行,但您可以在 Apex 控制器中覆寫流程。 - 透過 UI API 執行的作業會在使用者環境中執行。 - 透過 Apex 控制項執行的作業取決於該類別。若要在系統模式中執行這些作業,請設定共用或不共用的 Apex 類別。 #### 存取控制 如果您需要控制可以存取表單的人員,您可以經常查看內嵌表單的容器。例如,您可以將 Lightning 頁面指派給特定應用程式、記錄類型或設定檔。如果表單中的某些輸入是敏感的,請使用可視性規則來進一步控制向人員顯示的內容;此功能適用於「動態表單」與畫面流程。 您可以將流程[限制為](https://help.salesforce.com/articleView?id=flow_distribute_security.htm)特定設定檔或權限集,就像您可以 Apex 類別或 Visualforce 頁面一樣。依預設,流程不受限制,這表示任何具有「執行流程」使用者權限的使用者都可以執行流程。 如果您使用 OmniStudio,您可以設定 [Apex 類別權限檢查器](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5),以確保使用者需要對管理從 Omniscript、FlexCard、Classic 卡片或 REST API 呼叫之遠端動作的 Apex 類別明確存取權。 - 備註 Apex 類別權限檢查預設為針對新建立的指令檔啟用。不過,必須為任何現有指令檔手動啟用。 - 另請注意,Apex 類別權限檢查僅適用於 Apex 類別。我們也建議設定 [整合程序和資料對應器](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5)的設定檔層級權限。 如需來賓使用者權限的詳細資料與最佳作法,請參閱: - [來賓使用者記錄存取最佳作法](https://www.learnexperiencecloud.com/s/article/Guest-User-Record-Access-Development-Best-Practices#Pattern6) - [開發安全網站:已驗證與來賓使用者](https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_security_authenticated_and_guest_users.htm) **_最佳作法:_** - _如果您要向來賓使用者公開流程,請僅授與來賓使用者設定檔其所需流程的存取權。雖然可以將「執行流程」新增至來賓使用者設定檔,但我們認為這是一種有風險的作法。_ - 在系統環境中作業的流程需要特別小心*。強烈建議您將這些流程限制為特定使用者集,因為這些流程擁有較少的檢查和平衡功能來保護您的資料。* - _確保在來賓使用者社群中執行 Apex 的任何 Omniscript 在 Apex 類別定義中具有共用權限。_ - _在您的「來賓使用者」設定檔上,僅指派您要讓來賓使用者能夠呼叫的 Apex 類別,否則您無意中可能會向來賓使用者公開其他業務邏輯。_ 針對 LWC,您可以檢查執行使用者的權限指派,確認其是否具有特定標準或自訂權限。您可以直接從 JavaScript 匯入來自 @salesforce/userPermission 和 @salesforce/customPermission 範圍模組的 Salesforce 權限。或者您可以使用 Apex 來檢查相同項目。 #### 內嵌控制 只有在 Lightning Web 元件已新增為有效的 [目標](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags)時,才能在指定的位置使用。例如,您可以讓元件在記錄頁面上可用,而無法作為公用程式列項目使用。 啟用畫面流程後,無論您是否打算隨處可用,畫面流程支援的所有位置皆可使用該流程。不過,Flow Builder 支援具有畫面的多種類型的流程。結點類型為「畫面流程」,但有一些其他專用類型僅限於特定位置。例如,Field Service 行動應用程式僅支援您猜到的 Field Service 行動流程。同樣的情況也適用於僅 Experience Cloud 支援的「連絡要求流程」。 無論流程類型為何,進行流程的個人都無法控制流程的內嵌位置。流程會在該流程類型支援的每個位置中提供使用。 如果您使用的是 Salesforce Industries,則在 Omniscript 方面會有輕微的警告:雖然您無法為 Omniscript 本身指定目標,但您可以為您可能要內嵌的 FlexCard 指定目標。 ### 互動設計 靜態形式屬於過去。今天,您需要為此使用者 (這次是此地) 以正確的內容與值來動態更新表單。讓我們討論一下 Salesforce 表單建立工具在此情況下可能發生的功能。 #### 要詢問的問題: - 哪些類型的互動或條件應在您的表單中觸發動態回應? - 當表單正在填寫時,您是否需要在背景中執行螢幕外作業? - 您是否需要將欄位設定為可見、必要、唯讀或已停用,或根據表單輸入變更格式?
執行螢幕外資料作業 條件值與計算 條件化可視性 條件式必要性 條件式格式化 條件式唯讀狀態 條件式停用狀態
動態表單 不提供 不提供 可用 不提供 藍圖 不提供 不提供
畫面流程 可用 適用** 可用 適用* 不提供 適用** 適用**
OmniStudio 可用 可用 可用 可用 可用 可用 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用 可用
*限於使用資源選擇器而非靜態核取方塊的元件
** 限制的 Beta 版
透過反應性畫面,畫面流程的互動性現已實現。反應性可讓流程畫面上的個別元件彼此通訊,讓畫面流程變得無限強大。 **執行螢幕外資料作業:**「畫面流程」提供透過「畫面動作」在相同畫面上提取資料的陳述性方法。畫面動作可讓您在畫面中的任何變更或使用者按一下「動作按鈕」元件時觸發自動啟動流程。接著,您可以將這些自動啟動流程的結果對應至相同的畫面,以免使用者需要瀏覽至其他畫面。 LWC 提供完整的電線轉接器,可讓您存取 Salesforce 資料,以動態填入表單元件中的資料,並讓開發人員透過 Apex 控制項更新、刪除和建立記錄。 [Lightning Web 元件螢幕外資料作業_Lightning Web 元件螢幕外資料作業_](/docs/architect/zh-tw/reference-diagrams/guide/lightning-web-components-off-screen-data-operations) **可視性:**可視性可在所有表單建立工具中動態控制。「動態表單」、「Flow Builder」和 OmniStudio 透過元件可視性功能來解決此問題。透過此功能,您可以根據表單上的其他值,或使用者是否在行動裝置上,以宣告的方式顯示或隱藏欄位。 - 透過「動態表單」,您可以根據記錄欄位值、透過對應欄位相關的記錄和尺寸規格來控制可視性。 - 透過「流程」,您可以讓可視性規則以畫面上的其他輸入為基礎,以及在流程前期填入的其他資源,例如其他記錄中的公式或值。 - **以裝置為基礎的規則:**這一開始並不明顯,但您可以使用公式在使用者在行動裝置上時顯示或隱藏特定欄位。撰寫可檢查 \$User.UIThemeDisplayed 全域變數值的流程公式。如果值為 Theme4t,則表示使用者在 Salesforce 行動應用程式上。 - **評估其他資源:**手動變數和公式參照僅會在伺服器上評估。因此,資源在第一次呈現畫面時擁有的任何值,都是在您瀏覽至另一個畫面之前所擁有的值。在瀏覽時,流程執行階段會向流程引擎 (伺服器) 提交要求,並取得手動變數和公式的最新值。如果您預期您的可視性規則會在使用者通過單一畫面時更新 (例如,Onblur),請確保您僅參照畫面上其他元件的值。 - 透過 OmniStudio,您可以設定「條件式檢視內容」,條件式顯示或隱藏元件。不過,您無法為輸入新增多個條件式檢視內容。 **條件式輸入狀態:**如果您需要動態控制其他任何內容,例如欄位為必要、停用或唯讀,您有一些選項。LWC 如預期提供輸入狀態的完整反應性控制權。透過反應性「畫面流程」元件,您可以針對支援的標準元件動態控制元件屬性,例如「唯讀」、「已停用」和「必要」,而 OmniStudio 支援元件特定屬性的完整範圍。如果您的需求指出您需要「流程」,且元件不支援特定屬性狀態,您可以建立可內嵌 LWC 以達到動態輸入狀態。 如果您需要動態控制其他任何內容,例如欄位是必要或唯讀,短期內最佳的投注是 LWC,您可以完全控制該內容。如果您有針對如何處理開啟或點擊的自訂需求,則特別是如此。 畫面流程中的反應性 LWC:建立可在畫面流程上反應或變更其他元件的 LWC 時,請參閱此 [LWC 畫面流程最佳作法](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows)指南,以確保您的元件在流程執行階段引擎中完整整合,並如未來所預期運作。
標準事件處理 (模糊、焦點) 自訂事件處理
動態表單 不提供 不提供
畫面流程 不提供 不提供
OmniStudio 不提供 適用*
畫面流程 + LWC 可用 可用
LWC 可用 可用
*OmniStudio 標準執行階段不支援「發佈/副檔」,但支援 Windows postMessage
現在可用於自訂事件。如果您的部分輸入或整個表單需要與頁面中的其他項目通訊,則 LWC 是您唯一的選項。 - 若要在相同的 DOM 樹狀結構內通訊,請使用 [**CustomEvent 介面**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events)。 - 若要跨 DOM 通訊,請使用 [**Lightning 傳訊服務**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel)。 - 如果您的目標容器[不支援](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) Lightning 傳訊服務,請使用 **pub/sub 模組**。 #### 其他資源 - 如需詳細資料,請參閱《_Lightning Web 元件開發指南_》中的 [與事件通訊](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events)和跨 DOM [通訊](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub)。 - 針對 OmniStudio,請參閱 [從 Lightning Web 元件與 Omniscript 通訊。](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5) ### 樣式 為了提供最佳的使用者體驗,您必須確保表單的樣式與其內嵌應用程式或網站的其他樣式一致。若要達成此目標,這意味著從利用 Salesforce 提供的標準範本到建立完全利用設計中每個像素的自訂 CSS,以提供更明確的外觀與操作。 #### 要詢問的問題: - 您所需的樣式和 CSS 有多複雜? - 您是否需要自訂、像素完美的樣式,或是您可以使用標準主題?
直接設定樣式 組織和體驗產生器主題 像素完美樣式
動態表單 不提供 可用 不提供
畫面流程 不提供 可用 藍圖
OmniStudio 適用* 不提供 可用
畫面流程 + LWC 不提供 可用 可用
LWC 不提供 可用 可用
*僅限 Flex 卡
FlexCard 是本指南涵蓋的唯一產品,可讓您直接以宣告的方式控制在工具中建立之 UI 的樣式與版面配置,無論是邊緣和填補、列印圖、色彩等。 「動態表單」與「流程」皆遵循陳述性主題功能。如果您需要控制 [Salesforce 主題](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1)、[體驗產生器品牌集](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm)或 [LWR Experience Cloud 網站](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)支援的功能以外,請考慮使用程式設計解決方案。 針對喜歡使用 CSS 的小組,您有幾個選項: - 流程與 LWC 會繼承 [標準設計權杖](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm)。 - Omniscript 和 FlexCard 包含可自訂設計系統的支援:[Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5)。 - 透過 LWC,您可以撰寫您自己的元件,並完全控制其 HTML 和 CSS。 我們建議盡可能使用主題與設計系統,讓您的外觀與操作一致地套用至您的所有內容。 提醒:您可以在流程中內嵌 Lightning 元件。因此,如果您需要像素完美控制表單的外觀與操作,但想要使用流程的其他優點,例如瀏覽模型,您可以擁有這兩種世界的最佳功能。相同的原則也適用於 Omniscript 與 FlexCard。 ### 版面配置 選擇好的版面配置對於設計簡化表單而言至關重要,其可讓資料輸入快速且有效率,並提高資料完整性。如需此主題的詳細資訊,請參閱「[Salesforce Well-Architected - 表單](/docs/architect/zh-tw/well-architected/guide/engaging#表單)」。 #### 要詢問的問題: - 如何利用表單版面配置最佳化使用者體驗? - 如何向使用者呈現現有資料,讓使用者更容易在表單中輸入新資料?
2 欄 4 欄 4 欄以上 重複資料區塊 索引標籤容器 可折疊式容器
動態表單 可用 不提供 不提供 不提供 可用 可用
畫面流程 可用 可用 不提供 可用 不提供 可用
OmniStudio 可用 可用 可用 可用 適用* 可用
畫面流程 + LWC 可用 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用 可用
*若將資料內嵌在 Omniscript 中的 FlexCard 中,則可使用索引標籤
「動態表單」支援兩欄版面配置,並可分成包含欄位的個別區段。這些區段可以放置在元件中,例如索引標籤和折疊式,以建立易於使用且有組織的版面配置。 流程可以選擇性地使用「區段」元件呈現。透過區段,您最多可在流程畫面上新增四個欄,以及任意數量的區段。元件也可回應螢幕寬度,因此可在較小的螢幕上運作。最後,其可讓您將條件化可視性套用至整個區段,以便對區段內的多個欄位大量套用可視性。「流程區段」也支援欄標題,並提供類似的折疊式體驗,使用者可按一下標籤來摺疊整個區段。 Omniscript 具備各種版面配置選項,用於顯示欄位與資料。您可以建立資料區段,其中包含最多 12 個資料欄,包括條件式摺疊式折疊式。 透過 LWC,您可以使用 Lightning] 格式和支援的 Lightning] 欄位來控制版面配置。唯一的版面配置限制是來自 HTML/CSS 的版面配置限制。Lightning 遵循相關聯版面配置中的區段組態;例如,如果區段在版面配置中為兩欄,則此元件中為兩欄。 ### 翻譯 如果不同區域的使用者或使用不同語言的使用者可以存取您的表單,您必須確保您要用來建立表單的工具符合您的本地化需求。如需其他指引和建議,請參閱「[Salesforce Well-Architected - 本地化](/docs/architect/zh-tw/well-architected/guide/compliant#本地化)」。特別針對表單,本地化需求通常涉及將文字元素翻譯成其他語言。 #### 要詢問的問題: - 您的表單是否要在一個以上的國家或地區使用? - 表單中的文字是否需要本地化為其他語言?
在產生器中輸入的標籤 程式碼中的標籤
動態表單 適用* 不提供
畫面流程 可用 可用
OmniStudio 可用 可用
畫面流程 + LWC 可用 可用
LWC 不提供 可用
*僅欄位區段標題
如果您已本地化自訂欄位,則會在「動態表單」上遵循這些翻譯的標籤。「動態表單」也會遵循您在 Lightning 應用程式產生器中指派給元件標籤和屬性的[自訂標籤](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5)。 透過翻譯工作台的功能,流程支援翻譯所有標準與自訂畫面元件的使用者面向標籤。您可以本地化下列畫面元件的標籤、說明文字和錯誤訊息:文字、長文字區域、數字、貨幣、核取方塊、選項按鈕、選項清單、多重選擇選項清單、核取方塊群組、密碼、日期和日期/時間。 無內建翻譯支援立即可用的動作,例如「傳送電子郵件」或「張貼至 Chatter」。不過,有因應措施!如果您使用 [自訂標籤](https://help.salesforce.com/articleView?id=cl_about.htm)定義翻譯的標籤,則在 Flow Builder 中進行設定時,您可以在動作或元件中參照該自訂標籤。建立參照自訂標籤的流程公式,並在流程中的適當位置參照該公式。 Omniscript 使用自訂標籤進行翻譯。請參閱 [此說明文件](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm),準備好您的 Omniscript 多國語言。 現在為 LWC。某些基本元件會自動繼承相關聯物件欄位、說明文字和驗證訊息的翻譯 (若已在翻譯工作台中進行設定 (例如 Lightning。 如果您需要在程式碼中導入新的可翻譯標籤,則自訂標籤仍是未寫的 hero。宣告您需要的自訂標籤,然後從 @salesforce/label 範圍模組將其匯入至您的元件。 ### UI 測試自動化 有數種端對端測試自動化工具可供使用 (例如 Selenium),可讓您模擬使用者如何與您的表單互動。您可以針對任何標準或自訂 UI 撰寫這些測試,包括 Lightning 頁面和畫面流程。不過,請務必注意,這些測試類型無法驗證每個執行中方法的輸出。考量您對 UI 測試自動化的需求時,請務必考量這一點。 #### 要詢問的問題: - 您是否需要自動化表單測試? - 您需要執行哪些類型的測試? - 測試自動化需要的細微度層級為何?
單元測試 端對端自動化
動態表單 不提供 適用*
畫面流程 不提供 適用*
OmniStudio 適用* 適用*
畫面流程 + LWC 適用* 適用*
LWC 可用 可用
*需要程式碼
請考量您對 UI 測試自動化的需求。 **單元測試**可啟用更精確的自動化和驗證,此驗證適用於產業標準 CI/CD 系統和工具,可測試元件業務邏輯、其 JavaScript 控制項和其輸出。僅使用低程式碼,您將無法自行撰寫測試,但 Salesforce 會嚴格測試我們的端對端供應項目。 如果元件的方法足夠複雜,讓您想要個別測試方法,請將方法放入專屬的 JavaScript 檔案中。如此一來,您便可以將其匯入至 LWC 和使用如 `import { sort } from 'c/utils';` 的 Jest 測試。 如需在 Salesforce 上建立端對端自動化的各種選項比較,請參閱 Salesforce 上的 [UI 測試自動化](https://developer.salesforce.com/blogs/2020/01/ui-test-automation-on-salesforce.html)。包含何時使用 ISV 的無程式碼解決方案、Build Your Own 自訂測試自動化解決方案,或使用如 Selenium WebDriver 或 WebdriverIO 等開放程式碼測試架構的考量事項。這些解決方案適用於 Salesforce 中的任何 UI 互動,無論是 Lightning 頁面中的「動態表單」、公用程式列中的畫面流程,或是快速動作流程中的 LWC。 ### 度量 將表單部署至生產環境後,您會想要確保表單有效使用。視您的使用個案而定,這可能表示從追蹤填入次數到使用者在提交資訊前花費填入次數的時間。選擇工具前,請務必識別您要追蹤的 KPI。 #### 要詢問的問題: - 您是否需要追蹤表單的使用狀況? - KPI 會決定表單是否有效使用?
頁面檢視 表單所花費的時間 追蹤表單完成 追蹤成功率
動態表單 適用** 不提供 不提供 不提供
畫面流程 可用 適用* 可用 可用
OmniStudio 可用 適用* 可用 可用
畫面流程 + LWC 可用 適用* 可用 可用
LWC 適用** 適用* 可用 可用
*當啟用封裝型 OmniStudio 執行階段時可用
** 可供追蹤父系 Lightning 頁面用量
如果您需要追蹤表單的整體使用狀況和採用狀況,請從低程式碼工具開始。「動態表單」與「畫面流程」皆可使用立即可用的自訂報告類型進行追蹤,但您會從「畫面流程」追蹤報告中得到更多細微性。如果您需要追蹤 LWC 的使用狀況,立即可用的可用性取決於您使用該 LWC 的位置。如果它位於 Lightning 頁面上,則可用於追蹤 Lightning 頁面用量的任何項目都會套用至您的 LWC。同樣的情況也適用於內嵌在流程中的 LWC。 「動態表單」本身並非立即可追蹤,但您可以透過 [Lightning 用量物件](https://help.salesforce.com/articleView?id=lex_usage_reports.htm)追蹤父系 Lightning 頁面的用量。若要追蹤標準 Lightning 頁面,請使用「依頁面度量別的 _Lightning 使用者」_ 自訂報告類型。針對自訂 Lightning 頁面上的相同項目,請使用「_具有 Lightning 使用情況的使用者 (根據 FlexiPage 度量_)」自訂報告類型。 若要追蹤特定表單的採用狀況 (而不只是其所在的頁面),Flow 會為您提供協助。使用「範例流程報告:「畫面流程」可回答如下的問題: - 此表單的完成率為何?是否正確採用? - 使用者需要多久才能完成此表單? - 使用者花費最多時間在哪個畫面上? - 使用者向後瀏覽的頻率為何? - 錯誤的發生頻率為何? 如果標準報告不符合您的需求,請複製報告以進行您自己的變更,或使用「*畫面流程」*報告類型從頭開始 Build Your Own。 如果您使用封裝型 Omniscript 執行階段,您可以利用 [OmniStudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5)。此服務會追蹤任何類型的事件。例如,您可以追蹤在 Omniscript 中完成步驟所花費的時間,以識別流程改善方式。在標準 OmniStudio 中支援此服務是 OmniStudio 小組的藍圖。 若要針對未內嵌在畫面流程、Omniscript 或 Lightning 頁面中的 LWC 追蹤相同項目,則沒有立即可用的選項。您可以使用 Apex 建立自訂解決方案。 ### 封裝與部署 當您需要將解決方案部署至較高層級的環境以進行測試或部署至生產環境時,可能會使用變更集或 DevOps Center 來執行此操作。這些部署選項完全支援「動態表單」、「流程」與 LWC。OmniStudio 需要個別的工具:[IDX 工作台](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5)。 #### 要詢問的問題: - 您打算如何部署表單? - 您的表單會散佈至多個 Salesforce 組織嗎?
第一代受管理封裝 (1GP) 第二代受管理封裝 (2GP) 解除鎖定的封裝 變更集 DevOps Center
動態表單 可用 可用 可用 可用 可用
畫面流程 可用 可用 可用 可用 可用
OmniStudio 不提供 不提供 不提供 不提供* 不提供*
畫面流程 + LWC 可用 可用 可用 可用 可用
LWC 可用 可用 可用 可用 可用
*使用 IDX 工作台將 OmniStudio 解決方案部署至其他組織。
如果您是 ISV 或計畫將解決方案封裝在 AppExchange 上散佈的合作夥伴,我們建議您先查看「動態表單」、「流程」和「LWC」。OmniStudio 不支援封裝。 ## 其他主題 ### 將低程式碼瀏覽至 Pro-Code Continuum 本指南專注於協助您瞭解「動態表單」、畫面流程、OmniStudio 和 LWC 可使用的功能和自訂層級。在高層級: 低程式碼對 Pro-Code Continuum
- LWC 是建立表單的最可自訂且強大的選項,但具有最少的護欄。您可以透過確保[安全性](/docs/architect/zh-tw/well-architected/guide/secure)與可[調整](/docs/architect/zh-tw/well-architected/guide/reliable#延展性)性的方式來建立元件。 - 「動態表單」最不彈性,但發生錯誤的機會較少。 - Flow 與 OmniStudio 位於其中一處—比「動態表單」更強大,但不完全符合 LWC 的層級。透過相同的權杖,它們的護欄比「動態表單」少,但比自訂程式碼更難破壞。 如果有多個工具符合該帳單,則決定要決定哪個工具適合您的小組。其他「[結構設計師決策指南](/decision-guides)」會介紹在做出該決策時要考量的其他層面。 我們不會在此處深入說明每個層面的詳細資料,但我們會為此文件正在評估的特定工具解譯這些層面。 **專業技能**:您的小組在所比較工具方面的專業知識為何?有多少製造人員已熟悉 LWC 或 JavaScript?若建立者是 Flow Builder 專家或表示有興趣進入 Flow Builder,該如何?一般而言,「動態表單」和「流程」技能對於建立表單的人員族群較廣泛,較容易達成。「動態表單」是最具陳述性的表單建立工具,一律比「流程」更容易學習。不過,Flow 小組致力於盡可能降低該長條。在複雜性方面,OmniStudio 位於「流程」與 LWC 之間的某一處,提供重要的表單建立超級能力。 **交付委派**:因為您的某些需求需要 LWC,這不表示您的整個解決方案需要使用 LWC 建立。請思考如何模組化建立解決方案,讓需要 LWC 的組件編碼,以及未在低程式碼解決方案中內建的組件。這麼做可最大化多元小組的效率,並確保每個人都會為其專長解決適當的問題。 現在我們來談一下「流程」和「LWC」。透過反應性畫面元件,畫面流程元件現在可以在相同畫面上彼此交談,為結構設計師、管理員和開發人員解鎖全新的工具箱。開發人員現在可以建立有意義的模組化元件,這些元件可在整個組織中重複使用,進而提高小組中每個人的生產力。開發人員可以使用標準和自訂「流程」元件混合來專注於解決新挑戰,並節省時間,以實現表單動態。使用「流程」中的反應性元件時,建立表單時,將「流程」與 LWC 混合的時間從未更適合。 **永續性與長期擁有權**:如果您有多步驟表單,最好使用「流程」或混合「流程」和 LWC 來開始。如果您有低程式碼小組維護解決方案,請思考如何讓解決方案能盡可能為該受眾設定並延伸。無論您選擇的任何工具,請將您的解決方案組織為可[組合](/docs/architect/zh-tw/well-architected/guide/composable)單位,以改善可維護性和穩定性。 ### 版面配置 今後,設定記錄詳細資料頁面的建議方式為使用 Lightning 頁面的 Lightning 應用程式產生器中的動態表單。我們有增強型版面配置已經過一段時間,而且該趨勢將持續。以下是原因: - 「動態表單」更有彈性,您可以將欄位和區段直接放置在 Lightning 應用程式產生器中,在其中您可以利用區段、索引標籤和折疊式。就像您在 Lightning 頁面上使用元件一樣,您可以控制欄位和區段的可視性,而無須定義多個版面配置或記錄類型。 - 透過「可折疊式」與「索引標籤」元件,您可以限制一開始顯示的欄位數量。猜這意味著什麼?更快的頁面載入時間。 - 使用 Lightning 頁面管理版面配置較為簡單,因為您可以從 Lightning 應用程式產生器管理您頁面的所有內容,無論是頁面的內容或哪些使用者可存取頁面。您不再需要在版面配置中進行更新,才能在 Lightning 頁面中進行變更。此外,可視性規則的強大功能讓您不再需要建立多個頁面 (或版面配置) 來控制誰會在何時看見哪些欄位。這也表示您只需要將 Lightning 頁面指派給使用者,而不需要同時指派 Lightning 頁面與版面配置。 建議盡可能使用「動態表單」,並僅在必要時返回版面配置。如往常般,我們歡迎在「[計畫交換](https://ideas.salesforce.com/s/)」中提供對您組織影響最大的改善意見。 ### 績效 與「動態表單」、「畫面流程」、「OmniStudio」和 LWC 相關的任何效能考量事項都著重於這些技術本身的架構。以 LWC 為基礎的項目 (當然是 LWC 之外) 將會高於以 Aura 為基礎的項目。LWC 架構提供更好的效能,因為核心功能是在 Web 引擎中原生實作,而非透過架構抽象在 JavaScript 中實作。如果您不熟悉,請先閱讀[此部落格貼文](https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html)。 回到 2019 年,我們進行了一個比較 Aura 中相同功能與 LWC 中效能的 [個案研究](https://developer.salesforce.com/blogs/2019/06/case-study-dreamhouse-gains-speed-by-switching-to-lwc.html)。由於將 DreamHouse 從 Aura 轉換為 LWC,因此開發體驗與目前的 Web 前端開發標準和模式更加一致,而且效能提升顯著。實驗室測量顯示冷快取的收益範圍為 **2.4% 到 24.7%,**並在相同兩個頁面上顯示熱快取的收益範圍為 **31.83% 到** **63.32%**。 現在,我們的表單技術會使用哪個架構?換句話說,哪些格式技術受益於此優良的效能? - 「動態表單」整合在 Lightning 頁面中繼資料中,其建立在使用 LWC 堆疊的基礎上,這將讓我們實作一些長期要求的功能。「動態表單」使用漸進式呈現作為效能優點,進而改善具有大量欄位之頁面的頁面載入時間。 - 「畫面流程」以 LWC 為基礎,大多數個別立即可用的元件現在已轉換為 LWC,但兩個立即可用的元件除外:檔案上載和影像。雖然流程小組將流程執行階段用戶端轉換為 LWC 及其大多數元件,但客戶仍需要將其 Aura 畫面元件轉換為 LWC。不僅如此,Salesforce 僅支援畫面流程中新反應性元件架構中的 LWC 元件。有一個優秀的 Trailhead 模組說明如何執行:Aura 開發人員適用的 [Lightning Web 元件](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers)。當然如此:如果您正在考慮為畫面流程或任何其他容器建立自訂元件,請一律執行 LWC。 - 有一些版本的 OmniStudio 可供使用。如果您是長期客戶,您可能正在使用 Angular。我們鼓勵所有新客戶開始使用 LWC 型 Omniscript 和 FlexCard,並鼓勵現有客戶從 Angular 移轉。 - LWC 建立於 ...LWC 當然。這是免費註冊。 ## 結束備註 身為結構設計師,務必深入瞭解所有可用的選項,以及如何在特定使用個案中套用這些選項。針對在 Salesforce 上建立表單,選項範圍從低程式碼 (在 Lightning 應用程式產生器中使用「動態表單」、「Flow Builder 中的畫面流程」和 OmniStudio 中的 Omniscript) 到使用 Pro-code (使用 LWC 架構),其中包含畫面流程或 Omniscript 和 LWC 的組合。請記住此指南,並在您計畫在 Salesforce 上建立或重新設計表單時將其作為參考。如果您想要瞭解如何設計簡化且實用的表單,請諮詢 [Salesforce Well-Architected:參與中](/docs/architect/zh-tw/well-architected/guide/engaging)。 ### 告訴我們您的想法 協助我們確保我們發佈與您最相關的內容:[進行我們的調查](https://forms.gle/FCFCES6vsRbKv4E29)以提供此內容的回饋意見,並告訴我們您接下來想要看到的內容。 ## 指南概觀 在 Salesforce 與外部系統之間存取、同步化及共用資料的方式有多種。但並非每個工具都適合您的特定專案。本指南逐步引導您瞭解 Salesforce 提供的資料整合工具。此外也會針對最適合特定使用個案的工具 (或工具組合) 提供建議,以及針對特定情況避免使用之工具的指引。 此決策指南著重於涉及 Salesforce 的資料層級整合。具體而言,它涵蓋下列資料整合使用個案: - Salesforce 至外部系統 - 外部系統對 Salesforce - Salesforce 組織對 Salesforce 組織 這些僅是 Salesforce 結構設計師面對的整合挑戰子集,因此我們計畫新增更多決策指南,專注於事件驅動的整合、使用流程整合建立有效的客戶或員工面向工作流程等。最後,請務必注意,此處描述的許多工具和方法可用來解決整合在整個企業中的挑戰,但此類用途超出本指南的範圍。 ### 接待時間 - **避免不必要的資料複寫。**除非資料絕對需要位於 Salesforce 中,否則請考慮改為使用 Salesforce Connect 虛擬化資料。組織中的資料越多,最終會導致資料量越大,這會對[績效](/docs/architect/zh-tw/well-architected/guide/reliable#績效)造成負面影響,並增加技術負債。如果您的資料已位於 Salesforce 中且您在外部系統中需要資料,請避免將資料複製到外部系統,除非有絕對必要。請改為讓外部系統透過 Salesforce API 存取資料。 - **如果可用,請使用 MuleSoft 或其他 Enterprise Service Bus (ESB) 或 Extract-Transform-Load (ETL) 解決方案,且為您現有的區域範圍的一部分。**由於這些工具是為了協助支援資料移轉和轉換而建立,因此通常具有強大的功能,可讓您在整個企業中重複使用整合、維持更強大的管治,並集中管理整合。在此指南中,無論建議使用 MuleSoft Anypoint 的任何位置,請考量您現有的 ESB/ETL 解決方案是否足夠。 - **使用 Data 360 和 Data Cloud One 協調不同來源的資料。**透過 Customer 360 資料模型、身分解析、資料聯邦和其他功能,Data 360 會將 Salesforce 和其他外部系統的資料合併至您客戶的統一檢視。此外,透過 [Data Cloud One](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one),其他 Salesforce 組織中的使用者可以透過資料空間安全地存取從 Data 360 虛擬共用的資料。 - 使用 **Data 360 動作和啟用在組織之間移動資料。**將不同組織的資料從 Data 360 移入後,資料 [動作和啟用](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound)可以將資料同步至其他組織。此方法對於與 Marketing Cloud 組織的整合而言非常有用。 - 使用 **MuleSoft Anypoint.**MuleSoft Anypoint 可用來使用 Connect API 和 Data Graph API 從 Data 360 提取資料,並將其移至另一個 Salesforce 組織。若沒有 Data 360,則當需要在組織之間移動資料而不需要在 Data 360 中複製時,也可使用 MuleSoft Anypoint。 - **如果您選擇使用「輸出傳訊」建立,請特別小心。**Salesforce 會在目前的功能容量內繼續支援「輸出傳訊」,但不會計畫進一步投資此技術。 - **針對所有整合一律建議使用「僅 API」設定檔整合使用者授權。**Salesforce 也建議使用「外部用戶端應用程式」(偏好連線應用程式或 SOAP 登入) 作為所有整合適當允許的 AuthN 和 AuthZ 模式。 ## 選擇資料整合工具的常見考量事項 在深入瞭解可用的資料整合工具之前,選擇工具時,請務必記住幾個常見考量事項。如同結構一般,對於每個業務挑戰沒有指示性回答。如果您在進行整合選擇時說出「這取決於」,則表示您處於正確的位置。
考量區域 常見問題
現有工具與橫向 是否有現有的 ESB 或 ETL 解決方案?相關資料是否具有法規或規範需求?您嘗試整合的系統位於何處 (雲端或內部部署中)?
資料流程 (時間點、預期的使用者體驗、方向性) 資料是否需要同步、非同步移動,還是可批次/排程?資料複寫是否必要?哪個系統應該是事實來源?什麼是資料來源?什麼是目標目的地?使用者互動是否必要?使用者是否需要查看整合的結果?例外狀況處理 (重試、通知、失敗) 的需求為何?系統應如何緊密連接?
實作 非 Salesforce 系統的工作層級為何?哪些小組負責提供整合?他們偏好使用哪些工具?
永續性 哪些小組預期會維護整合?他們目前擁有哪些技能?他們未來需要哪些技能?一段時間內的總擁有成本為何?使用低度或專業程式碼工具測試、除錯、疑難排解的能力有多重要?
資料量 整合中涉及多少資料?您是否要使用 大型資料量 (LDV)?大量變更的發生頻率為何?singleton 更新的影響為何?它們會發生多少次?
限制 資料是否需要進行複雜轉換?資料是否必須從多個來源系統合併?每位使用者整合的發生頻率為何?使用者總數為何?您是否已預先計畫大量資料載入 (例如:新例項的初始資料載入)?
## 產品比較 以下是資料整合可用工具的概觀,以及開始評估每個選項的一些考量事項。下列區段包含深入的使用個案,以及這些工具功能的相關詳細資料。
從 Salesforce 至外部系統 從外部系統到 Salesforce 執行 需要其他授權
Apex 動作 可用 可用 伺服器端 否
變更資料取取 可用 不提供 伺服器端 否*
自訂 Apex (REST 和 SOAP Web 服務) 可用 可用 伺服器端 否
外部服務 可用 不提供 伺服器端 否
Heroku Connect 可用 可用 伺服器端 是
Data 360 可用 可用 伺服器端 是
MuleSoft Anypoint 可用 可用 伺服器端 是
原生 Salesforce API 不提供 可用 伺服器端 否
Omniscript 可用 可用 用戶端*** 是
OmniStudio 整合程序 可用 可用 伺服器端 是
輸出傳訊 不是理想 不提供 伺服器端 否
平台事件 可用 可用 伺服器端 否**
Salesforce Connect/外部物件 可用 可用 伺服器端 是
[\* 大量變更資料摘取事件使用個案需要附加元件](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm) [\*\*大量平台事件使用個案需要附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) \*\*\*適用於可在網頁瀏覽器中執行業務邏輯的情況。 資料欄圖例: - **可用**:適用於大多數使用個案 - **非理想**:可能但請考慮替代工具 - **不可用**:未來十二個月內沒有支援的計畫 ### 可能涉及將資料移入和移出 Salesforce 的其他工具: 其他工具可能支援資料層整合的某些層面,但不能視為解決整合問題的主要方法。現在讓我們快速查看這些工具。 **Lightning Web 元件**通常用於程序整合,但可以使用 JavaScript 功能進行呼叫,因此資料可能會涉及這些交易。 **Salesforce 流程**可用來使用「外部服務」或「Apex 動作」協調外部呼叫。Salesforce 流程本身並不視為獨立的資料整合工具。 **資料匯入精靈和 Data Loader** 可用來同步化、匯入和移轉資料。雖然 Data Loader 指令也可進行指令檔,以自動匯入和匯出資料,但 [指令行介面](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm)僅適用於 Windows,且這些工具都不為資料整合策略的建議基礎。請改用來補充您的資料管理與維護策略。 [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) 資料指令可用來操作您組織中的記錄。指令可協助您使用「大量 API」和「SObject 樹狀結構儲存 API」匯入和匯出資料,並透過 REST API 在個別記錄上執行簡單的 CRUD 作業。Salesforce CLI 本身並不視為獨立的資料整合工具。 **OmniStudio 資料對應工具**可作為陳述性 ETL 工具,在 Salesforce 物件與 JSON 資料結構之間移動資料。雖然會自動為每個「資料對應器」介面建立 REST 介面,提供從外部系統將資料移動至 Salesforce 物件的陳述性方式,但「資料對應器」獨立並非資料整合策略的建議基礎。「資料對應器」動作適用於 OmniStudio 整合程序。 [**Dataloader.io**](http://dataloader.io/) 是 Salesforce 的另一個資料載入工具,由 MuleSoft 的 Anypoint Platform 提供技術支援,可讓您快速安全地匯入、匯出和刪除企業的無限數量資料。Dataloader.io 並非資料整合策略的建議基礎。 ## Salesforce 對外部系統 (輸出整合) 針對 Salesforce 的輸出整合,您可以考量不同類型的工具:低程式碼、專業程式碼或混合式。下列區段提供每個工具類型的指引,並提供範例解決方案。 - [輸出整合的低程式碼工具](#salesforce-中輸出整合的低程式碼工具) - [輸出整合的混合式工具](#適用於-salesforce-輸出整合的混合式工具) - [輸出整合的 Pro-Code 工具](#salesforce-中輸出整合的-pro-code-工具) ### Salesforce 中輸出整合的低程式碼工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
變更資料取取 當您需要將在 Salesforce 中進行的記錄層級變更發佈至外部系統,且不需要自訂裝載時。 必要 非同步 否 否 是 使用 Pro-Code 工具 是 是 OAuth
外部服務 當您使用流程協調流程時,會使用 OpenAPI 規格描述 Apex、Einstein 機器人或 OmniStudio 和外部系統 API。 不需要 同步化 是 否 是 使用 Pro-Code 工具 否 無 已命名認證
Heroku Connect 當您想要透過雙向同步擴充資料,以在 Heroku 上啟用行動應用程式和其他應用程式,且您想要將資料也複製到 Salesforce 時。 必要 非同步 是 是 否 使用 Pro Code 工具 是 是,透過 Shield Connect OAuth
OmniStudio 整合程序 當您需要在沒有使用者互動的情況下轉換資料,並透過在伺服器處理而非瀏覽器改善效能時。 必要 兩者 是 是 是 宣告式支援 是 是 已命名認證
Salesforce Connect/外部物件 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在外部系統中時。資料不會複製到 Salesforce。 必要 同步化 否 是* 是 具有 Pro-Code 工具和陳述性追蹤器 否 無 已命名認證
*超過 4.01 版的 Odata 轉接器受限於呼叫限制。如需詳細資料,請參閱 OData 呼叫率限制考量事項。 ** 測試與部署是指在較低環境中建立並透過 中繼資料 API、封裝或變更集部署至生產的能力。
### 使用個案:使用低程式碼工具的輸出整合 > 當機會成交時,必須在公司的 ERP 系統或訂單管理系統中建立相關產品的訂單。 當「機會」記錄更新時,「變更資料集合」會發佈包含物件更新的變更事件。\*\*\*\*變更事件會透過 CometD 連線 (或透過 MuleSoft 連接器) 客戶端耗用,並用於更新客戶的 ERP 或訂單管理系統。變更事件可以加強,以一律包含外部記錄識別碼或物件 (例如區域) 中整合所需的其他資料。可將多個物件的變更事件串流合併為簡化訂閱和串流處理的 _管道_ (因此您可以訂閱和處理一個串流,而非多個串流)。 **外部服務** 如果您的 Web 服務支援 OpenAPI 2.0 或 3.0 規格,您可以在 Salesforce 中將作業和服務公開為外部服務。當機會的階段變更為「成交」時,在使用 Flow Builder 建立的流程中,API 作業 (例如建立順序) 可以稱為可叫用動作。 **Heroku Connect** Heroku Connect 通常用於將 Heroku Postgres 資料庫與 Salesforce 保持同步。如果客戶使用 Heroku Postgres 作為其事實來源交易存放區,則您可以使用 Heroku Connect 將記錄和從 Salesforce 變更同步至 Heroku Postgres。從此處,您可以使用 Heroku 串流連接器將這些變更發佈至 Apache Kafka,並將其作為事件傳送至下游應用程式,包括 ERP 或訂單管理系統。 **OmniStudio 整合程序** 提交訂單時,協調流程的 Omniscript 可以將訂單詳細資料張貼到 ERP 或 MuleSoft 連接器。貼文可以直接由 Omniscript (用戶端) 或間接透過整合程序 (伺服器端) 執行。如果 ERP 系統引發驗證錯誤,Omniscript UI 必須通知使用者,並視需要為使用者翻譯並內容化錯誤。 **Salesforce Connect/外部物件** 您可以在 Salesforce 中建立記錄觸發流程,當機會的階段變更為「成交」時,將記錄插入相關外部物件。由於這是[混合交易](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1),因此為了避免錯誤,請在「機會」更新與相關外部物件插入之間新增零秒的暫停元素,以便您在開始新的交易內容之前關閉一個交易內容。 ### 適用於 Salesforce 輸出整合的混合式工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
Apex 動作 當您想要透過 Salesforce 流程將呼叫自動化至其他系統時。開發人員可以撰寫流程可叫用的 Apex 類別,或者您可以從 AppExchange 下載預先建立的解決方案。 不需要 兩者 是 否 是 使用 Pro-Code 工具 否 是 多
事件轉送 當您需要從 Salesforce 將平台事件和變更資料擷取事件傳送至 Amazon EventBridge 時。事件轉送僅連線至 AWS Eventbridge 否 非同步 是 否 是 是 是 是 具有 TLS 的 HTTP/1.1
輸出傳訊 當您需要透過 HTTP(S) 將 SOAP 訊息傳送至指定的端點,並在由工作流程規則觸發時保證收到。 不需要 非同步 否 否 是 宣告式支援 是 是 雙向 TLS
平台事件 當您需要自定義的結構化裝載,以在 Salesforce 或外部系統中進行近乎即時的變更時。 不需要* 非同步 是 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect/外部物件 (含自訂 Apex 轉接器) 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在無法使用如 Odata 或 GraphQL 等標準通訊協定的外部系統中時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 無 多
Data 360 當您想要在一個資料存放區中協調不同來源的資料,或想要將資料複製到其他 Salesforce 組織或其他外部系統時。 必要 兩者 是 是 是 是 是 是 多
需要大量使用個案的 [\* 附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用混合式工具的輸出整合 > 當機會成交時,必須在公司的 ERP 或訂單管理系統中建立相關產品的訂單。 **Apex 動作** 根據機會狀態的記錄觸發流程可以在機會成交時自動觸發。流程會執行可叫用動作,使用外部呼叫將訂單提交至訂單管理系統或 ERP 解決方案。大量提交與多網站訂單是由 Apex 批次與排入排入機制處理。 **輸出傳訊** [設定輸出傳訊後](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm),您可以定義由機會更新觸發的工作流程規則,以透過 HTTP(S) 將 SOAP 訊息傳送至主控接聽者的指定端點 URL。訊息將包含在建立輸出訊息時指定的欄位。若物件中的資訊在通知排入排隊後變更,但在通知傳送之前變更,則只會傳送更新的資訊,且訊息會保持在排隊中,直到通知成功傳送,或直到訊息已超過 24 小時為止。在 24 小時後,訊息便會遭到排除。如果 ERP 系統需要其他資料,您可以在輸出訊息中傳遞 sessionId,以便外部系統提出回呼要求。 **平台事件** 您可以定義平台事件,其中包含在外部系統中建立記錄所需的自訂裝載資料。由於「平台事件」不會在記錄變更時自動發佈,因此當機會的階段變更為「成交」時,您必須透過 Apex、Salesforce 流程或流程產生器發佈事件。外部服務會使用 CometD (或 MuleSoft 連接器) 聆聽平台事件管道,並在外部系統中建立適當的記錄。 **Salesforce Connect/外部物件 (含自訂 Apex 轉接器)** 以 Salesforce Connect/外部物件為基礎的解決方案不適合僅需要資料同步的使用個案。不過,此解決方案適用於 Salesforce 中的使用者需要查看,並可能與外部系統中的資料互動的個案,且資料無法在 Salesforce 中複製。如果 ERP 或訂單管理系統不支援 Odata 或 GraphQL 通訊協定,則開發小組可以使用 [Apex 連接器架構](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm)來撰寫處理透過支援通訊協定與外部系統通訊的 Apex 類別。 **Data 360** 以 Data 360 為基礎的解決方案非常適合我們在單一資料存放區中需要來自不同來源之協調資料的使用個案。當我們需要使用 Data 360 作為資料中心,將資料從一個 Salesforce 組織複製到多個 Salesforce 組織,或複製到其他外部系統時,也會使用此功能。當機會在來源組織中成交並更新時,機會資料會同步化至 Data 360,並可在其中使用動作、啟用和 API 等不同機制在其他系統中複製,包括 Salesforce 組織。同樣地,您可以參照機會,而無須使用 Data Cloud One 在其他 Salesforce 組織中複製資料。不過,Data Cloud One 不支援非 Salesforce 平台。 ### Salesforce 中輸出整合的 Pro-Code 工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署** 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定
自訂 Apex 當您需要的功能比低程式碼工具所提供的功能多。 不需要 兩者 是 是 是 使用 Pro-Code 工具 否 是* 多
外部服務 使用 OpenAPI 規格說明從程式碼與外部系統 API 整合。 不需要 同步化 是 否 是 使用 Pro-Code 工具 否 無 多
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是* 多
\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用 Pro-Code 工具的輸出整合 > 當機會成交時,必須在公司的 ERP 或訂單管理系統中建立相關產品的訂單。 **自訂 Apex** 您可以在機會上建立 Apex 觸發和觸發處理常式,當機會的階段變更為「成交」時,其會對 ERP 或訂單管理系統進行呼叫。請注意,如果您從觸發或執行 DML 作業後進行呼叫,則必須使用註解為 future 或 queueable 的方法。觸發中的呼叫會在呼叫的留存時間內將資料庫連線保持開啟。所有 Apex 程式碼皆受限於「[Apex 管理員」和「API 限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm)」,這些限制會持續修訂。 **外部服務** 如果透過 OpenAPI 規格定義公司的外部 ERP 或訂單管理系統,則可簡化對未來方法或可排列工作中執行之服務的呼叫。您可以直接從 Apex 呼叫註冊的外部服務,而無須撰寫板碼。在此範例中,可由外部服務處理建立訂單的呼叫。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。MuleSoft Anypoint 可以建立 API 來啟用 Salesforce 和許多其他企業系統資料的讀取 (和/或寫入) 存取權。有 [許多預先建置的連接器可用](https://www.mulesoft.com/platform/cloud-connectors)來簡化實作,公司也可以建立和發佈自己的連接器。這些 API 可使用彈性的安全性原則在 Anypoint 中部署,並支援集中管理與管治。交易量沒有任何限制,只要 API 已適當調整其最大利用率的大小 (以 vCores 測量)。 ## 將外部系統資料新增至 Salesforce (輸入整合) 針對 Salesforce 的輸入整合,您可以考量不同類型的工具:低程式碼、專業程式碼或混合式。下列區段提供每個工具類型的指引,並提供範例解決方案。 - [輸入整合的低程式碼工具](#輸入整合至-salesforce-的低程式碼工具) - [輸入整合的混合式工具](#適用於-salesforce-輸入整合的混合式工具) - [輸入整合的 Pro-Code 工具](#輸入整合至-salesforce-的-pro-code-工具) ### 輸入整合至 Salesforce 的低程式碼工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署* 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
Heroku Connect 當您想要透過雙向同步擴充資料,以在 Heroku 上啟用行動應用程式和其他應用程式,且您想要將資料也複製到 Salesforce 時。 必要 非同步 是 是 否 使用 Pro-Code 工具 是 是,透過 Shield Connect OAuth
OmniStudio 整合程序 當您需要在沒有使用者互動的情況下,從第三方來源匯入和轉換資料時。 必要 兩者 是 是 是 宣告式支援 否 是 已命名認證
Salesforce Connect/外部物件 當您想要資料顯示在 Salesforce UI 中,但想要資料儲存在可使用標準通訊協定 (例如 Odata 或 GraphQL) 的外部系統中時。 必要 同步化 是 是 是 使用 Pro-Code 工具 否 無 多
\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用低程式碼工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 **Heroku Connect** Heroku Connect 通常用於將 Heroku Postgres 資料庫與 Salesforce 保持同步。除非 ERP 系統使用 Heroku Postgres 作為其交易存放區,否則此使用個案無法使用。如果使用 Heroku Postgres,則在 Postgres 表格中進行的變更可以使用 Heroku Connect 同步化至 Salesforce 中的物件。 **OmniStudio 整合程序** ERP 系統更新連絡人記錄後,可透過資料對應器產生的 REST API 呼叫包含資料對應器載入動作和回應動作的 OmniStudio 整合程序。首先,資料對應器載入動作會傳送 JSON 或 XML 裝載,用於根據「外部識別碼」欄位或透過「[更新插入金鑰」](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio)更新插入連絡人記錄。如果 JSON 中的簡單回應僅限預期,則「回應動作」會傳回先前動作中的任何相關資訊,以表示成功或失敗。如果 ERP 系統預期特定回應,則可使用「資料對應器轉換」或「解壓縮動作」產生含額外功能的 JSON 或 XML 回應,以宣告方式包含連絡人記錄更新所產生觸發中的資料。此案例的主要挑戰是並行:多個呼叫同時更新相同的連絡人記錄會造成問題,因為 API 存在於 Salesforce 中。 不建議針對此使用個案使用 **Salesforce Connect/外部物件** Salesforce Connect 和外部物件,因為此情況特別需要在 Salesforce 中複製資料。如果您擁有建立於 ERP 的預先存在 Salesforce Connect 整合,則如果 ERP 支援變更資料資料擷取,您可以設定 Odata 4.0 連接器來支援外部變更資料擷取。此外,您必須在 Salesforce 中設定,以使用 Pub/Sub API 從 ERP 訂閱變更串流。 ### 適用於 Salesforce 輸入整合的混合式工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署** 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
平台事件 當您需要自定義的結構化裝載,以在 Salesforce 或外部系統中進行近乎即時的變更時。 不需要* 非同步 是 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect/外部物件 (含自訂 Apex 轉接器) 當您需要資料顯示在 Salesforce UI 中,但想要資料儲存在無法使用 Odata 2.0/4.0 通訊協定的外部系統中時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 無 多
Data 360 當您想要在一個資料存放區中協調不同來源的資料,或想要將資料從其他 Salesforce 組織或複製到其他外部系統時。Data 360 也支援某些平台的虛擬化。 必要 兩者 是 是 是 否 是 是 多
\* 大量使用個案需要[附加元件](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)。 \*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 ### 使用個案:使用混合式工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 外部系統中的「**平台事件」**自訂程式碼會在 ERP 中更新連絡人記錄時發佈「平台事件」。Salesforce 中的觸發、程序或流程可以訂閱平台事件,並在處理事件時更新對應的 Salesforce 物件。平台事件可能只會作為在客戶 ERP 系統中發生變更而不包含任何資料的訊號運作,或者可能包含更新 Salesforce 物件所需的實際資料。 **Salesforce Connect/外部物件 (含自訂 Apex 轉接器)** 此解決方案不適用於需要資料複製的使用個案。如果您需要 Salesforce 中的使用者查看來自外部系統的資訊,且外部系統不支援如 Odata 或 GraphQL 等標準通訊協定,則此解決方案適用。請參閱 [使用個案:輸出整合使用混合式工具](#使用個案使用混合式工具的輸出整合)作為 Apex 自訂轉接器的範例使用個案。 **Data 360** 當在外部系統 (例如 ERP) 中更新連絡人時,可使用立即可用的連接器,或使用 API 和 Pro-Code 工具 (例如 MuleSoft) 將連絡人更新同步至 Data 360。您也可以使用零複製機制在 Data 360 中參照連絡人 (適用於某些平台)。一旦資料可在 Data 360 中使用,即可使用不同的立即可用整合機制將資料同步至其他 Salesforce 組織。您可以使用 Data Cloud One 透過參照來存取資料。您也可以使用立即可用的連接器來複製資料,或透過如 MuleSoft Anypoint 平台等專業程式碼工具的協助來複製資料。 ### 輸入整合至 Salesforce 的 Pro-Code 工具
指引 授權 時間 體積與規模 交付與維護 隱私權與安全性
使用時機 其他授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/Bulk 測試與部署**** 除錯 內建錯誤處理/重複處理行為 可與靜態加密的資料搭配使用 驗證通訊協定
自訂 Apex REST 與 SOAP Web 服務 當您需要比原生 API 端點提供更多的功能時,例如跨物件處理或其他複雜邏輯。 不需要 兩者 是 是 是 使用 Pro-Code 工具 否 是*** 多
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時。 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是*** 多
原生 Salesforce API 當您需要更多控制或擁有專業程式碼技能集,以透過 REST API、SOAP API、大量 API 或 GraphQL API 或 gRPC 建立整合時。 不需要* 兩者 是***** 是 是 使用 Pro-Code 工具 是** 是*** 多
\* 適用「[API 要求上限與配置](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)」。 \*\*大量 API 有重試行為的層面,而一些 API 透過 allOrNone 設定提供*回復*保護 (例如,請參閱複合與集合要求中的 [allOrNone 參數](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm)) \*\*\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 \*\*\*\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力。 \*\*\*\*\*複合 API 有多物件支援。 ### 使用個案:使用 Pro-Code 工具進行輸入整合 > 連絡人會在組織的 ERP 系統中更新。此連絡人資訊必須在 Salesforce 中更新。 **自訂 Apex REST 和 SOAP Web 服務** 您可以使用可在「連絡人」物件上執行 CRUD (建立、讀取、更新、刪除) 作業的 Apex 程式碼建立 Web 服務。此服務會透過 SOAP 或 REST 從外部系統 (ERP) 叫用。 **MuleSoft Anypoint** MuleSoft Anypoint 的意圖是提供企業級 API 管理。MuleSoft Anypoint 提供一[組大型預先建置連接器](https://www.mulesoft.com/platform/cloud-connectors),可用來與許多 ERP 系統整合,包括 SAP、Oracle EBS、Oracle ERP 和 NetSuite。您可以建立流程來聆聽這些 ERP 系統中的事件 (在此個案中為建立新連絡人時)。流程開始時,會使用 Salesforce 連接器建立新的「連絡人」記錄 (若連絡人已存在則更新一個)。此外,如果複製交易涉及將連絡人新聞訂閱至其他系統,則可以與其他系統整合。您可以視需要使用對應和轉換語言 (DataWeave) 來執行複雜邏輯和計算,作為跨多個不同系統的資訊流程。針對這些系統的驗證可透過許多不同的驗證機制完成,例如基本驗證和 OAuth。只要流程已適當調整其最大利用率的大小 (以 vCores 測量),交易量就沒有任何限制。 當 ERP 系統中的更新交易完成 (或立即完成後),您可以透過 SOAP API 對「連絡人」物件執行更新插入作業,或對 Salesforce 組織中的 Contact sObjects REST API 執行 [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) 。\*\*\*\* ## Salesforce 到 Salesforce 整合 Salesforce 到 Salesforce 產品已到期。Salesforce 到 Salesforce 讓合作夥伴可以輕鬆地共同銷售並支援聯合客戶,但 Salesforce 將投資在為其他工具帶來更多創新。繼續進行時,建議使用下列方法在 Salesforce 組織之間共用資料。 ### 在整個 Salesforce 組織之間資料整合的工具
指引 成本 時間 體積與規模 交付與維護 隱私權與安全性 要實作的工具
使用時機 額外授權 同步 (要求/回覆) 或非同步 (觸發/忘記) 多物件支援 LDV/大量 測試與部署* 除錯 內建錯誤處理/重試行為 可與靜態加密的資料搭配使用 驗證通訊協定 低程式碼 → 專業代碼
Heroku Connect 當您想要透過跨 Salesforce 組織的雙向同步擴充資料,同時啟用從 Heroku 上執行的行動應用程式和其他應用程式存取資料時 必要 非同步 是 是 否 使用 Pro-Code 工具 是 是,透過 Shield Connect OAuth 低程式碼
MuleSoft Anypoint 當您需要單一企業級統一解決方案來建立、協調和管理整合時;當您需要取代舊版點對點結構時;或當您需要 API 管理支援時 必要 兩者 是 是 是 使用 Pro-Code 工具 否 是** 多 專業代碼
原生 Salesforce API 當 Salesforce 或 Heroku Connect 不是選項或您需要更複雜的處理時 不需要 兩者 否 是 是 使用 Pro-Code 工具 否 是** 多 專業代碼
變更資料取取 當您需要將在 Salesforce 中進行的記錄層級變更發佈至外部系統,且不需要自訂裝載時。 必要 非同步 否 否 是 使用 Pro-Code 工具 是 是 OAuth
Salesforce Connect 與跨組織轉接器 當您想要一個組織中的使用者檢視或編輯不同組織的記錄時,無須複製資料 必要 非同步 是 是 是 使用 Pro-Code 工具 無 無 多 低程式碼
Data 360 當您想讓一個組織中的使用者檢視或編輯不同組織中具有 Data 360 中所複製資料的記錄時。 必要 兩者 是 是 是 使用 Pro-Code 工具 是 是 多 混合式
\*測試與部署是指在較低環境中建立並透過 [中繼資料 API](https://developer.salesforce.com/docs/metadata-coverage/)、封裝或變更集部署至生產的能力 \*\*啟用 Shield Platform Encryption 會變更某些行為,請參閱 [一般 Shield Platform Encryption 考量事項](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)以取得詳細資料。 _平台事件不適合將一個 Salesforce 組織的資料整合到另一個組織,因為它們無法在同一個事件的組織之間「聆聽」。自訂 Apex 也不為此類型整合的建議方法。_ ### 使用個案:連線多個 Salesforce 組織 > 大型企業在多個業務單位 (BU) 之間營運。每個 BU 都有自己的 Salesforce 組織。單一客戶處理企業的多個業務單位,因此在多個組織中擁有帳戶和機會資料。企業需要存取單一組織中所有 BU 之間所有「帳戶」和「機會」資料的彙總檢視。 _注意:根據「[Takeaway #1](#接待時間)」,下列所有解決方案都針對最少數量的資料複製設計。_ 您可以使用立即可用的 Salesforce 連接器,將不同 Salesforce 組織的「**Data 360 帳戶」**和機會資料提取至 Data 360。也可以彙總和協調 (若有需要)。在 Data 360 中彙總資料後,即可使用 Data Cloud One 在其他 Salesforce 組織中存取資料,而無須資料複製。 **Heroku Connect** 針對每個 BU 的個別組織,您可以使用 Heroku Connect 將變更從 Salesforce 同步至單一 Heroku Postgres 資料庫。在此情節下,雙向同步化未啟用,只會從 Salesforce 同步化至 Postgres。接著,在 Heroku Connect 中,您可以啟用 Odata 提供者,並選取要在 Salesforce 組織中公開為外部物件的表格,其中您想要彙總檢視。在 Salesforce 中,您可以定義指向 Heroku 中 Odata 提供者的外部資料來源。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。MuleSoft Anypoint API 可以設定為使用具有組織多個連線的 Salesforce 連接器來讀取來自多個相關 Salesforce 組織的資訊。MuleSoft 流程可查詢不同的 Salesforce 組織,並視需要傳回增強或增強其他第三方資訊的特定結構。叫用 API 時,會執行所有適當的 Salesforce 組織呼叫 (在此範例中查詢帳戶和機會資訊),以便取用者 (可能為 UI) 可以處理資料。對這些系統的驗證可以透過各種驗證機制完成,包括基本驗證和 OAuth。交易量沒有任何限制,只要流程已適當調整其最大利用率的大小 (以 vCores 或 Core 測量)。 「**原生 Salesforce API」** 查詢作業可以發出給每個感興趣的組織,特別是透過 Salesforce 大量 API 2.0,該 API 非常適合有效地提取數千筆記錄。您可以個別從每個組織中提取查詢結果,並根據客戶需求將其與自訂應用程式或中間程式彙總。 **Salesforce Connect with Cross-Org Adapter** Salesforce Connect Cross-Org 轉接器不適合此情況,因為遠端組織的帳戶或機會將全部顯示在中央組織中,作為 *不同的*物件。例如,無法為所有組織中所有機會的「金額」加總總計。 **選擇性更新跨組織案例:**銷售人員使用 Salesforce 組織 A,需要檢視和更新 Salesforce 組織 B 中的「個案」資料,並在組織 A 中工作時,將個案註解新增至 Salesforce 組織 B 上的父系個案。資料不能複製到組織 A。 **Heroku Connect** 您可以使用上述 *資料彙總案例*中所述的相同方法。不過,您必須透過 Odata 連接器在外部物件上啟用 CRUD,並將變更寫回 Heroku Postgres。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。您可以使用上述 *資料彙總情境*中所述的相同方法。 **原生 Salesforce API** 使用已命名認證並叫用原生 Salesforce API 以讀取和更新相關 Salesforce 組織中的資料。元件必須設計為顯示資料。 **Salesforce Connect with Cross-Org Adapter** 透過 [Salesforce 跨組織轉接器](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5)支援檢視外部物件中的資料 (如果您已在外部物件上啟用 CRUD,則也可以編輯資料)。外部物件之間也支援關係,因此您可以連結至外部物件中的父系個案。然而,建立關係是手動流程,您現在可以將現有資料類型轉換為關係資料類型。此外,在 Service Cloud 中執行的最佳化以更有效率地使用「個案」不會串聯至遠端組織。Salesforce 強烈建議您針對使用個案測試「跨組織轉接器」,並評估使用「外部物件」與「標準物件」的權衡。 **資料同步跨組織**:當組織其中一個業務單位 Salesforce 組織中更新客戶的帳戶時,其他 Salesforce 組織的「帳戶」物件必須更新,才能保持一致的帳戶資訊。 **Data 360** Data 360 可用於從一個組織複製資料至另一個 Salesforce 組織。單一 Salesforce 組織的帳戶資料可使用立即可用的 Salesforce 連接器,以便將這些連接中所輸入的資料匯入至 Data 360。我們也可以使用資料啟用機制,例如批次啟用、近乎即時的資料動作或以 API 為基礎的啟用,將資料從 Data 360 移至 Salesforce 組織。 **Heroku Connect** 您可以使用上述 *資料彙總案例*中所述的相同方法。不過,您必須啟用雙向同步化,且您不再需要啟用 Salesforce Connect,因為雙向同步化會在對 Postgres 表格進行變更時讓所有組織保持在最新狀態。 **MuleSoft Anypoint** MuleSoft Anypoint 提供企業級 API 管理。您可以在 MuleSoft Anypoint 中使用 Flow Designer [設定 Mule 應用程式](https://docs.mulesoft.com/design-center/about-designing-a-mule-application),以聆聽標準和自訂物件事件,以在 Salesforce 中開始自動啟動流程。觸發 Mule 應用程式時,其可以叫用 Anypoint Connector for Salesforce 以與任何數量的 Salesforce 組織通訊。在此使用個案中,當 Salesforce 組織中更新「帳戶」記錄時,Mule 應用程式可以更新相關 Salesforce 組織中的「帳戶」記錄。每個相關的 Salesforce 組織都會擁有內建在 MuleSoft 中整體應用程式流程中的唯一更新步驟。對這些系統的驗證可以透過各種驗證機制完成,包括基本驗證和 OAuth。只要流程已適當調整其最大利用率的大小 (以 vCores 或 Core 測量),交易量就沒有任何限制。 **原生 Salesforce API** [Replication API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (getUpdated、getDeleted 作業) 可用來跨組織同步化資料,但不建議使用此方法。 **Salesforce Connect with Cross-Org Adapter** 您可以使用記錄觸發流程和外部物件,讓 Salesforce 組織之間的部分資料保持同步。例如,更新「組織 A」中的帳戶記錄會觸發流程,然後更新「帳戶」外部物件上的相符記錄,這會將這些更新寫入「組織 B」中的帳戶記錄。這需要正確使用流程語意,以避免進行[混合的 DML 交易](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)。此外,請記住,「組織 B 中的驗證規則和流程」會以與 REST/SOAP API 進行變更時相同的方式觸發。 ## 結束備註 請記住此指南,並在您規劃涉及 Salesforce 的新資料整合時參閱該指南。最好瞭解您可用的完整選項範圍,以及這些選項如何符合您的特定使用個案。 ### 告訴我們您的想法 協助我們確保我們發佈與您最相關的內容。[參加我們的調查](https://sfdc.co/J0cWb)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 ## 概觀 Salesforce Platform 持續推進其自動化結構,以滿足複雜業務流程的需求。先前的產生—工作流程規則和流程產生器—提供事件驅動邏輯的初始步驟,擴充事件驅動邏輯的自動化功能,並將範圍延伸至更廣泛的產生器。 此進化為高效能的整合結構,其核心為兩個互補的支柱:記錄觸發流程與 Apex 觸發程序。此文件提供在設計觸發自動化時做出明智決策的架構與原則。 ## 範疇中的產品
流程 Salesforce 流程是一種功能強大的點選自動化工具,可讓使用者使用 Flow Builder 以視覺化方式建立複雜的業務流程、畫面和邏輯,而無須撰寫程式碼。它會自動化資料更新、傳送電子郵件和引導使用者等工作,透過如「畫面流程」(使用者互動) 和「觸發的流程」(記錄/排程事件) 等類型提供彈性。
Apex Salesforce Apex 是 Salesforce 平台的專屬物件導向程式語言,類似於 Java,用於建立自訂業務邏輯、自動化流程,並將核心 CRM 功能延伸至陳述性工具之外。
## 接待時間 在 Salesforce Platform 上建立可調整、可維護且效能高的記錄觸發自動化,需要以結構為導向的紀律化方法。流程與 Apex 之間的選擇,以及每個流程的實作,都由一組明確的原則所引導。這些點總結這些原則,並作為現代自動化設計的基礎規則。 - **根據 Salesforce 物件自動化密度為工作選擇正確的工具。** - 使用 Salesforce 物件的記錄觸發流程來進行 **低密度**自動化。 - 使用可叫用 Apex 增強記錄觸發流程邏輯,以進行 **中密度**自動化。 - 針對 Salesforce 物件使用 Apex 觸發以進行 **高密度**的自動化。 - **觸發非同步程序時請特別小心。** 無論您是在記錄觸發流程中叫用非同步程序,或從 Apex 建立可排列的工作,都適用此規則。雖然此模式對卸載工作來說很有吸引力,但可能會導入複雜的錯誤處理情境,並增加達到管理員限制的風險。 - **針對每個 Salesforce 物件使用一個進入點。** 針對指定的 Salesforce 物件,請使用一個機制作為自動化的進入點。嘗試避免將流程與 Apex 觸發混合為相同物件的進入點。 ## 決策點 ### 陳述性與程式設計實作 Flow 與 Apex 共用一組基本功能。每個工具都可以查詢記錄、執行條件邏輯、指派變數,以及執行 DML 作業,例如建立、更新和刪除記錄,順序以指定順序執行。 不過,此功能重疊不表示工具可互換。架構選擇的重點不在於工作是 _否_ 可以完成,而在於工作 _如何_ 完成,以及對效能、可擴充性和可維護性的長期影響。流程在簡易流程的陳述性清晰度和實作速度方面表現優異,而 Apex 提供複雜解決方案所需的細微控制和原始功能。 ### 自動化密度 **自動化密度**是指放置在特定 Salesforce 物件上的負載。它會作為述詞來決定物件的最佳實作。隨著自動化密度增加,違反交易限制的可能性也會增加。 透過檢查三個特定大小和複雜度來計算自動化密度: - **自動化數量:**在單一「資料操作語言」(DML) 事件期間執行的唯一自動化中繼資料項目 (流程、觸發動作等) 原始數目。 - **記錄量:**透過 API 載入或大量批次處理處理的每個交易記錄,其中效能會變為重要。 - **相依性擴展:**初始 CRUD 作業觸發的下游 DML 作業度量。它會量化圖表的深度,其中一個更新會串聯至相關物件的更新 (例如,個案 → 帳戶 → 連絡人 → 自訂累計)。 自動化密度維度 隨著 Salesforce 應用程式的範圍和複雜度增加,請認可單一主要進入點—記錄觸發流程或 Apex 觸發。避免在單一 Salesforce 物件上跨多個機制進行自動化分割,因為這會導致維護能力不佳和管治分割。 ### 密度選取矩陣 使用此矩陣可決定 Salesforce 物件的必要結構標準。 - **記錄觸發流程**是低自動化密度的偏好解決方案。其提供的功能與無障礙平衡,非常適合直接且彼此獨立的自動化。 - **混合模式 (含可叫用 Apex 的記錄觸發流程)** 是高複雜度的中密度自動化可維護強大選擇。此模式可讓小組在陳述性流程中維護排序的作法,同時將繁重運算作業委派至 Apex,以平衡無障礙與效能。 - **Apex 觸發程序**提供可支援高密度自動化的穩固結構基礎所需的建構組塊。Apex 的效能、細微控制,以及物件導向的抽象與多型,更適合管理這些案例的複雜性和規模。
密度層級 自動化數量 資料量 (批次大小) 相依性流程 結構標準
低 < 15
自動化		 標準
使用者驅動的 UI 互動或小型 API 載入 (1–200 筆記錄)		 不定
獨立邏輯。相同物件或相關物件上的 0–1 下游 DML 作業。		 記錄觸發流程
中型 15–30
自動化		 中度
標準批次處理 (具有需要謹慎大量處理的邏輯)		 已配對
「父系/子系」會更新 2–4 個下游 DML 作業。遞迴風險		 混合模式
流程 + 可叫用 Apex
高 > 30
自動化		 高
大量載入 API 的資料量 (2,000 – 10,000+ 筆記錄)		 複雜與遞迴
深度相依性圖表 (5+ 下游 DML 作業)。三角遞迴迴圈的風險		 Apex 觸發中繼資料架構
實際的結構決策需要您加權自動化密度的所有維度。為指定 Salesforce 物件選取自動化機制時,請考量潛在的未來範圍。 此外,請考量每日 DML 作業的總數,因為 Salesforce 會在多租戶環境中強制執行共用資源管理和[管理員限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm),以防止流失的自動化對共用資源進行垄断。具有高每日 DML 量之 Salesforce 物件需要謹慎的自動化選取。例如,CPU 時間 (60,000 毫秒) 和堆疊大小 (12 MB) 的非同步限制高於同步限制。此外,非同步執行的全組織 24 小時限制 (計算為 250,000 或使用者授權的 200 倍) 需要將每日 DML 總數納入結構設計中,以避免執行階段例外。 ## 產品比較 「記錄觸發流程」是平台用於記錄觸發自動化的首要陳述性工具。流程的易用性和內建平台保護功能可讓小組輕鬆建立可調整且可靠的解決方案。這是大多數的小組在 Salesforce 平台上建立解決方案的理想選擇。 Apex 是平台專屬、強大類型的物件導向程式語言。針對高度自動化密度的 Salesforce 物件,以及需要高效能、複雜邏輯或對交易進行細微控制的使用個案,使用 Apex。 為協助進行決策流程,此矩陣可提供跨關鍵結構功能的流程與 Apex 直接比較。
能力 記錄觸發流程 Apex 觸發
傳送與維護速度 建議
Flow Builder 的視覺使用者介面可讓管理員和其他陳述性產生器比撰寫、測試和部署 Apex 程式碼更快建立和修改自動化。此介面可讓更廣泛的小組成員提供業務價值,並減少對專門開發人員資源的依賴。		 需要專業知識
Apex 需要適當技能的軟體開發人員來實作、測試和維護程式碼。
模組性 可用
記錄觸發流程預設為模組化。小組會針對特定需求建立離散流程,並使用「流程觸發探索器」將其組合進行編程,而不是使用單一邏輯。此模組化功能可啟用隔離修改與簡單擴充,大幅降低長期擁有成本。		 可用
Apex 依設計分為功能模組。每個 Apex 類別都可實作單一功能模組。
可視性和管治 建議
「流程」的視覺性質提供直覺式的業務邏輯表示。「流程觸發探索器」提供物件上所有流程的合併檢視,讓結構設計師和管理員無須閱讀程式碼即可輕鬆瞭解、管理和疑難排解。		 需要專業知識
使用中繼資料架構組織觸發是有益的,但 Apex 需要嚴謹的開發小組,才能讓程式碼保持井然有序且可維護。
高效能大量資料處理 不建議
處理複雜邏輯或大量資料時,達到管理員限制的風險增加。		 建議
Apex 程式碼執行方式更接近平台的核心服務,並為開發人員提供查詢最佳化、資料處理和演算法效率的進階控制權。這會造成更佳的效能與規模,特別是在涉及大量資料的複雜案例中。
強大的邏輯與資料結構 可用
流程轉換元素可協助處理一些複雜的處理工作。然而,Flow 缺少原生「對應」與「設定」資料結構,使複雜的資料處理變得繁琐且計算效率不佳。		 建議
Apex 提供對「對應」、「集」和程式設計迴圈的完整存取權,以高效率、大量安全地操作資料。作為功能完整的程式語言,Apex 也提供複雜邏輯建構、資料結構和設計模式的存取權,可協助以可維持且有效的方式解決複雜的業務問題。Apex 包含進階功能的豐富標準文件庫 (例如 BusinessHours、Crypto),目前無法在陳述性工具中使用。
交易控制 不可用
流程不提供部分交易認可或回復的 `Database.savepoint`、`Database.rollback` 或部分成功 DML 作業存取權。		 可用
Apex 提供交易完整性和複雜錯誤復原情況的完整細微控制。
電子郵件散佈 建議
從記錄觸發流程傳送預先設定的電子郵件警示很簡單且可調整。自訂電子郵件警示可在執行階段建立與散佈。自訂電子郵件受限於 每日電子郵件傳送限制。		 可用
Apex 可以產生和傳送自訂電子郵件訊息。所有從 Apex 傳送的電子郵件皆受限於 每日電子郵件傳送限制。
套用平台保護 建議
流程包含內建的保護,例如自動批次和自動重試。這些防護措施會增加對值的速度,並防止其他需要複雜手動編碼的效能陷阱。		 需要手動實作
如大量處理等保護措施必須明確編碼 (例如管理集合並避免迴圈內的 SOQL)。自動重試並非觸發的原生功能,且需要複雜的自訂邏輯實作。
非同步處理 可用
流程為需要在非同步路徑中進行個別交易的自動化提供簡單機制。這些自動化會受限於每日限制。		 可用
Apex 可透過「變更資料擷取」和由分離的觸發訂閱者處理的可排列事件來啟用完整控制。
排程處理 建議
流程的已排程路徑提供獨特且強大的排程功能 (例如,「結束日期前 3 天觸發」)。如果記錄的資料變更,此功能包括自動取消和重新排程。這些自動化會受限於每日限制。		 不可用
Apex 觸發無法原生排程具有自動取消的時間記錄特定事件。雖然已排程 Apex 存在,但這是一個基本不同的機制,會在特定時間執行,且不會在作為觸發一部分的個別記錄處理期間進行排程。
排序和作法 可用
「流程觸發探索器」可讓管理員定義相同物件上多個流程的相對執行指示。		 可用
觸發架構提供對自動化確切順序的細微控制。
相同記錄欄位更新 可用 (儲存前)
「記錄觸發流程」是最有效的陳述性選項,用於在初始 DML 認可之前更新觸發記錄。		 可用 (儲存前)
Apex 提供最高的效能產品,而且額外成本最低。
跨物件 CRUD 可用 (儲存後)
流程適用於簡單、低複雜、跨物件 DML 作業。		 可用 (儲存後)
Apex 為跨物件 DML 作業提供超級的還原、錯誤處理和效能控制權。
減少重複的昂貴運算 可用
流程在透過自動大量處理來去除冗餘的查詢和 DML 陳述式方面表現出色。不過,狀態無法在不同的流程觸發之間或在一個交易內同一個流程的多個叫用之間快取或共用。在極端效能情況下,此限制可能會變得重要。		 建議
Apex 提供用於刪除重複昂貴作業的機制。開發人員可以利用使用靜態內容與變數的交易快取,以及使用「平台快取」的平台層級快取來儲存及重複使用資料。這些技術對於減少交易管理員限制 (例如 SOQL 查詢) 的耗用,並確保高效能與延展性十分重要。
自訂錯誤處理 可用
CustomError 元素可以封鎖儲存作業,並向使用者顯示訊息。		 建議
addError() 方法提供彈性的欄位級和條件式錯誤傳訊。
## 使用個案 ### 最適合的建議 此表格根據呈現的功能,提供一般使用個案的一般「最適合」建議。最後,您會考量其他考量事項,以找出最適合您特定案例的項目,例如此文件的「_相關最佳作法」_一節中包含的案例。在此,您將深入瞭解特定「流程」與 Apex 組合何時提供最佳方法。
使用個案 描述 最適合 理由
高效能批次處理 必須有效率地處理數千筆記錄的任何自動化 Apex Apex 提供豐富的 API,可用於與平台的介面和原始速度。
複雜資料處理 需要進階資料操作的案例 Apex Apex 提供「流程」中原生無法使用的資料結構,例如「對應」與「集」,這些結構對於撰寫效能高且安全的程式碼而言至關重要。
交易控制 控制如儲存點、結轉和部分認可等機制 Apex Apex 提供如 Database.savepoint 和 Database.rollback 等機制的存取權,並能夠處理部分成功的 DML 作業。
精密的自訂驗證 記錄中多個欄位的資料驗證 Apex 雖然「流程」可以防止使用「CustomError」元素儲存,但並非所有流程類型皆可使用,包含子流程。Apex addError() 方法提供多個欄位特定錯誤訊息,可在觸發處理期間隨時新增至記錄。
簡單程序內的中度複雜邏輯 由標準功能庫簡化,中度複雜度的邏輯與資料操作,作為不複雜流程的一部分發生 流程 + Apex 「記錄觸發流程」會作為協調流程層,而高複雜度的作業會壓縮在「可叫用 Apex」內。
簡單到中度複雜的邏輯 低至中度複雜度的資料操作,其中會觸發主要與相關資料物件的更新 流程 流程通常是執行選項,因為其以陳述性模型為基礎,可供管理員和開發人員存取。
通知與輸出訊息 傳送輸出電子郵件與訊息 流程 流程可讓在記錄變更時傳送電子郵件警示和輸出訊息輕鬆且高度調整。
排程處理 未來動態日期自動化 (例如結束日期前 3 天) 流程 已排程路徑為流程提供獨特的優勢,因為當記錄的資料變更時,平台會自動處理這些路徑的排程、取消和重新排程。
### 可調整處理:深入分析非同步使用個案 設計實作時,延展性是重要的考量事項。當記錄觸發自動化的商業邏輯變得複雜、執行時間長或涉及大量資料時,Salesforce 平台的核心管理員限制會變成結構限制。大量資料更新、複雜的 API 呼叫或繁重計算等作業會增加違反限制的風險,例如總 CPU 時間或單一資料庫交易內的 DML 陳述式數量。由於限制例外,同步觸發失敗會導致使用者的整個儲存交易回復,導致使用者體驗不佳並可能遺失資料。此固有的風險需要結構模式來卸載複雜工作。 非同步自動化在此個案中至關重要。使用非同步機制,結構設計師可以有效地將長時間執行或大量工作與主要同步記錄儲存交易分離。儲存可快速且可靠地完成,而大量處理會委派至稍後執行的個別平台管理交易。分離可改善穩定性、防止交易失敗,對於建立可調整的企業應用程式而言至關重要。此平台為此提供數種專用工具,每種工具皆具有與可靠性、數量和複雜度相關的不同優點和權衡。 ### 流程的非同步路徑 記錄觸發流程中的「非同步執行」路徑提供「觸發忘記」非同步邏輯的最簡單機制。原始記錄儲存交易成功認可至資料庫後,此路徑會在個別交易中執行。 - **理想使用個案**:這適用於不需要立即執行或自訂錯誤處理的工作。範例包括傳送電子郵件通知、建立後續追蹤工作,或對外部系統進行簡單呼叫。 - **限制**:此機制與其他非同步流程訪問共用相同的每日管理員限制。不適用於極大量處理。 ### Change 資料擷取 (CDC) Change 資料擷取 (CDC) 是一種高流量、可調整且彈性的模式,用於處理大量案例中記錄變更所觸發的非同步邏輯。在此模型中,觸發的唯一責任是同步儲存記錄。接著,平台會發佈詳細的事件訊息,其中包含記錄對大量 Event Bus 的變更。個別的專用 Apex 觸發會訂閱此變更事件。它會執行複雜、長時間執行或非同步的工作。 - **益處**:此模式會將非同步流程與初始使用者交易分離。非同步處理失敗不會造成使用者的記錄儲存回復。模式也提供可供多個內部訂閱者或外部系統使用的永久事件串流,且事件最多可重新執行 72 小時,提供強大的彈性。 - **限制**:CDC 事件訊息不包含記錄的先前狀態,亦即等同於 Apex `Trigger.oldMap`。事件裝載包含新的欄位值,但不包含其變更的值。這會使根據特定狀態轉換實作邏輯變得具有挑戰性 (例如,僅在 `Status__c` 從「待處理」變更為「已批准」時執行)。您可以透過在事件訂閱者中查詢物件的欄位歷程記錄來減輕此情況,但這會對流程增加複雜性,且欄位歷程記錄追蹤可能無法用於特定感興趣的欄位。這可能會限制您可以卸載至 CDC 的自動化類型。 依預設,CDC 最多可在五個 Salesforce 物件上啟用。需要更多的組織可以購買附加元件授權,以移除此限制並增加事件傳送配置。 ### 從觸發將 Apex 加以排列 直接從觸發程序執行可排列的 Apex 工作應視為具有風險的模式,僅在需要 Apex 提供的控制時使用 (例如,用於複雜邏輯或自訂重試機制),且 CDC 不是可行的選項。 如果 Apex 需要可排列,則實作必須包含適當的保護措施: - **限制檢查**:程式碼必須在嘗試新增其他工作之前,先檢查已在交易中建立的工作數目。 ``` if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... } ``` - **內容認知**:程式碼必須偵測其是否在非同步環境 (例如批次工作 (`System.isBatch()`) 內執行,並修改其行為,以遵循該環境中更嚴格的一次性交易限制。 ### 限制觸發非同步 Apex 的考量事項 從同步觸發叫用非同步 Apex 會導致穩定性風險。為了防止組織層級影響 (例如超出限制),此模式需要嚴格的設計和測試。 - 非同步 Apex 執行的每日限制 (`Batch`、`Queueable`、`@Future`) 會在整個組織中共用 (通常為 250,000 個或以使用者授權為基礎的計算)。大量資料載入 20,000 個記錄會造成觸發以 200 個區塊執行,進而導致 100 個個別的觸發叫用—如果大量批次大小少於 200 個記錄,則更多。如果每個叫用都會將非同步工作加以排列,則可能會耗用單一資料載入中每日限制的很大部分。此耗用可能會使非同步資源的其他重要業務流程枯竭。 - 指派工作的管理員限制會根據內容顯著不同。透過 UI 中使用者動作 (即 _同步_交易) 觸發的觸發,最多可建立 50 個可排列的工作。然而,從在批次 Apex 類別 (_非同步_交易) 的 `execute` 方法中觸發的觸發,只能將一個可排入排列的工作列入。無法考慮此差異是常見且嚴重的失敗點,這會在大型資料作業期間導致發生 `LimitException` 錯誤。 - 直接從觸發內容呼叫可排程 Apex (`System.schedule`) 或批次 Apex (`Database.executeBatch`) 會構成反模式。這些方法並非為了從觸發內容叫用而設計。這麼做會導致您快速耗用非同步 Apex 配置,進而導致限制例外。 ### 選擇正確非同步模式 每個非同步機制都有與效能、管理員限制和可靠性相關的特定權衡。使用此決策樹為指南,協助您瀏覽這些選項,並為您的使用個案選擇正確機制。 非同步模式決策樹 ### 已排程工作替代項目 如流程圖所示,當您面對大量的 DML 作業,但無法使用「變更 資料擷取」(可能是因為物件限制),最佳結構選擇通常是完全避免觸發叫用程序。 請考慮改用排程的流程。這可以是「排程的流程」或「排程的 Apex」。必要步驟包括: 1. 在同步觸發中執行簡單且低成本的更新。例如,將 `Status__c` 欄位設定為「待處理」,或插入低成本相關記錄 (例如 Chatter 貼文),以表示該記錄需要處理。 2. 建立排程工作,無論是排程流程還是排程 Apex,其會定期執行,例如每 15 分鐘或每小時執行一次。 3. 為所有處於待處理狀態的記錄排程工作查詢、在受控制的大量內容中執行複雜邏輯,然後將記錄更新為已處理。 此模式完全將大量處理與使用者的同步儲存分離,不受觸發批次的一個工作每個交易限制的約束,並為非即時需求提供高度可調整且可管理的解決方案。 如果已排程工作的延遲不適用於業務需求,且您仍然受限於使用 CDC 或觸發的可排列,則表示結構不相符。此時必須考量不同的機制。重新評估核心應用程式設計可能會導致某些結論,例如: - 購買附加元件以移除 CDC 物件限制。 - 從根本上挑戰業務需求,以確定近乎即時處理是否為「必須」或已排程工作的延遲是否為平台穩定性的可接受權衡。 ## 非功能考量事項 ### 複雜性 實作的複雜程度是解決方案的總擁有成本的一部分,以及其適應不斷變化的業務需求的能力。如果未遵循最佳作法,則複雜性可能會影響任何實作。在此文件的「_相關最佳作法_」區段中,有降低解決方案複雜程度的建議,包括以下模式: - 混合模式:流程中複雜邏輯的可叫用 Apex - 使用 Apex 觸發的中繼資料架構 - 超級流程與多個流程 ### 流程與標準 文件與自動化本身一樣重要。它不僅確保可維護,而且對 AI 和以工作人員為基礎的工具至關重要。文件可協助您瞭解和管理業務流程。 **在流程中** - 為所有元素和變數建立一致的命名慣例。 - 使用流程的「描述」欄位說明其整體目的、觸發條件和預期成果。 - 在每個個別元素上使用「描述」欄位 (例如,`Get Records`、`Action`、`Transform`)。此作法是傳達意圖的最佳方法。這對於可叫用動作和子流程而言特別重要,其中描述是說明動作執行之複雜邏輯的主要位置。 **In Apex** - 清楚地為程式碼加上註解,以說明邏輯背後的_原因_,而不只是說明_什麼_。 - 如果使用中繼資料驅動的架構,請確保您的中繼資料記錄包含並填入人類可讀的「描述」欄位,以說明每個處理常式類別的執行方式和執行時間。 DevOps 與來源控制是成熟開發生命週期的一部分。一律使用來源控制工具,例如 Git for Salesforce 專案。Apex 類別與 Salesforce 流程都是定義您業務邏輯的中繼資料,且必須經過版本化與管理。 在記錄觸發自動化的管理內容中,現代 DevOps 管道提供重要的優點。 - **自動化品質檢查:**如 [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) 等工具可設定為在您的管道中自動執行。靜態分析可以在兩個自動化工具升級前偵測到有問題的模式,並標記在「流程」迴圈內效率不佳的 `Get Records` 元素或迴圈內的 Apex 中的 `SOQL` 查詢等問題,這是效能降低的常見原因。 - **迴歸防止:**隨著自動化密度的增加,變更一個流程或 Apex 類別可能會對相同物件的其他自動化產生非預期的後果。強大的 DevOps 測試策略會根據任何建議的變更執行自動化 Apex 測試,這是確保新流程版本不會中斷現有 Apex 邏輯 (反之亦然) 的最可靠方法。 - **協同合作與可視性:**來源控制是「唯一的事實來源」。它可讓管理員和開發人員並列處理相同物件的自動化。它也提供寶貴的稽核追蹤:當生產流程中斷時,您可以立即查看變更自動化_的人員_、變更自動化_時機_,以及認可訊息—變更自動化_的原因_。 針對具有混合管理員與開發人員的小組,[DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) 提供統一介面,協助進行所有這些步驟的編程,讓小組中的每個人皆可存取可調整的來源控制開發流程。 此統一的文件與 DevOps 學科可確保貴組織的長期運作狀況與可維護性,這對您跟隨的每位結構設計師和管理員都有益。 ## 相關最佳作法 計畫實作之前,最好使用上述決策指南。其目標是協助您為使用個案選擇最佳產品。選取產品後,瞭解實作的現有最佳作法十分重要。 ### 利用混合模式:流程中複雜邏輯的可叫用 Apex _每個物件一個工具_原則對於管理高密度自動化而言至關重要,但請勿將其解譯為純陳述式或純程式設計堆疊之間的二進位選擇。更有效且可維護的結構模式利用「混合式」模型:將「記錄觸發流程」定位為協調流程層,同時在「可叫用 Apex」內壓縮高複雜度的作業。 混合模式圖 #### 協調流程層級:流程 「記錄觸發流程」可作為業務流程的協調流程層。它擁有輸入條件和執行內容 (_什麼_和_何時_)。透過在此層內保留決策邏輯和路由,結構的流程拓範可透過「流程觸發探索器」保持透明且可管理,進而防止重要業務邏輯在程式碼中隱藏。 #### 複雜元件:可叫用 Apex 複雜元件的一個常見範例為針對「個案」記錄實作「服務層級契約」(SLA) 計算。由於 BusinessHours 物件及其相關邏輯 (對於不含非工作時間與假日的準確計算而言至關重要) 無法在流程中原生存取,因此會使用專屬的 Apex 類別。此類別通常稱為 `ServiceLevelAgreementCalculator` 等名稱,其設計方式是使用單一靜態方法 (以 `@InvocableMethod` 註釋),以計算經過的營業時間、判斷 SLA 是「在目標內」還是「已到達」,並傳回結構化輸出。此方法會壓縮 Apex 中複雜且高效能的邏輯,同時允許流程順暢地執行並整合至記錄觸發流程的陳述性協調流程層。 定義 Apex `ServiceLevelAgreementCalculator` 類別後,即可在記錄觸發流程中使用: 此模式示範嚴格分隔關注。陳述性層用於管理交易生命週期和協調流程,而程式碼用於高複雜度執行。透過將程式碼視為功能公用程式而非基礎,我們能夠平衡效能與維護性。 #### 混合模式的主要收益 **模組性**:決策會從整個程序使用 Apex 或流程的單數性遠離。而是會將複雜邏輯壓縮為離散、大量安全且可獨立測試的單元。這些單位會作為陳述性層耗用的可重複使用元件運作,確保自動化會調整規模,而不會使結構設計變得複雜。 **可重複使用**:性邏輯會與觸發事件分離。設計良好的程式碼單位 (例如 `InvocableMethod`) 會寫入一次,但會利用多個進入點:記錄觸發的流程、畫面流程或外部整合。此程式碼重複使用可免除冗餘開發。 **永續性**:流程流程邏輯在陳述性流程中保持可見且可管理。此集中化會大幅減少除錯負擔,並確保系統的執行指示是決定性且透明的。 #### 混合模式的限制與權衡 雖然使用流程中可叫用 Apex 的混合式模型功能強大,但並非一體適用的方法。結構設計師必須先瞭解特定限制和權衡,才能認可混合式解決方案。 - **無儲存前支援**:這是最嚴重的限制。「可叫用動作」僅適用於儲存後內容 (動作和相關記錄的流程)。無法在高效能儲存前內容 (快速欄位更新的流程) 中使用。因此,此模式無法用於委派相同記錄欄位更新。在儲存前流程或在內容前 Apex 觸發中,使用原生「流程」元素執行高效能工作。 - **無刪除後支援:**「記錄觸發流程」目前不支援取消刪除後內容。如果 Salesforce 物件具有從資源回收筒還原記錄時執行自動化的業務需求,則 Apex 觸發是唯一的解決方案。 - **在大量案例中的效能負擔:**從流程執行階段轉換至 Apex 執行階段並非零成本作業。雖然通常快速,但從「流程」的執行階段放入「可叫用動作」的動作在運算上並非如同完全留在 Apex 觸發內的原生執行一樣快速。針對大多數的中密度自動化,此微重設為可提高無障礙性的可忽略且值得權衡。不過,針對極端高效能、大量案例,純粹 Apex 僅限架構將具有原始運算速度優勢。 ### 舊版自動化的策略 雖然自動化密度摘要提供更新的綠色欄位結構最終指引,但企業 Salesforce 環境的實際狀況通常更為細微。在成熟的組織中,通常會找到記錄觸發的流程和在相同的 Salesforce 物件上作業的 Apex 觸發。此案例與之前所述的混合模式不同:在此,流程與 Apex 觸發並未與之配對,且並未設計為共同運作。 此共存通常是由於平台功能不斷發展或舊版技術債務所導致。雖然這是可接受的作業狀態,但結構設計師必須將其視為已計算的權衡,而非結束狀態。 區隔的協調流程會造成嚴重的管治與維護負擔,導致開發、測試和事件處理活動遭到中斷且繁琐。這會導致解決時間 (TTR) 和作業複雜度增加。 - 針對新的 Salesforce 物件,請遵循自動化密度原則作為主要指引。 - 針對具有混合式足跡和雙 Apex 觸發和記錄觸發流程進入點的現有 Salesforce 物件,請評估密度,然後將架構器重新產生至可維護的混合式狀態。 - 針對低密度,重構器 Apex 會觸發記錄觸發流程,並指定執行順序,將其帶往單一自動化進入點。 - 針對中度密度,重構器複雜的大型流程會以正確的執行順序流入流程子集。僅在絕對必要時 (例如支援取消刪除內容後) 導入 Apex 觸發。 - 針對高密度,建議實作 Apex 觸發。 ### 使用 Apex 觸發的中繼資料架構 隨著組織在 Salesforce 平台上的業務流程成熟,記錄觸發自動化的數量和複雜度不可避免地增加。基礎最佳作法是維護每個 Salesforce 物件 _一個 Apex 觸發_。此規則十分重要,因為平台不保證針對相同事件在相同物件上執行多個觸發的執行順序。此限制可能會導致非決定性行為、種族條件和難以除錯的問題。 然而,遵循 _單一觸發_原則導致架構挑戰:如何以可維護且可調整的方式管理和協調從該單一進入點叫用的所有業務邏輯。 #### 傳統觸發處理常式的限制 此結構的第一個進化是 Classic 觸發處理常式模式。在此方法中,單一 Apex 觸發會將其所有的邏輯委派給對應的處理常式類別 (例如,`OpportunityTriggerHandler`)。此方法會將邏輯與觸發檔案分開,並為開發人員提供對處理常式類別方法中執行順序的決定性控制 (例如,`afterInsert()`)。 雖然是改善方式,但此模式通常會導致單一處理常式類別。隨著時間的推移,隨著業務需求增加,類別會變得較大、難以管理,且難以獨立測試。所有個別程序的執行順序會在單一方法中硬式編碼,使類別容易發生合併衝突,進而在大型企業環境中大幅增加監管和維護負擔。 #### 解決方案:中繼資料驅動的觸發架構 為了解決模組化與協調的核心問題,結構設計師會改用「**中繼資料驅動觸發架構**」。這是一個重要的結構突破,將自動化邏輯本身與執行_方式_和執行_時間_的組態分開。 此架構以三個主要優點為基礎: - **分割:**系統會將核心業務邏輯細分為小型原子 Apex 類別 (例如,`RecalculateAccountValues` 類別或 `NotifySalesLeads` 類別),每個類別都遵循「_單一責任原則_」。此模組性可讓邏輯在隔離中更容易測試、除錯和瞭解。 - **順序和作法:**執行指示不再以 Apex 硬式編碼。而是由組態記錄以宣告的方式定義,通常儲存在自訂中繼資料類型中 (例如,`TriggerAction__mdt`)。這可讓管理員透過修改中繼資料記錄來重新排序、新增或移除自動化動作,這不需要部署或程式碼變更。 - **略過功能:**架構提供標準化且細微的略過功能。每個自動化動作都可以透過其中繼資料記錄設定為全域關閉,或透過參照自訂權限來針對特定管理使用者略過。 物件的單一 Apex 觸發程序則只會作為動態分派員使用。它不包含業務邏輯,而是會例項化中央的 `MetadataTriggerHandler` 類別。此處理常式會查詢自訂中繼資料記錄,以動態決定執行順序,並以指定的順序叫用正確的原子 Apex 類別。自動化在單一、透明且可管理的層級之下統一。 ### 減去交易中昂貴的重複作業 在強大的架構中使用 Apex 的重要優點是能夠管理交易狀態,並透過去除冗餘工作來最佳化效能。隨著邏輯的累積,儲存訂單中的不同自動化通常會獨立執行相同昂貴的作業,進而耗用寶貴的管理員限制並增加 DML 作業時間。 架構的結構是透過兩個主要策略來解決此問題: - **共用狀態管理:**在單一 Apex 交易的範圍內,會利用靜態內容和變數來快取資料。這可確保昂貴的作業 (例如組態設定的 `SOQL` 查詢) 僅執行一次,即使在不同記錄或觸發階段中多次叫用自動化邏輯。交易限制的耗用量大幅減少。 - **平台快取利用率:**若要超越簡單的交易內快取,請使用平台快取來避免查詢特定資料的整個資料庫。此受管理的記憶體內快取非常適合用於在整個交易過程中 (例如,設定檔、角色、營業時間) 檢索非原始資料、經常閱讀的資料。使用 `Cache.CacheBuilder` 介面,系統會先檢查快取,且僅在資料缺少時執行資料庫查詢,以最大化效能與延展性。 ### 使用儲存前更新相同記錄 當自動化只需要變更啟動交易之記錄的欄位值時,請一律使用儲存前更新。這適用於流程中的快速欄位更新 (儲存前執行) 和 Apex 觸發中的內容前邏輯 (插入前、更新前)。 無論使用的工具為何,此模式都能執行,因為其會避免第二次 DML 作業和遞迴儲存週期。在記錄認可至資料庫 _之前_,系統會在記憶體中對記錄進行變更,並儲存為原始交易的一部分。系統會去除第二個儲存的額外負擔,否則會重新執行整個儲存訂單並再次觸發所有自動化。 ### 防止不受控制遞迴 未受控制遞迴是更新後觸發的常見陷阱,其中觸發邏輯會執行 DML 更新,進而導致再次觸發相同的觸發。這會建立一個無限迴圈,最終會以管理員限制例外來結束。雖然過去曾經用於防止此類遞迴的靜態布林值標記或已處理記錄識別碼的集合,但更精確且強大的模式是透過比較記錄本身新版本與舊版本之間的欄位值,來入口邏輯。 只有在特定感興趣的欄位實際已變更時,才執行邏輯。這可防止觸發程序在重要資料保持不變的相同交易中,對後續 DML 作業執行其邏輯。 #### 控制記錄觸發流程中的遞迴 在記錄觸發流程中,透過設定流程僅在記錄更新以符合條件需求時執行,以防止未受控制遞迴: 控制記錄觸發流程中的遞迴 如果您選擇在流程中使用項目條件公式,您可以透過比較 `$Record` 全域變數 (代表新值) 與 `$RecordPrior` 全域變數 (代表儲存前的原始值) 來防止流失遞迴。例如,若要確保流程僅在「機會」上的「金額」欄位已變更時執行,請在項目條件中使用以下項目: ``` $Record.Amount != $Record__Prior.Amount ``` #### 在 Apex 中控制遞迴 將新版本記錄 (`Trigger.new`) 的欄位值與舊版本記錄 (`Trigger.oldMap`) 的欄位值進行比較,以瞭解是否已發生您要尋找的特定變更。此方法可確保自動化是無效的,且只在需要時執行,進而提高系統效率並避免災難性遞迴迴迴圈。 ### 略過自動化 結構良好的 Salesforce 組織需要一致且可靠的機制來略過自動化。這不是選用的功能,而是維護資料完整性和啟用管理工作的核心作業需求。 略過架構對於某些情況至關重要: - 載入大量資料時,針對每個記錄觸發觸發程序會大幅減慢流程、造成限制例外,並建立錯誤的相關記錄和通知。略過可讓資料精簡且有效地插入。 - 整合使用者可能需要從記錄的外部系統同步化資料。當變更源自其他系統時,通常針對使用者起始的變更 (例如傳送電子郵件、建立工作) 觸發的自動化可能不理想或冗餘。 - 管理員或支援人員可能需要對記錄執行修正更新。略過機制可讓他們進行這些變更,而無須觸發標準業務自動化,這可能會造成非預期的後果。 **自訂權限**:實作略過邏輯的現代化、可調整標準為自訂權限。這些方法優於舊方法,原因如下: - **彈性:**自訂權限可透過權限集指派給使用者。此作法與現代的 Salesforce 安全性和存取模型保持一致,允許細微且彈性的指派。可以將略過授與特定使用者,甚至可以暫時授與特定到期日/時間。 - **維護性:**使用自訂權限可避免將設定檔或使用者硬式編碼至自動化邏輯。如果使用者的角色變更,或新設定檔需要略過存取權,則變更為簡單的「權限集」指派,而非需要部署的程式碼或流程修改。 - **延展性:**自訂權限提供可調整的架構,可管理跨複雜使用者群組的例外狀況。這些權限集可以透過權限集、權限集群組或設定檔指派給使用者。其與權限集或設定檔的關聯也可在來源中繼資料中表示。 **實作模式**:將一致的略過模式套用至組織中所有記錄觸發的自動化。 **略過記錄觸發流程**:略過流程的最有效率方法,就是避免流程完全執行。透過將條件新增至流程的項目條件來達成此目標。 - 在記錄觸發流程的「開始」元素中,將「條件需求」設定為「公式評估為 True」。 - 在公式產生器中,使用 `$Permission` 全域變數來納入自訂權限的檢查。將檢查與您現有的項目條件結合。 - 公式模式: ``` ( ) && NOT($Permission.Bypass_This_Flow) ``` - 此模式可確保只有在使用者 _未_ 獲指派指定的自訂權限時,流程才會執行。此檢查會在建立流程訪問之前執行,使其成為最具效能的方法。 **略過 Apex 觸發架構**:在 Apex 中,將略過邏輯直接整合至中繼資料驅動的觸發架構,進而允許細微控制。 - `TriggerAction__mdt` 自訂中繼資料類型應包含文字欄位,例如 `BypassPermission__c`。 - 在 `MetadataTriggerHandler` 類別中,程式碼應先讀取此欄位的值,再動態執行動作。 - 如果已填入欄位,則處理常式會使用 `FeatureManagement.checkPermission()` 方法判斷目前執行使用者是否具有指定的自訂權限。 - 如果 `checkPermission()` 傳回 true,則處理常式會略過該特定動作並繼續進行序列中的下一個動作。 - 此模式功能強大,因為它同時允許全域略過 (如果所有 `TriggerAction__mdt` 記錄都參照相同的權限) 和細微的各個動作略過 (如果不同的記錄參照不同的權限,或者有些記錄完全沒有略過權限)。 ### 超級流程與多個流程 這是一種反模式,可將物件的所有自動化合併到單一的大型大型流程中。將合併為一個流程與分割為多個適當條件流程的邏輯,不會對效能造成重大影響。最顯著的績效提升來自於: - 針對相同記錄欄位更新使用儲存前流程。 - 撰寫精確的輸入條件,以確保不會對其特定使用個案造成影響的變更排除執行流程。 [流程觸發探索器](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer)可讓您將訂單值指派給物件上的每個流程,以保證依序執行訂單。 流程觸發探索器 ## 資源
Apex 流程 作業
# 開始使用 Data 360 決策指南 本節提供關於 Salesforce Data 360 進行關鍵結構決策的實際指引,包括佈建策略、多組織連線和整合模式。使用這些指南設計與實作統一客戶資料並啟用 AI 強化的有效資料結構。 --- ## Data 360 佈建 「[Data 360 佈建」](/docs/architect/zh-tw/decision-guides/guide/data-360-provisioning) 涵蓋佈建 Salesforce Data 360 時的基本決策: - **首頁組織選取**:決定要在現有生產組織中佈建 Data 360 還是建立專屬組織,並考量監管、合規性和時間對價值。 - **多組織策略**:在多個獨立 Data 360 例項之間選擇,或使用 Data Cloud One 統一多個 Salesforce 組織,平衡自主性、合規性和成本。 - **Data Cloud One 結構**:啟用多個「伴隨組織」以透過組織之間的集中管理、中繼資料共用和功能比對來共用單一 Data 360 例項。 - **Data 360 組織之間的資料共用**:針對區域合規性、業務單位協同合作或聯合主管顯示面板,在獨立例項之間使用零複製資料共用。 - **佈建考量事項**:資料落地、管治模型、延遲、整合複雜度、成本和企業範圍部署 AI 整備的因素。 協助結構設計師設計佈建策略,以確保 Customer 360、AI 和跨平台創新的簡化、企業一致性、合規性和延展性。 --- ## Data 360 互通性 [Data 360 互通性](/docs/architect/zh-tw/decision-guides/guide/data-360-interoperability) 提供整合 Data 360 與外部平台和資料湖的架構: - **資料取用模式**:即時、串流和批次採取,以建立適合 Customer 360、合規和集中管理的受管理標準資料集。 - **零複製資料聯合**:即時查詢、加速查詢 (快取) 和檔案聯合方法,以即時存取外部系統而不重複,啟用個人化、顯示面板和 AI/ML 工作量。 - **混合式方法**:使用零複製聯合結合核心資料集的受管理性,以確保最新性和延展性,並支援 Omni-Channel 參與、Agentforce 驅動的動作和企業分析。 - **決策架構**:評估延遲、成本、可擴展性、管治和複雜性的權衡,以選取每個資料來源的正確整合模式。 - **建築師手冊**:針對財務、醫療照護、零售和電信情況的產業特定指引、設計作法和成本考量事項。 引導結構設計師平衡資料更新、管治和管道效率,以建立可調整、可互通且 AI 就緒的資料結構,以支援作業與分析工作量。 # 開始使用平台決策指南 本節提供關於 Salesforce Platform 功能之重要結構決策的實際指引。它涵蓋非同步處理、記錄觸發事件、表單建立、事件驅動的結構,以及步驟型非同步架構,以協助結構設計可調整、可維護和高效能平台解決方案。 --- ## 非同步處理 [非同步處理](/docs/architect/zh-tw/decision-guides/guide/async-processing)提供 Salesforce 中非同步作業工具和方法的指引: - **非同步處理工具**:可排列 Apex、排程的 Apex、平台事件觸發、變更資料擷取、排程路徑 (認可流程後) 和非同步路徑 (記錄觸發流程) 的比較,以及適當使用個案的指引。 - **伺服器端非同步處理**:長時間執行資料庫作業、外部呼叫和大量記錄處理的模式。 - **用戶端非同步處理**:如 Apex 繼續呼叫和用戶端非同步處理等技術,可在瀏覽器或行動應用程式中執行。 - **決策架構**:考慮使用個案驗證、可擴充性、瞭解交易何時為真非同步、監視及處理極端負載事件。 - **最佳作法與反模式**:適當使用的指引,包括輸出整合、監視和避免常見的陷阱。 讓結構設計師能夠實作可調整、可靠且可維護的非同步模式,避免可能影響效能的陷阱。 --- ## 建立表單 「[建立表單」](/docs/architect/zh-tw/decision-guides/guide/build-forms) 會引導結構設計師瞭解 Salesforce 表單建立選項: - **表單建立工具**:動態表單、畫面流程、OmniStudio、畫面流程與 Lightning Web 元件 (LWC) 和 LWC 的比較,包括技能和授權考量事項。 - **決策架構**:考量物件影響、表單範圍、瀏覽、位置 (應用程式、行動裝置、網頁)、UX 和測試自動化。 - **工具選取指引**:從簡單的記錄版面配置到多頁精靈和品牌面向客戶表單的建議。 - **組合模式**:結合工具的指引,例如「畫面流程」瀏覽與 LWC 樣式。 - **進階功能**:深入瞭解功能與限制以通知工具選擇。 協助結構設計師為其特定 UX、功能與整合需求選取正確的表單建立方法。 --- ## 以事件為導向的結構 [以事件為導向的結構](/docs/architect/zh-tw/decision-guides/guide/event-driven)提供 Salesforce 事件工具和模式的全方位指南: - **避免工具**:平台事件的概觀、Change 資料擷取、Pub/Sub API、MuleSoft Anypoint、Streaming API 和整合考量事項。 - **事件驅動模式**:針對各種以事件為導向的使用個案,包含發佈/訂閱、對應、傳送訊息、串流和排列模式。 - **與 MuleSoft 的整合**:針對企業結構使用 Anypoint 連接器 (Pub/Sub、JMS、Kafka、Solace、MQ、MQTT、AMQP)。 - **平台事件和變更資料**:發佈記錄和欄位變更的偏好機制指引,以及從 PushTopic/Generic Events 移轉的指引。 - **實作模式**:擴展性、一致性、錯誤處理和監視的最佳作法。 讓結構設計師設計可調整的近乎即時事件驅動系統,以有效率地連線多個系統。 --- ## 以步驟為基礎的非同步架構 [以步驟為基礎的非同步架構](/docs/architect/zh-tw/decision-guides/guide/step-based-async-framework)提供模組化、可調整的非同步工作處理架構: - **架構結構**:元件包含「可排列 Apex」、「完成者」、「排程流程」、「Apex 游標」、「可叫用動作」和 Slack 整合。 - **以步驟為基礎的處理**:分割為獨立步驟,可透過共用管理與營運可視性來執行、重試和重新啟動。 - **實作指引**:步驟介面、步驟處理器、Apex 可叫用圖層、延遲處理和通知的模式。 - **最佳作法**:適用於 CRM 中大多數資訊、大量工作負載和階層或樹狀目錄記錄處理時的建議;不使用時的指引。 - **企業級功能**:監管、合規性、散佈狀態、進度追蹤、SLA 監視、失敗診斷和稽核層級記錄。 為結構設計師提供單一批次工作和鏈結非同步呼叫的可調整替代方案,以完全的作業透明度支援大量 Salesforce 工作負載。 --- ## 記錄觸發自動化 [記錄觸發自動化](/docs/architect/zh-tw/decision-guides/guide/record-triggered)提供在 Salesforce Platform 上設計記錄觸發自動化的架構: - **工具選取**:何時使用「記錄觸發流程」與 Apex 觸發,以自動化密度 (低、中、高) 和密度選取矩陣為指引。 - **自動化密度**:如何評估自動化數量、記錄量和相依性擴展,以選擇「流程」、「混合式」(使用可叫用 Apex 進行流程) 或 Apex 觸發。 - **進入點與管治**:每個 Salesforce 物件一個進入點;進入條件、遞迴控制和排序執行的指引。 - **非同步叫用**:從記錄觸發流程或 Apex 叫用非同步流程的時間和方式,並謹慎處理錯誤和管理員限制。 - **最佳作法**:大量處理、混合式 Flow–Apex 設計和避免觸發自動化常見陷阱的模式。 讓結構設計師設計可調整、可維護且能效能的記錄觸發自動化,並符合平台標準。 # 開始使用整合決策指南 本節提供為 Salesforce 選擇正確資料整合工具和方法的實際指引。它涵蓋輸出整合、輸入整合和跨組織案例,協助結構設計師設計和實作資料層整合以平衡效能、可維護性和成本。 --- ## 與 Salesforce 的資料整合 [資料與 Salesforce 整合](/docs/architect/zh-tw/decision-guides/guide/data-integration)提供 Salesforce 資料整合工具和最佳作法的全方位概觀: - **整合工具橫向**:Salesforce 資料整合工具的概觀,包括低程式碼、混合式和專業程式碼選項,以及針對特定使用個案選取正確工具的指引。 - **輸出整合**:將資料從 Salesforce 傳送至外部系統的方法,包括 Change 資料擷取、External Services、Heroku Connect、OmniStudio 整合程序、Salesforce Connect、MuleSoft Anypoint 和自訂 Apex 解決方案。 - **輸入整合**:將外部資料帶入 Salesforce 的方法,以及資料複製與虛擬化的指引,以及每個工具的使用時機。 - **跨組織整合**:在 Salesforce 組織之間共用資料的建議方法,包括 MuleSoft Anypoint、Heroku Connect、原生 Salesforce API、使用跨組織轉接器變更 資料擷取 和 Salesforce Connect 包括取代舊版 Salesforce 到 Salesforce 實作的指引。 - **決策架構**:選取整合工具的關鍵考量事項,例如現有工具和橫向、資料流程需求 (時間、方向性、預期的使用者體驗)、實作複雜性、可維護性、資料量和平台限制。 讓結構設計師可以為每個案例選擇正確的整合工具和模式,減少不必要的資料複製、利用現有的 ESB/ETL 解決方案,並確保符合企業結構原則的可調整且可維護整合。