Web 系統呼叫 Power BI RDL 產生 PDF，正式上線到底要買什麼？

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

最近在規劃一套帳票系統，預計讓使用者從 Web 頁面選擇帳票，按下按鈕後，由後端呼叫 Power BI REST API，執行 Paginated Report，也就是 RDL 報表，最後將產生的 PDF 回傳給瀏覽器。

整體流程大致如下：

使用者
  ↓
Azure Web App
  ↓
Service Principal
  ↓
Power BI REST API / ExportToFile
  ↓
執行 Fabric Capacity 內的 RDL
  ↓
產生 PDF
  ↓
回傳給瀏覽器

這種架構真正需要購買的核心，並不是替每一個 Web 使用者購買 Power BI 授權，而是：

Microsoft Fabric Capacity（F SKU）
＋
至少 1 個 Power BI Pro 帳號

一、正式環境需要哪些授權？

對於「Web 按鈕產生 PDF」這種使用方式，授權可以分成兩個部分：

要購買的項目 數量 用途
Microsoft Fabric Capacity，F SKU 1 個容量 承載 RDL，並讓正式環境可以持續使用 ExportToFile API
Power BI Pro 至少 1 個 供開發或管理人員發布、修改及管理 RDL
Web 使用者的 Power BI 授權 不需要 使用者只從 Web 系統取得 PDF，不直接登入 Power BI
Service Principal 授權 不需要購買 Service Principal 是程式身份，不是人類使用者帳號

最容易混淆的地方，是 Power BI Pro 和 Fabric Capacity 並不是同一種東西。

Power BI Pro 是給開發者或管理者操作 Power BI Service 使用的個人授權。

Fabric Capacity 則是提供報表運算、渲染以及 API 執行能力的伺服器容量。

可以簡單理解成：

Power BI Pro
＝人員操作權限

Fabric Capacity
＝系統運算資源

二、為什麼不能只買 Power BI Pro？

Power BI Pro 可以讓開發人員發布報表、管理 Workspace，以及在 Power BI Service 中查看和測試內容。

但如果正式 Web 系統需要透過 REST API 自動將 RDL 匯出為 PDF，僅有 Pro 帳號通常並不足夠。

被 ExportToFile API 匯出的報表，需要放在支援這類功能的容量型 Workspace 中，例如：

  • Microsoft Fabric Capacity

  • Power BI Premium Capacity

  • Power BI Embedded Capacity

因此，正式系統真正負責執行報表和產生 PDF 的，是 Workspace 背後的 Capacity，而不是 Pro 帳號本身。

三、需要替 20 個 Web 使用者購買 Power BI 嗎？

不需要。

在這套架構中，普通使用者並不會直接進入 Power BI Service。

他們只會：

登入公司 Web 系統
→ 選擇帳票
→ 按下輸出按鈕
→ 下載 PDF

真正呼叫 Power BI API 的，是 Web 後端使用的 Service Principal。

因此，即使系統有 20 個、50 個甚至更多使用者，只要他們不直接登入 Power BI 查看報表，就沒有必要替每個人購買 Power BI Pro 或 PPU。

這也是這種架構的重要優勢之一。

四、為什麼不建議用 PPU？

PPU，也就是 Power BI Premium Per User，是以使用者為單位購買的授權。

它比較適合特定使用者直接登入 Power BI Service，查看或使用進階功能。

但對於 Web 系統後端大量、自動地輸出 PDF，PPU 並不是理想方案。

尤其是 Paginated Report 的自動匯出，在 PPU 環境中可能受到較嚴格的頻率限制，不適合作為正式帳票系統的穩定後端。

如果有約 20 個系統使用者，替每個人購買 PPU 不但成本高，而且這些人實際上又不會直接使用 Power BI，授權利用率非常低。

所以這種情況更適合購買共用的 Fabric Capacity。

五、到底應該買 F2 還是 F4？

對於小型帳票系統，技術上的起點可以考慮 F2。

適合先使用 F2 的情況

例如：

  • 系統使用者約 20 人

  • 不會所有人同時輸出報表

  • RDL 查詢速度正常

  • 單張報表頁數不多

  • 每天只產生幾十份或幾百份 PDF

  • 沒有大規模批次輸出需求

這種情況可以先從以下配置開始：

Microsoft Fabric Capacity F2 × 1
Power BI Pro × 1

F2 已經是正式的付費 Fabric Capacity，可以用來承載 Paginated Report，並支援正式環境中的 API 執行。

適合直接使用 F4 的情況

如果正式環境可能出現以下情況，則可以考慮 F4：

  • 多名使用者同時點擊輸出

  • 單張 RDL 查詢或渲染負擔較重

  • 報表頁數很多

  • 需要連續產生多份 PDF

  • 有批次輸出功能

  • 希望正式環境效能接近目前的 Fabric 試用環境

