Power BI 匯出 PDF：PPU、Fabric Capacity 與 Service Principal 到底有什麼區別？

| PowerPlatform | 4 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/1326

最近在研究如何讓 Blazor Web App 呼叫 Power BI Paginated Report，並自動生成 PDF 時，我被幾個概念繞暈了：

  • Service Principal

  • Fabric Capacity

  • Power BI Premium Per User

  • ExportToFile API

  • 「五分鐘只能匯出一次」的限制

乍看之下，它們像是兩套完全不同的方案，但真正理解之後會發現，這些概念其實分屬不同層次。

最重要的一句話是：

Service Principal 決定「誰來呼叫 API」，Fabric Capacity 或 PPU 決定「報表使用哪種運算與授權模式」。

它們並不是同一類東西。

一、先把問題拆成兩個維度

當 Web 系統呼叫 Power BI API 生成 PDF 時，需要回答兩個問題。

第一個問題是：

誰正在呼叫 Power BI API？

第二個問題是：

Power BI 使用什麼資源來執行 RDL 並生成 PDF？

這兩個問題的答案是獨立的。

呼叫身分
├─ Service Principal
└─ 真人 Microsoft 使用者

運算與授權模式
├─ Fabric / Premium Capacity
└─ Premium Per User

所以不能簡單地把它理解為：

Service Principal 方案
VS
PPU 方案

更準確的理解應該是：

呼叫身分
＋
Workspace 所在的容量模式

二、什麼是 Service Principal？

Service Principal 可以理解為一個專門代表應用程式的 Microsoft Entra ID 身分。

在 Entra ID 中註冊應用程式後，通常會取得：

Tenant ID
Client ID
Client Secret

Blazor 後端可以使用這些資訊取得 Access Token：

Blazor Web App
    ↓ Client ID + Client Secret
Microsoft Entra ID
    ↓ Access Token
Power BI REST API

Service Principal 不是一個真人帳號。

它不需要：

  • 開啟登入畫面

  • 輸入使用者密碼

  • 執行 MFA

  • 綁定某個員工的登入狀態

  • 等待真人操作

它非常適合 Web 後端、自動化程式和批次處理。

例如，使用者在 Blazor 頁面點擊「輸出 PDF」後，實際流程可以是：

使用者點擊按鈕
    ↓
Blazor 後端收到請求
    ↓
Service Principal 取得 Token
    ↓
呼叫 Power BI ExportToFile API

Service Principal 解決的是：

Power BI 如何確認這個 Web 應用程式有權呼叫 API？

但它本身不提供報表運算能力。

換句話說，Service Principal 只是身分與通行證，不是生成 PDF 的計算資源。

三、什麼是 Fabric Capacity？

Fabric Capacity 是一整池由組織購買或試用的運算資源。

例如：

Fabric Capacity
    ↓
分配給某個 Workspace
    ↓
Workspace 裡的 Paginated Report 使用該容量執行

當 RDL 被執行時，真正負責以下工作的，是 Fabric Capacity：

  • 執行報表 SQL

  • 處理報表參數

  • 執行 RDL 運算式

  • 計算分頁

  • 渲染文字和表格

  • 生成 PDF

  • 暫存匯出結果

因此可以把整體角色理解成：

Service Principal
→ 證明應用程式有權呼叫 API

Workspace 權限
→ 決定應用程式能不能操作這份報表

Fabric Capacity
→ 真正執行報表並生成 PDF

這三個概念不能混為一談。

四、目前的 Fabric 試用容量代表什麼？

假設 Power BI 管理畫面中顯示：

Fabric 試用容量
容量單位：4 CU
狀態：Active

那麼代表目前有一個試用中的 Fabric Capacity。

如果 Workspace 已經被分配到這個 Capacity，Workspace 裡的 RDL 就會使用這個試用容量進行運算。

整體流程如下：

Blazor Web App
    ↓
Service Principal
    ↓
Power BI ExportToFile API
    ↓
