編輯

共用方式為

多個 Power Apps 實例之間的最終一致性

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

本文概述一個案例，假設美國客戶 Contoso 最近在歐洲收購了另一家總部位於歐洲的公司，並正在兩家公司之間建立 CRM 和 ERP 系統。 在此整合中，他們必須保持其 Dynamics 365 Dataverse 實體的一部分同步，直到可以完全整合為止。 Conotso 專屬的企業營運 （LOB） 應用程式會從兩個系統取用數據，而且必須在數據等候同步處理或遺失時接受要求。 下列指南說明如何考慮Power Platform實例之間的最終一致性。

建築

外掛程式/流程，以一律根據 GUID 或替代金鑰向上插入

圖表顯示 dataverse 外掛程式，提供解決方案給失敗的多系統同步處理。

下載此架構的 Visio 檔案。

工作流程

此解決方案可以使用外掛程式生命週期內的數個 外掛程式 步驟來建置。 當您建立的實體為必要時，請使用 PreValidation 步驟。 在啟動任何資料庫交易之前，PreValidation 發生。 如果欄位為必要，則為慣用的選項。 不過，在某些情況下，PreCreate 外掛程式步驟就已足夠。

  1. 美國實例 嘗試透過邏輯應用程式將新帳戶同步處理至 歐洲實例。 由於停機或升級，歐洲實例 無法連線。
  2. Contoso LOB 應用程式會從 US 實例讀取主要帳戶實體。 它打算提交 API 呼叫，參考未復寫至 歐洲實例的帳戶實體。 就目前情況來說，API 呼叫會失敗，因為記錄不存在，因為同步無法運作。
  3. 不過，PreValidation/PreCreate 外掛程式會先根據提供的實體 GUID 和提供的參考數據執行 upsert。 如果已經存在，則不會變更任何專案。 如果不存在，則會建立新的帳戶，其中大部分字段都是空白的。
  4. API 呼叫成功，因為具有指定標識符的帳戶存在於系統中。 外掛程式攔截了作業，並正常處理遺漏的記錄。 已成功產生 LOB 應用程式的報表。

注意

Microsoft建議您在自定義程式代碼中引進斷路器模式，以在參考任一實例時，在此解決方案中回復並重試，以處理平臺中斷。 如需使用斷路器的詳細資訊，請參閱 斷路器模式。

選擇

上述案例使用自定義邏輯應用程式作為複寫方法。 不過，在 Dataverse 實例之間復寫數據的方式有很多種，包括，但不限於：

  • Logic Apps
  • Azure Functions 中的函式應用程式
  • Azure Data Factory
  • Azure Synapse Analytics
  • Power Automate

案例詳細數據

組織偶爾會發現需要讓兩個或多個 Power Platform 實例保持同步，更具體來說，通常是 Dataverse 實體的子集。 當組織刻意新增地理隔離的新實例，但需要所有地理位置的通用數據集時，就會發生這項需求。 或者，當兩個組織在Power Platform合併完成之前合併時，就會發生此情況。

當同步處理程式如設計般運作時，從這兩個實例取用的企業營運應用程式沒有問題。 不過，同步機制絕不是錯誤證明、中斷或可能發生非預期的問題。 在此情況下，您必須建置從這兩個實例取用數據的企業營運應用程式，以處理不完整的數據。

為了讓 Contoso 的新歐洲子公司整合到 Contoso 的商業結構中，必須將帳戶和聯繫人從一個 Power Platform 實例同步至另一個實例。 在此案例中，美國 Power Platform 實例會透過自定義邏輯應用程式將每日參考數據批次同步至歐洲實例。 專屬的 Contoso LOB 應用程式會產生使用者所建立問題票證的報告。 若要完成這項工作，LOB 應用程式會從 Dataverse 實例讀取用戶數據，以提取相關數據、美國實例的主要參考索引鍵，以及來自歐洲實例的票證數據。 如果因為停機、維護或其他通訊問題而尚未完成同步處理程式，則要求會產生錯誤，因為歐洲實例缺少實體。

潛在的使用案例

此模式在下列情況下很有用：

  • 傳送參考數據的系統已關閉。
  • 數據的同步處理需要很長的時間或程序延遲。
  • 取用系統沒有建立實體的邏輯。

使用此方法的時機

在下列案例中使用此方法：

  • 您想要保證具有指定索引鍵的記錄存在，而且您並不在意記錄未完全凍結。
  • 您必須接受建立，即使數據仍未同步處理也一樣。

此模式可能不適用於下列案例：

  • 建立記錄時會套用邏輯。 因為數據不會凍結，所以依賴某些可用的屬性並不安全。

例子

下列範例顯示潛在的旅程圖和同步處理延遲的結果。

範例 1 - 沒有中斷或暫時性錯誤的成功路徑

顯示成功多系統同步處理的圖表。

下載此架構的 Visio 檔案。

  1. 美國實例 會透過邏輯應用程式，將新帳戶同步至 歐洲實例。 由於沒有發生暫時性錯誤或中斷，因此一切都無法運作。
  2. Contoso LOB 應用程式會從 美國實例 讀取主要帳戶實體，並打算提交 API 呼叫，參考複寫至 歐洲實例的帳戶實體。 因為一切都已啟動，而且不會發生任何中斷或暫時性錯誤，所以運作正常。 已成功產生 LOB 應用程式的報表。

範例 2 - 同步關閉或延遲的失敗路徑

顯示多系統同步處理失敗的圖表。

下載此架構的 Visio 檔案。

  1. 美國實例 嘗試透過邏輯應用程式將新帳戶同步處理至 歐洲實例。 由於停機、維護或其他通訊問題，歐洲實例 無法連線。
  2. Contoso LOB 應用程式會從 美國實例 讀取主要帳戶實體，並打算提交 API 呼叫，參考未復寫至 歐洲實例的帳戶實體。 API 呼叫失敗，因為未在 歐洲實例中建立具有指定標識符的帳戶 且不會產生報告。

考慮

請考慮任何商業規則對尚未凍結之實體的影響。 請考慮實體尚未完全凍結和同步處理的案例。 某些屬性會是 Null，因此您必須確定在使用此方法時，會考慮數據的任何決策。

後續步驟

相關架構：

Web 開發的指引：