共用方式為

優化需要複雜商業邏輯的 canvas 應用程式效能

隨著組織越來越依賴 Power Platform 來打造可擴展且以數據驅動的應用程式，選擇合適的商業邏輯實作方法變得至關重要。 此參考架構提供兩種選項——Power Fx 函式與 Dataverse 自訂 API，以優化 Power Apps 畫布應用程式的效能與維護性。

Scenario

預設情況下，當應用程式查詢資料或執行多次修改時，會將個別的 HTTP 網路請求傳送給 Dataverse。 Dataverse 將資料回傳給應用程式，應用程式邏輯則會處理這些資料。

這種實作模式會造成等待時間，特別是當應用程式同時發送多個請求時，例如在 ForAll 函式中。 等待時間會負面影響效能與使用者體驗。 例如，若應用程式在 ForAll 迴圈中多次擷取與轉換資料，整體等待時間可能變得相當長，導致使用者體驗緩慢且效率低下。

為了優化資料互動，請透過使用 Dataverse 自訂 API 或 Power Fx 函式，將邏輯與資料檢索操作從畫布應用程式轉移到 Dataverse。 資料修改操作會在交易中完成，確保發生錯誤時資料的一致性。

小提示

本文提供一個範例情境及一個通用架構範例，說明使用 Dataverse 的畫布應用程式如何將複雜的商業邏輯轉移至 Dataverse 的自訂 API 與 Power Fx 函式，以提升效能。 你可以針對許多不同情境和產業修改架構範例。

架構圖

在此圖中，Power Fx 函式用於將複雜的商業邏輯從畫布應用程式轉移到 Dataverse。 你也可以使用 Dataverse 自訂 API 來達成相同的效果。 請參考 建議 以協助決定使用哪種選項。

架構圖示，展示使用 canvas 應用程式內建功能進行資料操作與使用 Power FX 函式的差異。

Workflow

  1. Power Apps 畫布應用程式使用 Dataverse 來管理資源分配。 該應用程式使用 Power Fx 函式（Dataverse 自訂 API 也能達到相同目的）來處理大量資料運算，而非直接使用內建存取功能。 該應用程式仍使用內建的 Dataverse 功能，用於較低流量的資料操作與不需交易支援的任務。

  2. Power Fx 函式（搭配 Dataverse 自訂 API）被設定為從呼叫應用程式傳遞輸入參數，並透過定義的輸出參數接收函式（或 API）的結果（回應參數）。 對：

    • Power FX 功能（預覽）： 在 Power Apps Studio 中實作邏輯。 透過使用 Power Fx 函數，創作者能在幾乎沒有編碼經驗的情況下構建複雜的邏輯。 了解更多關於 Power FX 函數。

    • Dataverse 自訂 API： 透過建立 Dataverse 的 .NET 外掛來實作邏輯。 自訂的 .NET 外掛需要更多程式設計知識，但能提供更高的控制與擴充性。 在 Dataverse 自訂 API 中了解更多。

使用案例細節

Power Apps 讓組織能夠打造客製化的使用者體驗並集中管理業務邏輯。 透過使用 Power Apps，您可以實現更有效率的資料架構，並降低客戶端的工作負載。

以下範例中，Power Apps 畫布應用程式幫助創作者有效分配資源給團隊與任務。 你可以將此架構模式應用於類似情境，當畫布應用程式包含資料操作並要求：

  • Canvas App 裡有多個迴圈，這是用 Concurrent function 功能無法實現的。
  • 多重資料轉換需進行密集計算。
  • 執行時間一致，與迴圈中項目數量或使用者的網路連線無關。
  • 在多次資料修改操作中保持資料一致性。

為了分配資源，製作者需要指定分配的位置、任務、子任務及其他相關的分配元資料。 在畫布應用程式中，「資源概覽」畫面顯示多層次相關的資料，例如：

  • 資源
    • 位置
      • 任務
        • 子任務
          • 批准

為了達成這個目標，你可以透過使用 Power Fx 來實作應用程式邏輯，方法如下：

ForAll(Resources,
    //Transformations
    ForAll(Location,
        //Transformations...
        ForAll(Tasks,
            //Transformations ...
        )
    )
)

此邏輯在應用程式執行時會產生多個 HTTP 呼叫給 Dataverse。 雖然最佳做法是將資料整合到Dataverse視圖中，或使用並行函式或其他Power Fx技術，但這種方法並不總是可行，或無法達成效能目標。

為了解決這個問題，可以透過將資料轉換（資料處理和所需結果）整合到單一回應中來消除 canvas app 的多次 HTTP 呼叫。 此方法縮短資料檢索等待時間，提升 Canvas 應用程式的整體效能，並提供更流暢且反應靈敏的使用者體驗。 透過集中資料轉換邏輯，確保伺服器端處理一致且高效，使解決方案能擴展大量資料與複雜轉換。

選項

Dataverse 的自訂 API 與 Power Fx 功能都擴展了 Dataverse 的商業邏輯。

Power Fx 函式

Power Fx 函式會抽象 Dataverse 的自訂 API 功能，你可以用 Power Fx 來做邏輯。

Power Fx 功能擴展了 Dataverse 的商業邏輯，並可隨時從 Power Platform 元件如 Power Apps 畫布應用程式、Power Automate 流程，以及使用 Microsoft Copilot Studio 建立的自訂代理程式中呼叫。 此功能支援更基礎的邏輯實作，且不需使用完整的 Dataverse 自訂 API 功能。

Dataverse 自訂 API