Fabric 試用 Capacity
    ↓
Paginated Report / RDL
    ↓
PDF

試用容量結束後，如果要保持同樣的架構，就需要購買正式的 Fabric 或 Embedded Capacity，並把 Workspace 移到正式容量中。

通常不需要重寫整套 Blazor 程式。

試用 Capacity
    ↓ 到期
正式 Capacity

Client ID、Service Principal 和 API 流程通常都可以繼續使用。

五、什麼是 Premium Per User？

Premium Per User，簡稱 PPU，是以「每名使用者」為單位購買的 Premium 授權。

例如：

使用者 A：有 PPU
使用者 B：有 PPU
使用者 C：沒有 PPU

如果某個 Workspace 是 PPU Workspace，那麼通常只有擁有 PPU 授權的使用者才能存取其中內容。

PPU 的核心邏輯是：

一個人購買一份 PPU
    ↓
這個人獲得 Premium 功能

它不是給公司提供一整池專用容量。

也就是說，PPU 並不是：

購買一份 PPU
    ↓
讓整個 Web 系統替所有人無限制生成 PDF

PPU 的設計目標主要是讓特定使用者獲得 Premium 功能，而不是讓一個共用帳號變成全公司的報表伺服器。

六、「五分鐘只能生成一份 PDF」是哪種限制？

這個限制適用於使用 PPU 進行 Paginated Report API 匯出的場景。

可以理解為：

每名 PPU 使用者
每五分鐘
只能發起一次匯出 API 請求

例如某個 PPU 使用者在 09:00 發起了一次 PDF 匯出：

09:00:00  PDF A → 成功
09:00:30  PDF B → 可能收到 429
09:02:00  PDF C → 可能收到 429
09:05:01  PDF D → 才能再次匯出

這個限制不是：

每份 RDL 五分鐘一次

也不是：

整個 Power BI 租戶五分鐘一次

而是：

每個 PPU 使用者五分鐘一次

七、共用一個 PPU 帳號會發生什麼？

假設 Blazor 後端一直使用一個固定的 PPU 帳號：

[email protected]

所有 Web 使用者的請求最終都變成同一個 Power BI 使用者發起。

例如有 20 名 Web 使用者：

使用者 A
使用者 B
使用者 C
使用者 D
    ↓
Blazor Web App
    ↓
同一個 PPU 帳號

從 Power BI 的角度來看，這些請求全部來自：

[email protected]

於是可能出現：

A 09:00:00 匯出成功
B 09:00:10 匯出失敗
C 09:01:00 匯出失敗
D 09:03:00 匯出失敗

整個 Web 系統實際上會接近：

每五分鐘只能成功啟動一個 PDF 匯出工作。

對一個多人使用的業務系統來說，這通常不實用。

八、每名使用者都購買 PPU 又如何？

另一種做法是讓每一名使用者都購買 PPU。

使用者 A：PPU
使用者 B：PPU
使用者 C：PPU
……

那麼每個人的五分鐘限制是分開計算的。

A 可以匯出一次
B 也可以匯出一次
C 也可以匯出一次

但是這種方式會帶來其他問題：

  • 每個人都要購買 PPU

  • 每個人都要登入 Microsoft 帳號

  • Blazor 需要處理使用者委派登入

  • 使用者仍不能在五分鐘內連續匯出多份報表

  • 後端不能簡單使用一個固定 Client Secret 統一處理

  • 權限管理會變得更複雜

因此，PPU 比較適合少數使用者自己登入 Power BI 操作報表。

它不太適合這種場景：

20 名普通 Web 使用者
    ↓
Blazor 按鈕
    ↓
後端統一生成 PDF

九、Fabric Capacity 為什麼沒有固定五分鐘限制？

Fabric Capacity 是組織級運算資源。

它的邏輯不是：

每個人多久可以匯出一次

而是：

目前容量有多少可用計算資源

假設三名使用者在短時間內點擊生成 PDF：

