---
schema_version: "1"
id: b527834818afb58d70083ef0b49aa4c63edb9a29cee1d7bcfd1c3961b557598a
title: Data 360 整合模式
collection: architect
version: current
locale: zh-tw
portal_url: https://docs.salesforce.com/architect/current/zh-tw/fundamentals/guides/data360_integration_patterns_and_practices.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: b4a2ff3e478161d57d21f02ec557689ac3f23fe21df76101723f0ff3eaf05585
products:
  - 基本概念
  - Architect Site Content Repo
updated_at: 2026-02-01T00:00:00Z
---
# 概觀
現代 Salesforce 整合必須支援比簡單的資料交換更多。他們預期能夠提供即時客戶體驗、協調多個系統的動作,並在企業規模上可靠運作,同時符合嚴格的安全性和合規性需求。因此,選擇正確的整合方法是重要的結構決策,而非實作詳細資料。
請考量常見的企業案例。客戶在行動應用程式中完成購買,以觸發個人化優惠的即時資格檢查。同時,必須在 ERP 系統中記錄交易資料、在 Salesforce 中更新客戶屬性,以及將分析串流至資料湖—而不會導致延遲、資料重複或合規性風險。此類案例現在在現代 Salesforce 環境中很典型,Salesforce 很少獨立運作,且必須與更廣泛的應用程式與資料平台生態系統順暢整合。
此指南是為了協助結構設計師和開發人員以清晰且自信的方式設計這些整合。它不專注於點對點實作,而是呈現一組**已驗證的整合模式**,以處理循環的企業案例,例如流程協調流程、資料同步化和即時資料存取。每個模式都會強調架構意圖、權衡和執行模式,讓小組能夠做出明智的設計決策,以擴展和持續。
在此文件中,您會發現:
* 代表流程、資料和虛擬存取情況之間常見企業「階層類型」的整合模式
* 模式選取架構,可協助根據整合意圖和執行時間點找出正確的方法
* 關於可擴充性、彈性、管治和安全性考量事項的實際指引
* 從實際世界 Salesforce 與 Data 360 實作中所取得的最佳作法

此文件的目標是提供整合的共用結構語言,協助小組設計平衡效能、彈性和 Trust 的解決方案,同時與企業資料和管治策略保持一致。

## 目的與範圍
此文件適用於需要將企業中其他應用程式的資料與 Salesforce Data 360 (先前稱為 Data Cloud) 整合的設計師和結構設計師。此內容是 Salesforce 結構設計師和合作夥伴成功實作的精密精簡。
若要熟悉可用於大規模採用 Data 360 的整合功能和選項,請參閱下方的「模式摘要」和「模式選取指南」一節。結構設計師和開發人員在將資料互動專案納入 Data 360 的設計和實作階段期間,應考量這些模式詳細資料和最佳作法。
若正確實作,這些模式可讓您盡快進入生產環境,並擁有最穩定、可調整且無維護的應用程式集。Salesforce 自己的諮詢結構設計師會在結構審查期間使用這些模式作為參考點,並主動維護和改善模式。
與所有模式一樣,此內容涵蓋大部分的整合案例,但並非全部。例如,Salesforce 允許使用者介面 (UI) 整合,但此類整合超出此文件的範圍。
### 模式範本
每個整合模式皆遵循一致的結構。這可讓每個模式提供的一致資訊,並且更容易比較模式。
* **名稱**:此模式識別碼也表示模式中包含的整合類型。
* **內容:**模式處理的整體整合情況。「內容」提供使用者嘗試達成之目標的相關資訊,以及應用程式支援需求的行為。
* **問題:**以問題表示,這是模式設計要解決的案例。請閱讀此區段以瞭解模式是否適合您的整合案例。
* **力:**使所述情況難以解決的限制與狀況。
* **解決方案:**解決整合案例的建議方法。
* **草稿:**UML 順序圖表,顯示解決方案如何處理案例。
* **結果:**說明如何將解決方案套用至整合案例的詳細資料,以及其如何解決與該案例相關聯的障礙。此區段也包含因套用模式而可能發生的新挑戰。
* **側列:**與模式相關的其他區段,其中包含重要的技術問題、模式變化、模式特定的疑慮等。
* **範例:**描述如何在 Salesforce 實際案例中使用設計模式的實際世界案例。範例說明整合目標,以及如何實作模式以達成這些目標。
## 模式摘要
使用此表格作為此文件中所包含整合模式的目錄。
### 模式清單
<table>
<thead>
<tr>
<th>模式層級1</th>
<th>模式層級2</th>
<th>模式</th>
<th>助理</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#資料入院模式--資料輸入">資料入院模式--資料輸入</a></td>
<td><a href="#批次吸收模式">批次吸收模式</a></td>
<td><a href="#從雲端儲存空間中大量取用資料">從雲端儲存</a>裝置大量取用資料</td>
<td>系統會從企業雲端儲存來源 (例如 Amazon S3、Azure Blob 或 Google Cloud Storage) 將資料以大量原始資料批次 (例如交易或產品記錄) 的形式,將資料納入 Data 360。</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#從-salesforce-cloud-大量資料取用">從 Salesforce Cloud</a> 大量資料取用</td>
<td>Data 360 會從多個 Salesforce 組織 (例如 Sales Cloud、Service Cloud) 大量接收 CRM 資料,以建立統一的客戶設定檔。</td>
</tr>
<tr>
<td></td>
<td><a href="#串流和即時取用模式">串流和即時取用模式</a></td>
<td><a href="#以事件為導向的使用者可透過採取-api--串流">事件驅動的使用者介於「Embase API--串流」中</a></td>
<td>Data 360 會訂閱來自企業系統中接收連續事件裝載 (例如購買事件、IoT 遠端測試),以進行即時設定檔更新的串流取用端點。</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#即時-web-與行動裝置的行動行為">即時 Web 與行動裝置的行動行為</a></td>
<td>Data 360 會透過 SDK 收集並處理即時網站和行動應用程式行為資料,以增強參與度量和個人化模型。</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#透過串流近乎即時的-crm-同步化">透過串流近乎即時的 CRM 同步化</a></td>
<td>Data 360 會透過事件串流接收近乎即時的 CRM 資料更新 (例如連絡人、個案、機會變更),以維護持續同步的 Customer 360 檢視。</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#cloud-messaging-platformskinesis-和-msk-中的事件串流">來自雲端傳訊平台—Kinesis 和 MSK 的事件串流</a></td>
<td>Data 360 會直接從雲端事件平台 (例如 AWS Kinesis 或 Kafka (MSK)) 取用串流資料,以處理高頻率的作業或 IoT 事件。</td>
</tr>
<tr>
<td><a href="#零複製模式輸入與輸出">零複製模式--輸入與輸出</a></td>
<td><a href="#輸入零複製---外部平台至-data-360">輸入零複製--外部平台至 Data 360</a></td>
<td></td>
<td>Data 360 會依需求透過「Zero Copy Capture」來查詢外部資料集 (例如 Snowflake、BigQuery),而不會實際地將資料移至 Salesforce。</td>
</tr>
<tr>
<td></td>
<td><a href="#輸出零複製--data-360-至外部平台">輸出零複製--Data 360 至外部平台</a></td>
<td></td>
<td>外部系統 (例如 Databricks 或 Tableau) 可透過「零複製輸出」連線存取 Data 360 中增強的區段和洞察,而不需要資料複製。</td>
</tr>
<tr>
<td><a href="#使用-data-cloud-one-整合多組織資料平台">使用 Data Cloud One 整合多組織資料平台</a></td>
<td></td>
<td></td>
<td>Data Cloud One 會在共用的中繼資料和語意模型下統一多個 Salesforce 組織和外部資料來源,提供一致的 Customer 360,而不會重複資料。</td>
</tr>
<tr>
<td><a href="#資料啟用模式--資料輸出">資料啟用模式--資料輸出</a></td>
<td><a href="#批次啟用模式">批次啟用模式</a></td>
<td><a href="#將區段啟用至行銷和廣告平台">行銷和廣告平台的區段啟用</a></td>
<td>Data 360 會將精密設計的客戶區段直接啟用至 Marketing Cloud、Meta、Google Ads 或其他廣告平台,以進行個人化行銷活動傳送</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#資料匯出至雲端儲存空間">資料匯出至雲端儲存空間</a></td>
<td>Data 360 會將統一或篩選的資料集 (例如同意的客戶記錄) 作為 CSV 或 Parquet 檔案匯出至企業雲端儲存空間,以供分析或合規歸檔。</td>
</tr>
<tr>
<td></td>
<td><a href="#隨選-api-型啟用">隨選 API 式啟用</a></td>
<td><a href="#透過-connect-api-自訂應用程式整合">透過 Connect API 的自訂應用程式整合</a></td>
<td>外部應用程式會根據目前的客戶資料,在即時中叫用 Data 360 Connect API,以根據實際客戶的資料,從個性化動作 (例如忠誠度平衡檢查或 AI 優惠產生) 中提取或觸發個人化動作。自訂建置的 Web 或行動應用程式會透過 Connect REST API 安全地提取已協調的 Data 360 洞察,以在企業或合作夥伴 UI 中顯示。</td>
</tr>
<tr>
<td></td>
<td></td>
<td><a href="#透過資料圖形-api-完成客戶設定檔尋找">透過 Data Graph API 完成客戶設定檔檢索</a></td>
<td>系統會使用「資料圖表」API 提取客戶的統一設定檔,以傳回完全全方位檢視的預先聯結即時 JSON 表示,以進行決策或個人化。</td>
</tr>
<tr>
<td></td>
<td><a href="#即時資料動作">即時資料動作</a></td>
<td><a href="#將客戶訊號轉換為立即動作的即時資料動作">將客戶訊號轉換為立即動作的即時資料動作</a></td>
<td>Data 360 會偵測及處理即時事件 (例如同意更新、購買觸發),並立即叫用連線的系統或 Salesforce 流程進行後續動作。Data 360 中的客戶活動訊號 (例如偵測到流失風險) 會觸發即時即時動作,例如更新 CRM、叫用 Einstein 評分或啟動保留旅程。</td>
</tr>
</tbody>
</table>

### **模式方法**
此文件中的整合模式分為三個種類:資料、程序和視覺整合。
#### **資料整合**
Data 360 中的資料整合模式可解決跨系統的資料移動和同步化,以確保 Data 360 與外部平台都保留一致、及時且值得信賴的資訊。這些模式通常會處理大規模、大量的資料流程,並依賴強制執行結構描述一致性、歷程追蹤和掌握規則的受管理管道。
* **「批次接收模式**」代表企業資料上線的基礎層。從雲端儲存體服務 (例如 AWS S3、Azure Blob 或 Google Cloud Storage) 採取大量資料,可將大型歷程記錄資料集定期載入至 Data 360 以進行身分解析、區隔和分析。同樣地,從 Salesforce Clouds (例如 Sales、Service 或 Marketing Cloud) 大量採取會使用原生連接器和資料串流,將 CRM 資料帶入統一的資料層,確保參與系統之間的調和和和連續性。
* 「**串流和即時取用模式」**可藉由快速事件資料來加強此功能。透過「取用 API」以事件為導向,會讓外部系統能夠將客戶活動持續串流至 Data 360。即時 Web 和行動行為取用會直接從數位接觸點捕捉點閱與互動資料,以推動立即個人化。透過串流 API 進行近乎即時的 CRM 同步化,可確保客戶屬性和同意更新可在整個系統之間快速反映。來自如 Amazon Kinesis 或 Confluent MSK 等傳訊平台的事件串流,支援連續的高輸送量管道,讓 Data 360 與企業事件結構保持一致。
* **統一多組織資料平台與 Data Cloud One** 進一步範例化資料整合,提供一個合併的環境,以在共同的管治和語意層下統一來自多個 Salesforce 組織和外部來源的資料。這可讓組織達成企業範圍資料一致性、共用資料模型和可調整分析。
* 在啟用階段中,**批次啟用模式**遵循相同的資料整合原則。在 Data 360 中精密設計的區段會在排程的工作中匯出至下游行銷和廣告平台 (例如 Marketing Cloud、Meta Ads 或 Google Ads),在其中觸發行銷活動執行。同樣地,資料集可以匯出至雲端儲存目標,以支援外部分析和資料科學銷售管道。在所有這些使用個案中,Data 360 會作為同步化與精密設計的客戶資料事實來源。
#### **流程整合**
Data 360 中的流程整合模式涉及在近乎即時的情況下,觸發或協調跨系統的業務流程。這些模式可讓 Data 360 主動參與企業工作流程,以啟用內容相關回應和動態資料啟用。
* **隨選 API 型啟用**可啟用即時參與情況。透過 Connect API,自訂應用程式可以直接從 Data 360 查詢或啟用客戶設定檔,以作為作業流程的一部分,例如工作人員主控台在客戶互動期間提取統一設定檔洞察。「**透過 Data Graph API 完成客戶設定檔檢索」**支援依賴對客戶完整實體圖表的 API 驅動存取權的複合應用程式和微型服務,以允許沒有預先階段區段的動態體驗。
* 「**即時資料動作」**透過啟用立即回應性,進一步推動此整合方法。當偵測到客戶訊號時 (例如購買、表單提交或值值事件),Data 360 可以觸發動作,例如更新 CRM 記錄、叫用外部 Webhook 或啟動個人化優惠工作流程。這些模式實現了真正的流程協調流程,將即時客戶智慧與自動化作業執行橋接。
#### **虛擬整合**
Data 360 中的虛擬整合模式可讓您即時存取外部或聯邦資料來源,而無須實際複製或複製資料。這些對於在查詢時需要受管理且最新的資訊,同時將資料移動降到最低的企業而言至關重要。
* **輸入零複製資料聯合 (External Platforms-to-Data 360)** 允許外部系統 (例如資料倉庫或資料湖) 透過受管理的安全連線 (例如 Snowflake 安全資料共用) 與 Data 360 共用資料集。這可確保 Data 360 可以虛擬地存取和操作外部資料,進而保持最新狀態並消除不必要的複製。
* **輸出零複製資料共用 (Data 360 至外部平台)** 可讓 Data 360 透過安全的資料聯合和即時查詢機制,將精密設計的資料集公開供外部使用,例如 AI 建模、業務情報或進階分析。
為您的系統選擇最佳的整合策略並非不簡單。有許多要考慮的層面以及可以使用的工具,有些工具比其他工具更適合某些工作。每個模式都會處理特定重要區域,包括每個系統的功能、資料量、失敗處理和交易性。
## 模式選取指南
選取整合模式時,請先回答整合整體設計和行為的兩個基本問題。
**您要整合什麼?—程序、資料或虛擬存取權**
此維度定義整合的主要目的。
* **流程整合**著重於協調業務工作流程和跨系統協調動作。
* **資料整合**專注於在系統之間同步化、增強或移入資料。
* **虛擬整合**專注於即時存取外部資料,而無須在 Salesforce 或 Data 360 中複製或保留。
瞭解此意圖有助於決定系統之間所需的協調流程、資料移動和配對層級。
* **如何執行? — 同步或非同步**方法定義整合的執行模式。
* **同步**整合是即時和封鎖的,來電者預期立即回應,通常用於使用者驅動或驗證案例。
* **非同步**整合為非封鎖與分離,專為處理規模、長時間執行流程、重試和大量資料而設計。
這些兩個維度 (**整合意圖**和**執行時間**) 共同提供清晰且一致的架構,可供選取正確的整合模式,同時平衡使用者體驗、可擴充性和作業彈性。
**備註:**整合可能需要外部中介或整合解決方案 (例如,Enterprise Service Bus),端視適用於整合案例的層面而定。
### 將 Data 360 與其他系統整合
此表格列出模式及其關鍵層面,以協助您在從 Salesforce 整合至其他系統時判斷最適合您需求的模式
<table>
<thead>
<tr>
<th>類型</th>
<th>時間</th>
<th>輸出考量事項</th>
</tr>
</thead>
<tbody>
<tr>
<td>資料整合</td>
<td>非同步</td>
<td><a href="#將區段啟用至行銷和廣告平台">行銷和廣告平台的區段啟用</a></td>
</tr>
<tr>
<td>程序/資料整合</td>
<td>同步</td>
<td><a href="#透過-connect-api-自訂應用程式整合">透過 Connect API 的自訂應用程式整合</a><br>
<a href="#透過資料圖形-api-完成客戶設定檔尋找">透過 Data Graph API 完成客戶設定檔檢索</a></td>
</tr>
<tr>
<td>資料整合</td>
<td>同步</td>
<td><a href="#將客戶訊號轉換為立即動作的即時資料動作">將客戶訊號轉換為立即動作的即時資料動作</a></td>
</tr>
<tr>
<td>虛擬整合 (使用零複製)</td>
<td>非同步</td>
<td><a href="#輸出零複製--data-360-至外部平台">輸出零複製--Data 360 至外部平台</a></td>
</tr>
<tr>
<td>虛擬整合</td>
<td>非同步</td>
<td><a href="#使用-data-cloud-one-整合多組織資料平台">使用 Data Cloud One 整合多組織資料平台</a></td>
</tr>
</tbody>
</table>

### 將其他系統與 Data 360 整合
此表格列出模式及其關鍵層面,以協助您在從其他系統整合至 Salesforce 時,決定最符合您需求的模式。
<table>
<thead>
<tr>
<th>類型</th>
<th>時間</th>
<th>輸入考量事項</th>
</tr>
</thead>
<tbody>
<tr>
<td>資料整合</td>
<td>非同步</td>
<td><a href="#從雲端儲存空間中大量取用資料">從雲端儲存</a>裝置大量取用資料<br>
<a href="#從-salesforce-cloud-大量資料取用">從 Salesforce Cloud</a> 大量資料取用</td>
</tr>
<tr>
<td>資料整合</td>
<td>非同步</td>
<td><a href="#cloud-messaging-platformskinesis-和-msk-中的事件串流">來自雲端傳訊平台—Kinesis 和 MSK 的事件串流</a><br>
<a href="#透過串流近乎即時的-crm-同步化">透過串流近乎即時的 CRM 同步化</a></td>
</tr>
<tr>
<td>流程整合</td>
<td>同步</td>
<td><a href="#以事件為導向的使用者可透過採取-api--串流">事件驅動的使用者介於「Embase API--串流」中</a><br>
<a href="#即時-web-與行動裝置的行動行為">即時 Web 與行動裝置的行動行為</a></td>
</tr>
<tr>
<td>虛擬整合</td>
<td>非同步</td>
<td><a href="#輸入零複製---外部平台至-data-360">輸入零複製--外部平台至 Data 360</a></td>
</tr>
</tbody>
</table>

### 中介軟體詞彙與定義
此表格列出與 middleware 相關的一些重要詞彙,以及與這些模式相關的其定義。
<table>
<thead>
<tr>
<th>期限</th>
<th>定義</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>事件處理</strong></td>
<td>事件處理是指從來源系統或應用程式接收、路由和回應可識別的事件。中間軟體會透過識別目標端點、轉送事件,以及觸發必要業務動作 (例如記錄、重試或啟用下游服務) 來處理事件。在 Data 360 架構中,事件處理對於即時資料取用、啟用觸發和發佈/訂閱模式至關重要。事件可能源自外部系統 (Kafka、AWS Kinesis) 或 Salesforce Platform 事件,且由中介軟體或 Data 360 Event Bus 路由以供立即處理。</td>
</tr>
<tr>
<td><strong>通訊協定轉換</strong></td>
<td>通訊協定轉換允許使用不同的資料傳輸標準在系統之間進行通訊。中間軟體會將專屬或舊版通訊協定 (例如 AMQP、MQTT、FTP) 翻譯為支援的 Data 360 通訊協定 (REST、gRPC 或 HTTPS)。這可確保不同階層系統的互通性。由於 Data 360 不會原生處理通訊協定轉換,因此 middleware 會提供適應層,將訊息壓縮或轉換為 Data 360 API 格式,連接器可以進行解譯。</td>
</tr>
<tr>
<td><strong>翻譯和轉換</strong></td>
<td>翻譯和轉換可透過將一個資料格式或結構描述對應至另一個資料格式來確保互通性。Middleware 會執行這些轉換,使各種資料裝載 (CSV、XML、JSON) 與 Data 360 資料模型物件 (DMO) 和統一資料層物件 (UDLO) 保持一致。這包括清除、增強和套用以語意或基於本體的對應,然後再採取。雖然 Salesforce 提供如資料準備配方等轉換工具,但複雜轉換 (尤其是用於語意調和) 最適合在中介軟體中處理。</td>
</tr>
<tr>
<td><strong>排隊和緩衝</strong></td>
<td>以非同步訊息傳遞為依據,以確保彈性、分離的通訊。中介軟體平台 (例如 MuleSoft、Kafka 或 Azure Event Hub) 會提供永久的可在 Data 360 或下游系統忙碌或無法存取時暫時儲存資料。這可防止資料遺失,並支援近乎即時的快取或啟用重試。Data 360 支援串流移入和流程式輸出傳訊,但永久的排入和保證傳送通常由中介軟體處理。</td>
</tr>
<tr>
<td><strong>同步傳輸通訊協定</strong></td>
<td>同步傳輸通訊協定涉及封鎖、即時要求/回應作業。寄件者在繼續之前會等待回覆。在 Data 360 中,這些項目用於隨選 API 式啟用、即時增強或設定檔對應,其中立即需要回應。中間軟體可確保連線可靠性,並管理同步 Data 360 API 呼叫的重試或回復處理。</td>
</tr>
<tr>
<td><strong>非同步傳輸通訊協定</strong></td>
<td>非同步傳輸通訊協定支援非封鎖、分離的通訊,其中寄件者可繼續處理,而無須等待回應。中間軟體可處理批次啟用、串流移入和事件驅動啟用的非同步流程。這可實現高輸送量和彈性,這對於 Data 360 中的事件串流和近乎即時的資料取用模式而言至關重要。</td>
</tr>
<tr>
<td><strong>中介路由</strong></td>
<td>仲裁路由會定義系統之間的複雜訊息流程,確保正確的資料或事件到達正確的消費者。中介會作為中介者,根據規則、標題、內容或事件類型處理路由邏輯。在 Data 360 整合中,中介可確保來自多個系統的事件和設定檔更新正確路由至「資料取用 API」、啟用端點或外部取用者。這可簡化協調流程,並支援多系統資料同步化。</td>
</tr>
<tr>
<td><strong>流程編程和服務協調流程</strong></td>
<td>流程 koreography 和協調流程可協調多系統流程。koreography 支援以事件為導向的自動非同步流程,其中系統會根據沒有中央控制項的共用規則來執行動作。協調流程是集中管理的流程,可導向服務執行。在 Data 360 架構中,中介軟體可管理跨系統採取和啟用的協調流程,而 Salesforce 工作流程或「流程」可處理平台內的輕量型 koreography。建議在中介軟體層進行複雜協調流程 (需要交易協調或狀態管理)。</td>
</tr>
<tr>
<td><strong>交易性 (加密、簽署、可靠傳送、交易管理)</strong></td>
<td>交易性可確保在整個系統之間有原子、一致、隔離且永久 (ACID) 的作業。Salesforce 和 Data 360 在其範圍內進行交易,但不支援跨外部系統的散佈交易。中間軟體可處理全域交易控制,包括加密、訊息簽署、回復、薪水和可靠傳送。針對關鍵任務的資料流程 (例如財務或同意更新),中介軟體可確保跨 Data 360 和外部系統的端對端完整性和復原。</td>
</tr>
<tr>
<td><strong>路由</strong></td>
<td>路由指定元件之間訊息或資料的控制流程。其可以標題、內容類型、優先順序或規則為基礎。中間軟體可處理涉及 Data 360 事件和啟用的路由邏輯,例如將豐富的受眾區段導向至不同的下游系統 (廣告平台、倉庫、CRM 應用程式)。雖然可在 Salesforce (Apex、流程) 內實作路由,但為了擴充性、彈性和管治,偏好使用中介軟體路由。</td>
</tr>
<tr>
<td><strong>提取、轉換和載入 (ETL)</strong></td>
<td>ETL 涉及從來源系統中提取資料、將其轉換為一致的結構描述,並將其載入至目標 (例如 Data 360)。中間軟體或 ETL 工具會處理這些作業,然後再移轉資料。Data 360 可以透過 API、連接器或大量取用管道接收 ETL 輸出,也支援變更資料擷取 (CDC) 以進行近乎即時的同步化。中間 ETL 流程對於整合舊版系統並確保資料品質在 Data 360 中統一之前至關重要。</td>
</tr>
<tr>
<td><strong>長輪詢</strong></td>
<td>長輪詢 (Comet 程式設計) 是維護系統之間開放通訊以進行即時更新的方法。用戶端會傳送要求,伺服器會保留要求直到事件發生為止,然後回應並重新開啟新的連線。Salesforce 會在串流 API 和 CometD/Bayeux 通訊協定中使用此功能,以進行以事件為導向的資料同步化。中間軟體可以訂閱這些事件,並將其轉送至 Data 360 以進行即時取用或啟用觸發,以確保跨企業系統的延遲最小。</td>
</tr>
</tbody>
</table>