目前 Fabric 試用容量如果顯示為 FTL4，代表測試環境大致使用 4 CU 的容量級別，和 F4 比較接近。

如果在試用環境中的 RDL 執行速度已經符合預期，而正式環境突然降低到 F2，報表的排隊、節流或產生時間可能會比測試時更明顯。

因此：

預算優先：先從 F2 開始

穩定性優先：直接選擇 F4

六、容量不足時會發生什麼？

Fabric Capacity 並不是「容量稍微不足，API 就永久不能使用」。

比較常見的情況是：

  • 報表開始排隊

  • PDF 產生時間變長

  • API 被暫時節流

  • 同時執行的工作互相競爭資源

  • 高峰時間的回應速度不穩定

因此，比較合理的做法不是一開始就購買很大的容量，而是：

先購買 F2
↓
使用實際 RDL 進行壓力測試
↓
模擬 3～5 人同時輸出
↓
觀察是否排隊或出現 throttling
↓
視情況升級至 F4 或 F8

Fabric F SKU 可以在 Azure 中調整容量大小，因此不需要一開始就永久決定只能使用某一個 SKU。

正式上線後，也可以透過 Fabric Capacity Metrics 觀察容量使用量、背景作業及互動式作業的負載，再決定是否升級。

七、為什麼不需要 F64？

F64 是一個分界非常明顯的容量級別。

它的重要價值之一，是讓沒有 Power BI Pro 授權的使用者，可以直接進入 Power BI Service，查看容量中的 Power BI 內容。

但目前的系統架構中，普通使用者根本不會進入 Power BI。

他們只是從公司 Web 系統取得 PDF。

因此，為了讓 Free 使用者直接瀏覽 Power BI 內容而購買 F64，對這個系統沒有實際意義。

簡單來說：

使用者直接登入 Power BI 看報表
→ 可能需要考慮 F64 或個人授權

使用者只從 Web 下載 PDF
→ 不需要為此購買 F64

對於只有約 20 名內部使用者的小型帳票系統，一開始購買 F64 通常會造成非常大的資源和成本浪費。

八、為什麼仍然需要至少一個 Power BI Pro？

即使已經購買 Fabric Capacity，開發和管理人員仍然需要操作 Power BI Service。

例如：

  • 使用 Power BI Report Builder 製作 RDL

  • 將 RDL 發布到 Workspace

  • 修改報表

  • 設定資料來源

  • 設定 Gateway 或連線資訊

  • 管理 Workspace 權限

  • 在 Power BI Service 中查看和測試報表

  • 確認 Report ID 和 Workspace ID

這些日常開發和管理工作，通常仍然需要 Power BI Pro 或 PPU。

理論上，部分發布和管理流程可以透過 Service Principal 與 REST API 自動化，但對於一般開發流程而言，保留一個 Pro 帳號最直接，也最容易維護。

因此，最基本的正式配置仍然是：

Fabric Capacity × 1
Power BI Pro × 1

九、Service Principal 需要購買授權嗎？

不需要。

Service Principal 是 Microsoft Entra ID 中的一種應用程式身份。

Web 後端可以使用以下資訊取得 Access Token：

  • Tenant ID

  • Client ID

  • Client Secret

取得 Token 後，再以程式身份呼叫 Power BI REST API。

Service Principal 不是一名真正的人類使用者，因此不需要另外購買 Power BI Pro 授權。

不過，它仍然需要：

  • 被允許使用 Power BI API

  • 加入對應的安全組

  • 在 Power BI 管理入口中開放相關設定

  • 被加入目標 Workspace

  • 擁有足夠的 Workspace 權限

所以不需要購買授權，不代表完全不需要設定權限。

十、試用版結束後，要不要重新建立所有東西？

通常不需要。

目前如果使用的是 Fabric 試用容量，正式購買 Fabric F SKU 後，可以將現有 Workspace 從試用容量切換到正式容量。

大致流程如下：

在 Azure 建立 Microsoft Fabric Capacity
↓
選擇適合的 Azure 區域
↓
回到 Power BI Service
↓
開啟 Workspace 設定
↓
修改 License info 或 Workspace capacity
↓
從 Fabric Trial 切換到正式 Fabric Capacity

只要正式 Capacity 和目前 Workspace 仍然位於同一個 Microsoft Entra 租戶，並且保留原本的 Workspace，通常以下資訊都可以繼續使用：

Tenant ID 不變
Client ID 不變
安全組不變
Workspace ID 不變
Report ID 不變
Service Principal 權限基本不變

Client Secret 也可以繼續使用到原本設定的到期日。

換句話說，這並不是重新建立一套 Power BI 環境，而只是把 Workspace 背後的運算資源從：