Dataverse 外掛是一種自訂事件處理程式，會根據特定事件執行。 以 Dataverse 自訂 API 為例，當你定義 API 時，應用程式會產生一個自訂事件，當應用程式使用 API 時會觸發這個事件。 你將這些外掛作為自訂類別實作，編譯成 .NET Framework 組合語言，然後上傳並在 Dataverse 中註冊。

外掛程式擴充了 Dataverse 的商業邏輯，讓開發者能撰寫自訂程式碼，在特定事件發生時執行，例如建立、更新或刪除紀錄，或透過自訂 API 直接呼叫。 此功能支援在 Power Platform 內實作更複雜且量身打造的業務流程，促進與 canvas 應用程式或 Power Automate 的完整整合。

透過同時使用 Power Fx 函式與 Dataverse 自訂 API，製作者可直接在公式中呼叫函式動作，支援綁定與非綁定動作。 他們也可以在應用程式中新增 Power Fx 環境語言物件，讓使用者能夠存取函式。 透過使用 Dataverse 自訂 API，製作者可以處理輸入與輸出的未類型物件欄位。

Recommendations

Power Fx 函式與 Dataverse 自訂 API 皆能完成交易中的資料修改操作。

如果您的使用情境符合以下條件，請選擇 Power Fx 功能 ：

  • 你的邏輯 不算太複雜 ，可以用 Power Fx 來表達。
  • 你要 授權創作者 （非開發者）來建立和維護邏輯。
  • 你偏好能無縫整合 Power Apps 入口的 低程式碼方法 。
  • 你需要交易 一致性 ，但不需要進階的 .NET 功能。
  • 你想要 集中邏輯 ，方便跨應用程式和流程重複使用，且不必涉及 .NET 開發者。

欲了解更多，請參閱 Microsoft Dataverse 的函數（預覽版）。

如果您的使用情境需要以下內容， 請選擇 Dataverse 的自訂 API ：

  • 複雜的商業邏輯 是 Power Fx 無法表達的。
  • 進階功能 如自訂錯誤處理、遙測及與外部系統整合。
  • .NET 開發專業知識在您的工作流程中是可用且可接受的。
  • 對執行流程的完全控制，包括外掛註冊與監控。
  • 遙測和診斷，例如用於健康情況追蹤的 Application Insights。

在 「建立與使用自訂 API」中了解更多。

如果你的目標是簡化 Canvas 應用程式的效能，同時讓解決方案對開發者保持可存取與維護，Power Fx 功能是更好的選擇。 如果你正在打造一個關鍵任務、高度客製化的後端，可以考慮 Dataverse 的自訂 API。

Alternatives

另一種做法是將資料操作與邏輯轉移到 REST API，然後實作自訂連接器，讓操作能從 Power Apps 使用。 此方法的差異在於邏輯與資料操作的執行地點。 在這種情況下，它們會執行在實作 REST API 的運算資源中，例如 Azure 函式。

由於這些操作不在 Dataverse 執行時沙盒中執行，資料操作比用戶端快，但比 Dataverse 執行的慢。 同樣地，這個邏輯也不會在 Dataverse 交易的脈絡中運作。 除非採取特殊步驟，否則每個資料操作都是獨立的，不會作為交易單元完成。

了解更多關於 使用 REST API 來擴充畫布應用程式的功能。

考慮事項

這些考慮會實施 Power Platform Well-Architected 的核心支柱，也就是一組能夠改善工作負載品質的指導原則。 在 Microsoft Power Platform Well-Architected 中深入瞭解。

Reliability

設計你的工作量以避免不必要的複雜性：將資料操作與邏輯從 Canvas 應用程式轉移，可以避免應用程式不必要的複雜性。 這種方法也集中邏輯，讓組織內其他應用程式都能使用。 此外，Power Apps 開發者能在不增加複雜度的情況下，從效能提升中受益。

測試韌性與可用性：將邏輯從 canvas 應用程式移至 Dataverse 自訂 API 或 Power FX 函式，能讓你獨立測試 API 或功能。

測量並發布健康指標（Dataverse 自訂 API）：Dataverse 自訂 API 透過 .NET 外掛提供進階監控與遙測。 為確保追蹤能力，建議使用 應用洞察 記錄。

卓越營運

採用安全部署措施：透過自動化部署流程（如管線）標準化 Power Apps 應用程式變更的部署。 僅在測試變更後，才將應用程式提升到生產環境。 作為解決方案元件，Dataverse 的自訂 API 與 Power Fx 函式會在同一個 Dataverse 解決方案中與應用程式一同部署。 這種方法能降低環境中元件不同步的風險。

實施部署失敗緩解策略：當你同時部署應用程式與 Dataverse 自訂 API 或 Power Fx 函式時，緩解策略會簡化，因為它遵循與應用程式相同的回滾或修復策略。

效能效率

設計符合效能需求：評估解決方案的效能與資料量需求。 檢視你的應用程式如何存取資料，以及使用 Power Apps 使用不同資料來源是否會因每個資料庫發送的個別請求延遲而降低效能。 舉例來說，如果你的應用程式邏輯跨越資料來源的多列，你可能能將所有網路流量轉移到自訂的 API 或函式。 將與自訂 API 或函式的單一互動簡化，並由其處理與 Dataverse 的通訊，使操作更有效率。

優化邏輯（Dataverse 自訂 API）： 隨著 canvas 應用程式的邏輯變得越來越複雜，Dataverse 的自訂 API 能讓你將這些邏輯卸載到集中且可重複使用的服務中。

測試效能：除了測試功能與故障外，還要測試並建立效能基準。 如果 Dataverse 自訂 API 或 Power Fx 函數對工作完成時間的變化很敏感，請在發佈週期中評估此基準。

貢獻者們

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

  • Last updated on