## 資料入院模式--資料輸入
Salesforce Data 360 資料生命週期中的第一個且最關鍵的步驟,即是資料取用。這是來自多個外部系統 (CRM、ERP、網頁、行動或第三方 API) 的原始資訊進入平台並成為統一客戶檢視的一部分的方式。
正確的採取模式取決於業務需求:
* **資料量**—一次移動的資料量
* **延遲**—資料的最新程度
* **來源系統功能**—系統如何連線和傳送資料
Data 360 支援多個採取模式以符合下列需求:適用於大量載入的批次、近乎即時更新的串流、以事件為基礎以進行交易立即處理,以及可立即存取外部資料且不實際移動的「零複製」。
這些模式共同確保每個客戶訊號 (無論是購買事件、點閱記錄或忠誠度更新) 都會有效率、安全且在正確的時間範圍內流入 Data 360,以支援信任的分析和 AI 驅動的體驗。
### 批次吸收模式
批次取用模式是 Data 360 中大規模資料上線的支柱。其針對大量處理資料的情境 (通常是排程或定期處理) 而非持續處理資料的情況進行最佳化。
這些模式最適用於:
* 以現有企業記錄初始化平台的**歷程記錄資料載入**
* 定期與記錄系統 (例如 ERP、資料倉庫或專屬資料庫) 進行**同步化**
* **使用不需要即時新鮮度**,但需要一致性、完整性和可稽核性的個案
針對管理結構化或半結構化資料的 TB 時,可預測的效能與作業簡易性,這使其成為信任的選擇。
Data 360 提供一組現成生產的廣泛可用**[連接器,這些連接器](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5)**原生支援批次入院。這些連接器可簡化整合設定、減少自訂 ETL 開發,並確保每次匯入的資料品質與安全性。下表會醒目提示用於企業規模批次取用最常見的連接器。
#### 從雲端儲存空間中大量取用資料
##### Context
此模式針對企業案例設計,其中涉及從集中化資料湖或排程檔案中移除大量結構化資料 (例如 CSV 或 Parquet 檔案) 和非結構化資產。資料來源通常包括雲端儲存平台,例如 Amazon S3、Google Cloud Storage (GCS) 和 Microsoft Azure Blob Storage,其中檔案會定期作為上游資料銷售管道或批次匯出的一部分傳送。
##### 問題
組織如何根據可預測的循環排程,建立可靠、安全且高輸出流程,將大量的檔案式資料集從其主要的雲端儲存平台提取至 Data 360,而不犧牲管治、擴展性或效能?
##### 力量
將大量以檔案為基礎的資料集中至 Data 360 並非簡單的資料傳輸演練,而是由規模、管治和平台限制所塑造的結構挑戰。

**資料量與規模:**已針對可靠性和管治最佳化 Data 360 取用連接器,而非任何大量輸送量。例如,Amazon S3 連接器支援最多 1 千萬列或每個物件 50 GB,取決於先到達的限制。針對具有歷程記錄資料集的企業,此邊界會成為重要的設計限制。單一檔案、提取和排班方法快速無法運作,需要智慧資料分割、切分和協調策略才能達到規模,而無須達到連接器限制。

**結構描述定義與維護:**Data 360 需要針對每個採取管道具備明確的結構描述定義,以確保語意與結構完整性。在 S3 取用的情況下,csv 檔案必須定義欄標題和單一代表資料列。此檔案會作為來源系統 (即雲端儲存體) 與 Data 360 之間的標準契約。任何欄位名稱、資料類型或編碼中的錯誤對齊方式,都可能會導致輸入失敗或無訊息資料損毀。在版本控制中維護此結構描述檔案,並透過 CI/CD 或資料管理工作流程強制驗證,會成為生產環境的最佳作法。

**嚴格命名慣例:**Data 360 會強制執行 **嚴格的物件和欄位命名規則**,以維持中繼資料圖表的一致性。
* 物件名稱必須以字母開頭,且只能包含字母、數字或底線。
* 欄位名稱必須遵循相同的模式。
違反這些慣例的檔案 (例如,包含空格、特殊字元或不支援符號的欄位) 會在取用期間無法驗證結構描述。企業必須實作**食用前資料衛生程序**,以清除和正規化傳入的檔案結構。

**驗證和安全性狀態:**每個外部儲存空間的連線都必須符合企業級安全性和合規性標準。
* 驗證通常會透過 AWS 存取金鑰/機密金鑰或聯邦身分提供者 (IdP) 驗證來處理。
* IAM 角色必須以範圍來強制執行最低權限,僅允許對指定儲存路徑的讀取存取權。
* 為了安全存取,輸出 IP 位址必須直接新增至來源系統的允許清單。
這些分層控制項可確保每個檔案傳輸都會在零 Trust 可稽核的範圍內運作,以平衡企業合規性與大規模摘要所需的彈性。
##### 解決方案
此表格包含此整合問題的解決方案。
<table>
<thead>
<tr>
<th>解決方案</th>
<th>適合</th>
<th>註解</th>
</tr>
</thead>
<tbody>
<tr>
<td>使用原生雲端儲存連接器 (Amazon S3、Google Cloud Storage、Azure Blob Storage)</td>
<td>最佳</td>
<td>此為大規模、循環檔案型取用至 Data 360\ 的建議且最可靠模式。原生連接器可提供受管理驗證、結構描述對應,以及直接將資料安全移動至 Data 360 的資料湖物件 (DLO)。適用於排程的批次載入,其延遲不重要 (例如排程每小時或每日)。</td>
</tr>
<tr>
<td>處理大型資料集 (超出連接器限制)</td>
<td>最適用於預先處理</td>
<td>每個連接器都會強制執行取用限制 (例如 S3: 100 萬列或每個物件 50 GB)。針對較大的資料集,請實作 ETL 預先處理步驟,以將資料分割至低於下限的較小檔案/資料夾。接著,設定多個資料串流以並行地取用每個分割,然後在 Data 360 內使用批次資料轉換中的附加節點,將分割重新合併為統一的資料集。</td>
</tr>
<tr>
<td>安全性與管治</td>
<td>最佳</td>
<td>所有連接器都支援透過雲端原生方法 (IAM 角色、服務帳戶或存取金鑰) 進行安全驗證。如需額外控制,請透過雲端提供者的允許清單限制 Data 360 IP 範圍的存取權。資料傳輸會透過加密的管道進行,其中檔案會儲存在暫時安全的暫存層中,並且會在取用期間進行。</td>
</tr>
<tr>
<td>不使用時機</td>
<td>子最佳</td>
<td>此模式不適用於:<br> <ul> <li>即時或近乎即時的事件。</li>
<li>交易、低延遲整合。</li>
<li>沒有結構描述定義功能的來源在這種情況下,請改用串流連接器 (Kafka、Kinesis、Pub/Sub) 或 Zero Copy Data Federation。</li>
</ul>
</td>
</tr>
</tbody>
</table>

##### 草稿
此圖表說明將資料從雲端儲存空間匯入至 Data 360 的步驟順序
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/batch_cloud_storage.png" alt="顯示實作雲端儲存整合之流程的 UML 圖表" />

在此情況下:
* 管理員透過 Data 360 設定介面設定雲端儲存空間的連線 (指定驗證、分類詳細資料、IAM 角色和白名單)。
* 「Data Cloud 設定」介面會使用 Cloud Storage Platform 進行驗證,驗證認證和存取權。
* 管理員會在 Data 360 中建立資料串流,將資料串流連結至 Cloud Storage 中的物件/資料夾,並定義取用排程。
* 在排程觸發時,資料串流會從雲端儲存平台要求來源檔案 (例如 CSV、Parquet)。
* Cloud Storage Platform 會傳送檔案,包括必要的有效 schema_sample.csv 以及其他符合命名慣例的資料檔案。
* 「資料串流」會將檔案傳輸至 Data 360 內的內部暫存環境。
* Data 360 Pipeline 處理檔案:使用 schema_sample.csv 中的結構描述定義「驗證結構、欄位名稱」,並在超過取所值 (100 百萬列/每個檔案 50 GB) 時分配載入。如果偵測到大型檔案,則會在外部執行預先處理的分割步驟 (通知管理員以進行下一次執行)。
* 記錄會從暫存匯入至資料湖物件 (DLO)。
* 如果需要且資料已分割,請使用批次資料轉換中的 append 節點來結合多個 DLO。
* Data 360 會記錄成功/失敗、更新監視狀態,並表示資料已準備好進行對應、調和和統一。
##### 結果
此模式的應用可安全、排程及大規模地將結構化或非結構化檔案從企業雲端儲存平台提取至 Data 360。此流程為自動化、可調整且彈性的,可將原始資料傳送至資料湖物件 (DLO),作為調和和對應至 Customer 360 資料模型的基礎。
###### 吸收機制
取用機制取決於在 Data 360 中定義的連接器和排程策略。
<table>
<thead>
<tr>
<th>吸收機制</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td>本地雲端儲存連接器 (Amazon S3、GCS、Azure)</td>
<td>建議直接從企業的雲端資料湖中,從 CSV 或 Parquet 格式的檔案採取。這些連接器支援增量與完整重新整理排程。例如,銀行可以設定從 S3 分類將客戶交易檔案每日同步至 DLO。</td>
</tr>
<tr>
<td>分割檔案策略</td>
<td>對於非常大的資料集 (超過 1 億列或每個物件 50 GB),資料會分割為較小的邏輯集 (例如依月份或區域)。系統會以個別的「資料串流」管理每個分割,之後再使用含附加節點的「批次資料轉換」來重新組合。</td>
</tr>
<tr>
<td>自動排程的同步化</td>
<td>Data 360 提供一個陳述性排程器 (每小時、每日或自訂步調),此排程器會自動觸發取用工作,以確保資料新鮮無須手動介入。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
錯誤處理和復原對於確保高流量摘要作業的可靠性而言至關重要。
* **錯誤偵測:**每個「資料串流」執行都會記錄「Data 360 監視」中的採取錯誤 (例如結構描述不相符、檔案損毀或命名違規)。管理員可以檢閱並重新處理失敗的批次。
* **復原機制**:Data 360 會維護檢查指標,以確保失敗的批次不會損毀先前的摘要。您可以在修正來源問題 (例如格式錯誤的 CSV) 之後設定重試。
* **結構描述驗證**:schema_sample.csv 檔案會定義資料類型與結構。任何變更都會觸發驗證,以避免在執行之間漂移無訊息的結構描述。
###### 潛在設計考量事項
依設計而言,會無法移入;重新處理相同的檔案不會導致記錄重複。
重要策略包括:
* **檔案指紋:**Data 360 會計算核取總和,以識別並略過先前處理的檔案。
* **交易提取:**資料會暫存並僅在成功處理所有記錄時認可至 DLO。
* **附加與取代:**視業務邏輯而定,串流可附加至或完全取代目標 DLO;如此可確保決定性成果並避免部分資料重疊。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **驗證與授權:**連接器使用 Salesforce 的「安全整合架構」,利用已命名認證和外部認證進行驗證,而不公開密碼。
* **加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
* **網路控制:**來源儲存系統 (例如 S3 分類) 必須將 Data 360 IP 列入允許清單。
* **合規對齊方式:**與客戶管理金鑰 (CMK) 配對時,支援企業資料保護架構,例如 GDPR、HIPAA 和 FFIEC 指導方針。
* **稽核性:**系統會針對可追溯性與合規性報告,來記錄每個採取工作和認證存取權。
##### 側列
###### 及時性
時間取決於取用排程和資料量。
* 大型企業資料集 (超過 100 萬列) 可能需要分割以進行並列接收。
* 依檔案大小和轉換複雜度而定,通常會有從 **分鐘到數小時**的延遲。
* 針對近乎即時的採取,Data 360 串流或以 API 為基礎的連接器可以補充檔案型模型。
###### 資料量
* 最適合大量定期批次採取。
* 透過 S3 連接器處理的每個物件最多支援 1 千萬列或每個檔案 50 GB。
* 針對 petabyte 級系統,請使用資料分割和多串流協調流程。
###### 端點功能與標準支援
端點的功能與標準支援取決於您選擇的解決方案。
<table>
<thead>
<tr>
<th>連接器類型</th>
<th>端點需求</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Amazon S3 連接器</strong></td>
<td>具有適當 IAM 原則和結構描述\_sample.csv 檔案的 S3 分類。</td>
</tr>
<tr>
<td><strong>Google Cloud Storage 連接器</strong></td>
<td>具有統一命名慣例的服務帳戶認證和分類存取權。</td>
</tr>
<tr>
<td><strong>Azure Storage 連接器</strong></td>
<td>存取金鑰或 SAS 權杖驗證;Blob 或資料夾結構必須遵循 Data 360 慣例。</td>
</tr>
</tbody>
</table>

###### 州/省管理
系統會透過「資料串流」及其上次成功執行時間戳記來追蹤狀態。
* Data 360 會自動維護同步化狀態和偏移,以確保僅在後續執行時處理新的或修改的檔案。
* 與外部 ETL 工具整合時,建議使用唯一的檔案識別碼 (例如 UUID 或時間戳記),以避免重複。
###### 複雜整合案例
在進階企業結構中,此模式可以與:
* **中介 ETL 銷售管道 (例如 Informatica、MuleSoft):**以協調預先處理、驗證和檔案分割,然後再轉移至 Data 360。
* **AI/ML 工作流程:**處理的 DLO 資料可透過 DMO 發佈至模型化訓練環境,或透過 Data 360 啟用目標發佈 RAG 索引。
* **交易系統:**協調的 DMO 可以透過「資料動作」或「平台事件」在 Salesforce CRM 或外部系統中觸發下游更新。
##### 範例
全球金融機構將客戶和交易資料儲存在 AWS S3 資料湖中,其中會依區域 (例如美國、歐盟和亞太地區) 每晚產生分割的 Parquet 檔案。資料結構小組會在 Data 360 中設定多個「資料串流」,每個都連線至區域資料夾,並使用共用的 schema_sample.csv,以確保所有分割的標題和資料類型一致。每晚的採取排程會自動將資料載入至 DLO,之後「批次資料轉換」會將所有區域分割附加至統一的 Customer_Transactions_DLO。此協調資料集接著會對應至 Customer 360 資料模型,以啟用後續分析和 AI 啟用。此方法可從現有資料湖中提供自動且可靠的採取、強制執行與企業 IT 原則一致的強式驗證和加密,並提供可調整的模組式基礎,以支援未來擴展和結構描述演進。
#### 從 Salesforce Cloud 大量資料取用
##### Context
Data 360 的主要且重要使用個案是整合 Salesforce 生態系統中的客戶資料。此模式涵蓋從核心 Salesforce 平台 (Sales Cloud 和 Service Cloud (統一稱為 Salesforce CRM) 和 Marketing Cloud Engagement) 原生收集資料。來源包含標準和自訂 CRM 物件 (例如帳戶、連絡人、個案、機會) 和 Marketing Cloud Engagement 資料延伸模組,這些擴充模組會保留參與事件、電子郵件傳送和追蹤資料。
##### 問題
組織如何有效且可靠地將標準和自訂 CRM 物件和 Marketing Cloud Engagement 資料延伸模組提取至 Data 360,以便將資料用於建立統一的客戶設定檔 (身分解析、Customer 360),同時維持效能、管治和最少的來源系統中斷?
##### 力量
原生連接器可簡化工作,但必須管理數個作業和結構力:
* **全方位來源權限:**專屬連線使用者 (整合帳戶) 必須擁有適當的物件和欄位級讀取權限。無法指派必要權限集 (例如,預先建置的 Data 360 連接器權限集) 是一個常見的原因。
* **資料重新整理模式與成本:**連接器支援完整和 delta/增量重新整理模式。完整重新整理對效能和點數而言較為重要;delta 解壓縮會減少負載,但取決於來源系統中可靠的變更追蹤。
* **自訂結構描述與欄位對應:**CRM 例項通常包含自訂物件/欄位。需要精確的結構描述對應和自訂欄位 (名稱、類型) 處理,以避免對應錯誤或語意漂移。
* **入門資料搭售方案與自訂對應:**「入門資料搭售方案」可透過預先選取一般物件/欄位來加速上線,但大量自訂的組織需要自訂串流定義。
* **輸出與 API 限制:**來源組織 API 限制和 Marketing Cloud 解壓縮率會限制您可排程重新整理的積極性。
* **資料衛生與命名慣例:**來源欄位名稱、空值行為和資料類型必須先正規化,才能避免發生下游對應問題。
* **安全性和最低權限:**連接器依賴安全驗證,且必須遵循最低權限的 IAM 模式、稽核性與網路控制。
##### 解決方案
此表格包含此整合問題的解決方案。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td>解決方案適合</td>
<td>最佳</td>
<td>在 Data 360\ 中使用原生 Salesforce CRM 連接器和 Marketing Cloud 參與連接器。從標準使用個案的「入門資料搭售方案」開始,並加速上線。針對自訂或網域特定的資料模型,使用手動串流自訂。</td>
</tr>
<tr>
<td>處理高度自訂的 CRM 例項</td>
<td>最佳使用對應工作坊</td>
<td>將「入門搭售方案」視為基準,並執行對應工作坊以識別:自訂物件與關係。公式或計算欄位。受管理封裝擴充。針對重型公式欄位,請在階段前 ETL 或 Data 360 轉換內計算值,以將來源組織的 API 負載降到最低。</td>
</tr>
<tr>
<td>不使用時機</td>
<td>子最佳情況</td>
<td>在下列情況中請避免使用此模式:您需要高頻頻率或即時事件 (請改用串流連接器、平台事件或零複製聯合)。來源組織的 API 容量有限,且無法在沒有節流或排程延遲的情況下維持已排程取用。</td>
</tr>
<tr>
<td>安全性與管治</td>
<td>必要控制</td>
<td><strong>最低權限原則</strong> - 使用具有最低讀取存取權的專屬整合使用者。請勿使用組織範圍管理員。<br> <strong>驗證</strong>—使用 OAuth 2.0 和連線的應用程式;定期輪替用戶端密碼並監視重新整理權杖的使用狀況。<br> <strong>稽核與可追蹤性</strong> — 記錄所有採取執行、結構描述變更和連接器事件。將記錄轉送至 SIEM 或合規性系統以取得稽核整備。<br><strong>資料分類</strong> — 使用 CEDAR 原則,在取用後立即套用 PII/PHI 標記和以屬性為基礎的存取控制 (ABAC),以強制執行遮蔽、同意和下游合規。</td>
</tr>
</tbody>
</table>

##### 草稿
此圖表說明將資料從雲端儲存空間匯入至 Data 360 的步驟順序
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/batch_crm_connector.png" alt="顯示實作 CRM 連接器之流程的 UML 圖表" />

在此情況下:
* **管理員會佈建整合使用者**,並在來源組織中指派連接器權限集。
* **管理員會在 Data 360 設定中設定連接器** (透過 OAuth/連線應用程式連線至 Salesforce CRM 和 Marketing Cloud)。
* **管理員建立「資料串流」,**選取物件和「資料延伸模組」,選擇完整或差異重新整理,並設定排程。
* **排程執行時**,Data 360 會向來源要求結構描述和差異權杖。
* **來源系統會傳回記錄** (delta 或完整裝載)。Marketing Cloud 可能會傳送提取;CRM 可能會傳回 JSON/Query 結果。
* **Data 360 會在其內部安全暫存區域中暫存檔案**,並根據對應的結構描述進行驗證。
* **若驗證失敗**,會記錄錯誤、警示管理員,並停止認可。如果驗證成功,Data 360 會以原子方式將記錄認可至目標 DLO。
* **監視與稽核記錄**會以歷程、執行持續時間、列數和認證用量更新。若觸發的值或錯誤,則發出給管理員的警示。
##### 結果
核心客戶關係與行銷參與資料會作為「資料湖物件」(DLO) 來加以輸入至 Data 360。這會產生:
* 包含設定檔、個案、機會和電子郵件/參與度量的 **統一資料集**。
* **身分解析與建立「統一個人設定檔」的基礎** 。
* 下游調和、增強、AI 建模和啟用,同時保留管治與稽核能力的**營運整備**。
###### 吸收機制
取用機制取決於在 Data 360 中定義的連接器和排程策略。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td>Salesforce CRM 連接器 (原生)</td>
<td>最適用於標準/自訂 CRM 物件;支援完整和差異重新整理。</td>
</tr>
<tr>
<td>Marketing Cloud 參與連接器 (原生)</td>
<td>最適用於「資料延伸模組」、「傳送」與「追蹤」、提取;支援 full/delta 模式。</td>
</tr>
<tr>
<td>入門資料搭售方案</td>
<td>加速常見「銷售/服務/行銷」物件的上線。</td>
</tr>
<tr>
<td>自訂串流 + 預先處理</td>
<td>當需要複雜轉換或嚴重的結構描述正規化時使用。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
錯誤處理和復原對於確保高流量摘要作業的可靠性而言至關重要。
* **每次執行記錄:**每個「資料串流」執行都會提供成功/失敗詳細資料與列層級錯誤。
* **重試與檢查:**修正來源或結構描述問題後,可以重試失敗的執行;Data 360 使用暫存和原子認可語意。
* **警示:**設定結構描述漂移、重複失敗或差異序列間隙的警示。
###### 潛在設計考量事項
依設計而言,會無法再多取所取—重新處理同一個項目不會導致記錄重複。
重要策略包括:
* **變更偵測:**差異解壓縮依賴來源系統變更指標 (LastModifiedDate / 系統變更資料擷取)。確認來源提供可靠的時間戳記/標記。
* **復原:**使用唯一的業務金鑰 (例如,Contact.ExternalId) 來復原或更新插入至 DLO。
* **交易認可:**記錄會暫存並僅在批次處理成功完成時認可。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **驗證與授權:**連接器使用 Salesforce 的「安全整合架構」,利用已命名認證和外部認證進行驗證,而不公開密碼。
* **加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
* **網路控制:**來源儲存系統 (例如 S3 分類) 必須將 Data 360 IP 列入允許清單。
* **合規對齊方式:**與客戶管理金鑰 (CMK) 配對時,支援企業資料保護架構,例如 GDPR、HIPAA 和 FFIEC 指導方針。
* **稽核性:**系統會針對可追溯性與合規性報告,記錄每個採取工作和認證存取權
##### 側列
###### 及時性
時間取決於取用排程和資料量。
* **理想步調**取決於業務需求—每小時為近乎即時的行銷觸發,每晚為大型協調。
* **Delta 模式**會降低負載和成本;完整重新整理較為繁重,並用於初始載入或主要結構描述變更。
###### 資料量
* CRM 連接器針對交易和中量資料集 (數百萬筆記錄) 進行最佳化。
* 針對極大的歷程記錄量,請考慮階段式 ETL 以分割和載入階段。
###### 端點功能與標準支援
端點的功能與標準支援取決於您選擇的解決方案。
<table>
<thead>
<tr>
<th>連接器</th>
<th>端點需求</th>
</tr>
</thead>
<tbody>
<tr>
<td>Salesforce CRM 連接器</td>
<td>來源組織必須允許連線的應用程式、OAuth 權杖,以及具有讀取權限的專用整合使用者。</td>
</tr>
<tr>
<td>Marketing Cloud 連接器</td>
<td>Marketing Cloud API 認證或已安裝的封裝;「資料延伸模組」必須透過 Extracts/API 公開資料。</td>
</tr>
</tbody>
</table>

