將多客戶應用程式移轉至服務主體設定檔模型

本文說明如何將 Power BI 內嵌式分析多客戶應用程式移轉至服務主體配置檔模型，改善可擴縮性。

服務主體設定檔讓您更輕鬆管理 Power BI 中的組織內容，並提高使用容量的效率。

注意

本文鎖定的組織已經有一個應用程式，可支援來自單一 Power BI 租用戶的多個客戶。

未必所有應用程式都受益於服務主體模型。 例如，下列應用程式不應移轉：

• 維護一個服務主體且物件少的小型應用程式。
• 每個客戶使用一個多個服務主體的應用程式

必要條件

開始移轉之前，請務必先閱讀服務主體設定檔。

您也必須執行下列步驟：

• 依照使用服務主體內嵌 Power BI 內容前三個步驟設定服務主體。
• 從 Power BI 租用戶系統管理員帳戶，啟用在租用戶建立設定檔。

移轉至服務主體設定檔

移轉至服務主體設定檔的過程包含下列步驟：

1. 建立設定檔，每個客戶一個設定檔。
2. 整理工作區。
3. 將應用程式程式碼變更為使用設定檔。
4. 使用設定檔模型測試應用程式。
5. 清理備援權限。

建立設定檔 (必要)

使用設定檔 REST API 搭配您建立的服務主體，為每個客戶建立一個設定檔。

不妨在資料庫儲存每個資料客戶識別碼及其相應設定檔識別碼的對應。 稍後需要此對應，才能使用租用戶設定檔進行 API 呼叫。

最佳化您的工作區

管理資料最簡單的方式是維持每個客戶一個工作區。 如果應用程式已經使用此模型，您就不必建立新的工作區。 不過，您仍必須使用 [新增群組使用者 API]，為每個設定檔提供相應工作區的系統管理員存取權。

如果並非每個客戶都有一個工作區，請使用相應的設定檔呼叫建立群組使用者 API，為每個客戶建立新工作區。

在工作區整理項目

現在每個客戶應該都有一個設定檔和一個工作區了。 如果您已經在上一個步驟建立新工作區，必須將項目 (例如報表和語意模型) 匯入這些工作區。 您匯入的語意模型取決於目前的解決方案：

• 如果應用程式針對每個客戶使用不同的語意模型，語意模型設計可正常運作。

• 如果應用程式使用一個有資料列層級安全性 (RLS) 的語意模型，為不同客戶提供不同的資料，為每個客戶建立個別的語意模型，並使用本文所述的設定檔，即可改善可擴縮性。

• 使用設定檔和個別資料來源克服可擴縮性限制之後，使用 RLS 搭配設定檔即可獲得更多資料分隔。

  • 如果您仰賴 Dynamic RLS，則會在 DAX 函數 UserName() 傳回設定檔名稱。
  • 如果在產生內嵌權杖時使用靜態 RLS 並覆寫角色，您可以繼續這樣做。

項目準備就緒後，請將它們匯入相關的工作區。 若要將流程自動化，請考慮使用匯入 API。

將應用程式程式碼變更為使用設定檔

一旦擁有具有相關工作區系統管理員存取權的設定檔，以及具有顯示哪個設定檔代表哪個客戶之對應的資料庫，您便可進行必要的程式碼變更。 建議您讓兩個程式碼流程並排，並逐漸向客戶公開設定檔程式碼流程。

進行下列程式碼變更：

• 授權碼變更

  • 如果您在 Microsoft Entra ID 應用程式使用主要使用者，請變更取得權杖程式碼。 閱讀使用服務主體內嵌，了解如何建立僅限應用程式的 Microsoft Entra 權杖。
  • 如果您使用服務主體，而且已為設定檔建立新的主體，請調整程式碼，使用正確的服務主體識別碼和密碼。

• 管理程式碼變更

  部分應用程式有管理程式碼，會自動在註冊時將新客戶上線。 管理程式碼通常使用 Power BI REST API 建立工作區及匯入內容。 此程式碼多半應該維持不變，但您可能必須調整下列詳細資料：

  • 每次建立新的客戶租用戶時，請建立新的服務設定檔，成為該租用戶工作區的建立者和系統管理員。
  • 如果您決定重新整理 Power BI 內容，請編輯程式碼以反映變更。

• 內嵌權杖程式碼變更

  取代 API 呼叫者。 請確定設定檔會呼叫 GenerateToken API，因為在設定檔模型，只有特定設定檔可以存取客戶的內容。

Validate

最佳做法是徹底測試應用程式，再將其移至設定檔模型。 即使 SaaS 應用程式程式碼有 Bug，報表仍可能載入，因為您並未刪除工作區較舊的權限。

移轉之後的清理

既然您已完成移轉並驗證結果，請移除不再需要的內容。

• 清理程式碼：不妨停用舊的程式碼路徑，確保只執行仰賴設定檔的新程式碼。
• 清除 Power BI 中的工作區和權限：如果您已建立新工作區，可以刪除不再使用的舊工作區。 如果重複使用相同的工作區，不妨刪除工作區較舊的權限 (例如主要使用者權限)。

相關內容

管理服務主體設定檔

更多問題嗎？ 嘗試在 Power BI 社群提問