Power BI Paginated Report：為什麼在 Manage 頁面無法更換 RDL 的連線 Server？

| PowerPlatform | 1 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1392

Power BI Paginated Report：為什麼在 Manage 頁面無法更換 RDL 的連線 Server？

在 Power BI Service 中管理 Paginated Report（RDL）時，我們可以在 「Gateway and cloud connections」 頁面看到「Maps to／マップ先」下拉選單。

這很容易讓人產生一個疑問： 既然可以切換雲端連線，是否也能藉此將報表從 Sandbox Dataverse 改連到 DEV Dataverse？

核心結論：
Power BI 網頁中的「Maps to／マップ先」只能更換 雲端連線與認證， 不能修改 RDL 資料來源中的 Server 與 Database。

一、RDL 資料來源與雲端連線是兩個不同層次

一份 Paginated Report 的資料連線大致可分成以下兩層：

第一層：RDL 的資料來源定義

  • 資料來源名稱（Datasource Name）
  • 資料來源類型，例如 SQL／SQLAZURE
  • Server
  • Database／Initial Catalog
  • 其他 Connection String 設定

第二層：Power BI Service 的雲端連線

  • OAuth、Basic 或其他認證方式
  • 認證帳號
  • 個人雲端連線或共用雲端連線
  • 哪些使用者有權使用該連線

因此，雲端連線並不是 RDL Connection String 的替代品。 它主要負責為 RDL 已經指定的資料來源提供 認證與連線管理。

二、為什麼「Maps to」不能切換 Dataverse 環境？

假設 RDL 中的 Connection String 是：

Data Source=org-sandbox.crm7.dynamics.com,5558;
Initial Catalog=sandbox_database;
Encrypt=True;
TrustServerCertificate=False;

即使在 Power BI Service 中選擇了一個名為 DEV_Dataverse_Connection 的雲端連線，也不代表 RDL 中的 Server 會自動變成：

org-dev.crm7.dynamics.com,5558
注意： 「Maps to」是在為既有的 datasource 選擇連線物件， 並不會重寫 RDL 中的 Connection String。

三、真正更換 Server／Database 的三種操作

操作方式 能否修改 Server／Database 本質
Power BI 網頁 Manage 頁面 不能 只切換雲端連線和認證
Power BI Report Builder 可以 修改 RDL 的 ConnectString，再重新發布
Power BI REST API 可以 更新 workspace 中已發布 RDL 的 datasource

方法一：使用 Report Builder 修改 RDL

Report Builder 雖然提供圖形化操作介面，但本質仍然是在修改 RDL。 應將舊的 Server／Database 明確替換成新的值：

修改前：
Data Source=org-sandbox.crm7.dynamics.com,5558;
Initial Catalog=sandbox_database;

修改後：
Data Source=org-dev.crm7.dynamics.com,5558;
Initial Catalog=dev_database;

不能將 Server 或 Database 留空， 再期待 Power BI Service 的雲端連線自動填入。 留空只會形成不完整或無效的資料來源定義。

方法二：使用 Power BI REST API

Power BI 提供專門用於 Paginated Report 的 API， 可以直接修改 workspace 中已發布報表的 datasource：

POST /groups/{workspaceId}/reports/{reportId}/Default.UpdateDatasources

請求內容的概念如下：

{
  "updateDetails": [
    {
      "datasourceName": "DataverseTDS",
      "connectionDetails": {
        "server": "org-dev.crm7.dynamics.com,5558",
        "database": "dev_database"
      }
    }
  ]
}

這個 API 不只適合批量處理，也可以只修改 一份 RDL 中的一個 datasource。

  • 一份 RDL、一個 datasource： 一次 API 呼叫
  • 一份 RDL、多個 datasource： 在同一個 updateDetails 中放入多筆資料
  • 多份 RDL： 使用 PowerShell、Fabric CLI 或其他程式逐份呼叫 API

方法三：部署後再映射正確的雲端連線

無論透過 Report Builder 還是 REST API 修改 datasource， 完成後仍應在 Power BI Service 中將報表映射到對應環境的雲端連線。

正確順序：
更新 RDL datasource 的 Server／Database → 建立或確認對應環境的雲端連線 → 在「Maps to」中完成映射 → 測試報表

四、API 修改後，本機 RDL 不會自動同步

REST API 修改的是 workspace 中已發布的 Paginated Report。 它不會同步修改開發者電腦或原始碼版本庫中的 `.rdl` 檔案。

版本管理風險：
如果本機 RDL 仍保留舊 Server，日後重新發布這份 RDL 時， 舊的 datasource 設定可能再次被帶回 workspace。

因此，REST API 很適合部署自動化，但 本機 RDL 仍應作為需要妥善管理的原始定義。

五、建議的 DEV／SANDBOX／PROD 管理方式

  1. 將 RDL 納入 Git 或其他版本管理。
  2. 確保不同 Dataverse 環境具有相同的必要資料表、欄位及 schema。
  3. 將 RDL 發布到目標 workspace。
  4. 部署後透過 REST API 設定該環境的 Server／Database。
  5. 將報表映射到該環境對應的雲端連線。
  6. 使用 API 再次讀取 datasource，確認 Server／Database 是否正確。

這種方式能讓同一套 RDL 在 DEV、 SANDBOX 和 PROD 之間部署，而不必每次手動打開 XML 修改。

六、使用 UpdateDatasources API 的限制

  • 只支援 Paginated Report。
  • 新舊資料來源必須具有完全相同的 schema。
  • 不能透過此 API 改變資料來源類型。
  • 不支援 ODBC 資料來源。
  • 操作者必須是資料來源擁有者。
  • 需要 Reports.ReadWrite.All 權限。

最終整理

  • Power BI 網頁 Manage 頁面： 只能切換連線和認證，不能修改 Server／Database。
  • Report Builder： 透過 UI 修改 RDL 的 ConnectString，再重新發布。
  • REST API： 直接更新 workspace 中已發布 Paginated Report 的 datasource。
  • 批量修改： 對多份 RDL 逐一呼叫 API 即可實現。
  • 版本管理： API 不會同步修改本機 RDL，必須避免後續發布舊設定。

官方參考資料

This article was last edited at