使用者 A 09:00:00 點擊
使用者 B 09:00:01 點擊
使用者 C 09:00:02 點擊

Blazor 後端可以透過同一個 Service Principal 發起三個匯出工作：

Export Job A
Export Job B
Export Job C

這些任務可能：

  • 同時執行

  • 短暫排隊

  • 依序完成

  • 在容量不足時被節流

但它們不受 PPU 那種固定的「每五分鐘一次」限制。

Fabric Capacity 的限制主要來自：

  • Capacity 大小

  • CU 數量

  • RDL 複雜程度

  • SQL 查詢時間

  • 同時執行的匯出數量

  • PDF 頁數

  • 圖片和運算式數量

  • 平台節流機制

因此，Fabric Capacity 的邏輯是：

資源負載限制，而不是固定時間限制。

十、HTTP 429 不一定代表 PPU 五分鐘限制

無論是 PPU 還是 Capacity，都可能遇到 HTTP 429。

但是原因不同。

PPU 模式

PPU 下的 429 可能是因為：

同一名使用者
在五分鐘內
再次呼叫匯出 API

這屬於固定頻率限制。

Fabric Capacity 模式

Capacity 下的 429 可能是因為：

容量負載過高
同時請求太多
報表消耗太大
資源暫時不足

這屬於資源節流。

所以不能看到 429 就直接判斷：

這是五分鐘一次的限制

必須先確認 Workspace 使用的是：

PPU
還是
Fabric / Premium Capacity

十一、完整的 Service Principal＋Fabric Capacity 架構

對於 Blazor Web App，典型架構如下：

20 名 Web 使用者
        ↓
登入 Blazor Web App
        ↓
點擊「輸出 PDF」
        ↓
Blazor 後端
        ↓
使用 Client ID + Client Secret
        ↓
Service Principal 取得 Access Token
        ↓
呼叫 Power BI ExportToFile API
        ↓
Workspace 中的 Paginated Report
        ↓
Fabric Capacity 執行 RDL
        ↓
生成 PDF
        ↓
Blazor 將 PDF 返回瀏覽器

這裡的普通 Web 使用者不需要：

  • 登入 Power BI

  • 取得 Workspace ID

  • 知道 Report ID

  • 持有 Client Secret

  • 自己呼叫 Power BI API

  • 自己擁有 PPU 帳號

從使用者角度來看，只是點擊了一個普通的 Web 按鈕。

十二、Service Principal 本身不等於免費 Capacity

另一個很容易產生的誤解是：

有了 Service Principal
就可以免費呼叫 Power BI 生成 PDF

這是不正確的。

Service Principal 只解決應用程式身分問題。

它不能取代：

  • Fabric Capacity

  • Premium Capacity

  • Workspace 授權

  • Power BI 運算資源

可以把它理解成：

Client Secret
→ 證明你是誰

Workspace 權限
→ 決定你能操作什麼

Fabric Capacity
→ 提供生成 PDF 的計算資源

僅僅有 Client ID 和 Client Secret，不代表報表就有可用的運算容量。

十三、為什麼 PPU 比 Capacity 便宜？

因為兩者解決的問題完全不同。

PPU

PPU 賣的是：

一個使用者
獲得 Premium 功能

如果一個 PPU 帳號可以被 Web 後端無限制地替數百人生成 PDF，那麼公司只需要購買一個使用者授權，就能把它當成整個組織的報表伺服器。

因此，PPU 對 API 匯出增加了較嚴格的限制。

Fabric Capacity

Fabric Capacity 賣的是：

一整池組織級運算能力

公司支付 Capacity 費用後，可以讓應用程式服務多名使用者。

因此，Capacity 不需要使用固定的每人五分鐘限制，而是根據容量資源進行排程與節流。

十四、兩種模式的實際比較