###### 州/省管理
* **連接器狀態:**「資料串流」會維護上次成功同步化的時間戳記和差異位移。
* **主要關鍵策略:**偏好一致的公司識別碼 (外部識別碼),以決定下游協調和更新插入。
###### 複雜整合案例
在進階企業結構中,此模式可以與:
* **混合式拓型:**使用串流 (平台事件) 結合 CRM 快取以取得近乎即時的更新。
* **中介協調流程:**當需要複雜協調流程、增強或轉換預先取用時,請使用 MuleSoft 或 ETL 工具。
* **啟用回饋意見迴圈:**協調的 DMO 可以透過「資料動作」或平台 API 觸發來源系統的下游更新 (請謹慎使用 SoD 控制項)。
##### 範例
多國零售商將「帳戶」、「連絡人」、「個案」、「機會」和 Marketing Cloud 參與度量合併至 Data 360,以建立統一的客戶檢視。「入門資料搭售方案」會初始化核心「銷售」與「服務」物件,而小組會使用自訂欄位 (例如 Loyalty_Membership__c 和 Customer_Tier__c) 來擴充模型,以獲取忠誠度內容。「CRM 資料串流」會在 delta 模式下每小時執行一次,而 Marketing Cloud Engagement 會使用參與事件的 delta 解壓每天同步化。這些資料集透過 DLO 和身分解析進行處理,進而產生統一的客戶設定檔,該設定檔結合了 CRM 和參與訊號,以強化個人化和下游 AI 模型。
#### 串流和即時取用模式
這些模式是針對毫秒十分重要的情況所建立—當客戶互動、交易或訊號必須觸發立即洞察或動作時。其可超越傳統排程的批次取用,以啟用以事件為導向的資料流程,其中會在產生資訊時處理資訊。
在 Salesforce Data 360 生態系統中,「即時」不是單一模式,而是延遲模型的連續。一端是近乎即時的同步化,其中記錄系統 (例如 CRM 或 ERP) 的更新會在秒或分鐘內反映在 Data 360 中。另一端是即時事件捕捉,其中用戶端行為訊號 (例如點擊、購買或行動互動) 會以毫秒為單位,以取用和啟用。
對於結構設計師,區別不僅僅是語意。其定義銷售管道的設計方式、API 的叫用方式,以及下游決策的方式。選取正確的模式,無論是近乎即時的同步化或事件串流取用,都可確保系統符合業務的營運延遲目標,同時維持資料完整性、可擴充性和管治。
#### 以事件為導向的使用者,可透過採取 API--串流
##### Context
此模式可讓任何外部系統 (例如自訂應用程式、物聯網 (IoT) 平台、銷售點 (POS) 系統或第三方服務) 以程式設計的方式,在離散事件發生時,近乎即時地將事件資料推送至 Data 360。
##### 問題
開發人員如何以低延遲的方式,從外部應用程式將單筆記錄或非同步小批次的事件可靠地傳送至 Data 360,讓資料可供快速處理、區隔和啟用?
##### 力量
此模式提供較低的延遲和更好的開發人員控制,但導入了數個技術限制和作業相依性:
* **開發人員相依性:**需要開發人員努力來實作已驗證的 REST API 用戶端和錯誤/重試邏輯—這不是點選連結。
* **嚴格的撰寫結構描述:**「取用 API」會強制執行結構描述撰寫。必須定義精確的結構描述並上載至連接器組態;所有裝載都必須完全符合或遭到拒絕。
* **雙互動模式:**相同的連接器支援串流 (JSON),以進行低延遲、逐筆記錄更新,以及大量 (CSV),以進行較大的定期同步化—結構設計師必須為每個使用個案選擇。
* **驗證與安全性:**通話必須使用 OAuth 2.0 透過 Salesforce 連線的應用程式進行驗證 (例如,伺服器對伺服器的 JWT 承載者流程)。權杖管理、輪替和最低權限範圍是必要的。
* **營運可視性:**開發人員和平台小組必須實作回應代碼、重試、無效字母及結構描述漂移警示的監視。
* **即時圖表需求:**針對即時啟用 (即時區隔、即時 DMO 對應),目標「資料模型物件」(DMO) 必須是即時資料圖形的一部分;否則事件會周遊略低延遲的銷售管道。
##### 解決方案
此表格包含此整合問題的解決方案。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>解決方案適配</strong></td>
<td><strong>最適用於</strong>低延遲事件捕捉</td>
<td>針對推送單一事件或微批次,請使用 <strong>Data 360 Capture API</strong> (串流 JSON)。使用嚴格的 OAS 3.0 結構描述 (.yaml) 來設定接收 API 連接器。針對較大且較不頻繁的同步化使用大量 CSV。</td>
</tr>
<tr>
<td><strong>處理結構描述變更</strong></td>
<td><strong>嚴格 / 受管理</strong></td>
<td>結構描述變更中斷:更新 OAS .yaml、版本化連接器,並執行契約測試。如果產生者無法同時變更,請實作滾動結構描述移轉。</td>
</tr>
<tr>
<td><strong>不使用時機</strong></td>
<td><strong>子最佳</strong></td>
<td>如果需要預先處理 (例如:刪除重複、保證訂單等),或非常大的大量負載 (使用原生大量連接器或批次 ETL),則不理想。如果來源無法產生結構描述有效的裝載,或無法安全地驗證,請使用替代的方法。</td>
</tr>
<tr>
<td><strong>安全與管治</strong></td>
<td><strong>必要</strong></td>
<td>將 <strong>OAuth 2.0</strong> 與最低權限範圍、輪替金鑰、記錄權杖用量搭配使用。強制執行 TLS 1.2+,視需要驗證用戶端 IP,並確保裝載 PII 標記。所有事件都必須包含來源中繼資料 (來源、時間戳記、結構描述版本、無效金鑰)。</td>
</tr>
</tbody>
</table>

##### 草稿
此圖說明如何將資料從「取用 API」匯入至 Data 360 的步驟順序
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/ingestion_api_push_event_flow_to_data360.png" alt="顯示「流程」的 UML 圖表,可實作「取用 API」" />

**在此情況下:**
* 外部系統從「驗證伺服器」要求透過 OAuth/JWT 進行驗證。
* Auth Server 會將存取權杖傳回至外部系統。
* 外部系統會透過授權與 JSON 裝載,將資料取用 POST 要求傳送至 Data 360 取用 API。
* 透過「暫存驗證」模組驗證要求結構描述和驗證。
* 結構描述/驗證失敗時:
* 傳回至外部系統的錯誤。
* 針對監視與警示記錄的拒絕。
* 成功驗證時:
* 暫存並認可至資料湖物件 (DLO) 的記錄。
* 已成功記錄進行監視。
* 若已啟用,則會將資料移入至觸發下游工作流程的即時資料圖表 (DMO)。
* 否則,會透過標準批次或較高延遲管道處理資料。
* 通訊 API 確認外部系統的成功。
* 監視元件會警示管理員無效字母、拒絕率或延遲問題。
##### 結果
外部事件資料會以較低的延遲將其採取至 Data 360 DLO。當目標 DMO 是即時圖表的一部分時,資料可用於立即區隔、工作人員工作流程、AI 模型和作業啟用。這可讓業務快速回應來自任何已連線系統的事件。
###### 吸收機制
取用機制取決於在 Data 360 中定義的連接器和排程策略。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>串流 JSON (吸收 API)</strong></td>
<td>單一事件、微批次、行為事件、點擊串流、IoT 遙測—需要低延遲時。</td>
</tr>
<tr>
<td><strong>大量 CSV (吸收 API 大量模式)</strong></td>
<td>縮短延遲需求的大型定期上載。</td>
</tr>
<tr>
<td><strong>邊緣/中介</strong></td>
<td>當您需要驗證、轉換、增強或比率限制時,請先使用,再推送至「採取 API」。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **立即 (同步) 錯誤:**結構描述/驗證錯誤的 4xx 回應 — 用戶端必須修正裝載或權杖並重試。
* **暫存 (非同步) 失敗:**5xx 回應 — 具有指數反轉與動靜的用戶端重試。
* **無效信函 (DLQ):**持續失敗會進入 DLQ 以手動檢查和重新執行。
* **監視:**追蹤結構描述拒絕率、驗證失敗、延遲百分位數和 DLQ 待處理。通話的警示。
###### 潛在設計考量事項
* **Idempotency 索引鍵:**每個事件應包含唯一的識別碼金鑰/訊息識別碼。
* **更新插入策略:**使用業務金鑰 (ExternalId) 可避免重複回覆。
* **停用視窗:**結構設計師應定義用於識別效能追蹤的取消重複視窗和保留。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **驗證:**建議用於伺服器對伺服器的 OAuth 2.0 (JWT 承載者)。將範圍限制為僅取用。
* **加密:**TLS 1.2+ 用於傳輸;Data 360 會在靜態中強制執行加密。
* **最低權限:**連線的應用程式認證擁有最少權限;輪替機密和儀器存取記錄。
* **薪水管理:**在事件中繼資料中包含同意/耗用標記;在取用後立即套用 ABAC/CEDAR 原則。
* **IP 控制項 / 私人連線:**如有需要,請透過允許清單限制存取,或將「私人連線」用於私人網路。
##### 側列
###### 及時性
時間取決於取用排程和資料量。串流 JSON 會根據處理和圖形組態產生子秒到第二個延遲。大量 CSV 為分鐘到小時。根據業務 SLA 選擇。
###### 資料量
個別事件大小應小 (< 幾 KB)。針對高輸送量產生者,請考慮在呼叫 API 之前在產生者處批次或使用串流緩衝時間 (Kafka/Kinesis)。
###### 州/省管理
* **結構描述版本化:**在事件中繼資料中維護結構描述版本,並在更新 OAS 契約時使用連接器版本化。
* **連接器位移:**Data 360 會處理認可語意;產生者應追蹤識別碼鍵和最後一個成功的序列,以確保安全的重新執行。
###### 複雜整合案例
在進階企業結構中,此模式可以與:
* **邊緣驗證層:**使用中介軟體將異質的產生者格式翻譯為必要的 OAS 契約、執行比率限制和預先增強。
* **混合結構:**針對事件與「連接器」來進行大量協調,來結合取用 API。
* **工作人員啟用:**對應至即時 DMO 的事件可以觸發 Agentforce 工作流程和 Einstein 模型以進行自動化決策。
##### 範例
零售鏈將銷售點 (POS) 購買事件串流至 Data 360 inReal-Time,以促進立即的客戶參與。每個商店都會執行輕量型伺服器元件,該元件會收集交易、以位置和裝置中繼資料增強交易,並使用 JWT Bearer OAuth 與 IDempotency 金鑰安全地張貼 JSON 事件,以避免重複。管理員透過上載適用於 **銷售點**的 OAS 結構描述,並設定「接收 API」連接器來定義事件結構。傳入的事件會在 **pos_sale DLO 中**採取、對應至 **銷售 DMO**,並新增至即時圖表。因此,系統會立即偵測高價值的購買,在 Agentforce 中觸發 VIP 工作流程並更新客戶區段以驅動即時個人化。
#### 即時 Web 與行動裝置的行動行為
##### Context
此模式可讓您在 trueReal-Time 中從網站和行動應用程式,從大量細微的使用者互動資料 (例如頁面檢視、按鈕點擊次數、產品印象和影片播放) 來捕捉。這是提供即時個人化的基礎,其中每個數位互動都可以動態地影響使用者體驗並驅動參與。
##### 問題
企業如何從數位內容 (每分鐘可跨越數百萬個使用者互動) 捕捉和處理行為事件的連續串流,並使資料立即可在 Data 360 中使用,以強化即時區隔、個人化和啟用?
##### 力量
此使用個案會引入數個設計挑戰,這些挑戰需要針對目的所建置且低延遲的採取結構:
* **極端輸送量:**高流量網站或行動應用程式每分鐘會發出數百萬個事件。接收層必須水平調整,才能處理此量,而不會發生事件損失或反壓,以確保在高峰負載下保持一致的延遲。
* **用戶端儀器:**不同於伺服器驅動的整合,此模式取決於用戶端 SDK。必須在每個頁面中內嵌 JavaScript 指標 (Salesforce Interactions SDK),或整合至行動應用程式的原生 SDK。這需要強大的用戶端部署、版本化和事件結構描述管理。
* **低延遲事件處理:**使用者動作 (例如「加至手推車」或「影片播放」) 必須在秒內到達 Data 360,以啟用即時啟用和內容相關回應 (例如目標化優惠、個人化建議)。
* **資料調和與身分解析:**收到的事件通常包含匿名識別碼 (Cookie、裝置識別碼、工作階段權杖)。若要強化 Customer 360 使用個案,必須透過 Data 360 的身分解析將這些個案對應至已知設定檔,並與 Customer 360 資料模型協調。
##### 解決方案
建議的方法是使用 **Salesforce Marketing Cloud 個人化連接器**—專為高輸送量行為摘要而設計的**原生完整受管理串流管道**。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>以 SDK 為基礎的事件捕捉</strong></td>
<td><strong>最佳</strong></td>
<td>部署 Salesforce Interactions SDK (Web) 或原生 SDK (行動裝置)。這些輕量型文件庫會將使用者互動以即時式方式加成序列,並附加中繼資料 (工作階段識別碼、時間戳記、內容)。</td>
</tr>
<tr>
<td><strong>事件串流銷售管道</strong></td>
<td><strong>最佳</strong></td>
<td>事件會透過安全的 HTTPS 傳送至 Marketing Cloud Personalization 的事件串流服務。此層可水平調整,並針對低延遲傳動 (&lt;2s) 進行最佳化。</td>
</tr>
<tr>
<td><strong>Data 360 整合</strong></td>
<td><strong>最佳</strong></td>
<td>Data 360 的「個人化連接器」會訂閱串流摘要,以近乎即時的方式將每個事件提取至「資料湖物件」(DLO)。</td>
</tr>
<tr>
<td><strong>資料模型對應</strong></td>
<td><strong>最佳作法</strong></td>
<td>此將對應至 Customer 360 資料模型物件 (DMO)。這可讓您透過「身分解析」連結匿名與已知使用者。</td>
</tr>
<tr>
<td><strong>即時圖表啟用</strong></td>
<td><strong>選用 / 建議</strong></td>
<td>在即時圖表中包含對應的 DMO,以進行立即區隔,透過 Einstein 或 Agentforce 工作流程觸發個人化動作。</td>
</tr>
<tr>
<td><strong>不使用時機</strong></td>
<td><strong>子最佳</strong></td>
<td>以下情況下,此模式並不理想:來源資料為 Web 用戶端與事件 (請改用「取用 API」)。組織無法控制 Web/行動用戶端。不需要即時行為追蹤 (使用批次採取)。</td>
</tr>
<tr>
<td><strong>處理結構描述變更</strong></td>
<td><strong>受管理的進化</strong></td>
<td>事件結構描述會隨著新增互動而演進。SDK 應版本化事件定義。與舊版相容的變更 (新增選用欄位) 是安全的;中斷變更需要重新設定連接器和契約測試。</td>
</tr>
</tbody>
</table>

##### 草稿
此圖說明將資料從 Mobile 和 Web 管道的步驟順序至 Data 360
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/real_time_web_mobile.png" alt="UML 圖表顯示實作「即時接收」的流程" />