Fabric Trial Capacity

切換成：

Paid Fabric F Capacity

因此，Web 系統中用來呼叫 API 的 JSON 設定通常不需要整套重寫。

十一、RDL 和 API 設定能不能直接移到正式環境？

如果正式環境仍然使用同一個 Workspace，最簡單的做法就是直接替原 Workspace 更換 Capacity。

這樣可以最大限度地保留：

  • Workspace ID

  • Report ID

  • RDL

  • Workspace 權限

  • Service Principal 設定

  • Web 系統中的 API 設定

如果公司要求測試環境與正式環境完全分離，則可能需要建立新的正式 Workspace，重新發布 RDL。

這時候通常會改變：

  • Workspace ID

  • Report ID

  • 部分資料來源設定

  • API 設定檔中的 ID

但 Tenant ID、Client ID 和 Service Principal 本身仍然可以繼續使用，只要正式 Workspace 也授予它相應權限。

因此，是否需要修改 JSON，取決於是「同一個 Workspace 換 Capacity」，還是「另外建立正式 Workspace」。

十二、需要購買 Power Automate Premium 嗎？

不一定，而且對目前架構來說通常不需要。

如果 Azure Web App 後端已經可以：

  • 取得 Entra ID Access Token

  • 呼叫 Power BI REST API

  • 輪詢 ExportToFile 狀態

  • 下載產生的 PDF

  • 將 PDF 回傳給瀏覽器

那麼 Web App 本身就已經可以完成整個流程。

Power Automate 比較適合低程式碼流程，例如：

  • 收到表單後自動產生報表

  • 產生 PDF 後寄送 Email

  • 將報表存入 SharePoint

  • 定時產生報表

  • 串接 Teams 或審批流程

但它不是執行 ExportToFile API 的必要條件。

如果 Web 系統本身已經有後端，直接由後端呼叫 REST API，架構通常更單純，也更容易控制錯誤處理和使用者體驗。

十三、需要 Power BI Embedded A SKU 嗎？

對目前需求而言，通常不需要。

Power BI Embedded A SKU 主要用於將互動式 Power BI 報表嵌入到自家應用程式中。

例如：

Web 頁面內直接顯示 Power BI 報表
使用者可以篩選、點擊圖表、交叉分析

但目前的需求只是：

點擊按鈕
→ 執行 RDL
→ 產生 PDF
→ 下載

並不需要將完整 Power BI 介面嵌入 Web，因此使用 Fabric F SKU 即可，沒有必要另外採購 A SKU。

十四、建議的正式採購方案

目前系統的條件是：

  • 約 20 名內部使用者

  • 少量 RDL 報表

  • 使用者不直接登入 Power BI

  • Web 後端透過 Service Principal 呼叫 API

  • 主要功能是輸出 PDF

  • 暫時沒有大量批次輸出需求

因此，可以先採用以下方案：

Microsoft Fabric Capacity F2 × 1
Power BI Pro × 1

上線前，使用實際報表進行併發測試。

例如模擬：

  • 3 人同時輸出

  • 5 人同時輸出

  • 同一份 RDL 連續輸出

  • 不同 RDL 同時輸出

  • 大頁數 PDF

  • 複雜 SQL 查詢

如果測試中已經出現明顯排隊、節流或輸出時間過長，再升級為：

Microsoft Fabric Capacity F4 × 1
Power BI Pro × 1

如果希望正式環境的容量級別接近目前 4 CU 的試用環境，則可以直接從 F4 開始。

十五、最終結論

對於以下正式架構：

Web 點擊按鈕
→ Service Principal
→ Power BI REST API
→ 執行 RDL
→ ExportToFile
→ 產生 PDF

真正需要購買的是：

必須購買

Microsoft Fabric Capacity F2 或 F4

建議同時購買

Power BI Pro × 1

不需要購買

每個 Web 使用者的 Power BI 授權
20 份 Power BI PPU
Microsoft Fabric F64
Power Automate Premium
Power BI Embedded A SKU
Service Principal 授權

如果以成本為優先，可以先購買 F2，再根據正式報表的實際負載決定是否升級。

如果以穩定性為優先，並希望正式環境接近目前 FTL4 試用容量的效能，則可以直接選擇 F4。

最重要的一點是：

Fabric Capacity 是可以在 Azure 中調整大小的。

因此沒有必要在系統剛上線時就購買非常大的容量。先用實際 RDL、實際 SQL 和實際併發數量進行測試，再根據 Fabric Capacity Metrics 的結果調整，才是成本和穩定性最平衡的做法。

備註：Microsoft 的授權、容量功能及 API 限制可能調整，正式採購前仍應以當時的 Microsoft 官方文件、Azure 價格頁面及公司租戶設定為準。

This article was last edited at