項目 PPU Fabric Capacity
計費方式 每名使用者 整體容量
適合對象 少數 Power BI 使用者 組織級系統與 Web 應用
Workspace 類型 PPU Workspace Capacity Workspace
匯出 PDF 支援 支援
固定五分鐘限制 有，每名 PPU 使用者一次 沒有此固定限制
多人共用後端帳號 不適合 適合 Service Principal
普通 Web 使用者需要 Power BI 帳號 通常需要考慮個人授權 App-owns-data 場景下可不需要
主要限制 使用者授權與頻率 Capacity 負載與節流
適合 Blazor 統一輸出 PDF 不太適合 適合

十五、哪種方式適合 Blazor Web App？

假設需求是：

約 20 名使用者
    ↓
登入自建 Blazor 系統
    ↓
點擊帳票按鈕
    ↓
直接下載 PDF

那麼更適合的架構是：

Service Principal
＋
Fabric / Embedded Capacity

原因是：

  • 使用者不需要各自登入 Power BI

  • 後端可以統一管理權限

  • 不依賴某個員工的帳號

  • 不受 PPU 每名使用者五分鐘一次的固定限制

  • 可以集中處理 PDF 匯出

  • 適合 App-owns-data 模式

  • 可以根據實際負載調整 Capacity

PPU 更適合：

少數員工
直接登入 Power BI
查看和操作報表
偶爾手動匯出

而不是充當 Web 系統背後的自動報表伺服器。

十六、試用結束後有哪些選擇？

假設目前使用的是：

Service Principal
＋
Fabric 試用 Capacity
＋
Workspace
＋
Paginated Report

試用結束後，大致有三條路。

選擇一：購買正式 Fabric Capacity

Service Principal 保持不變
Client ID 保持不變
Blazor 程式保持不變
Workspace 移到正式 Capacity

這是最自然的正式化方案。

選擇二：改成 PPU

Workspace 改成 PPU
使用者購買 PPU
改用使用者身分呼叫
接受每人五分鐘一次的限制

對多人 Web 系統通常不理想。

選擇三：改用自建報表伺服器

Blazor
    ↓
SSRS / Power BI Report Server
    ↓
RDL
    ↓
PDF

這樣可以不再依賴 Power BI Service，但需要自己管理：

  • Windows Server

  • 虛擬機

  • SQL Server 授權

  • 報表伺服器

  • 憑證

  • 防火牆

  • 更新

  • 備份

  • 監控

十七、最容易記住的比喻

可以把整套架構想成叫車。

Service Principal

Service Principal 是司機身分

它證明這個司機有權進入系統、接收任務。

Fabric Capacity

Fabric Capacity 是汽車和引擎

它真正負責消耗能源並把報表生成出來。

Workspace 權限

Workspace 權限是通行許可

它決定司機能不能進入指定區域並操作指定報表。

Web 使用者

Web 使用者只是乘客

乘客只需要在 Blazor 頁面下單，不需要自己擁有 Power BI 帳號。

PPU

PPU 更像個人車票

每名使用者各自購買自己的使用資格，而且匯出 API 有固定頻率限制。

十八、最終結論

Service Principal、Fabric Capacity 和 PPU 不是三個互相替代的產品。

它們分別解決不同問題：

Service Principal
→ 應用程式使用什麼身分呼叫 API

Workspace 權限
→ 應用程式能否操作這份報表

Fabric Capacity
→ 由哪一池資源執行 RDL 並生成 PDF

PPU
→ 某一名使用者是否擁有 Premium 功能

「五分鐘只能匯出一次」是 PPU 使用者模式下的特殊限制，並不適用於 Fabric Capacity 模式。

因此，對於以下需求：

多名使用者
    ↓
Blazor Web App
    ↓
後端統一呼叫 Power BI
    ↓
自動生成 PDF

比較合適的方案是：

Service Principal＋Fabric 或 Embedded Capacity。

而不是讓所有使用者共用一個 PPU 帳號。

一句話總結：

Service Principal 負責證明應用程式是誰，Fabric Capacity 負責真正出力生成 PDF；PPU 則是個人授權，並且其 Paginated Report API 匯出受到每名使用者五分鐘一次的限制。

This article was last edited at