**在此情況下:**
* 在 Web 或行動管道中部署 SDK (使用者-互動捕捉)。
* 使用租戶識別碼、環境和同意控制來設定 SDK。
* 將捕取的 JSON 事件 (中繼資料 + 屬性) 串流至 Marketing Cloud 串流端點。
* 在「Data 360 設定」中,建立並設定租戶的「個人化連接器」。
* 在 Data 360 內將 DLO → DMO 對應至 DLO。
* 在即時圖表中啟用 DMO,以立即啟用。
* 監視延遲、結構描述合規性、同意標記、輸出、錯誤率。
* 部署至生產環境並持續監視。
##### 結果
從數位管道流動至 Data 360 的行為事件連續低延遲串流。在數秒內,每個使用者動作都可供即時區隔、預測建模或觸發個人化使用,以實現真正的自適應客戶體驗。
###### 吸收機制
取用機制取決於在 Data 360 中定義的連接器和排程策略。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Interactions SDK (Web)</strong></td>
<td>從網頁瀏覽器和 SPA 進行即時快照。</td>
</tr>
<tr>
<td><strong>Mobile SDK</strong></td>
<td>來自原生行動應用程式的即時快照。</td>
</tr>
<tr>
<td><strong>個人化連接器</strong></td>
<td>Marketing Cloud 與 Data 360\ 之間的受管理訂閱。</td>
</tr>
<tr>
<td><strong>即時圖表對應</strong></td>
<td>在「區隔」、「Einstein」和「旅程」中啟用立即啟用。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **分層錯誤容忍:**實作多階驗證和重試機制 — 用戶端 SDK 會處理暫時失敗,並以指數反向方式處理,當然,取用層級會使用可持久持續排列和可重新執行的管道來防止資料遺失。
* **結構描述與資料管理:**持續執行事件的版本與驗證結構描述;無效或進化事件會路由至「結構描述拒絕」或「無效信頭」以安全地分級與重新執行。
* **Idempotency 與 deduplication:**使用穩定事件識別碼和更新插入語意,以保證即使在重試或重試期間,仍能完全處理一次。
* **監視與復原自動化:**持續監視輸送量、延遲和錯誤率會觸發自動復原工作流程,以確保低延遲、可靠的傳送,以及一致的即時個人化結果。
###### 潛在設計考量事項
* 每個事件都必須帶有唯一的識別碼或訊息識別碼,以便在下游中刪除重複的提交。
* 在適當的情況下使用業務金鑰 (例如 sessionID + eventTimestamp + userID) 來識別重複項目。
* 定義忽略或篩選重複事件的復原期間 (例如 24 小時)。
* 在適當的情況下使用更新插入策略 (例如,更新計數器或標記,而非插入重複項目)。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **傳輸加密:**所有 SDK → 串流服務連線的 TLS 1.2+。
* Data 360 和行銷串流中的靜態資料加密。
* SDK 遵循 **使用者同意標記 (GDPR/CCPA)**,並在拒絕同意時抑制追蹤。
* **SDK 流量驗證:**確保只有已批准的租戶/用戶端可以串流事件。
* **中繼資料:**每個事件都必須包含來源識別碼、時間戳記、結構描述版本、工作階段識別碼、無效金鑰。
* **最低權限存取權:**SDK 端點與連接器僅限於事件取用範圍;定期輪替認證。
* **資料分類:**在事件裝載中註解 PII,並在取用後立即強制執行原則
##### 側列
###### 及時性
* 時間取決於一般使用者活動和事件串流組態。
* 經由 Salesforce Interactions SDK 收取並透過 Marketing Cloud 個人化串流傳送的事件通常達到子秒到 ~2 秒的延遲,然後才可在 Data 360 即時圖表中使用。
* 這可在啟用中的使用者工作階段內啟用近乎立即的區隔、個人化和啟用。
###### 資料量
個別行為事件 (例如按一下、檢視、新增至手推車) 為輕量型,通常為每個裝載 1–5 KB。
針對大規模數位內容,每分鐘預期會發生數千到數百萬個事件。
若要確保輸出量與彈性:
* 針對高流量頁面使用 SDK 的內建批次與重試機制。
* 將突發處理卸載至 Marketing Cloud 串流緩衝層。
* 使用連接器度量顯示面板監視採取輸出和錯誤比率。
###### 州/省管理
每個事件都包含狀態和版本控制的中繼資料:
* **結構描述版本化:**在每個事件中內嵌結構描述版本;更新結構描述時版本化個人化連接器。
* **重複執行處理:**由於暫時網路問題而失敗的事件會由 SDK 以指數反向的方式自動重試。
* **Idempotency 金鑰:**唯一識別碼 (sessionId + eventType + 時間戳記) 可確保重新執行的事件不會在 Data 360 中建立重複項目。
* **位移管理:**Data 360 會追蹤成功的認可,任何未處理的事件都會由連接器重新計算,直到成功取用為止。
###### 複雜整合案例
此模式可順暢整合至進階企業結構:
* **邊緣增強層:**在事件到達 Marketing Cloud 之前,新增中繼軟體 (例如反向 Proxy 或無伺服器函數) 以插入其他內容,例如地理位置、裝置類型或行銷活動中繼資料。
* **混合式 (串流 + 批次):**將 Marketing Cloud 連接器用於即時串流,並將其與批次 ETL 工作 (例如訂單資料) 結合,以進行下游協調。
* **工作人員啟用:**對應至即時 DMO 的事件可以觸發 Einstein 個人化、Agentforce 工作流程或 AI 驅動的決策,以適應目前的數位體驗。
* **多租戶管理:**使用同意標記和認知租戶的中繼資料,以在多品牌或多區域環境中強制執行隱私權與合規。
##### 範例
全球電子商務公司在購物者主動瀏覽 React 型單一頁面應用程式 [**www.retailx.com**](http://www.retailx.com) 時,向購物者提供個人化的產品建議和動態內容。使用用戶端的 Salesforce Interactions SDK,網站會即時捕捉頁面檢視、產品點擊、手推車動作和視訊互動。這些事件會透過「Marketing Cloud 個人化」事件串流和「個人化」連接器流入 Data 360 DLO,並在其中模型化為 DMO 並納入即時圖表。此結構可讓行為訊號立即用於區隔、Einstein 驅動的個人化和 Agentforce 啟用,以啟用回應式的工作階段客戶體驗
#### 透過串流近乎即時的 CRM 同步化
##### Context
針對許多業務關鍵流程,保持 Data 360 與核心 CRM 系統中最新更新的完全一致是必要的。客戶服務、銷售和行銷小組依賴最新的資訊來驅動決策、觸發旅程和啟用自動化。此模式提供一個機制,可將對關鍵 Salesforce CRM 物件 (例如連絡人、帳戶和個案) 的變更同步至 Data 360 的最短延遲,而不會造成頻繁批次輪詢的效率低下或延遲。
##### 問題
Data 360 如何與關鍵 Salesforce CRM 物件保持近乎完全同步的狀態,確保下游分析、區隔和 AI 驅動的啟用一律在最新的可用資料上作業?
##### 力量
此模式介紹了數個技術限制與結構考量事項:
* **事件驅動的結構:**同步必須為反應性,其由 CRM 來源組織中的變更事件所驅動,而非定期批次工作。
* **選擇性物件支援:**並非所有 Salesforce 標準與自訂物件皆支援即時串流。結構設計師在設計期間必須參照支援的物件清單,以避免發生間隙。
* **存取權與權限:**啟用串流需要將「啟用 CRM 串流的權限」系統權限指派給來源組織中的整合使用者。
* **資料更新與處理成本:**雖然近乎即時同步化可改善回應能力,但過多的事件輸送量可能需要水平調整規模和強大的錯誤復原機制。
* **安全性與 Trust 層整合:**所有事件資料都必須符合 Salesforce 的 Trust 和 Security 架構—傳輸中加密、針對結構描述合規性進行驗證,並在組織的 Trust 界限內處理。
##### 解決方案
建議方法是使用已啟用串流的 Salesforce CRM 連接器 (變更 資料擷取。為支援的 CRM 物件 (例如,連絡人) 建立資料串流時,管理員可以切換「啟用串流」選項。Salesforce 的 Change 資料擷取 (CDC) 平台會在每次在來源 CRM 組織中建立、更新、刪除或取消刪除記錄時,立即發佈 ChangeEvent 訊息。
Data 360 CRM 連接器會訂閱這些 CDC 事件,並將對應的變更近乎即時地套用至 Data 360 內的對應資料湖物件 (DLO)。這可確保 CRM 和 Data 360 之間的連續同步化,但需要最少的手動介入。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>CDC 式串流連接器</strong></td>
<td>最佳</td>
<td>本地 Salesforce 機制;完全受管理,並與平台事件基礎結構整合。</td>
</tr>
<tr>
<td><strong>事件訂閱與傳送</strong></td>
<td>最佳</td>
<td>Connector 會透過永久的重新執行識別碼訂閱 ChangeEvent 管道 (例如 /data/ContactChangeEvent)。</td>
</tr>
<tr>
<td><strong>資料對應與結構描述演進</strong></td>
<td>最佳作法</td>
<td>將串流裝載對應至對應的 DLO;在中繼資料中處理結構描述版本化,以避免發生中斷。</td>
</tr>
<tr>
<td><strong>重複執行與錯誤復原</strong></td>
<td>建議</td>
<td>使用重新執行識別碼和識別碼金鑰可避免重複並從暫時錯誤中復原。</td>
</tr>
<tr>
<td><strong>混合模式 (串流 + 批次)</strong></td>
<td>選擇性</td>
<td>針對不支援的物件或初始大量載入,請使用與 CDC 串流組合使用批次取用。</td>
</tr>
<tr>
<td><strong>不使用時機</strong></td>
<td>子最佳</td>
<td>以下情況下,此模式可能為「<strong>子最佳」</strong>:來源物件未啟用 CDC。使用個案不需要即時更新 (批次足夠)。來源組織中的網路輸出受到限制或事件限制超過。</td>
</tr>
</tbody>
</table>

##### 草稿
此圖說明在近乎即時的情況下,將 CRM 中的資料從 CRM 移至 Data 360 的步驟順序
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/near_realtime_sync_for_crm.png" alt="顯示流程的 UML 圖表,可實作近乎即時的 CRM Capture" />

**在此情況下:**
* 變更會在 Salesforce CRM 中發生 (建立/更新/刪除/取消刪除)。
* CDC 會將 ChangeEvent 發佈至內部 Salesforce Event Bus。
* Data 360 CRM 連接器會使用永久的重新執行游標來訂閱 Event Bus。
* 系統會針對結構描述、權限和資料完整性驗證事件裝載。
* Data 360 會將驗證的事件寫入對應的 **資料湖物件 (DLO)**。
* 若已啟用,則對應的「**資料模型物件」(DMO)** 會以近乎即時的方式更新,進而加強區隔和啟用。
##### 結果
Data 360 會維持關鍵 CRM 資料的連續同步化鏡像。
這可啟用:
* 即時觸發 (例如建立「個案」時啟動 Journey)。
* 最新的區段 (例如,在帳戶狀態變更時將客戶移至「金級」區段)。
* 根據即時 CRM 內容更精確的分析和個人化。
###### 吸收機制
系統會原生透過已啟用「變更資料擷取」(CDC) 的 Salesforce CRM 連接器來管理此模式的採取機制。Data 360 會作為 CDC 事件串流的訂閱者,確保來源 CRM 組織與 Data 360 之間的可靠低延遲同步化。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>透過 CDC 串流 (偏好)</strong></td>
<td>適用於需要近乎即時同步化的所有支援 Salesforce 標準和自訂物件。</td>
</tr>
<tr>
<td><strong>混合模式 (CDC + 批次)</strong></td>
<td>適用於尚未啟用 CDC 的物件,或需要初始歷程記錄載入的物件。</td>
</tr>
<tr>
<td><strong>重複執行訂閱模式</strong></td>
<td>用於停機或部署後重新同步化。</td>
</tr>
<tr>
<td><strong>錯誤隔離模式</strong></td>
<td>適用於測試和驗證環境。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **自動錯誤復原:**CRM 連接器會使用指數反向來自動重試暫時網路或平台錯誤,並將持續失敗路由至「無效字元排隊」(DLQ) 以供重新執行。
* **結構描述與驗證彈性:**結構描述不相符的項目會在「結構描述拒絕排隊」中進行隔離以供管理員檢閱,而驗證或權限錯誤會透過 Data 360 Monitoring 觸發受控制的重試和警示。
* **保證事件持續性:**持久的 ReplayID 可確保連接器停機期間不會遺失事件;錯過的事件會透過重新執行視窗或批次重新同步工作重新水化。
* **資料完整性和訂單:**內建的 idempotency (RecordID + SequenceNumber) 可防止重複,而 ChangeEventHeader.sequenceNumber 可保留每個 CRM 記錄的正確事件順序。
###### 潛在設計考量事項
* **事件唯一性:**每個 CDC 事件都帶有 ReplayID 和 ChangeEventHeader.entityName 以進行決定性重複。
* **更新插入策略:**根據記錄識別碼實作 UPSERT 邏輯,以確保重複的事件不會建立重複項目。
* **重複執行處理:**使用連接器的重新執行游標,以在暫時失敗時從上次認可的位移繼續。
* **結構描述演進:M 會在事件中繼資料中**維護結構描述版本,並在 CRM 結構描述變更時更新 DLO 對應。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **加密和 Trust :**所有事件都使用 **TLS 1.2+** 傳輸,並在 Data 360 中靜態加密儲存。
* **存取控制:**只有具備適當整合權限的已驗證連接器可以訂閱 CDC 管道。
* **結構描述驗證:**每個事件裝載都會根據 DLO 結構描述進行驗證,然後才會接收。
* **同意傳播:**同意與資料分類中繼資料會在每個事件後續流動,以保留隱私權與合規性 (GDPR、CCPA)。
* **作業管理:**系統會透過 Data 360 Trust 圖層記錄、稽核事件,並監視重新執行、結構描述拒絕和輸出異常。
##### 側列
###### 及時性
* CDC 事件會以近乎即時的方式處理,通常是在 CRM 中變更的秒內處理。
* 延遲會根據事件量和連接器輸送量而有所不同,但 Data 360 保證支援物件的子分鐘可用性。
###### 資料量
* 每個事件裝載均為輕量型 (~1–5 KB)。
* 針對如「個案」或「連絡人」等高變速物件,請確保輸出限制符合 Salesforce CDC 事件配置。
###### 州/省管理
每個事件都包含狀態和版本控制的中繼資料:
* **重複執行識別碼:**用於序列事件復原。
* **結構描述版本化:**維護版本中繼資料以管理契約變更。
* **Idempotency 金鑰:**在重試之間取消重複的回覆。
* **位移認可:**Data 360 會在每個成功的事件批次之後保留認可狀態。
###### 複雜整合案例
此模式可順暢整合至進階企業結構:
* **混合式 (串流 + 批次):**使用 CDC 進行 delta 更新,並大量工作進行完整重新整理。
* **跨組織串流:**多個來源組織可以透過 DMO 對應統一串流至相同的 Data 360 租戶。
* **工作人員啟用:**即時物件更新會觸發 Einstein 或 Agentforce 自動化。
* **事件路由:**中間軟體 (例如 MuleSoft 或事件轉送) 可以增強或路由 CDC 訊息,然後再進行取用。
##### 範例
全球銀行想要確保 Salesforce Sales Cloud 中的客戶資料變更會立即反映在 Data 360 中。當在 Sales Cloud 中更新連絡人的地址時,「變更 資料擷取」機制會發佈 ContactChangeEvent。Data 360 CRM 連接器會取用此事件、將更新套用至 Customer DLO,並自動更新所有相關聯的 Customer 360 設定檔。這會觸發 Einstein Next Best Action 驗證新地址—在原始 CRM 變更後的秒內完成回饋意見迴圈。
#### Cloud Messaging Platforms—Kinesis 和 MSK 中的事件串流。
##### Context
現代數位企業依賴如 Amazon Kinesis 資料串流和 Amazon MSK (適用於 Apache Kafka 的受管理串流) 等即時事件串流平台,以便從散佈式應用程式、IoT 裝置和交易系統中捕捉連續的資料流。Data 360 可透過原生第一方連接器從這些平台直接採取,因此不需要自訂 ETL 或以中介軟體為基礎的解決方案。此模式是針對高輸送量、低延遲資料取用、提供近乎即時洞察、個人化和 AI 驅動的啟用所設計。
##### 問題
企業如何安全且高效地將 Data 360 連線至 AWS Kinesis 或 AWS MSK Kafka 主題,以持續提取結構化事件和設定檔資料,確保結構描述合規性、可擴展性和管治?
##### 力量
此模式介紹多個結構與作業考量事項:
* **原生連接器可用性:**Salesforce 提供適用於 Amazon Kinesis 和 Amazon MSK 的廣泛可用原生連接器。這些連接器提供第一方支援,並消除自訂 API 型管道的需求。
* **驗證與安全性:**每個連接器都需要 **AWS 層級驗證**。
* 針對 Kinesis,這會使用 AWS 存取金鑰和密碼金鑰,由 IAM 原則管理。
* 針對 MSK,您可以透過存取金鑰/密碼或 OpenID Connect (OIDC) 來設定驗證。
* **結構描述定義:**Data 360 需要結構描述才能解譯串流裝載。
針對 Kinesis,會在連線設定期間上載結構描述檔案,以定義事件結構和欄位對應。
* **組態來源:**
* Kinesis 連接器訂閱特定的「Kinesis 串流」名稱。
* MSK 連接器訂閱 MSK 叢集內的「Kafka 主題」。
* **網路存取權:**針對安全的環境,可使用 PrivateLink 或 VPC 路由來設定連接器,以確保沒有任何資料周遊公用網際網路。
* **作業管理:**在 Data 360 Trust 層內監視串流輸送量、結構描述驗證和驗證事件,以確保合規性和可追蹤性。
##### 解決方案
解決方案利用 **Data 360** 內的 **原生 Amazon Kinesis** 或 **Amazon MSK** 連接器。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Kinesis 原生連接器</strong></td>
<td>最佳</td>
<td>第一方與 AWS Kinesis 的整合;支援連續高輸送量。</td>
</tr>
<tr>
<td><strong>MSK 原生連接器</strong></td>
<td>最佳</td>
<td>使用 OIDC 和金鑰型驗證支援的受管理 Kafka 採取。</td>
</tr>
<tr>
<td><strong>結構描述對應與驗證</strong></td>
<td>最佳作法</td>
<td>上載結構描述 (.json/.avro),定義事件結構;強制執行合併期間。</td>
</tr>
<tr>
<td><strong>IAM 組態</strong></td>
<td>建議</td>
<td>將具有唯讀存取權的最低權限 IAM 角色指派給目標 Kinesis 串流或 MSK 主題。</td>
</tr>
<tr>
<td><strong>私人網路路由</strong></td>
<td>選擇性</td>
<td>設定 PrivateLink/VPC 端點以進行安全內部路由。</td>
</tr>
<tr>
<td><strong>混合模式 (串流 + 批次)</strong></td>
<td>選擇性</td>
<td>使用串流進行差異處理,並針對回填或歷程記錄載入使用批次處理。</td>
</tr>
<tr>
<td><strong>錯誤隔離模式</strong></td>
<td>建議</td>
<td>將結構描述拒絕並將暫時錯誤路由至 DLQ 以供重新執行</td>
</tr>
</tbody>
</table>

##### 草稿
此圖說明在近乎即時的情況下,將「事件」平台 (例如 Kafka 和 Kinesis) 的資料從「資料 360」納入「資料 360」的步驟順序
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/aws_msk_kafka_streaming.png" alt="顯示「實作 Event Platform」之流程的 UML 圖表" />

**在此情況下:**
* 應用程式或裝置會將事件發佈至 Kinesis 串流或 MSK 主題。
* Data 360 連接器會使用 AWS 認證或 OIDC 權杖進行驗證。
* 連接器會持續輪詢或訂閱串流。
* 事件會暫存、驗證結構描述與原則,然後認可至「資料湖物件」(DLO)。
* 若已對應,「資料模型物件」(DMO) 會近乎即時更新以供啟用。
* 「監視層」會追蹤度量、結構描述拒絕和延遲。
##### 結果
將結構化資料直接從 AWS Kinesis 或 MSK 連續延遲低,並移至 Data 360。資料可立即用於:
* 身分解析
* 即時區段
* Einstein AI 啟用
* Agentforce 驅動的觸發
去除批次 ETL 的相依性,啟用與企業事件驅動設計一致的串流型結構。
###### 吸收機制
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Kinesis 連接器 (偏好)</strong></td>
<td>適用於 AWS 原生串流來源,此串流來源需要持續提取大量結構化資料。</td>
</tr>
<tr>
<td><strong>MSK 連接器</strong></td>
<td>適用於在 Kafka 相容平台上執行事件銷售管道的組織。</td>
</tr>
<tr>
<td><strong>混合式 (串流 + 批次)</strong></td>
<td>適用於與定期大量負載結合的增量事件。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **自動重試:**連接器會以指數反向的方式重試暫時網路或平台錯誤。
* **結構描述拒絕:**無效的裝載會路由至結構描述拒絕排列,以供管理員檢閱。
* **DLQ 重新執行:**持續失敗會在無效文字信號中來進行重新處理。
* **Idempotency Control:**事件索引鍵或序號可確保還原重複項目並順序地取用。
* **監視整合:**所有失敗、重試和輸送量度量都會顯示在 Data 360 Monitoring 顯示面板中。
###### 潛在設計考量事項
* **事件唯一性和追蹤:**系統會將決定性唯一索引鍵指派給每個事件 (例如,PartitionKey + SequenceNumber for Kinesis,或 Topic + Partition + Offset for MSK),以確保精確取用一次性。
* **連接器檢查點數:**Data 360 連接器會保留最後處理的偏移或序號,以在失敗或重新啟動後安全恢復。
* **復原與 UPSERT 邏輯:**在 DLO 認可期間,系統會偵測及略過重複事件;有效記錄會使用唯一索引鍵來更新插入以維護一致性。
* **重複執行與復原控制:**失敗或延遲的事件會透過「無效字母」與「重新執行排列」從儲存的偏移重新執行,以確保可靠的復原而不會重複。
###### 安全性考量事項
從驗證到加密和存取控制,安全性在整個採取管道中是整體的。
* **驗證:**使用 AWS IAM 原則或 OIDC 保護認證交換。
* **加密:**Data 360 內**傳輸中 (TLS 1.2+)** 和 **靜態 (AES-256)** 加密的資料。
* **存取控制:**強制執行最低權限角色;範圍為特定串流/主題的連結。
* **管治:**套用至每個記錄的歷程和分類中繼資料,以確保完整的可追溯性。
* **網路安全性:**或者,使用 AWS PrivateLink 在 **私人子網路中**部署。
##### 側列
###### 及時性
* **近乎即時處理:**CDC 和串流連接器會在來源變更的秒內處理事件,通常可確保子分鐘資料是最新的。
* **決定性延遲:**端對端延遲取決於來源輸送量、事件批次和網路條件,但 Data 360 保證支援物件的可預測 SLA 驅動延遲。
* **彈性調整:**其會在高事件量下自動調整其規模,即使在資料高峰期間仍可保持準時性。
* **營運可視性:**監視顯示面板會顯示事件延遲、認可時間戳記和重新執行狀態,以確保延遲和疑難排解。
###### 資料量
* **輕量型裝載:**個別 CDC 或串流事件精簡 (1–5 KB 標準大小),針對高頻率更新最佳化。
* **高變化物件:**針對波動式實體 (例如「個案」、「連絡人」、「訂單」),結構設計師必須確保 CDC 配置和事件輸送量符合預期的更新率。
* **平行串流:**Data 360 支援跨大型物件量或跨多個來源組織的水平調整多串流。
* **反壓處理:**內建的節流機制可在負載下維持吸收穩定性,而不會捨棄事件。
###### 州/省管理
每個事件都包含狀態和版本控制的中繼資料:
* **重新執行與位移追蹤:**每個事件都帶有「重新執行識別碼」和序列中繼資料,可啟用排序遞送和檢查點式復原。
* **結構描述版本化:**事件標題內的版本標記可確保在來源結構描述演進時與舊版相容的處理。
* **Idempotency 金鑰:**每個事件都包含唯一的交易或認可金鑰,可讓 Data 360 安全地去除重複重複和重試。
* **Atomic Commit:**只有在下游認可 DLO 成功時,便會將偏移標記為完成,以確保一致性。
###### 複雜整合案例
此模式可順暢整合至進階企業結構:
* **混合吸收:**將增量差異的 CDC 與大量資料串流結合在一起,以進行完整的重新整理,同時維持新鮮性和完整性。
* **跨組織串流:**多個 CRM 或 ERP 組織可以發佈至相同的 Data 360 租戶,並透過 DMO 對應和本文對齊方式統一。
* **事件增強:**中間軟體 (例如 MuleSoft、Event Relay) 可以在串流資料到達 Data 360 之前增強、篩選或路由串流資料。
* **AI 與工作人員啟用:**即時更新會在發起事件的秒數內觸發下游自動化,例如 Einstein 預估或 Agentforce 回應。
##### 範例
一家全球零售企業使用 AWS Kinesis 來串流銷售點和 Web 互動資料。Data 360 的 Kinesis 連接器會透過 IAM 認證進行驗證,並持續將事件提取到「交易 DLO」中。每個記錄都會經過結構描述驗證、以中繼資料豐富,並立即傳播至「客戶 DMO」。在幾秒內,Einstein AI 模型會更新客戶區段,而 Agentforce 會觸發即時 Next-Best-Offers 建議,以達成完全以事件為導向的個人化迴圈。
## 零複製模式:輸入與輸出
「零複製」不只是整合方法,而是企業資料移動方式 (亦即不移動) 的基礎變更。傳統上,資料整合需要透過 ETL 管道複製大量記錄、建立冗餘的資料存放區、同步延遲和管治挑戰。零複製會消除所有項目。
在此模型中,Data 360 會直接連線至外部資料平台,例如 Snowflake 和 Databricks,安全地讀取並啟用資料,而無須移動或複製資料。結果是企業資料湖庫與 Salesforce 生態系統之間的流暢橋接,提供即時存取、降低營運負擔,並強化資料管理。
#### 輸入零複製 - 外部平台至 Data 360
輸入零複製功能可讓 Data 360 查詢和協調儲存在 Snowflake 或 Databricks 中的來源外部資料,例如客戶設定檔、交易或產品資料。Data 360 會建立安全且具有中繼資料認知的連線,以利用外部倉庫中現有的結構描述定義和安全性原則,而不必取用檔案。
* **直接聯邦:**Data 360 會透過安全且最佳化的查詢讀取資料,而無須複製。
* **統一管理:**資料會保留在來源系統的安全性、存取控制及合規性架構之下。
* **營運效率:**消除 ETL 額外負擔和儲存重複,減少成本和複雜性。
* **即時整備:**啟用隨選調和—當 Snowflake 中的資料更新時,即可立即在 Data 360 中啟用。
##### Context
現代資料驅動的企業在雲端規模資料湖目錄平台 (例如 Snowflake 和 Databricks) 內管理客戶、交易和遠端測試資料的 petabyte。這些環境可作為分析、AI 和合規性的單一事實來源。
Data 360 導入 Zero CopyData Federation,允許 Data 360 直接查詢和使用外部資料集,而無須複製、轉換或儲存冗餘資料。**
此模式可讓組織將 Customer 360 架構擴充至現有的資料倉庫或湖家基礎結構,以實現即時統一和啟用,並透過零重複、零延遲和零對管治進行妥協。
##### 問題
企業如何利用已在 Snowflake、Databricks 或如 Apache Iceberg 等開放湖格式中精密設計的豐富資料集,以進行區隔、身分解析和在 Data 360 中啟用,而不需要 ETL 銷售管道或實體資料移動的成本、延遲和管治負擔?
##### 力量
此模式導入多個結構、安全性和效能考量事項:

**網路與安全性**
* Data 360 必須建立與外部倉庫或湖舍的安全私人連線。
* 通常使用 Salesforce Private Connect 或 PrivateLink/VPC 對等設定,以確保流量永不離開客戶控制的網路。
* 外部系統必須將 Data 360 IP 列入允許清單,並強制執行 TLS 1.2+ 加密。
  
**驗證與存取控制**
* 支援金鑰組驗證、OAuth 2.0 或以身分提供者 (IdP) 為基礎的 Trust 委派 (Data 360 作為信任用戶端)
* 外部系統中以角色為基礎的存取控制 (RBAC) 會強制執行查詢的最低權限存取權。
  
**效能與計算相依性**
* 查詢聯合會將 SQL 執行推送至 Snowflake 或 Databricks,利用其運算叢集。
* 具有外部查詢負載的效能與成本級數—區隔延遲與成本與外部運算組態相關聯。
  
**不斷發展的標準:檔案聯合**
* 新一代模型檔案聯合利用如 Apache Iceberg 或 Delta Lake 等開放式表格格式,讓 Data 360 能夠直接從物件儲存空間 (例如 Amazon S3、Azure ADLS、Google Cloud Storage) 讀取資料。
* 透過略過來源計算層,檔案聯合可大幅減少易讀的分析工作負載延遲和成本,同時維持結構描述完整性。
  
**管治與合規**
* 資料永遠不會離開來源平台—規範、加密和保留原則仍會在原始位置強制執行。
* 所有中繼資料、歷程和同意屬性均會移入 Data 360 的 Trust 圖層,以確保端對端可追蹤性。
  
##### 解決方案
建議方法是在 Data 360 內針對 Snowflake、Databricks 或檔案聯合使用原生 Zero Copy 連接器。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Snowflake Zero Copy 連接器</strong></td>
<td><strong>最佳</strong></td>
<td>第一方原生整合;透過 Snowflake 的資料共用或外部表格 API 建立即時查詢聯合。</td>
</tr>
<tr>
<td><strong>Databricks Zero Copy 連接器</strong></td>
<td><strong>最佳</strong></td>
<td>支援在 Delta Lake 中直接即時存取表格/檢視;推送查詢會在 Databricks 執行階段中執行。</td>
</tr>
<tr>
<td><strong>檔案聯合 (Apache Iceberg / Delta / Parquet)</strong></td>
<td><strong>新增最佳作法</strong></td>
<td>Data 360 會直接從物件儲存空間讀取開啟的表格格式,而不需要外部運算相依性。大量資料集的理想選擇。</td>
</tr>
<tr>
<td><strong>私人網路組態</strong></td>
<td><strong>建議</strong></td>
<td>使用 Salesforce Private Connect 或 VPC 對等以取得安全的網路級聯合。</td>
</tr>
<tr>
<td><strong>驗證與金鑰管理</strong></td>
<td><strong>最佳作法</strong></td>
<td>透過定期輪替和儲存庫管理實作安全的金鑰型或 OAuth 型驗證。</td>
</tr>
<tr>
<td><strong>結構描述註冊</strong></td>
<td><strong>必要</strong></td>
<td>Data 360 會取用外部結構描述,並將其對應至「外部資料湖物件」(外部 DLO)。</td>
</tr>
<tr>
<td><strong>受管理中繼資料</strong></td>
<td><strong>建議</strong></td>
<td>所有外部 DLO 都會繼承分類、同意和歷程中繼資料,以瞭解合規性。</td>
</tr>
</tbody>
</table>

##### 草稿
下圖說明如何在 Data 360 中設定零複製連線並建立外部 DLO。
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/zero_copy_federation.png" alt="顯示實作 Zero Copy Federation 之流程的 UML 圖表" />

在此情況下:
* 管理員會在 Data 360 設定 (Snowflake、Databricks 或檔案聯合) 中設定「零複製」連線。
* 已建立安全驗證和網路路由 (私人連線/OAuth/金鑰配對)。
* 管理員建立「資料串流」,選取外部來源—瀏覽即時資料庫、結構描述和表格。
* Data 360 會建立外部 DLO (資料湖物件),即參照即時表或 Iceberg 檔案的中繼資料指標,而不是複製資料。
* 外部 DLO 會對應至 Customer 360 實體 (例如客戶、交易、產品)。
* Data 360 會在區隔、啟用或洞察計算期間查詢來源。
* 所有存取、查詢歷程和中繼資料都會在 Data 360 Trust 層內進行稽核。

##### 結果
* 外部資料會保留在 Snowflake、Databricks 或 S3 中—無 ETL、無重複,無額外儲存空間。
* Data 360 可取得企業規模資料的即時讀取存取權,以用於身分解析、已計算洞察和啟用。
* 組織可在其現有的管治、加密與合規架構下維持完整控制權。
* 此模式會啟用真正的「零複製」結構,結合本機存取的效能與聯合儲存空間的管理。

###### 通話機制
呼叫機制取決於用來實作此模式的解決方案。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td>Snowflake Federation (偏好)</td>
<td>適用於具有受管理企業資料倉庫的即時高效能查詢聯合。</td>
</tr>
<tr>
<td>Databricks 聯邦</td>
<td>適用於使用 Delta 或 Parquet 支援資料集的統一分析與湖家環境。</td>
</tr>
<tr>
<td>檔案聯合 (Apache Iceberg / Delta Lake)</td>
<td>適用於物件儲存空間中的大規模資料集,其中運算分離與成本最佳化十分重要。</td>
</tr>
<tr>
<td>混合模式 (零複製 + 接收)</td>
<td>當歷程記錄資料需要一次性取用,但透過「零複製」存取即時資料時。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **自動重試與查詢待處理項目:**暫時連線或查詢逾時會使用指數反斜方式自動重試。
* **結構描述不相符的隔離:**來源結構描述中的變更 (例如,新資料欄) 會記錄到「結構描述拒絕排隊」中;管理員可以重新對應或重新整理結構描述中繼資料。
* **驗證失敗:**如果認證到期,Data 360 會使用儲存的重新整理權杖或金鑰輪換原則重試連線。
* **計算可用性偵測:**如果 Snowflake 或 Databricks 叢集已暫停,則 Data 360 會在計算恢復時暫停聯合工作和重試。
* **監視整合:**Data 360 Monitoring 顯示面板中顯示的所有連線健康、查詢延遲和歷程中繼資料。
###### 潛在設計考量事項
* **查詢決定性:**聯合查詢會使用一致的快照語意,以確保區隔或啟用期間可穩定且可重複的讀數。
* **外部 DLO 版本化:**每個聯合查詢都包含用於歷程追蹤的結構描述和時間戳記中繼資料。
* **無位移存取權:**由於「零複本」為唯讀,因此不依賴事件位移—透過外部系統的 ACID 保固 (Snowflake/Delta Lake) 強制執行一致性。
* **結構描述漂移管理:**在 Data 360 中維護版本化結構描述對應;重新整理來源進化上的外部 DLO 中繼資料。
###### 安全性考量事項
安全性在整個聯合模型中是不可或缺的,因此可確保不會影響 Trust 或合規性。
* **加密:**所有資料交換都使用 TLS 1.2+;外部倉庫使用 AES-256 靜態加密。
* **存取控制:**透過具有唯讀權限的最低權限角色存取外部表格。
* **網路隔離:**私人 Connect 或 VPC 路線可防止任何公用端點的曝光。
* **受管理資料流程:**屬性、同意和分類中繼資料會流入 Data 360 Trust 圖層以強制執行原則。
* **稽核性:**系統會記錄每個聯合查詢和結構描述存取事件,以便追蹤合規性 (GDPR、CCPA、HIPAA)。
##### 側列
###### 及時性
* 查詢會針對外部倉庫或儲存空間即時執行,以確保即時可看見最新的資料狀態。
* 區隔或啟用執行會反映 Snowflake、Databricks 或 S3 支援的 Iceberg 表格中最新的變更。
* 查詢延遲取決於來源系統的效能層級,通常為每個查詢的秒數到秒數。
* 適用於需要「最新且未複製」資料存取權的分析和 AI 工作量。
###### 資料量
* 支援原生儲存在 Snowflake 或 Databricks 中的 petabyte 級資料集,而無須複製。
* Data 360 只會提取結果,而非原始資料集,以將網路和運算成本降到最低。
* 檔案聯合透過分割與資料欄推送功能表來最佳化大型分析掃描。
* 透過倉庫計算容量和 Data 360 的聯合查詢協調流程層,以線性方式調整規模。
###### 州/省管理
* 外部 DLO 會保留在 Data 360 中的連線、結構描述和版本中繼資料。
* 系統會透過中繼資料重新整理週期自動管理結構描述進化。
* 查詢歷程包含時間戳記、使用者身分和執行度量以確保可追溯性。
* 系統不會維護任何狀態取用或位移—一致性繼承自外部來源的 ACID 保固。
###### 複雜整合案例
* **混合模式:**將「零複製」(適用於即時聯邦) 與取用 (適用於歷程記錄資料集) 結合。
* **跨倉庫存取權:**Data 360 可從一個組織內的多個 Snowflake 或 Databricks 租戶聯合。
* **AI/BI 互通性:**外部系統 (例如 SageMaker、Tableau、Power BI) 可以透過反向零複製來查詢 Data 360 的增強型設定檔。
* **檔案聯合副檔名:**採用開放湖格式 (Iceberg/Delta) 的企業可以在一個聯合模型下統一結構化與非結構化資料。
##### 範例
全球金融企業會將所有交易和互動資料儲存在 Snowflake 中,同時在 Data 360 中維護客戶屬性和行銷事件。使用 Zero Copy Data Federation,Data 360 會透過私人連線安全地連線至 Snowflake。當區隔工作執行時,例如「過去 30 天內有 $10,000 美元的客戶花費,Data 360 會將查詢向下推送至 Snowflake 並在 Journey Builder 中立即啟用這些設定檔。不需要複製或 ETL。此範例使用整個企業資料生態系統統一的即時聯合情報。
#### 輸出零複製--Data 360 至外部平台
輸出零複本會反向地延伸相同的原則。如 Snowflake 等外部系統無法從 Data 360 匯出或複製資料集,而是可以直接查詢 Data 360,將其視為豐富客戶智慧的聯合來源。
* **反向聯邦:**外部分析或 AI 平台可以存取 Data 360 的統一設定檔資料,而無須將其解壓縮。
* **來源的資料啟用:**無論是 AI 建模、報告或客戶個人化,業務小組都可以利用已存在資料所在位置的洞察。
* **免延遲的互通性:**沒有批次匯出或同步化工作;洞察會在平台之間立即流動。
* **一致的語意:**由於兩個系統皆共用相同的本體與結構描述對應,因此會在整個生態系統中保留內容與意義。
Zero copy 會將 Data 360 的角色從 *資料存放庫*重新定義為*語意啟用層級*。它可讓組織在受管理且高效能的倉庫中確實保留資料,同時在 Salesforce Trust 界限內釋放其完整價值。
此模式符合現代資料網格與 AI 原生結構:資料會保持去中心化,但情報會變成統一。結構設計師現在可以建立更快速、更精簡且更符合的啟用管道,無須複製。
##### Context
現代企業日益在多平台資料生態系統中運作,其中 Salesforce Data 360 可支援統一的客戶設定檔和啟用,而如 Snowflake 或 Databricks 等企業資料倉庫可作為資料科學、機器學習和 BI 工作負載的分析支柱。
Salesforce Data 360 的「零複製輸出共用」功能可順暢地橋接這些環境,允許直接在 Snowflake 或 Databricks 中管理、安全且即時地存取協調的 Data 360 資料,無須複製或 ETL。
這可讓分析師和資料科學家在支援行銷、銷售和服務啟用的相同即時、信任資料上進行查詢、視覺化和建模。
##### 問題
企業如何安全且有效地將 Data 360 的統一客戶設定檔和計算度量 (例如「終身價值」、「流失風險」) 公開給外部分析系統,而無須複製資料、破壞管治或透過傳統反向 ETL 管道導入延遲?
##### 力量
此模式介紹多個結構、管治和營運考量事項:
* **管理安全性:**Data 360 資料的存取權必須受控制、精確且可稽核。「零複製」共用使用明確的物件級存取權,確保僅已批准的「資料模型物件」(DMO) 和「已計算洞察物件」(CIO) 可供指定消費者使用。
* **明確物件選取:**管理員透過「資料共用」精密設計可共用資料,明確選取要公開的物件。這可維持監管並將風險曝光降到最低。
* **雙邊組態:**Data 360 與外部倉庫都需要設定。Data 360 定義「資料共用目標」(Snowflake/Databricks),而接收系統必須接受並例項化共用。
* **查詢聯合模型:**一旦接受後,外部平台便會透過聯合檢視即時查詢、管理 Data 360 資料,進而去除解壓縮工作或手動重新整理週期。
* **開放標準演進:**如檔案聯合等新增方法利用開放式表格格式 (例如 Apache Iceberg) 來在儲存層啟用唯讀存取權,進而改善跨多雲端結構的擴充性、效能和互通性。
##### 解決方案
此解決方案利用 Salesforce Data 360 的原生「零複製共用」搭配如 Snowflake 或 Databricks 等資料平台。
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>資料共用建立</strong></td>
<td><strong>最佳</strong></td>
<td>管理員在 Data 360 內建立「資料共用」,新增選取的 DMO 和 CIO (例如,「統一個人」、「客戶健康分數」)。</td>
</tr>
<tr>
<td><strong>目標組態</strong></td>
<td><strong>最佳</strong></td>
<td>建立「資料共用目標」,指定 Snowflake 或 Databricks 帳戶識別碼和驗證參數。</td>
</tr>
<tr>
<td><strong>共用發佈</strong></td>
<td><strong>最佳作法</strong></td>
<td>將「資料共用」連結至「資料共用目標」以安全發佈。</td>
</tr>
<tr>
<td><strong>倉庫接受</strong></td>
<td><strong>必要</strong></td>
<td>外部管理員接受共用,將共用物件作為倉庫中的唯讀檢視/表格具體化。</td>
</tr>
<tr>
<td><strong>細微存取控制</strong></td>
<td><strong>建議</strong></td>
<td>在 Data 360 內套用物件和以角色為基礎的權限;與倉庫層級以角色為基礎的存取控制保持一致。</td>
</tr>
<tr>
<td><strong>聯合查詢存取權</strong></td>
<td><strong>最佳</strong></td>
<td>分析師透過標準 SQL 查詢即時共用資料;聯結原生倉庫資料以供下游分析和 ML。</td>
</tr>
<tr>
<td><strong>檔案聯合選項</strong></td>
<td><strong>選擇性</strong></td>
<td>針對大型資料集,請利用以 Apache Iceberg 為基礎的聯合,以直接取得 S3 或 Delta Lake 讀取,而不需要計算相依性。</td>
</tr>
</tbody>
</table>

##### 草稿
下圖說明從 Salesforce Data 360 至外部 Data Platform 的呼叫。
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/data_sharing.png" alt="顯示實作零複製資料共用之流程的 UML 圖表" />

**在此情況下:**
* Data 360 管理員定義「資料共用」,包括「統一客戶」和「已計算洞察」物件。
* 使用安全認證和管治原則註冊「資料共用目標」(Snowflake 或 Databricks 帳戶)。
* Data 360 會發佈共用;Snowflake/Databricks 管理員會接受該共用。
* 共用的資料會在倉庫內顯示為安全且唯讀的表格。
* 分析師、BI 工具或 ML 管道會查詢即時且統一的客戶資料,而無須複製或同步化。
* 所有存取權都會在 Data 360 Trust 層與倉庫管理記錄中進行稽核。
##### 結果
* 外部倉庫可取得已協調 Data 360 資料的即時可查詢存取權。
* 去除反向 ETL 銷售管道,減少營運負擔和延遲。
* 直接在統一資料上啟用 AI/ML 訓練、預測建模和進階 BI。
* 維持零重複、強大的管治,以及安全的依設計存取控制。
* 完成雙向「零複製」迴圈,其中輸入聯合與輸出共用在單一管治模式下同時存在。
###### 通話機制
呼叫機制取決於用來實作此模式的解決方案。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Snowflake 安全資料共用 (偏好)</strong></td>
<td>當您的企業倉庫是 Snowflake 且您需要對協調的 Data 360 資料集進行即時、受管理的存取,而不需要資料移動或重複時使用。適用於需要零延遲共用和原生歷程強制執行的分析、AI 和合規性導向工作量。</td>
</tr>
<tr>
<td><strong>Databricks Delta 共用</strong></td>
<td>當下游取用者在 Databricks 或 Delta Lake 環境中作業,且需要透過開放的 Delta 共用通訊協定對統一或已啟用資料集的即時唯讀存取權時使用。</td>
</tr>
<tr>
<td><strong>外部表格共用 (Apache Iceberg / Parquet)</strong></td>
<td>當維護物件儲存空間 (S3、ADLS 或 GCS) 中的開放格式結構,以及需要跨分析引擎 (例如 Athena、BigQuery 或 Snowflake-on-Iceberg) 進行互通、低成本共用時使用。</td>
</tr>
<tr>
<td><strong>資料共用 API (程式設計存取權)</strong></td>
<td>當自訂應用程式或中介軟體 (例如 MuleSoft) 必須透過 API 安全地探索、訂閱或取用共用資料集時,使用以事件為基礎的重新整理通知和細微的存取控制。</td>
</tr>
<tr>
<td><strong>混合共用 (零複製 + 輸出共用)</strong></td>
<td>實作雙向交換模式時使用—利用輸入資料的「零複製」和發佈洞察的「輸出資料共用」,確保跨企業資料層的語意與管治一致性。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **連線重試:**Data 360 與倉庫之間暫時連線或驗證失敗的自動重試。
* **共用驗證:**無效或未經授權的共用組態會在「**管理員檢閱排隊」中**進行隔離。
* **同步化健康狀態監視:**Data 360 會透過「監視」顯示面板呈現即時共用狀態、查詢延遲和存取記錄。
* **存取撤銷:**管理員可以立即撤銷共用,並停用兩端的存取權,而不需要殘差資料複本。
* **受管理稽核追蹤:**系統會記錄所有組態和存取權變更以進行合規性驗證。
###### 潛在設計考量事項
* **一致共用識別:**每個「資料共用」與「資料共用目標」配對都有唯一識別碼,可確保精確的監管與存取追溯性。
* **固定的檢視:**共用資料物件為唯讀;消費者無法變更狀態,以確保決定性結果與合規性。
* **原子共用生命週期:**共用發佈、撤銷和更新是原子作業,完全完成或回復。
* **重複執行一致性:**Data 360 資料重新整理時,倉庫端查詢一律傳回最新的一致快照,以免過時讀取。
###### 安全性考量事項
安全性可固定零複製共用的每個層面:
* **驗證**:使用 OAuth 2.0、私人金鑰交換或身分聯合 (OIDC) 建立的共同 Trust。
* **加密**:在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密的資料。
* **存取控制**:物件級權限會強制執行最低權限存取權;由 Data 360 Trust 層管理。
* **網路安全性**:資料交換會透過私人網路連結 (例如 Salesforce Private Connect 或 Secure Data Exchange API) 進行。
* **管治中繼資料**:每個共用的物件都帶有歷程、分類和同意屬性,以確保完整的可追溯性與法規合規性。
##### 側列
###### 及時性
* **即時可用性:**共用的資料會反映 Data 360 的最新狀態,而不會發生複製延遲。
* **查詢重新整理:**DMO 或 CIO 中的變更會立即移入共用的倉庫檢視。
* **效能彈性:**查詢推送功能表會動態調整至倉庫計算資源。
* **監視:**即時顯示面板會顯示共用延遲和查詢效能度量,以確保作業。
###### 資料量
* **可調整共用:**根據分析需求,支援細微物件層級或完整網域資料共用。
* **最佳化查詢效能:**Snowflake/Databricks 會智慧地快取共用資料,以將延遲降到最低。
* **儲存效率:**零重複會減少冗餘的儲存成本。
* **檔案聯合選項:**針對 petabyte 級資料集,直接 Iceberg 式共用會略過計算並加速存取。
###### 州/省管理
* **結構描述演進:**版本控制的結構描述會在 Data 360 模型演進時確保相容性。
* **存取狀態追蹤:**針對生命週期管理,在 Data 360 中維護的啟用/停用共用狀態。
* **中繼資料同步化:**共用物件定義的更新會自動反映在下游倉庫目錄中。
* **不變狀態保固:**倉庫檢視一律代表 Data 360 資料的一致時間點狀態。
###### 複雜整合案例
* **混合模式:**將「零複製」(適用於即時聯邦) 與取用 (適用於歷程記錄資料集) 結合。
* **跨倉庫存取權:**Data 360 可從一個組織內的多個 Snowflake 或 Databricks 租戶聯合。
* **AI/BI 互通性:**外部系統 (例如 SageMaker、Tableau、Power BI) 可以透過反向零複製來查詢 Data 360 的增強型設定檔。
* **檔案聯合副檔名:**採用開放湖格式 (Iceberg/Delta) 的企業可以在一個聯合模型下統一結構化與非結構化資料。
##### 範例
跨雲端分析可讓組織將受管理的 Salesforce Data 360 資料與如 Snowflake 和 Databricks 等平台中的原生資料集結合在一起,以提供完整的全方位分析檢視。透過多租戶存取權,不同的業務單位可以透過個別共用安全地取用精密設計和保單控制的資料配量,而無須重複資料。然後,資料科學家可以透過直接在 Snowflake ML 或 Databricks MLflow 環境中的統一客戶設定檔上訓練模型,來執行聯合 AI 和機器學習。在整個流程中,內建的歷程、管治和稽核功能可確保所有資料存取和使用都保持符合企業原則和法規需求,例如 GDPR 和 HIPAA。
## 使用 Data Cloud One 整合多組織資料平台
Data Cloud One 可讓具有多個 Salesforce 組織的組織 (例如因為業務單位、區域、產品線或收購) 共用單一的集中 Data 360 例項。此組織會作為「首頁組織」,而其他組織 (稱為「同伴組織」) 可以存取統一資料並對其採取行動,只需花費最少的精力、無須自訂程式碼及完整的管治控制。
##### Context
企業經常執行多個 Salesforce 組織 (例如,一個用於銷售、一個用於服務、一個用於行銷或不同的區域)。每個組織都可以擁有自己的資料、組態和流程。在 Data Cloud One 之前,每個組織都需要自己的 Data 360 設定或複雜的自訂程式碼,才能跨組織共用資料。Data Cloud One 允許使用 Data 360 和多個透過低程式碼組態和中繼資料共用連線的「同伴」組織來簡化此操作。
##### 問題
企業如何在所有 Salesforce 組織之間 (以便銷售、行銷、服務等皆使用相同的基本資料) 啟用一致使用統一 Customer 360 資料 (由主要組織的 Data 360 採取、協調和管理),同時避免工作重複、自訂編碼、每個組織的個別 Data 360 例項以及管治缺口?
##### 力量
此模式導入多個結構、安全性和效能考量事項:
* **多組織複雜性**:每個業務單位的組織可能有不同的資料、自訂物件、安全性與流程,因此不易維持一致的統一檢視。
* **重複與成本**:每個組織執行個別的 Data 360 例項表示額外的設定、額外的監管、額外的授權,以及資料孤立的風險。
* **管治與資料共用控制**:您需要決定每個伴隨組織可以看見並採取動作的*資料*—您無法簡單地共用「所有內容」,而不需要管理風險。
* **設定速度**:行銷、銷售或服務小組無法等待數週的自訂程式碼,讓跨組織資料可供使用—他們需要點按組態解決方案。
* **資料落地、區域考量事項**:如果首頁與伴隨組織位於不同的區域,則可能會有關資料儲存位置或資料共用方式的法律或法規限制。

##### 解決方案
下表包含此整合問題的各種解決方案。

<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>首頁組織佈建</strong></td>
<td><strong>最佳</strong></td>
<td>將一個 Salesforce 組織指定為佈建 Data 360 的主要組織,這會成為中央資料存放庫和管治中心。</td>
</tr>
<tr>
<td><strong>伴侶組織連線</strong></td>
<td><strong>最佳</strong></td>
<td>透過 Data Cloud One 應用程式,設定從「主要組織」到一或多個「伴侶組織」的「伴侶連線」,無須自訂程式碼。</td>
</tr>
<tr>
<td><strong>資料空間定義</strong></td>
<td><strong>最佳作法</strong></td>
<td>定義「首頁組織」內的「資料空間」,以邏輯方式將資料分段 (例如零售、服務、行銷),並隔離存取邊界。</td>
</tr>
<tr>
<td><strong>資料空間共用</strong></td>
<td><strong>最佳</strong></td>
<td>明確地將選取的「資料空間」從「主要組織」共用至「伴侶組織」,以確保統一資料的以角色為基礎的受管理可視性。</td>
</tr>
<tr>
<td><strong>存取組態</strong></td>
<td><strong>必要</strong></td>
<td>在「伴侶組織」中,啟用 Data Cloud One 應用程式,並指派設定檔、洞察和區段存取權的使用者權限。</td>
</tr>
<tr>
<td><strong>管治與保單控制</strong></td>
<td><strong>建議</strong></td>
<td>集中在「首頁組織」中執行所有採取、身分解析和 Trust 組態,並維持端對端管理。</td>
</tr>
<tr>
<td><strong>多組織同步化</strong></td>
<td><strong>最佳</strong></td>
<td>「首頁組織」中的資料變更和已計算洞察會透過受管理的同步化管道,在「伴隨組織」之間即時反映。</td>
</tr>
<tr>
<td><strong>混合式部署選項</strong></td>
<td><strong>選擇性</strong></td>
<td>針對大型企業,多個「伴侶組織」可以連線至單一「首頁組織」,同時維護本機內容與合規性邊界。</td>
</tr>
</tbody>
</table>

##### 草稿
下圖說明此模式中的事件順序,其中 Salesforce 是資料主要資料。
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/data_cloud_one.png" alt="顯示實作 Data Cloud One 之流程的 UML 圖表" />

**在此情況下:**
* **首頁管理員**:建立「資料空間」並定義「資料共用」(選取 DMO/CIO、區段)。
* **首頁管理員**:建立「伴隨組織的資料共用目標」,並設定 Trust (OAuth 用戶端、允許的組織識別碼)。
* **首頁管理員**:將「資料共用」發佈至目標;附加 ABAC 原則 (CEDAR) 和加密/金鑰控制項 (如有需要,CMK)。
* **伴侶組織管理員**:接收邀請、驗證身分對應,並接受共用。
* **伴侶組織**:Data Cloud One Bridge 會佈建 Data Cloud One 使用者,並套用「權限集與資料空間」可視性。
* **伴隨組織應用程式 (流程 / Einstein / Apex)**:查詢資料圖表或呼叫 Data Cloud One API 以讀取共用的 DMO 或區段。
* **啟用**:伴侶組織會觸發啟用,或透過資料動作寫回 (若允許)。
##### 結果
* 所有已連線組織中客戶資料 (Customer 360) 的 **單一事實來源**—沒有冗餘的 Data 360 例項。
* **更快的評估時間。**伴隨組織只需幾分鐘,就能存取統一資料和 Data 360 技術提供的功能,而不需要數週的自訂編碼。
* **受控制的資料共用。**只會共用授權的資料空間,以保留安全性和管治,同時啟用業務靈活性。
* 業務功能 (銷售、服務、行銷) 會在相同的統一資料基礎上運作,在整個企業中啟用一致的度量、啟用和洞察。
###### 通話機制
呼叫機制取決於用來實作此模式的解決方案。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Data Cloud One 原生共用 (偏好)</strong></td>
<td>當多個 Salesforce 組織 (銷售、服務或 Industry Cloud) 需要直接從 Data 360\ 存取統一客戶資料的即時存取權時使用。這可免除複製,並啟用對金級記錄、區段和已計算洞察的零延遲存取權。</td>
</tr>
<tr>
<td><strong>透過 Data Cloud One Bridge 進行組織對組織共用</strong></td>
<td>當多個業務單位或子公司在個別的 Salesforce 組織中營運,但需要從中央 Data 360 例項共用對常見客戶資料和區段的存取權時使用。適用於維護獨立作業系統的多組織企業。</td>
</tr>
<tr>
<td><strong>Einstein 1 平台查詢 API</strong></td>
<td>當 Salesforce 應用程式、流程或 Einstein Copilot 必須以程式設計的方式查詢或啟用 Data 360 資料時使用。啟用將統一設定檔、度量或啟用結果即時提取至其他 Salesforce 應用程式,而無須批次匯出。</td>
</tr>
<tr>
<td><strong>啟用至 Salesforce 管道</strong></td>
<td>當 Data 360 資料 (區段、洞察或屬性) 必須啟用至 Marketing Cloud、Service Cloud 或 Commerce Cloud 以進行個人化、行銷活動執行或工作人員協助體驗時使用。</td>
</tr>
<tr>
<td><strong>資料圖形存取權 (語意查詢層)</strong></td>
<td>當您需要透過 Salesforce 資料圖表對統一資料模型的語意層級存取權時使用—支援 Copilot、AI 工作流程和即時跨雲端分析,無須手動聯結或轉換。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **跨組織同步彈性:**Data Cloud One 會使用暫時網路或平台錯誤的指數反向回應,在「首頁」與「伴隨組織」之間自動重試失敗的同步化工作。
* **部分批次隔離:**失敗的記錄批次會在「首頁組織」內的「重試到來」中進行隔離,直到協調成功為止,以避免資料分歧。
* **結構描述拒絕管理:**結構描述或對應不相符的項目會路由至「結構描述拒絕排隊」以供管理員檢閱和更正。
* **重複執行與恢復持續性:**每個同步化工作都會維護偏移檢查點,因此複製可以從上次成功認可繼續,而不會重複。
* **整合監視:**所有失敗、重試和復原度量都會在 Trust 圖層監視顯示面板中進行儲存,以取得可視性和 SLA 保證。
###### 潛在設計考量事項
* **決定性識別碼能力索引鍵:**每個同步化事件都會帶有唯一的金鑰 (組織識別碼 + 記錄識別碼 + 版本號碼),以保證完全可處理一次。
* **重複執行安全性:**重複或重新執行的事件會在認可時間篩選,以確保一致的下游 DMO 和 CIO 更新。
* **原子認可語意:**「伴侶組織」只會在成功下游撰寫後將資料標記為已認可,以保留跨組織交易完整性。
* **衝突解決:**多來源更新會遵循上次寫成交或原則驅動的合併邏輯,維持歷程和一致性。
* **檢查點持續性:**同步化工作會保留在「Trust層」內的上次處理偏移和狀態,以安全地復原和重新執行。
###### 安全性考量事項
* **強式驗證:**「首頁」與「伴隨組織」之間的連線會使用共同 OAuth 2.0 與透過「連線的應用程式」管理的自動旋轉權杖。
* **細微授權:**「伴侶組織」只能存取透過受管理的「資料共用原則」明確共用的特定「資料空間」、「DMO」或 CIO。
* **隨處加密:**資料會在「首頁」與「伴侶組織」之間傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
* **最低權限原則:**整合使用者的範圍僅限於必要物件;不會移入管理或系統層級權限。
* **稽核與合規性可視性:**所有同步化事件、結構描述變更、認證更新和存取授與都會記錄在 Data 360 Trust 層中,以確保完整的可追蹤性。
* **私人網路隔離:**選擇性 Salesforce 私人連線或私人連結可確保資料複寫僅透過安全內部管道進行。
##### 側列
###### 及時性
* 「首頁」與「伴侶組織」之間的同步化會近乎即時進行,通常是在來源組織中資料變更的秒數內。
* 「零複製」結構可確保所有參與組織都能立即查詢共用資料,而不會發生複製或批次延遲。
* 啟用和區隔工作會自動反映來自任何已連線組織的最新更新,維持營運最新狀態。
* 端對端延遲是決定性的,並由 Data Cloud One 的協調流程管道管理,以確保即使在載入的情況下仍可保持一致的跨組織時間。
###### 資料量
* 針對跨區域和業務單位的多租戶超規模資料同步化所設計,可在每個組織中管理數十億筆記錄。
* 資料會參照,而非重複,進而減少儲存空間足跡,同時維持全域可查詢性。
* 串流差異與中繼資料壓縮可最佳化頻寬,並為高變速物件 (例如「連絡人」、「訂單」) 認可負擔。
* 透過透過 Trust 層級的自適應負載平衡和協調流程,水平調整多個「伴隨組織」。
###### 州/省管理
* 每個同步化的資料集都會維護中繼資料歷程、版本和組織擁有權內容,以確保端對端可追蹤性。
* 檢查點持續性會針對組織之間的上次同步偏移,允許復原而不會重複。
* 結構描述版本化和跨組織的語意對齊方式由 Trust 圖層自動管理。
* 不需要手動狀態重設,系統會透過 Data Cloud One 協調流程服務來維護同步化狀態。
###### 複雜整合案例
* **跨組織聯合:**在統一管理模型下,在多個 Data 360 租戶或區域之間啟用流暢的查詢和啟用。
* **混合同步化:**將近乎即時的交易更新複寫與大量或歸檔資料的已排程同步化結合。
* **多區域管理:**支援地理散佈的資料共用,同時遵守落地、同意和合規性邊界。
* **AI 與自動化啟用:**同步化資料可立即為組織之間的 Einstein AI、Agentforce 或自訂 ML 模型提供動力,以啟用即時的跨組織情報。
###### 範例
全球零售組織有三個 Salesforce 組織:一個用於消費者零售、一個用於高級品牌,另一個用於國際市場。他們在 Consumer Retail 組織中佈建 Data 360 (使其成為主要組織)。透過 Data Cloud One,他們可以設定與 Premium Brands 和 International Markets 組織的伴侶連線。他們只會與每個伴侶組織共用適當的資料空間 (例如「Customer 360 – Retail Profiles」和「Customer 360 – Premium Profiles」)。在 Premium Brands 組織中,行銷小組可以檢視統一的客戶設定檔、根據已計算的洞察 (例如,頂級客戶終身價值) 建立區段,並觸發行銷自動化—所有這些都由主組織的 Data 360 例項提供技術支援,無須自訂編碼或資料重複。
## 資料啟用模式--資料輸出
資料啟用是 Salesforce Data 360 的真正價值開始生效的地方。這是取得平台內統一、豐富和受管理資料的流程,並使其在整個業務中運作。在實際上,這意味著安全地將 Data 360 的精密設計區段、已計算洞察和內容屬性傳遞至與客戶互動的系統,無論是行銷自動化、服務主控台、銷售啟用、分析或 AI 模型。
從技術角度來看,啟用模式會定義此資料的移動方式:觸發哪些管道、發生哪些轉換或對應,以及如何在過程中強制執行原則。這些模式並非僅用於匯出資料,而是用於協調即時的原則認知資料流程,以推動可測量的業務成果。每個啟用路線都會將 Customer 360 轉為即時的作業資產,為每個接觸點提供個人化、預測決策和持續學習。
### 批次啟用模式
批次啟用仍是從 Data 360 匯出資料的最廣泛使用且經營證明方法。其會依照排程的步調運作—定期將預先定義的受眾區段或屬性集發佈至下游平台。此模式非常適用於依賴一致且大量受眾傳送而非立即更新的行銷和參與工作流程。
一般使用個案包括增強電子郵件旅程、直接郵件行銷活動,或受眾上載至數位廣告網路。每個啟用執行都會從 Data 360 的統一設定檔圖表中提取合格區段、套用監管與同意原則,並安全地將輸出傳輸至目標系統。
在結構上,批次啟用為資料散佈提供可預測、可稽核且具成本效益的方法,以平衡營運簡易度與企業級可靠性。這是大規模行銷活動執行的支柱,其中正確的資料會即時提供並控制,進而推動可測量的業務影響。
#### 將區段啟用至行銷和廣告平台
##### Context
現代行銷人員跨多個參與管道 (電子郵件、廣告、行動和 Web) 作業,每個管道都需要精確、及時且個人化的客戶受眾。Data 360 可作為這些受眾的統一基礎,將每個系統的客戶資料結合到豐富且可運作的區段中。
批次啟用是用來將這些區段從 Data 360 匯出至下游行銷或廣告平台的最常見啟用模式。一般目的地包括 Marketing Cloud Engagement、Google Ads、Meta 自訂受眾或 LinkedIn Ads,您可在其中直接針對這些精密設計的受眾執行行銷活動。
##### 問題
行銷小組如何取得使用 Data 360 中統一且豐富資料建立的精確定義受眾,並使其可在外部行銷或廣告系統中供啟用?
例如,請思考區段:「過去 90 天內未購買,但最近在網站上參與的高價值客戶。」
行銷人員需要確保此受眾正確轉移、使用相關屬性 (例如,忠誠度等級、區域或預測的 CLV) 增強,並定期重新整理,以維持行銷活動的相關性和成效。
##### 力量
多個技術與作業因素構成「批次啟用」模式:
* **身分對應:**精確的受眾傳送需要將 Data 360 的「統一個人識別碼」對應至目的地系統中的對應識別碼,例如 Marketing Cloud 中的「訂閱者金鑰」或數位廣告平台的雜湊電子郵件。這可確保精確比對並免除目標錯誤。
* **屬性選取與增強:**行銷人員必須超出識別碼,並包含其他設定檔資料 (例如名字、忠誠度狀態、CLV 或其他個人化屬性),才能啟用下游個人化和分析。
* **目標平台組態:**每個目的地必須在 Data 360 中註冊為「啟用目標」,包括連線詳細資料、驗證和資料欄位對應。此一次性設定會定義安全連線,並管理哪些系統可以接收已啟用的資料。
* **管治與合規:**資料啟用必須遵循同意中繼資料、隱私權原則 (例如 GDPR 或 CCPA),以及儲存在統一設定檔中的行銷權限。認可啟用可確保資料僅用於授權用途。
* **排程和效能:**啟用通常會每日或每小時排程,以讓下游受眾保持最新狀態。系統必須有效處理大量和增量重新整理,而不會重複或遺失資料。

##### 解決方案
Data 360 中的 **批次啟用**流程遵循引導式工作流程,可將行銷人員的技術摩擦降到最低,同時保留管治與延展性:
<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>區段建立</strong></td>
<td><strong>最佳</strong></td>
<td>行銷人員或分析師可透過套用任何資料模型物件 (DMO) 或已計算洞察物件 (CIO) 之間的篩選條件,在視覺區隔畫布中建立區段。這會定義啟用的目標受眾。</td>
</tr>
<tr>
<td><strong>啟用設定</strong></td>
<td><strong>最佳</strong></td>
<td>使用者建立啟用,並選取他們剛才建立的區段作為來源。這會定義 Data 360 要匯出至下游系統的受眾。</td>
</tr>
<tr>
<td><strong>啟用目標選取</strong></td>
<td><strong>最佳作法</strong></td>
<td>行銷人員會選取預先設定的啟用目標 (例如 Marketing Cloud、Google Ads、LinkedIn Ads)。每個目標都會使用驗證認證和欄位對應在 Data 360 中註冊。</td>
</tr>
<tr>
<td><strong>Payload 定義</strong></td>
<td><strong>必要</strong></td>
<td>行銷人員透過選擇連絡人識別碼 (例如電子郵件、行動裝置、雜湊識別碼),並選取其他設定檔屬性 (例如名字、忠誠度等級或 CLV) 來增強目的地系統,來定義裝載。</td>
</tr>
<tr>
<td><strong>排程和頻率</strong></td>
<td><strong>建議</strong></td>
<td>可將啟用排程為執行一次,或循環執行 (例如每日或每週)。排程可確保下游受眾保持同步且處於最新狀態。</td>
</tr>
<tr>
<td><strong>執行與匯出</strong></td>
<td><strong>最佳</strong></td>
<td>當啟用工作執行時,Data 360 會查詢區段、收集選取的屬性、套用同意篩選條件,並將資料匯出至目標平台。針對 Marketing Cloud,這通常會導致建立或更新「共用資料延伸模組」。</td>
</tr>
<tr>
<td><strong>管治與合規</strong></td>
<td><strong>必要</strong></td>
<td>Trust 層會強制執行結構描述驗證、同意中繼資料和原則控制,以確保符合資料保護與行銷法規 (例如 GDPR、CCPA)。</td>
</tr>
<tr>
<td><strong>監視與稽核性</strong></td>
<td><strong>最佳作法</strong></td>
<td>系統會在 Trust 層監視顯示面板中使用成功/失敗度量、執行記錄和歷程可視性來追蹤每個啟用執行,以啟用作業透明度和 SLA 保證。</td>
</tr>
</tbody>
</table>

##### 草稿
以下是步驟的摘要:
* **建立區段:**行銷人員或分析師使用視覺區隔工具建立區段,結合任何統一資料物件的篩選條件。
* **建立啟用:**他們選取區段作為來源,並選擇預先設定的目的地 (例如 Marketing Cloud 或 Google Ads)。
* **定義裝載:**連絡人識別碼和其他設定檔屬性會選擇用於受眾匯出與報告。
* **排程遞送:**啟用排程為執行一次或循環執行,讓受眾在目的地處於最新狀態。
* **執行:**在觸發時,Data 360 會查詢區段、建立裝載、套用篩選條件以取得同意,並將結果推送至目的地系統。

<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/batch_activation_new.png" alt="顯示實作區段啟用流程的 UML 圖表" />

##### 結果
* Data 360 的目標性、豐富的受眾區段可直接在下游行銷和廣告平台中使用。
* 受眾會自動重新整理並使用最新的統一客戶資料進行同步化,以維持即時行銷活動的相關性。
* 行銷人員可以使用這些已啟用的受眾作為 Marketing Cloud 旅程、電子郵件行銷活動或數位廣告平台 (例如 Google Ads、Meta 或 LinkedIn Ads) 中的自訂受眾的輸入來源。
* 每個啟用執行都會維持端對端歷程,確保 Data 360 與外部系統之間的合規性、可追蹤性和一致性。
* 業務使用者可以透過完整且信任的 Customer 360 檢視提供高度個人化的資料驅動體驗。
###### 通話機制
呼叫機制取決於目的地平台和啟用目標組態。

<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Marketing Cloud 參與啟用 (偏好)</strong></td>
<td>在 Marketing Cloud 中執行需要動態區段、個人化屬性和即時更新的電子郵件或跨管道旅程時使用。Data 360 會直接匯出至「共用資料延伸模組」以啟用行銷活動。</td>
</tr>
<tr>
<td><strong>廣告平台啟用 (Google Ads、LinkedIn Ads、Meta Ads)</strong></td>
<td>在廣告平台中啟用 Data 360 區段作為自訂受眾時,用於重新定位或類似建模。支援雜湊識別碼和認可傳送。</td>
</tr>
<tr>
<td><strong>CRM 啟用 (Sales 或 Service Cloud)</strong></td>
<td>將豐富的客戶資料、洞察或傾向分數分享給 CRM 使用者,以進行個人化的銷售參與或服務互動時使用。資料可透過「資料動作」或「統一設定檔元件」作為增強的記錄或洞察使用。</td>
</tr>
<tr>
<td><strong>透過 MuleSoft 或 API 的外部啟用</strong></td>
<td>當啟用需要到達非 Salesforce 系統 (例如忠誠度、電子商務或第三方資料倉庫) 時使用。MuleSoft 或 Data 360 啟用 API 可透過以事件為基礎的重新整理選項,確保安全且由原則管理的傳送。</td>
</tr>
<tr>
<td><strong>混合式啟用 (批次 + 事件觸發)</strong></td>
<td>將排程的批次啟用與以事件為基礎的觸發結合時使用—針對如捨棄手推車或流失風險警示等敏感時間行銷活動啟用「永遠開啟」個人化。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **工作層級錯誤隔離:**每個啟用執行都會在 Data 360 協調流程層中作為個別且可追蹤的工作執行。失敗的執行會自動隔離,而不會影響其他啟用或區段定義。
* **部分批次復原:**如果某些記錄無法匯出 (例如,由於識別碼不相符或 API 速率限制),則系統會使用增量差異排入和並行復原的差異排列來重試這些記錄。
* **結構描述驗證錯誤:**當輸出裝載屬性不再符合目標結構描述 (例如,已刪除的屬性或重新命名的欄位) 時,工作會將受影響的記錄路由至「結構描述拒絕排隊」以供管理員檢閱。
* **重新執行與恢復支援:**每個啟用工作都會維護檢查點權杖,以便捕捉最後一個成功批次。復原後,處理會從檢查點恢復,以確保不會重複或遺失資料。
* **全方位監視:**所有啟用事件、重試和傳送度量都會記錄在 Trust 層監視中,啟用 SLA 追蹤、根本原因分析,以及透過 Event Monitoring API 自動化警示。
###### 潛在設計考量事項
* **決定性啟用金鑰:**每個啟用執行都會使用複合使用者效能金鑰 (其結合「區段識別碼」、「啟用識別碼」和「目標系統識別碼」),以保證完成一次傳送。
* **重複執行偵測:**Data 360 啟用服務會根據先前的工作雜湊來檢查傳入的裝載,以偵測並抑制回覆。
* **原子匯出認可:**僅在成功寫入確認後,才會將裝載認可至目標系統,以防止部分更新或重複計數。
* **一致的身分解析:**由於啟用取決於統一識別碼 (例如「統一個人」),因此重試或重試一律會鎖定相同的金級記錄,以維持語意一致性。
* **啟用狀態持續性:**協調流程層會保留啟用狀態中繼資料 (時間戳記、狀態代碼和序列權杖),以便視需要進行決定性重新處理。
###### 安全性考量事項
* **強式驗證:**每個啟用目標 (例如 Marketing Cloud、廣告或 CRM) 都會使用 OAuth 2.0 搭配權杖輪換和租戶特定範圍,以防止未經授權的資料匯出。
* **屬性層級管理:**只有「統一設定檔」中的已批准屬性符合啟用資格,由「資料共用原則」與「啟用範本」強制執行。
* **傳輸和靜態加密:**所有裝載都會在傳輸期間使用 TLS 1.2+ 加密,而 AES-256 會在 Data 360 和目標平台中靜態加密。
* **同意與保單強制執行:**啟用工作會遵循儲存在 Data 360 的 Trust 圖層中的「同意物件」和「資料原則」。沒有有效同意中繼資料的記錄會自動從匯出中排除。
* **稽核與合規性記錄:**每個啟用執行都會捕捉起始者、傳送的資料以及目的地—在Trust層顯示面板內啟用完整的監管稽核追蹤 (GDPR、CCPA)。
* **最低權限存取權:**每個目標的整合使用者僅限於啟用特定範圍—沒有管理權限或不相關系統的寫入存取權。
##### 側列
###### 及時性
* 針對排程或近乎即時的批次匯出 (分鐘到小時延遲) 所設計。
* 支援與行銷活動行事曆一致的時間範圍重新整理。
* 可使用資料整備標記來排序啟用工作,以確保資料是最新的。
* 最適合非互動式啟用案例,其中資料準確性高於立即性。
###### 資料量
* 處理大規模資料集 (每次執行數百萬筆記錄)。
* 透過區段分割和並列匯出管道水平調整規模。
* 使用以區塊為基礎的批次來避免逾時並最佳化輸送量。
* 適用於資料完整性十分重要的企業級資料銷售管道。
###### 州/省管理
* 維護記錄工作識別碼、時間戳記和序列權杖的啟用狀態物件。
* 使用檢查指標進行重新啟動和錯誤復原。
* 版本化區段定義可確保啟用週期之間的可複製性。
* 啟用來源區段、DMO 屬性和目標裝載之間的歷程追蹤性。
###### 複雜整合案例
* 透過預先建置的連接器,與 Salesforce CRM、Marketing Cloud 和外部系統順暢整合。
* 支援多目標啟用,同時將資料散佈至不同的目的地 (例如 CRM + Ads)。
* 可以觸發複合工作流程,例如批次匯出,後面接著是下游 API 呼叫或 AI 評分。
* 透過「資料模型管理層」妥善處理結構描述進化。
##### 範例
一個全球零售品牌想要重新吸引過去 90 天內未啟用的客戶。資料結構設計師會使用 Data 360 定義「孤立購物者」區段,其中包含購買歷程記錄、忠誠度等級和同意中繼資料。「批次啟用工作」會每晚執行,將此區段推送至 Marketing Cloud Engagement 以觸發個人化「我們遺漏您」電子郵件行銷活動,並推送至 Ad Studio 以重新定位。此工作運用臨時傳送功能,確保不會重複重複重試,且所有事件都會記錄在 Trust 層中進行稽核合規性。
#### 資料匯出至雲端儲存空間
##### Context
企業通常需要受管理機制,才能將 Salesforce Data 360 的統一或區隔資料匯出至標準檔案格式 (例如 CSV 或 Parquet),以供歸檔、合規或後續整合。此模式可啟用 Data 360 至雲端儲存空間匯出—允許信任的客戶資料安全地流入 Amazon S3、Azure Blob 或 Google Cloud Storage (GCS) 上主控的企業資料湖或分析管道。
一般使用個案包括:
* 定期歸檔同意的客戶資料集以供監管保留。
* 匯出非 Salesforce 分析工作量 (例如 Tableau、Databricks 或 Power BI) 的精密設計區段。
* 啟用需要結構化 CSV 或 Parquet 檔案作為輸入的外部機器學習模型。
##### 問題
組織如何以受管理、安全和自動的方式,從 Data 360 將精密設計的區段或資料集匯出至雲端儲存分類 (例如 Amazon S3),同時維護結構描述完整性和合規性控制?例如,規範小組可能需要:「在取得有效同意的情況下,從歐盟地區的所有已啟用客戶中提取資料,並每週將資料匯出至 S3 位置以進行外部稽核和報告。」這需要可重複且注意原則的匯出管道,以確保正確的檔案格式、存取權限和傳送排程,而無須手動介入或未受管理的資料移動。
##### 力量
多個營運與結構因素管理此匯出模式:
* **驗證與授權**:匯出必須遵循雲端提供者的 IAM 模型 (例如,AWS IAM 角色或 Azure 服務主體),以確保只有授權的系統可以寫入至目標分類。
* **結構描述對齊**:輸出結構描述必須符合目標系統預期的結構與格式 (CSV、Parquet 或 JSON)。
* **資料隱私與同意**:匯出的資料集必須篩選出任何缺少有效同意中繼資料的記錄。
* **排程與新鮮度**:許多匯出都是定期 (每日、每週或每月) 且必須符合企業資料重新整理週期。
* **管治與監視**:每個匯出都必須可以完整的歷程可視性進行稽核,以確保符合資料保留和法規要求 (例如 GDPR、CCPA)。
##### 解決方案
「檔案匯出啟用」模式會重複使用與用於取用但針對資料匯出設定的相同安全雲端儲存連接器。管理員會先將雲端儲存平台 (例如 Amazon S3、Azure Blob Storage 或 GCS) 註冊為 Data 360 中的「啟用目標」。接著,使用者會設定並執行「啟用工作流程」以將所需區段匯出至指定的檔案儲存路徑。

<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>區段選取</strong></td>
<td><strong>最佳</strong></td>
<td>分析師會在 Data 360\ 內選取現有的「區段」或「查詢」定義。區段會決定要匯出的記錄和屬性。</td>
</tr>
<tr>
<td><strong>啟用設定</strong></td>
<td><strong>最佳</strong></td>
<td>使用者建立新的「啟用」,選擇「區段」作為來源,並選擇「雲端儲存空間目標」(例如 S3) 作為目的地。</td>
</tr>
<tr>
<td><strong>啟用目標組態</strong></td>
<td><strong>必要</strong></td>
<td>管理員會使用認證、IAM 角色和輸出路徑預先設定目標。支援的格式包括 CSV、Parquet 和 JSON。</td>
</tr>
<tr>
<td><strong>Payload 定義</strong></td>
<td><strong>最佳作法</strong></td>
<td>透過選取所需屬性 (例如識別碼、名稱、電子郵件、區域、同意標記) 來定義匯出結構描述。系統會強制執行屬性層級管理。</td>
</tr>
<tr>
<td><strong>排程與頻率</strong></td>
<td><strong>建議</strong></td>
<td>匯出可以排程在定義的步調 (每日、每週、每月) 上執行,也可以視需要手動觸發。</td>
</tr>
<tr>
<td><strong>執行與遞送</strong></td>
<td><strong>最佳</strong></td>
<td>在執行時,Data 360 會使用雲端提供者的 API 來查詢區段、編譯匯出檔案、加密檔案,並將其寫入設定的分類/資料夾。</td>
</tr>
<tr>
<td><strong>管治與合規</strong></td>
<td><strong>必要</strong></td>
<td>Data 360 的 Trust 圖層可確保所有匯出皆遵循同意原則、結構描述驗證和合規性篩選條件。</td>
</tr>
<tr>
<td><strong>監視與稽核性</strong></td>
<td><strong>最佳作法</strong></td>
<td>系統會在包含狀態、執行記錄和歷程中繼資料的 Trust 圖層監視顯示面板中追蹤每個匯出。</td>
</tr>
</tbody>
</table>

##### 草稿
以下是步驟的摘要。

* **選取「區段:**分析師或資料管理員選擇要匯出的統一區段。
* **建立啟用:**他們會建立新的「啟用」工作,並選取註冊的「Cloud Storage」目標。
* **定義裝載:**指定匯出結構描述、屬性清單和檔案格式 (例如 CSV)。
* **排程匯出:**選擇一次性或循環排程。
* **執行工作:**Data 360 會產生檔案並安全地將其傳送至指定的分類路徑。
* **監視與確認:**系統會在「Trust層」中檢閱結果和記錄以瞭解驗證與合規性。

<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/data_export_to_cloud_storage_new.png" alt="顯示「實作資料匯出至雲端的流程」的 UML 圖表" />

##### 結果
* Data 360 的目標性、豐富的受眾區段可直接在下游行銷和廣告平台中使用。
* 受眾會自動重新整理並使用最新的統一客戶資料進行同步化,以維持即時行銷活動的相關性。
* 行銷人員可以使用這些已啟用的受眾作為 Marketing Cloud 旅程、電子郵件行銷活動或數位廣告平台 (例如 Google Ads、Meta 或 LinkedIn Ads) 中的自訂受眾的輸入來源。
* 每個啟用執行都會維持端對端歷程,確保 Data 360 與外部系統之間的合規性、可追蹤性和一致性。
* 業務使用者可以透過完整且信任的 Customer 360 檢視提供高度個人化的資料驅動體驗。

###### 通話機制
呼叫機制取決於目標雲端儲存平台和啟用組態。

<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Amazon S3 啟用</strong></td>
<td>在 AWS 上主控您的企業資料湖時使用。Data 360 會使用 IAM 角色或暫存認證直接寫入至 S3 分類,以確保安全且可調整的匯出。</td>
</tr>
<tr>
<td><strong>Azure Blob Storage 啟用</strong></td>
<td>當您的組織在 Microsoft Azure 上作業時使用。Data 360 使用 SAS 權杖或服務主體將加密檔案寫入 Blob 容器。</td>
</tr>
<tr>
<td><strong>Google Cloud Storage (GCS) 啟用</strong></td>
<td>當您的資料科學或分析工作量在 GCP 上執行時使用。Data 360 使用 OAuth 認證,以 CSV 或 Parquet 格式將檔案匯出至 GCS 分類。</td>
</tr>
<tr>
<td><strong>SFTP 或 External File Gateway</strong></td>
<td>當法規或舊版系統需要透過 SFTP 端點或企業管理的檔案傳輸平台安全傳送時使用。</td>
</tr>
<tr>
<td><strong>混合式匯出 (檔案 + API)</strong></td>
<td>當下游應用程式需要分析的檔案型匯出,以及工作流程協調的 API 觸發 (例如 MuleSoft 流程) 時使用。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **工作層級隔離:**每個匯出都會以離散工作執行。失敗的工作會獨立隔離並重試。
* **部分檔案重試:**如果某些批次無法上載 (例如由於網路中斷),則系統會使用指數反向方式重試這些區塊。
* **結構描述不相符處理:**任何結構描述漂移或欄位不相符都會將記錄路由至「結構描述拒絕排隊」以供檢閱。
* **檢查點與恢復:**匯出工作會維護檢查點中繼資料,從上次成功的寫入啟用恢復,而不會重複。
* **整合監視:**失敗和重試會記錄在 Trust 圖層顯示面板中,以取得可視性和 SLA 合規性。
###### 潛在設計考量事項
* **決定性匯出索引鍵:**每個匯出工作都包含由「區段識別碼 + 目標識別碼 + 時間戳記」所組成的唯一識別碼。
* **重複執行安全性:**系統會使用工作雜湊偵測重複的工作執行,並略過以防止冗餘匯出。
* **原子寫入保證:**Data 360 只會在完整完成和核取總和驗證後,將檔案認可至目標分類。
* **一致的結構描述版本化:**匯出定義是版本控制,以確保執行之間的結構描述一致。
* **檢查點持續性:**匯出工作保持狀態,可視需要進行決定性復原和重新處理
###### 安全性考量事項
* **強式驗證:**雲端連接器會針對已驗證的寫入使用 OAuth 2.0、IAM 角色或服務主體。
* **隨處加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
* **同意感匯出:**僅會匯出具有有效同意的記錄,由 Trust 層原則強制執行。
* **最低權限原則:**匯出使用者和服務帳戶僅限於其指定的儲存路徑。
* **全方位稽核記錄:**每個匯出都會記錄中繼資料,包括起始者、結構描述、目的地和合規性報告的時間戳記。
##### 側列
###### 及時性
* 針對具有子秒延遲的立即事件驅動啟用所設計。
* 適用於需要立即個人化、建議或決策的情境。
* 在串流模式中作業—只要在 Data 360 中發生合格資料變更,便會觸發。
* 確保持續回應,而無須等待批次排程或區段重新計算。
###### 資料量
* 處理大規模資料集 (每次執行數百萬筆記錄)。
* 透過區段分割和並列匯出管道水平調整規模。
* 使用以區塊為基礎的批次來避免逾時並最佳化輸送量。
* 適用於資料完整性十分重要的企業級資料銷售管道。
###### 州/省管理
* 每個事件動作都會維護自己的事件權杖和重新執行識別碼,以進行識別處理。
* 支援在暫時失敗時,從上次認可的事件恢復檢查點持續性。
* 包含內建的復原邏輯和重新執行視窗,以確保完全符合啟用一次的語意。
* 動作結果 (成功/失敗) 會即時記錄,並透過 Trust 圖層可觀察性顯示面板呈現。
###### **複雜整合案例**
* 直接與 Salesforce 流程、Einstein 1 平台事件或立即回應鏈的外部 Webhooks 整合。
* 可以觸發下游自動化,例如立即 CRM 記錄更新、AI 評分或 Marketing Cloud 訊息傳送。
* 支援可編輯協調流程:事件觸發程序可以呼叫 Data 360 動作、Apex 叫用或外部 API。
* 針對具有即時感知內容回應的代理和自適應企業模式所設計。
###### 範例
全球零售企業需要每週匯出其「已啟用忠誠度成員」區段,以在 Databricks 中進行分析。Data 360 管理員會將 Amazon S3 設定為啟用目標,並排程每週的 CSV 匯出至 s3://enterprise-analytics/loyalty/weekly\_exports/ 路徑。匯出工作會每週日執行,產生具有 2 百萬筆以上記錄的同意篩選檔案。
所有事件、結構描述定義和歷程記錄在 Trust 圖層顯示面板中,以確保透明度、可稽核性和合規性。

### 隨選 API 型啟用
隨選 API 型啟用是一種即時、以事件為導向的方法,可讓 Data 360 洞察在需要時運作,而不必等待批次工作或排程匯出。此模式可讓外部系統、Salesforce 應用程式或 AI 工作人員直接呼叫 Data 360 API,以依需求提取或啟用特定受眾配量、客戶屬性或洞察,而不是以固定步調發佈預先建立的區段。
此模式是針對互動式、以觸發為基礎的體驗所設計,例如當使用者登入入口網頁、工作人員開啟客戶記錄,或 AI Copilot 起始 Next-best-action 查詢。系統不會依賴預先計算的匯出,而是動態地從 Data 360 inReal-Time 查詢或啟用最新的受管理資料。
主要優點為立即性和精確度:
* 每個 API 呼叫都會在 Data 360 的統一同意設定檔圖表中存取最新的客戶智慧。
* 啟用功能適用且可稽核,符合企業 Trust 與合規性需求。
* 可透過 Einstein 1 平台 API、Connect API 或啟用 API,直接從 Salesforce 流程、Apex 或外部系統觸發整合。
此方法支援最重要的延遲和個人化使用個案,例如:
* 在服務通話期間觸發個人化產品供應項目。
* 根據即時行為事件產生動態行銷活動受眾。
* 將即時決策提供給參與時作業的 AI 或 ML 模型。
#### 透過 Connect API 自訂應用程式整合
##### Context
企業通常需要在自訂建立的應用程式 (例如內部網頁入口網頁、行動應用程式或合作夥伴面向的 Web 體驗) 內呈現協調的即時 Data 360 洞察。此模式可讓開發人員建立以 UI 為中心的安全解決方案,這些解決方案會與 Salesforce CRM 和其他內容相關系統一起取用並顯示統一的客戶資料,全都透過受管理和以 API 為基礎的存取。
一般使用個案包括:
* 將 Data 360 洞察內嵌至內部員工顯示面板或行動應用程式。
* 使用客戶和交易可視性建立合作夥伴或經銷商入口網頁。
* 將 Data 360 資料整合至第三方 Web 應用程式或體驗層。
* 顯示 Data 360 和 Einstein 1 提供的即時個人化建議。
##### 問題
開發人員如何建立以 UI 為中心的自訂應用程式,以安全地存取並顯示協調的 Data 360 資料,通常與其他 Salesforce 資料來源一起,而不重複或匯出敏感資訊?
例如,企業可能需要建立客戶入口網頁,以從 Data 360 顯示統一的客戶設定檔、互動和已計算洞察。
這需要單一、安全且效能高的 API 圖層,以支援前端體驗、處理驗證,並確保監管,同時移除 Data 360 內部資料模型的複雜性。
##### 力量
多個結構與作業考量事項會影響此模式:
* **以使用者為中心的存取權:**主要目標是在自訂前端體驗 (Web 或行動) 內呈現資料,而不是執行批次解壓或後端同步。
* **Secure Gateway:**所選的 API 必須作為已驗證應用程式和使用者的安全且可調整的進入點,強制執行企業級存取控制。
* **統一資料內容:**應用程式應能順暢地將 Data 360 資料 (例如統一設定檔、已計算洞察) 與 CRM、ERP 或自訂物件資料結合在一起。
* **開發人員簡單性:**API 應傳回簡報就緒的裝載,以將用戶端層中的後端處理或結構描述對應最小化。
* **管治與可觀察性:**所有存取權都應透過可信任且可稽核的管道來流動,並具有明確的歷程、驗證和強制執行原則。
##### 解決方案
解決方案是使用 Salesforce Connect REST API 作為在 Data 360 上建立自訂資料驅動應用程式的主要整合門戶。
Connect API 提供對 Salesforce 資料 (包括 Data 360 的協調設定檔、區段和已計算洞察) 的 RESTful 存取權,其回應格式針對 UI 耗用最佳化 (JSON 型、輕量型和行動使用)。
開發人員透過連線的應用程式進行驗證、取得 OAuth 2.0 權杖,並呼叫 Connect API 資源,例如 /query、/Chatter 或 /data,以直接在其應用程式介面中呈現統一資料。
Connect API 可在背景作為其他 API (例如查詢 API、Data Graph API 和 Einstein 1 Platform API) 的傳輸基礎,讓開發人員能夠在單一統一存取模式下結合多個資料來源。

<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>驗證與應用程式註冊</strong></td>
<td>必要</td>
<td>在 Salesforce 中建立連線的應用程式以進行以 OAuth 2.0 為基礎的驗證。設定 Data 360 API 存取的範圍。</td>
</tr>
<tr>
<td><strong>資料存取權 (設定檔、區段、洞察)</strong></td>
<td>最佳</td>
<td>使用 Connect API 端點 (/services/data/vXX.X/connect) 查詢已協調的 Data 360 資料、統一設定檔和已計算洞察。</td>
</tr>
<tr>
<td><strong>UI 整合</strong></td>
<td>最佳</td>
<td>前端應用程式 (React、Angular、iOS、Android) 會呼叫 Connect API,以在顯示面板、入口網頁或行動介面中呈現 Data 360 資料。</td>
</tr>
<tr>
<td><strong>資料圖表查詢</strong></td>
<td>建議</td>
<td>將 Connect API 與 Data Graph API 結合,以取得簡化複雜聯結和關係的語意層級查詢。</td>
</tr>
<tr>
<td><strong>即時重新整理</strong></td>
<td>選擇性</td>
<td>將 Connect API 與 WebSocket 或串流擴充用於即時資料更新。</td>
</tr>
<tr>
<td><strong>安全與管治</strong></td>
<td>必要</td>
<td>使用 OAuth 範圍、Data 360 原則和 Trust 層稽核架構強制執行資料可視性。</td>
</tr>
</tbody>
</table>

##### 草稿
以下是步驟的摘要。
* **註冊連線的應用程式** — 定義外部應用程式驗證的 OAuth 範圍和 API 權限。
* **取得存取權杖** — 外部應用程式執行 OAuth 2.0 驗證以接收 Data 360 存取權杖。
* **Invoke Connect API** — 應用程式會執行 REST API 呼叫,以提取統一設定檔、區段或洞察資料。
* **在 UI 中呈現資料**—會剖析回應,並在品牌入口網頁或行動介面中向使用者顯示。
* **處理錯誤與重新整理權杖** — 應用程式會實作重試邏輯和自動權杖重新整理,以保持工作階段持續性。
* **監視與稽核存取權** — 所有 API 呼叫都會記錄在 Trust 圖層中,以瞭解可視性和合規性。
  
<img style="border:1px solid #e5e5e5;margin:2rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/connect_api_new.png" alt="顯示實作 Connect API 流程的 UML 圖表" />

##### 結果
開發人員可以建立與 Data 360 密切整合的安全自訂品牌應用程式。這些應用程式可以:
* 以即時方式呈現已協調的客戶設定檔和洞察。
* 透過統一 API 與 CRM 或自訂物件一起顯示 Data 360 資料。
* 透過 Trust 層運用一致的驗證、授權和稽核控制。
* 為業務使用者或合作夥伴提供流暢且受管理的跨體驗信任客戶智慧存取權。
##### 通話機制
呼叫機制取決於目標雲端儲存平台和啟用組態。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>連線 REST API (偏好)</strong></td>
<td>建立需要以 UI 易用 JSON 格式即時存取 Data 360 資料的 Web、行動或第三方應用程式時使用。</td>
</tr>
<tr>
<td><strong>資料圖形 API</strong></td>
<td>應用程式需要在多個物件之間執行語意層級查詢 (例如客戶 → 交易 → 行銷活動) 時使用。</td>
</tr>
<tr>
<td><strong>查詢 API</strong></td>
<td>執行 SOQL 類似查詢時使用,以高精確度的方式提取協調的資料集。</td>
</tr>
<tr>
<td><strong>Einstein 1 平台 API</strong></td>
<td>在自訂 UI 中整合 AI 驅動洞察或 Copilot 產生的建議時使用。</td>
</tr>
<tr>
<td><strong>MuleSoft 或 Apex Gateway 包裝程式</strong></td>
<td>當應用程式與 Connect API 之間需要額外協調流程、快取或強制執行原則時使用。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **要求節流:**自動在比率限制下備份和重試 API 呼叫。
* **結構描述漂移保護**:使用 GraphQL 結構描述版本化或 REST 中繼資料探索以適應結構描述變更。
* **權杖到期管理** – 應用程式會自動重新整理 OAuth 權杖,以避免工作階段中斷。
* **API 錯誤區隔** – 系統會記錄失敗的 API 呼叫並重試,而不會影響同時工作階段。
* **信任層觀察性** – API 成功/失敗率和存取記錄會顯示在「信任層」顯示面板中。
###### 潛在設計考量事項
* **決定性要求識別碼**:每個 API 要求都包含重複執行安全處理的關聯性識別碼。
* **快取驗證標題:**ETag 和「上次修改」標題會防止冗餘的資料提取。
* **原子讀取作業:**Connect API 可確保每個回應皆反映統一資料的一致快照。
* **重複執行保護** – 使用要求簽章和時間戳記篩選重複的 API 呼叫。
###### **安全性考量事項**
* **OAuth 2.0 驗證:**所有 API 呼叫都會透過「連線的應用程式」使用安全且短暫的 OAuth 存取權杖。
* **最低權限存取權:**API 範圍僅限於必要物件和欄位。
* **隨處加密:**傳輸中的 TLS 1.2+;快取或儲存回應的靜態 AES-256 加密。
* **同意資料存取權**:Data 360 可確保所有已提取的記錄皆遵循同意與管治原則。
* **全方位稽核記錄:**系統會在 Trust 圖層中記錄使用者、應用程式和時間戳記中繼資料的每個 API 互動。
##### 側列
###### 及時性
* 針對低延遲、即時 API 存取所設計。
* 適用於需要立即資料呈現的互動式應用程式。
* 透過快取與索引的 Data 360 來源支援近乎立即的查詢回應時間。
* 不需依賴批次排程或非同步啟用週期。
###### 資料量
* 針對互動式使用個案 (例如設定檔、洞察或最近交易) 所最佳化。
* 透過游標式分頁順暢地處理分頁結果。
* 不適用於大量大量匯出—針對大型資料集使用「批次」或「檔案匯出」模式。
###### 州/省管理
* 應用程式會使用 OAuth 權杖和本機快取來維持輕量型工作階段狀態。
* Connect API 支援條件式要求和部分重新整理以提升效率。
* API 回應包含版本標記,用於跨版本的結構描述一致性。
###### 複雜整合案例
* 將 Connect API 與 Data Graph API 結合,以跨多個網域進行語意查詢。
* 與 Einstein 1 Copilot 或 AI API 整合,以獲得預測式對話式體驗。
* 搭配 Experience Cloud 或 Lightning Web 元件使用,以進行混合式 UI 開發。
* 透過 MuleSoft 擴充,以即時協調資料增強或外部系統對應。
##### 範例
跨國保險公司建立客戶自助式服務入口網頁,讓保單持有人能夠檢視其統一設定檔、最近索賠和個人化優惠。前端以 eact 為基礎的應用程式會透過 OAuth 2.0 進行驗證,並使用 Connect REST API 和 Data Graph API 提取資料。所有資料都會即時顯示、感知同意,並透過 Data 360 Trust 層級進行管理。開發人員可直接在 Salesforce 內監視 API 呼叫並稽核追蹤,以確保完全合規性和可觀察性。
#### 透過資料圖形 API 完成客戶設定檔尋找
##### Context
企業對即時決策系統 (例如服務主控台、建議引擎或個人化平台) 所需的完整客戶設定檔即時存取權越來越多。此模式可讓應用程式使用 Data 360 的 Data Graph API,以近乎即時的方式,以預先計算且統一檢視客戶資料,為互動體驗提供子秒回應時間。
一般使用個案包括:
* 在「客戶服務」或 Sales Console 內顯示全方位的客戶檢視。
* 為 AI 型「Next Best Action」或「Next Best Offer」建議提供動力。
* 在頁面載入時提供超個人化的 Web 或行動體驗。
* 在工作人員或自助式服務環境中支援工作階段內決策。
##### 問題
應用程式如何能立即提取完整、預先計算且統一的客戶檢視,而不是在執行階段執行慢速的多物件查詢?例如,網頁個人化引擎必須在毫秒內載入完整的客戶內容 (人口統計、偏好、交易和已計算洞察),才能選取個人化優惠。傳統關聯式查詢可能需要多個聯結,並導致無法接受的延遲。這需要 API,提供反正規化且可供使用的設定檔資料,且可透過單一金鑰對應 (結合速度、完整性和管治性) 來進行搜尋。
##### 力量
多個營運和效能因素會影響此模式:
* **速度:**回應時間必須接近即時。API 必須在毫秒內傳回完整設定檔,才能支援同步互動。
* **完整性:**回應必須包含所有相關屬性、關係和已計算洞察,理想情況下是在單一裝載中。
* **對應效率:**設定檔應可透過識別碼 (例如 customerId、contactKey 或電子郵件),以免發生多步驟查詢。
* **資料新鮮度與延遲性:**某些使用個案偏好預先計算 (快取) 的資料速度;而其他則需要即時資料,接受較高的延遲。
* **管治與安全:**存取權必須保持由 Salesforce Trust 圖層原則管理,以確保符合資料可視性和同意規則。
##### 解決方案
解決方案是使用 Salesforce 資料圖表 API 來檢取儲存為「資料圖表」記錄的預先計算反正規化客戶檢視。「資料圖形」是一種具體化的語意檢視,將多個「資料模型物件」(DMO) (例如「個人」、「交易」和「ProductInterest」) 結合成單一唯讀記錄,通常以 JSON blob 表示。
開發人員可以使用 REST 端點,例如:
GET /api/v1/dataGraph/{dataGraphEntityName}/{id}
以透過其唯一識別碼,來取回完整記錄。針對動態情況,API 支援 live=true 參數,可略過已具體化的快取,在 Data 360 中執行即時查詢,並針對最新的資料交易最短延遲。
這可讓開發人員根據業務需求,在立即 (快取) 和最新 (即時) 設定檔中選取。

<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>資料圖形定義</strong></td>
<td>必要</td>
<td>結構設計師定義將多個 DMO 合併為單一語意實體的「資料圖表」(例如,UnifiedCustomerProfile)。</td>
</tr>
<tr>
<td><strong>設定檔搜尋</strong></td>
<td>最佳</td>
<td>應用程式會呼叫 GET /api/v1/dataGraph/{entity}/{id} 以依唯一識別碼或金鑰來檢取完整的反正規化設定檔。</td>
</tr>
<tr>
<td><strong>即時參數用量</strong></td>
<td>選擇性</td>
<td>附加 ?live=true 以強制重新計算,而非快取取用;適用於高價值決策。</td>
</tr>
<tr>
<td><strong>驗證</strong></td>
<td>必要</td>
<td>透過連線的應用程式使用 OAuth 2.0 來安全地驗證 API 呼叫。</td>
</tr>
<tr>
<td><strong>回應剖析</strong></td>
<td>最佳作法</td>
<td>應用程式會將 JSON 回應直接剖析至其 UI 或決策引擎,無須進一步聯結。</td>
</tr>
<tr>
<td><strong>快取策略</strong></td>
<td>建議</td>
<td>針對重複的設定檔對應,實作短期本機快取 (例如記憶體內或 CDN)。</td>
</tr>
<tr>
<td><strong>監視與可觀察性</strong></td>
<td>必要</td>
<td>使用 Trust 圖層顯示面板監視查詢效能、回應時間和原則符合度。</td>
</tr>
</tbody>
</table>

##### 草稿
以下是實作流程的摘要:
* **定義資料圖表** — 資料結構設計師建立「資料圖表」,在多個 DMO 之間建模統一的客戶檢視。
* **註冊連線的應用程式** — 開發人員可設定 OAuth 認證以安全地存取 API。
* **叫用資料圖表 API** — 應用程式會發出具有「資料圖表」名稱和記錄識別碼的 GET 要求。
* **流程回應** — API 會傳回客戶設定檔的完整 JSON 表示。
* **呈現或動作**—取用應用程式 (UI 或引擎) 會使用統一資料進行個人化、建議或服務動作。
* **監視和調整** — 透過 Trust 層觀察性主控台檢閱效能度量和存取記錄。
  
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/data_graph_api.png" alt="顯示流程以實作 Graph API 的 UML 圖表" />

##### 結果
應用程式現在可以立即提取完整且預先加入的客戶設定檔,以支援即時互動,例如個人化、服務和決策自動化。
此模式可確保:
* 目前決策的子秒回應時間。
* 與 Data 360 語意模型相符的一致且受管理的資料提取。
* 簡化應用程式邏輯—無聯結,無結構描述協調。
* 可透過 Trust 層進行追蹤且符合的存取,以進行稽核和可觀察。
###### 通話機制
呼叫機制取決於目標雲端儲存平台和啟用組態。
<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>資料圖形 API (偏好)</strong></td>
<td>可用於透過識別碼或金鑰即時快取完整且預先具體化的設定檔。</td>
</tr>
<tr>
<td><strong>具有 live=true 的資料圖表 API</strong></td>
<td>用於需要最新資料的高價值使用個案 (例如詐騙偵測、即時優惠),接受略有較高的延遲。</td>
</tr>
<tr>
<td><strong>Connect API (回復)</strong></td>
<td>用於複合應用程式案例,其中將「資料圖形」,以及其他的 Salesforce 資料相結合。</td>
</tr>
<tr>
<td><strong>查詢 API</strong></td>
<td>建構臨時查詢或分析讀取時使用,而非立即設定檔提取。</td>
</tr>
<tr>
<td><strong>MuleSoft API Proxy</strong></td>
<td>用於在透過企業門戶路由 Data Graph 呼叫或需要額外協調流程/強制執行原則時使用。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **優良回復** – 如果即時查詢失敗或超過逾時值,則會自動回復為快取的「資料圖形」,
* **逾時管理** – 針對載入高的 API 呼叫實作重試與斷線邏輯。
* **識別碼處理無效** – 傳回標準 404 找不到不存在設定檔金鑰的回應;請謹慎處理 UI。
* **結構描述版本驗證** – 驗證「資料圖表」版本中繼資料,以避免結構描述演進時發生不相符項目。
* **可觀察性整合** – 記錄 SLA 監視的「信任層」顯示面板內所有錯誤、重試和延遲。
###### 潛在設計考量事項
* **決定性索引鍵** – 每個設定檔會使用穩定識別碼 (例如,IndividualId),以確保可預測且安全地執行查詢。
* **快取一致性** – 使用 ETag 或「上次修改」標題以進行條件式提取和快取驗證。
* **Atomic Retrieval** – 每個 API 回應皆代表已具體化「資料圖形」記錄的一致快照。
* **重複執行保護** – 確保用戶端應用程式透過關聯性識別碼和時間戳記偵測重複的提取。
###### 安全性考量事項
* **強大驗證** – OAuth 2.0 透過連線的應用程式強制執行以權杖為基礎的安全存取。
* **同意感取** – 只會傳回同意的屬性;同意篩選會由 Trust 層自動套用。
* **欄位級管理** – 透過 Data 360 的中繼資料和原則定義控制屬性的存取權。
* **在傳輸和靜態加密** – 所有回應都使用 TLS 1.2+ 和 AES-256 加密。
* **稽核與可追溯性** – 系統會使用識別碼、時間戳記和原則內容來記錄每個設定檔提取事件。
##### 側列
###### 及時性
* 適用於即時取用。
* 支援以略有較高的延遲 (子秒) 即時查詢最新的資料。
* 針對同步決策和互動式應用程式最佳化。
* 無須進行批次前啟用或區段重新計算。
###### 資料量
* 對於每個要求的 **單筆記錄對應**或小組 (十到數百個) 而言非常適合。
* 並非針對大規模的大規模大量取用最佳化;針對大量讀取使用批次或查詢 API。
* 使用水平調整快取和預先具體化的速度。
###### 州/省管理
* 維護輕量型且無狀態的存取權;每個要求皆獨立。
* 支援快取標題以確保重新執行安全性。
* 應用程式可以維護本機快取或短時間工作階段儲存空間,以減少重複對應。
###### 複雜整合案例
* 與 **Einstein 1**、**Connect API** 和 **MuleSoft** 順暢整合,以獲得複合資料體驗。
* 可以支援需要立即上下文感知的**原始系統** (例如 Copilot 或 AI 推理引擎)。
* 與「**資料動作**」結合,以便在取用或狀態變更時即時觸發。
* 實現大規模的**個人化**,而不會影響績效或管治。
##### 範例
全域電子商務平台使用 **Data 360 的 Data Graph API** 即時針對其建議引擎來提取統一的客戶設定檔。當使用者登入時,應用程式會叫用 Data Graph 端點來為該客戶提取 **UnifiedCustomerProfile**,以單一 JSON 裝載傳回人口統計屬性、行為訊號和已計算洞察。個人化引擎會在啟用的工作階段期間,在毫秒內耗用此回應,以決定並顯示「Next Best Offer」。所有要求都會透過 **Trust Layer** 進行管理和記錄,以確保整個互動的完整可視性、強制執行原則和合規性。
### 即時資料動作
即時資料動作可在 Data 360 中即時啟用客戶資料的變更。這些動作不會等待排程的批次匯出,而是會以毫秒的方式將更新、洞察或觸發直接推送至 Salesforce 或外部系統。在 Data 360 中更新客戶的狀態、同意或參與度量時,該訊號會立即強化個人化優惠、觸發 Service Cloud 自動化或更新忠誠度層級,以確保每個客戶體驗皆反映最新的統一事實。
此模式適用於**高影響、敏感於延遲的使用個案**,例如個人化 Web 體驗、詐騙偵測警示、Next-best-action 建議或即時 CRM 更新。其可減少資料洞察與業務動作之間的間隙,將統一資料轉為即時情報。
#### 將客戶訊號轉換為立即動作的即時資料動作
##### Context
現代數位體驗和作業工作流程在事件發生時需要立即的內容相關動作,例如在 Checkout 期間更新客戶記錄、掃描退貨時調整庫存,或在使用者離開手推車時提供個人化促銷。**[即時資料動作](https://help.salesforce.com/s/articleView?id=data.c360_a_data_actions_cdp.htm&type=5)**可讓系統透過子秒到秒延遲,叫用、增強統一 Data 360 設定檔和已計算洞察,並對其採取動作,以實現互動式個人化、作業自動化和即時決策。
##### 問題
應用程式、UI 互動流程或中介軟體如何在執行階段呼叫 Data 360 以讀取、計算或更新單一統一設定檔,或以低延遲、強大一致性和管治控制來觸發動作 (例如傳送優惠、更新 CRM、啟動工作流程),而無須等待排程的批次工作或繁重的管道?
##### 力量
多個技術、營運和管治部門構成此模式:
* **低延遲需求:**通話必須在下秒到幾秒的範圍內完成,才能保留良好的 UX 或符合作業 SLA。
* **決定性身分解析:**要求必須可靠且快速地解析至正確的「統一個人」設定檔 (金級記錄)。
* **微調授權:**即時呼叫必須在要求時間強制執行屬性層級原則和同意檢查。
* **支付量最小化:**即時裝載應小型且聚焦 (單一設定檔或小型屬性集),以減少延遲和成本。
* **開發人員體驗:**API 必須為開發人員易用 (REST/gRPC/GraphQL),具有明確的結構描述和穩定的契約,才能供生產使用。
* **稽核與可追溯性:**每個即時動作都必須以歷程記錄、使用者身分和原則決策來進行合規。
##### 解決方案
建議的解決方案是使用 **Data 360 的即時資料動作**介面 (API + SDK),並在必要時結合邊緣快取和最少的運算轉換。整合會叫用資料動作端點來讀取或寫入設定檔屬性、計算洞察或起始協調流程。在退回任何裝載或執行動作之前,系統會在「保單強制執行點」上套用即時原則檢查 (CEDAR) 和動態遮蔽。

<table>
<thead>
<tr>
<th>解決方案區域</th>
<th>適合</th>
<th>註解/實作詳細資料</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>即時資料動作</strong></td>
<td><strong>最佳</strong></td>
<td>顯示單一記錄讀/寫與動作觸發的端點。透過 OAuth/JWT 進行驗證。</td>
</tr>
<tr>
<td><strong>身分解析</strong></td>
<td><strong>必要</strong></td>
<td>將傳入識別碼 (email、externalId、cookie) 內嵌解析為「統一個人識別碼」。將決定性解析程式與快取搭配使用。</td>
</tr>
<tr>
<td><strong>保單強制執行 (CEDAR)</strong></td>
<td><strong>最佳作法</strong></td>
<td>在要求時評估同意、ABAC 和遮蔽原則;拒絕或遮蔽每個原則決策的欄位。</td>
</tr>
<tr>
<td><strong>邊緣/快取層級</strong></td>
<td><strong>建議</strong></td>
<td>針對設定檔片段和已計算洞察使用短TTL 快取,以減少延遲;變更事件時失效。</td>
</tr>
<tr>
<td><strong>輕量型轉換</strong></td>
<td><strong>建議</strong></td>
<td>在動作路徑中套用簡單增強或已計算欄位;重量轉換應預先計算。</td>
</tr>
<tr>
<td><strong>動作協調流程</strong></td>
<td><strong>最佳</strong></td>
<td>支援複雜流程的同步單一步驟動作 (例如,傳回提供權杖) 和非同步協調流程 (queue \+ webhook)。</td>
</tr>
<tr>
<td><strong>觀察性與追蹤</strong></td>
<td><strong>必要</strong></td>
<td>將要求/回應、原則決策和歷程記錄到 Trust Layer/SIEM 以用於稽核和除錯。</td>
</tr>
<tr>
<td><strong>比率限制與節流</strong></td>
<td><strong>必要</strong></td>
<td>針對高流量時刻,強制執行用戶配額和優雅的降級策略。</td>
</tr>
</tbody>
</table>

##### 草稿
以下是步驟的摘要。
* Client (UI/ middleware/POS) 會傳送具有識別碼和動作類型的已驗證「資料動作」要求。
* API Gateway 會驗證權杖、比率限制,並轉送至 Data 360 Action Service。
* 動作服務會解析識別碼 → 統一個人識別碼 (快速路徑快取;回復至圖表對應)。
* 「保單強制執行」(PDP) 會使用 PIP 與要求內容中的屬性評估 CEDAR 原則。
* 若允許,則「動作服務」會讀取任何必要的設定檔屬性/洞察,並執行輕量轉換。
* 「動作服務」會同步傳回回應 (例如提供權杖、更新的屬性),或排入非同步協調流程,並傳回確認。
* 所有事件、決策和裝載都會記錄到 Trust 圖層,並選擇性轉送至 SIEM。
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_int_patterns/data_action_new.png" alt="顯示實作資料動作之流程的 UML 圖表" />

##### 結果
* 應用程式會收到透過子秒到第二次延遲的統一設定檔讀/寫和動作觸發的原則管理即時存取權。
* 即時個人化、決策和作業工作流程 (例如,優惠、工作人員協助、庫存更新) 會啟用,而不會發生批次延遲。
* 所有動作皆可稽核、感知同意,並強制執行屬性層級遮蔽,以維護隱私權與合規性。
###### 通話機制
呼叫機制取決於目的地平台和啟用目標組態。

<table>
<thead>
<tr>
<th>機制</th>
<th>使用時機</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>RESTful 資料動作 API</strong></td>
<td>偏好用於需要同步設定檔讀取或動作回應的 Web/行動應用程式和中介軟體。</td>
</tr>
<tr>
<td><strong>gRPC / Binary RPC</strong></td>
<td>用於超低延遲的企業服務或具有永久連線的內部微型服務。</td>
</tr>
<tr>
<td><strong>GraphQL 單一記錄查詢</strong></td>
<td>用於用戶端需要彈性選取欄位並想要最小化裝載時使用。</td>
</tr>
<tr>
<td><strong>事件觸發的 Webhooks</strong></td>
<td>用於動作觸發下游流程 (例如開始旅程) 的非同步工作流程。</td>
</tr>
<tr>
<td><strong>平台事件/PubSub</strong></td>
<td>用於多個系統必須回應單一動作事件的扇出案例。</td>
</tr>
<tr>
<td><strong>Edge SDK (用戶端 lib)</strong></td>
<td>用於快取設定檔片段並僅在需要時呼叫「資料動作 API」的低延遲用戶端。</td>
</tr>
</tbody>
</table>

###### 錯誤處理與復原
* **同步錯誤:**使用人類可讀的訊息和識別權杖傳回結構化錯誤代碼。
* **暫時重試:**客戶應針對 429/5xx 回應重試具有指數反向的潛在要求。
* **原則拒絕處理:**拒絕會傳回明確原因代碼;原則失敗時,不會傳回敏感資料。
* **非同步協調流程失敗:**協調流程工作會移至 DLQ 並可重新執行;工作狀態 API 允許客戶輪詢或接收回呼。
* **回復策略:**如果身分解析失敗,則傳回決定性錯誤,並選擇性傳回建議的補救措施 (例如,需要 externalId)。
###### 潛在設計考量事項
* **Idempotency 索引鍵:**用戶端提供識別碼金鑰 (UUID + 用戶端命名空間) 以用於變更動作。
* **決定性索引鍵:**使用複合索引鍵 (UnifiedIndividualId + ActionType + TimestampWindow) 來偵測重複項目。
* **安全重試:**設計動作以容忍副作用,或執行更新插入而非隱藏插入。
* **重複執行保護:**保留已處理的 idempotency 金鑰,並在業務期間後進行 TTL,以避免重複執行。
* **無國籍:**盡可能將同步動作保持為無狀態;保留非同步工作流程的最低狀態。
###### 安全性考量事項
* **驗證:**OAuth 2.0 (JWT 承載者或 mTLS 用於服務帳戶);短期權杖和重新整理輪替。
* **授權:**「原則決策點」會針對每個要求強制執行「以屬性為基礎的存取控制」(CEDAR) 和同意檢查。
* **傳輸與儲存加密:**傳輸中的 TLS 1.2+;任何快取片段或稽核記錄的靜態 AES-256。
* **最低權限:**範圍為最小權限的 API 用戶端;讀取與寫入與協調的角色分開。
* **資料最小化:**僅傳回要求與同意的屬性;對 PII/PHI 套用動態遮蔽。
* **網路控制:**您可以選擇性地從私人網路 (Private Connect、IP 允許清單) 呼叫,以進行高風險動作。
* **稽核與監視:**將要求中繼資料、原則決策、要求者身分和回應雜湊記錄至 Trust Layer 和 SIEM。
##### 側列
###### 及時性
* 針對同步動作的子秒到低單秒範圍中平均延遲所設計。
* 邊緣快取 (短 TTL) 和預先計算洞察會減少來回行程。
* 非同步路徑針對繁重工作提供近乎即時的確認與背景處理。
###### 資料量
* 針對單一記錄或小批次互動 (1–100 筆記錄) 最佳化。
* 不適用於大量匯出—針對大量使用使用批次啟用。
* 高輸送量會使用集區/連線重複使用和並列協調流程。
###### 州/省管理
* 同步通話的無州要求模型;贈款/交易的最低動作狀態仍存在。
* 由變更事件驅動的快取無效—確保 TTL 和無效訊號讓快取保持最新狀態。
* 協調流程工作會維持儲存在 Trust 圖層中的永久狀態 (jobId、status、retries)。
###### 複雜整合案例
* **工作人員助理:**工作人員的即時設定檔對應 + 以子秒傳回至 Service Console 的已計算傾向。
* **POS/邊緣裝置:**本機 SDK + 偶發資料動作,用於驗證促銷或忠誠度狀態。
* **混合式流程:**針對決策 + 非同步協調流程同步化資料動作,以更新下游系統並觸發行銷活動。
* **第三方中繼軟體:**MuleSoft 或 API Gateways 可以媒介驗證、增強內容,並強制執行額外的原則檢查。
##### 範例
零售行動應用程式會決定購物者點選「 **結帳** 」時是否要顯示個人化的立即優惠券,方法是透過使用購物者的電子郵件和手推車內容叫用優惠 **資格** 資料動作。要求會由 API Gateway 驗證,並轉送至「資料動作服務」,此服務會使用快取快取來解析電子郵件至統一個人識別碼、透過 PDP 驗證行銷同意,並根據客戶的終身價值和最近購買的時間評估資格。如果購物者符合資格,則服務會傳回簽署的優惠券權杖並記錄決策。當優惠券核發需要庫存預留時,會觸發非同步協調流程來預留庫存並通知 CRM 系統。應用程式會立即顯示優惠券,而後續更新會在背景中完成,而「Trust層級」會針對管治與合規性的完整稽核追蹤。

## 參照
* [連接器與整合](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&language=en_US&type=5)
* [Web 與 Mobile SDK](https://help.salesforce.com/s/articleView?id=data.c360_a_web_mobile_app_connector.htm&language=en_US&type=5)
* [次要即時的吸收](https://help.salesforce.com/s/articleView?id=data.c360_a_real_time_capabilities.htm&type=5)
* [自帶湖 (零複製查詢)](https://help.salesforce.com/s/articleView?id=data.c360_a_byol_data_federation.htm&language=en_US&type=5)
* [自帶湖 (零複製檔案)](https://help.salesforce.com/s/articleView?id=data.c360_a_file_federation.htm&type=5)
* [資料圖](https://help.salesforce.com/s/articleView?id=data.c360_a_data_graphs.htm&type=5)
* [啟用:MC 參與](https://help.salesforce.com/s/articleView?id=data.c360_a_create_marketing_cloud_activation.htm&language=en_US&type=5)
* [啟用:MC 個人化](https://help.salesforce.com/s/articleView?id=data.c360_a_create_mc_personalization_activation_target.htm&language=en_us&type=5)
* [啟用:B2C Commerce](https://help.salesforce.com/s/articleView?id=data.c360_a_b2c_commerce_activation.htm&language=en_US&type=5)
* [資料共用 (零複製)](https://help.salesforce.com/s/articleView?id=data.c360_a_data_shares.htm&language=en_US&type=5)
* [啟用:檔案儲存空間](https://help.salesforce.com/s/articleView?id=data.c360_a_add_activation_target.htm&language=en_US&type=5)
* [資料動作](https://help.salesforce.com/s/articleView?id=data.c360_a_data_actions_CDP.htm&language=en_US&type=5)
* [即時次要資料動作](https://help.salesforce.com/s/articleView?id=data.c360_a_create_a_real_time_data_action.htm&language=en_US&type=5)
* [外部啟用平台](https://help.salesforce.com/s/articleView?id=data.c360_a_build_external_activation_platforms.htm&language=en_US&type=5)