成功的整合設計始於理解三個基礎面向：音量與頻率、方向性，以及能力。 這些面向有助於評估業務需求、系統限制與可擴展性需求。
舉例來說，假設你有一個高層次目標，比如將 SAP 連接到 Dataverse，或是每次有使用者處理案件更新時都會發送通知。 設計整合的起點是什麼？
第一步是將需求拆解為整合的三個關鍵組成部分：
音量與頻率
此維度定義了傳輸多少資料及傳輸頻率。 音量與頻率共同作用，塑造整合架構。 雖然它們看起來相似，但它們以不同方式影響解決方案設計。 以下組成部分詳細說明音量與頻率如何相互作用並影響整合決策。
比較音量與頻率
兩種整合情境可能涉及相同的總量，例如每小時60,000筆紀錄和每分鐘1,000筆紀錄，但頻率不同。 雖然兩者具有相同的每小時容量，但每分鐘的期望值會改變方案設計。
- 不要以為一個解決方案能同時適用兩者。
- 驗證系統處理高頻負載的能力。
- 如果某個模式資源密集或很少使用，考慮建立獨立解決方案。
觸發類型
觸發器決定整合的執行方式與時間。 根據可預測性和系統負載選擇正確的觸發器。
排程觸發器 (亦稱為「批次」)：
- 固定間隔跑步。
- 比較容易預測和管理。
- 適合穩定的資料成長模式。
事件驅動觸發器：事件可以是按鈕選擇、系統中記錄變更，或是 API 呼叫。
- 根據使用者操作或系統事件啟動。
- 比較難預測。
- 尤其是在對外系統中，可能會突然飆升。
Seasonality
資料量會隨商業週期波動。 規劃預定與事件驅動整合的季節性高峰。
- 每月或季度的帳單週期可能導致可預測的激增。
- 報稅季節或公共服務截止日期可能會造成難以預測的高峰。
- 實施防護措施以防止尖峰時段過載。
利害關係人協作
與流程負責人及業務用戶討論工作量與頻率。 驗證假設與實際工作流程的對照。
- 商業用戶可能不了解整個流程。
- 架構師必須調查並確認營運實況。
未來規劃
設計整合解決方案時，應以成長為先。
- 清楚定義操作條件。
- 納入長期可擴展性計畫。
- 估算何時需要縮放。
Directionality
方向性定義了系統間資料的流動。 定義資料的來源與交付地點，以塑造整合的配置與執行方式。 在確定資料流的方向性時，應考量系統可用性、合規要求及安全措施，以確保運作可靠且安全。 例如，資料可能來自一個不一定隨時可用或受嚴格合規與安全規範約束的私有系統。
利害關係人與合規
合規在整合設計中扮演關鍵角色，且各系統間差異甚大。 請諮詢基礎設施架構師及資安人員，確保連線符合組織安全與法規標準。
- 高安全性環境通常會施加嚴格的存取控制，影響整合架構。
- 舊有的本地系統可能會限制入站連線。 在這種情況下，設計整合時，讓舊系統主動與雲端應用程式溝通。
能力
整合效能取決於各系統的能力。 鏈條中最弱的系統限制了整體結果。
- 根據業務需求評估系統能力。
- 識別可能影響高頻或大量資料傳輸的瓶頸。
- 如果系統無法達到效能預期，請考慮進行改進。
能力與頻率
頻率會影響系統處理資料傳輸的能力。 在單日中表現良好的系統，可能在多次日常負載下出現故障。
- 將系統能力與所需頻率匹配。
- 不要以為僅僅是數量就決定可行性。
快取功能
當系統無法滿足效能要求時，快取是一種常見的解決方法。
- 使用像 Azure Synapse Link for Dataverse 這 類工具，將資料複製到可擴展的儲存空間。
- 了解這個取捨：快取能提升回應時間，但可能會產生過時的資料。
- 確保資料保持新鮮，以防止即時流程中出現不準確的結果。
轉換與商業邏輯
系統能力包括執行必要的轉換與商業邏輯，以滿足業務需求。
- 評估每個系統在資料傳輸前、傳輸中及傳輸後能做什麼。
- 考慮來源資料的複雜性、轉換需求及目標系統處理。
例如，將帶有儲存程序的 SQL 視圖匯出到 Dataverse，可能需要在中程調整及抵達後執行外掛。
能力利害關係人
系統管理員提供關於系統功能的見解。 與集中式或去中心化的 IT 團隊互動，驗證假設。
- 在選擇整合模式前，先評估每個系統。
- 確認技術能力是否符合業務期望。
把它全部整合起來
有效的整合設計始於理解三個核心組成部分。 總結：
- 音量和頻率 決定了傳輸多少資料以及傳輸頻率。 這些指標影響工具選擇、效能期望與可擴展性規劃。
- 方向性 則是識別資料的來源與目的地。 它有助於判斷資料如何在系統間流動，並確保符合安全與法規要求。
- 能力 衡量每個系統傳送、接收及處理資料的能力。 它凸顯效能限制，並協助識別整合過程中的潛在瓶頸。
每個元件都直接對應到初始業務需求。 與利害關係人共同分析，量、頻率、方向性及能力如何影響整體整合流程。
利害關係人合作在分析過程中至關重要。 他們的意見能重塑整合方式。
- 流程負責人 提供初步業務需求。
- 基礎設施架構師與資安人員確保 合規與安全連線。
- 系統管理員評估 系統能力與限制。
範例案例
讓我們用一個例子來串聯一切。 想像一下，商業需求是建立一個整合流程，讓外部客戶與內部服務工程師之間的案件資訊保持同步。 客戶可以透過網站為案件添加評論，而工程師則可以透過 Power App 新增案件資訊。
請求音量與觸發頻率
音量和頻率決定系統傳輸多少資料以及傳輸頻率。 在此情境下，客戶主要主導案件創建，因此數量取決於公司服務的客戶數量及預期的成長軌跡。
更新總量可計算為：
[Customers] × [Cases per customer] × [Average updates per case]
將這個數字在圖表上視覺化，展示它隨時間的成長。 例如，如果你一開始每年有 1,000 萬次更新，並預期每年增加 20%，圖表上應該會顯示更新數量逐年穩定增加。
利用歷史數據和成長預測來估算未來負荷。 例如，若系統目前每年處理 1,000 萬次更新，且每年成長 20%，則整合必須在五年內每年支援 2,500 萬次更新。
頻率分析顯示每月有高峰。 如果目前需求是每月320萬件，未來需求可能會達到800萬件。 設計整合以符合這些效能門檻。
為確保整合在典型的五年投資報酬率（ROI）期間內持續有效，設計解決方案時應支援每年至少 2,500 萬筆請求。 這種容量規劃考量了預期的成長，並幫助解決方案在業務需求演變時保持可擴展性與可靠性。
頻率部分是指相關系統在一年內處理資訊的能力。 同樣地，我們可以繪製歷史數據來理解頻率如何適用。
方向性與資料流
方向性定義了系統間資料的流動。 此情境包含四種不同的資料流：
- 從網站提供資料流，用來將案件更新寫入 Dataverse
- 另一個用於網站從 Dataverse 讀取更新的串流
- 第三個資料流是工程師從 Power App 平台撰寫更新至 Dataverse
- 最後的資料流，用於在「Power App」中讀取更新
此圖展示了直接整合模式，顯示資料如何透過四條不同的資料流在網站、Dataverse 與 Power App 之間流動：
了解這些流程有助於你配置安全且高效的整合。 根據系統能力與效能需求，使用直接或解耦模式。
實際作戰能力
在這個整合範例中，內建連接器簡化了流程。 從 Dataverse 取得案件資訊時，請套用篩選器並設定請求限制，以優化資料檢索，並只在應用程式中顯示必要的資料。 使用 Power Automate HTTP 觸發器 發佈端點，以啟用網站上的資料讀寫功能。 評估 Power Automate 流程與 Dataverse 的容量，確保它們能支援預期負載。 檢視自動化、排程及即時流程的限制，以避免超出平台限制。
使用 Dataverse Analytics 來監控目前的使用情況。 如果 Dataverse 接近預期的請求負載，可以考慮加入一個保護緩衝區，例如 Azure Data Lake。
下圖展示了解耦讀取模式，即在 Dataverse 和網站之間引入 Data Lake，用以減輕讀取流量的負擔並提升擴展性：
此策略有助於降低 Dataverse 的讀取量並防止限速錯誤（例如 HTTP 429 請求過多）。
為了進一步降低依賴，可以使用像 Azure Service Bus 這樣的佇列服務，將建立與更新請求從網站中解耦。
此圖顯示了完全解耦的整合模式，讀寫皆透過資料湖與隊列卸載，以最大化可靠性並保護 Dataverse 免受需求激增的影響：
設計雲端流程以處理錯誤、實作重試邏輯，並遵循最佳 可靠性實務 。 選擇整合模式時，優先選擇以最小複雜度滿足業務需求的解決方案。 在技術能力與成本、授權及維護需求之間取得平衡。 選擇最簡單、既符合需求又避免不必要的投資的方法。
後續步驟
探索常見模式，將需求分析轉化為實用且可擴展的整合架構。
相關資源
- 什麼是適用於 Dataverse 的 Azure Synapse Link？
- 為 HTTP 請求觸發加入 OAuth 認證
- 自動化、排程與即時流程的限制
- 檢視和下載 Microsoft Dataverse 分析
- Create an Azure Synapse Link for Dataverse with Azure Data Lake
- 服務匯流排佇列、主題和訂用帳戶