編輯

多個 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 應用程式會從 美國實例讀取主要帳戶實體。 它想要提交 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 開發的指引：