Power BI Paginated Report：本番環境由客戶管理時，RDL 的接続先應該怎麼處理？

| 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/1394

在使用 Power BI Paginated Report（RDL）進行系統開發時，經常會遇到這樣的情況：

  • 開發側只能操作 DEV／SANDBOX 環境
  • 本番環境完全由客戶側管理
  • 開發側無法登入或操作本番 Workspace
  • 本番 Dataverse／資料庫的實際接続先不會提供給開發側
  • 最終由客戶側負責將 RDL 部署到本番環境

這時就會產生一個問題：

正式納品的 RDL 中，Datasource 的 Server 到底應該填什麼？

另外，如果存在數十份 RDL，究竟應該使用 Power BI REST API 批量修改，還是直接修改 RDL 檔案本身？

一、RDL 本身仍然包含 Datasource 定義

Power BI Paginated Report 使用 embedded data source 時，Datasource 是 RDL 報表定義的一部分。

其中通常會包含：

  • Data source type
  • Connection information
  • Connection string
  • Datasource name

例如：

Data Source=xxx.crm.dynamics.com,5558;
Initial Catalog=xxx;

因此，不能簡單理解成：

RDL 完全不記錄接続先
↓
上傳 Power BI
↓
Power BI Service 自動幫忙補上 Server

RDL 本身仍然需要保留 Datasource／Connection String 的定義。

但是「需要有 Connection String」並不等於「一定要寫入真實的本番 Server」。

二、正式納品的 RDL 不需要包含真實本番 Server

如果本番環境完全由客戶側管理，而且開發側根本不知道本番 Dataverse Endpoint，那麼正式納品時可以直接使用 Placeholder。

例如：

Data Source=__PROD_DATAVERSE_TDS_SERVER__;
Initial Catalog=__PROD_DATAVERSE_DATABASE__;

這裡的：

__PROD_DATAVERSE_TDS_SERVER__

並不是 Power BI 的特殊變數。

它只是一段普通文字，用來作為部署時的替換標記。

真正部署時，由客戶側將它替換成本番環境的實際值：

納品時：

Data Source=__PROD_DATAVERSE_TDS_SERVER__;

↓ 客戶側部署

Data Source=xxxxx.crm.dynamics.com,5558;
注意：
Placeholder 尚未被替換之前，該 RDL 當然無法正常連線。它的用途不是讓 Power BI 自動解析，而是明確表示「此處需要在部署本番時設定」。

三、為什麼不建議直接保留 DEV／SANDBOX 的 Server？

技術上，可以直接將目前使用中的 DEV／SANDBOX Connection String 保留在 RDL 中，再交付給客戶。

例如：

Data Source=sandbox-example.crm.dynamics.com,5558;

然後告知客戶：

部署本番之前請記得修改。

但正式納品時不太推薦這種方式。

因為它存在非常直接的誤操作風險：

納品 RDL
↓
仍保留 SANDBOX Server
↓
部署人員忘記修改
↓
直接 Upload

即使最後因為 Credential 或 Permission 問題無法真正連線，正式本番報表中殘留開發環境的接続先，本身也不理想。

因此，更推薦使用一眼就能看出「尚未完成本番設定」的 Placeholder。

例如：

__PROD_DATAVERSE_TDS_SERVER__
__PROD_DATAVERSE_DATABASE__

四、正式納品時：直接修改 RDL，還是使用 REST API？

Power BI REST API 可以修改已經發布到 Workspace 中的 Paginated Report Datasource。

例如：

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

因此理論上也可以採用：

Upload RDL
↓
取得 Report ID
↓
呼叫 UpdateDatasources API
↓
修改 Server / Database

這種方式本身沒有問題。

但是一旦 RDL 數量很多，就要額外管理：

  • API Authentication
  • API Permission
  • Workspace ID
  • Report ID
  • Datasource Name
  • HTTP Response
  • API Error
  • Retry
  • 部分成功、部分失敗
  • 修改後驗證

例如：

Report 01 → Success
Report 02 → Success
Report 03 → Success
...
Report 38 → Failed
Report 39 → Success
...

這時還需要進一步判斷：

  • 為什麼失敗？
  • 需要 Retry 嗎？
  • Datasource Name 是否一致？
  • 是不是 Permission 問題？
  • 是不是 Report ID 對應錯誤？
API 的問題不是「做不到」，而是它會額外引入一層 Deployment State Management。

五、本番完全由客戶管理時，直接修改 RDL 反而更簡單

如果前提是：

開發側完全不能操作本番，正式部署全部由客戶側完成。

那麼直接修改 RDL 通常更加自然。

因為 RDL 本身就是 XML，Connection String 本質上也是文字內容。

