Licencování a režimy připojení

Licencování bývá první téma, které se v praxi přeskočí — a první téma, kvůli kterému pak přijde tiket „Proč nemůžu publikovat report?“ nebo „Proč kolega nevidí dashboard, i když má na něj přístup?“. Špatně zvolená licence nebo kapacita není kosmetická chyba. Je to funkce, která prostě chybí — bez ohledu na to, jak dobře je report navržený.

V Power BI a Microsoft Fabric fungují licence ve dvou nezávislých rovinách, které se musí sečíst:

• Licence per uživatel — co smí konkrétní osoba dělat (tvořit, publikovat, sdílet).
• Licence per kapacita — na jakém výpočetním a úložném základu workspace běží, a jak moc tato kapacita snižuje nároky na licence jednotlivých uživatelů.

Tři úrovně licencí se liší hlavně v tom, co uživatel smí vytvářet a sdílet — nikoli primárně v tom, co smí konzumovat (to určuje spíš kapacita, viz sekce 1.3–1.4).

Druhá rovina licencování se netýká osoby, ale workspace — na jaké kapacitě běží. Kapacita určuje výkon, limity velikosti modelu a hlavně to, zda konzumenti potřebují vlastní Pro licenci.

Přiřazení workspace na F-SKU nebo P-SKU kapacitu mění, co je ve workspace vůbec dostupné — nejde jen o výkon. Podrobný přehled kapacit a jejich administraci probírá kapitola 7, přiřazení kapacity ke konkrétnímu workspace kapitola 2.

GET https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}
// odpoved obsahuje pole isOnDedicatedCapacity a capacityId

Rychlý způsob, jak programově ověřit, zda workspace běží na dedikované kapacitě: pole isOnDedicatedCapacity v odpovědi Power BI REST API.

Toto je nejčastější zdroj zmatku v licencování: Fabric Free uživatel s rolí Viewer může prohlížet Power BI obsah bez Pro licence, ale jen na dostatečně velké kapacitě. Hranicí je F64 (nebo odpovídající P-SKU) — na menších F-SKU (F2 až F32) musí mít i konzument Pro, PPU nebo individuální trial licenci, stejně jako na shared capacity. Stejně jako F64+ se pro prohlížení chová i Fabric Trial kapacita (60denní zkušební F64 ekvivalent). Podmínka role Viewer platí bez výjimky — Free uživatel s jinou rolí (Contributor, Member, Admin) potřebuje Pro nebo PPU bez ohledu na velikost kapacity.

Pozastavená (paused) kapacita je jiný stav než shared capacity — nejde o „nižší úroveň“, ale o vypnutý zdroj. Pozastavení může obsah na kapacitě zcela znepřístupnit, dokud ji někdo znovu nespustí.

Toto je praktický důvod, proč administrátor kapacity a vlastník workspace musí komunikovat: pauza naplánovaná bez vědomí business týmu se projeví jako „report najednou nejde otevřít“ — a bez znalosti stavu kapacity se to špatně diagnostikuje.

Zvláštní případ kombinace licence a kapacity: Free uživatel s Build permission na sdíleném sémantickém modelu smí na kapacitě F64+ nebo P-SKU vytvořit vlastní report nad tímto modelem — ale jen ve svém My workspace. Nemůže report sdílet ani uložit jinam.

• Build permission dává automaticky role Contributor a vyšší ve workspace, kde model žije, nebo ji lze přidat explicitně.
• My workspace je osobní pískoviště — nelze ho sdílet, není určeno pro produkční distribuci.
• Co jde do produkce, patří do sdíleného workspace (viz kapitola 2) — odtud teprve jde distribuovat dál.

Podrobněji o Build permission a sdílených modelech pojednává kapitola 6.

Licence a kapacita určují, kdo smí co dělat. Režim připojení určuje, jak model získává data — a má přímý dopad na aktuálnost, výkon i zátěž zdrojového systému.

Direct Lake existuje ve dvou variantách, které se liší chováním při fallbacku na DirectQuery — rozdíl, který se v praxi často přehlíží a pak překvapí na neočekávaně vysoké latenci nebo naopak chybě.

Fallback u varianty on SQL endpoint nenastává jen kvůli SQL RLS nebo view — spouští ho i překročení guardrails kapacity (počet Parquet souborů, row groups, řádků v tabulce) nebo SQL dynamic data masking, a to v režimu DirectLakeBehavior = Automatic. K SQL OLS a CLS definovaným na SQL analytics endpointu dokumentace uvádí nejednotně jak fallback, tak chybu při odepření přístupu — přesné chování si ověřte na konkrétním modelu, např. diagnostickým DAX dotazem EVALUATE TABLETRAITS(), jehož sloupec DirectLakeFallbackInfo ukáže důvod fallbacku (nebo jeho absenci) pro každou tabulku. Chování při nesplnění podmínek obecně řídí vlastnost DirectLakeBehavior (v Desktopu záložka Properties → Direct Lake behavior): Automatic (výchozí, tichý fallback na DirectQuery), DirectLakeOnly (dotaz skončí chybou — vhodné pro vývoj) a DirectQueryOnly (vynutí DirectQuery vždy, pro měření výkonu fallbacku). Vlastnost platí jen pro on SQL variantu.

• Fabric licenses — kdo co potřebuje
• End-user features podle licence a kapacity
• Build permissions pro sdílené sémantické modely
• Pause a resume F-SKU kapacity
• Monitorování pozastavené kapacity
• Premium Per User — FAQ a limity
• Limity plánovaného refreshe
• Composite modely — DirectQuery na Power BI semantic model
• Direct Lake — přehled
• Direct Lake — jak to funguje