因此，可以統一納品：

Data Source=__PROD_DATAVERSE_TDS_SERVER__;
Initial Catalog=__PROD_DATAVERSE_DATABASE__;

然後提供一個簡單的部署腳本：

.\Set-RdlConnection.ps1 `
    -Server "本番 Server" `
    -Database "本番 Database"

客戶側只需要輸入自己掌握的本番資訊。

腳本執行：

搜尋所有 *.rdl
↓
替換 __PROD_DATAVERSE_TDS_SERVER__
↓
替換 __PROD_DATAVERSE_DATABASE__
↓
確認替換件數
↓
確認 Placeholder 是否殘留
↓
Upload 到 Power BI Workspace

這個流程完全不需要：

  • Report ID
  • OAuth Token
  • Power BI REST API Permission
  • Datasource Owner
  • API Retry
核心結論
如果本番完全由客戶側操作，Placeholder RDL ＋ 部署前批量替換，通常比為了修改 Connection String 特地導入 Power BI REST API 更簡單。

六、批量修改 RDL 的另一個優點：容易驗證

本地批量處理之後，可以很容易輸出檢查結果。

例如：

RDL files found       : 70+
Server replaced       : 70+
Database replaced     : 70+
Remaining placeholders: 0
Errors                 : 0

還可以再次全文搜尋：

__PROD_DATAVERSE_TDS_SERVER__

如果結果為：

0 files

就可以很直觀地確認所有 Placeholder 都已被替換。

相比之下，如果走 REST API，還需要確認每一個 HTTP Request 是否成功。

七、推薦的角色分工

開發側

負責：

  • RDL Layout
  • Dataset
  • Query
  • Parameter
  • Datasource Type
  • Datasource Name
  • Placeholder Connection String
  • 部署／替換腳本

正式納品：

Data Source=__PROD_DATAVERSE_TDS_SERVER__;
Initial Catalog=__PROD_DATAVERSE_DATABASE__;

客戶側

負責：

  • 本番 Dataverse Endpoint
  • 本番 Database／Catalog
  • 本番 Workspace
  • Cloud Connection
  • Credentials
  • Power BI Permission
  • RDL Upload
  • 本番動作確認

這樣一來，開發側完全不需要知道本番環境的 Connection Information。

八、推薦的 Deployment Flow

DEV / SANDBOX
      ↓
開發完成 RDL
      ↓
納品前改成 Placeholder
      ↓
正式納品
      ↓
客戶側執行 Connection 替換腳本
      ↓
Placeholder
→ PROD Server / Database
      ↓
Upload Power BI Workspace
      ↓
設定 Cloud Connection / Credential
      ↓
測試 Report
最大的優點：
開發側不需要取得任何本番環境資訊，也不需要取得操作本番 Workspace 的權限。

九、那麼 UpdateDatasources API 什麼時候比較適合？

REST API 並不是沒有價值。

它非常適合：

  • DEV → TEST → SANDBOX 自動部署
  • 同一個開發團隊管理多個 Workspace
  • CI/CD Pipeline
  • 已經 Upload 的大量 RDL 需要切換 Datasource
  • Deployment Pipeline 本身已經具有 Power BI API 權限

例如：

Publish RDL
↓
取得 Report ID
↓
UpdateDatasources
↓
Validate Datasource

在由同一個團隊完整控制 Workspace 的情況下，API 自動化非常方便。

但如果：

本番環境完全由客戶管理，而且開發側沒有操作權限。

那麼單純為了修改 Connection String，而要求客戶額外準備 API Authentication、Permission、Report ID 等資訊，反而可能把簡單的事情變複雜。

十、最終結論

推薦方案
RDL
↓
使用明確的 Connection Placeholder
↓
正式納品
↓
客戶側部署前批量替換
↓
Upload

例如：

Data Source=__PROD_DATAVERSE_TDS_SERVER__;
Initial Catalog=__PROD_DATAVERSE_DATABASE__;

這些 Placeholder：

  • 不需要是真實 Server
  • 不需要可以連線
  • 不會被 Power BI 自動解析
  • 只是部署時用來批量替換的標記

而 Power BI REST API 的 UpdateDatasources 更適合作為 CI/CD 或 Workspace 自動化工具，而不是在客戶完全掌握本番環境的情況下，強行加入正式納品流程。

能在部署前安全、確實地修改 RDL，就沒有必要單純為了修改接続先而額外導入 Power BI REST API。

對大量 RDL 而言，使用 Placeholder ＋ 批量 XML 替換腳本，是一種簡單、容易驗證，而且能明確區分開發側與本番管理側責任的方式。

官方參考資料

This article was last edited at