Kapitoly kurzu
1. Licencování a režimy připojení 2. Sdílené pracovní prostory 3. Power BI Apps, Audiences a RLS 4. Gateway a aktualizace dat 5. Kapacita, pipelines, verzování 6. Sémantické modely, Dataflows, OneLake 7. Administrace a monitoring
Cvičení
8. Cvičení 1: Workspaces a sdílení 9. Cvičení 2: App a RLS 10. Cvičení 3: Sdílený model 11. Cvičení 4: Životní cyklus obsahu
🏠 Rozcestník kurzu
GOC686 · Cvičení

Cvičení 4: Refresh, endorsement a pipeline

Plánovaný refresh bez gateway, označení obsahu a deployment pipeline DEV → TEST s pravidlem
🧪 Cvičení

Cíle kapitoly

  • Nastavit plánovaný refresh modelu bez gateway a přečíst historii refreshů
  • Označit model jako Promoted a ověřit endorsement v OneLake catalog
  • Postavit deployment pipeline DEV → TEST a použít parameter rule pro parametr Prostredi
  • Přečíst usage metrics reportu a vědět, proč mohou být v den kurzu prázdné
11.1

Úvod — co je proveditelné na F2

Na kapacitě F2 s Pro licencí a rolí Admin ve vlastních workspace je proveditelná většina tématu Správa životního cyklu — jen dvě části zůstávají mimo dosah tohoto cvičení.

Téma osnovyHands-on v tomto cvičeníPoznámka
Automatizace refreshůAnoCloudový zdroj bez gateway, limit 48× denně na kapacitě
Deployment pipelinesAnoVytvoření pipeline stačí Pro licence; přiřazení stage vyžaduje Admin workspace a kapacitu — obojí máš
EndorsementAno, jen PromotedCertified vyžaduje autorizaci Fabric adminem
Usage metricsOmezeněData mohou mít zpoždění až 24 hodin — v den kurzu bude report nejspíš prázdný
Gateway, Admin portal, Capacity MetricsNeVyžaduje lokální admin práva nebo roli Fabric/capacity admin — zůstává jako demo lektora
11.2

Krok 1 — Plánovaný refresh

  1. U semantic modelu GOC686-Starter v GOC686-StudentXX klikni … → Settings → Refresh.
  2. Zapni Configure a refresh schedule → On.
  3. Nastav frekvenci Daily, přidej dva časy a časové pásmo (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague.
  4. Klikni Apply.
  5. Otevři Refresh → Refresh history a zkontroluj poslední běhy (manuální z cvičení 1 tam už je).
Proč jsi vlastníkem credentials ty, a ne lektor?▼

Řešení pro kontrolu: Kdyby model do tvého workspace nahrál lektor, byl by vlastníkem on — a i když jsi Admin workspace, musel bys nejdřív udělat Take over (převzetí vlastnictví), teprve pak bys mohl nastavit credentials a schedule. Protože jsi Starter nahrál sám v cvičení 1, jsi vlastník rovnou a refresh i schedule řídíš přímo. Gateway bys potřeboval jen u on-premises zdroje (SQL Server v síti klienta, sdílená složka) — veřejné CSV přes anonymní HTTP gateway nevyžaduje vůbec.

✓
Ověření: Schedule je uložený jako On s dvěma denními časy a v Refresh history vidíš historii proběhlých refreshů.
11.3

Krok 2 — Promoted endorsement

  1. U semantic modelu klikni … → Settings → Endorsement.
  2. Vyber Promoted → Apply.
  3. Otevři OneLake catalog, najdi svůj model a ověř, že badge Promoted je vidět.
ℹ️
Poznámka: Promoted smí nastavit kdokoli s write permission na obsahu — proto ho zvládneš sám. Certified vyžaduje autorizovaného recenzenta nastaveného Fabric adminem a v tomto cvičení ho nezkoušíš.
✓
Ověření: V OneLake catalog vidíš u svého modelu badge Promoted.
11.4

Krok 3 — Deployment pipeline DEV → TEST

Development GOC686-Starter model + report Prostredi = DEV 1. Deploy jen metadata, bez dat a 4. druhý Deploy Test 2. Credentials + Refresh 4. Compare (v Development) 5. Refresh znovu Prostredi = TEST 3. Parameter rule Prostredi = "TEST" (platí až příště)
Pořadí kroků pipeline zleva doprava: první Deploy je jen metadata bez dat, teprve credentials a Refresh v Test naplní model daty (2). Parameter rule (3) se nastavuje v Test, ale projeví se až po druhém Deploy (4), po kterém je potřeba ještě jeden Refresh (5).
  1. Ve workspace GOC686-StudentXX klikni Create deployment pipeline (nebo v levém panelu Workspaces → Deployment pipelines → + New pipeline). Vytvořit pipeline stačí licence Pro/PPU — tu máš.
  2. Pojmenuj pipeline GOC686-StudentXX a vytvoř dvě stage: Development a Test.
  3. Přiřaď GOC686-StudentXX ke stage Development a GOC686-StudentXX-TEST ke stage Test. Přiřazení workspace ke stage vyžaduje roli Admin v daném workspace — tu v obou workspace máš.
  4. První Deploy do prázdné Test: zaškrtni report GOC686-Starter → Select related (přibalí i jeho semantic model automaticky). Zkontroluj, že Prodeje podle regionu - StudentXX ani Thin report - StudentXX zaškrtnuté nejsou → Deploy.
  5. V GOC686-StudentXX-TEST u nasazeného modelu (jsi jeho vlastník od prvního deploye) nastav … → Settings → Data source credentials → Edit credentials → Anonymous, Public → Sign in, pak Refresh now. Teprve po dokončení refreshe otevři report — deploy je vždy jen metadata, bez dat.
  6. Pořád ve stage Test otevři u modelu Deployment rules → Parameter rules → nastav Prostredi = "TEST" → Save. Pravidlo smí nastavit jen vlastník modelu a neplatí zpětně — projeví se až při dalším deployi.
  7. Vrať se do Development a uprav model, ne report: u GOC686-Starter klikni … → Open semantic model → Editing a přidej míru, např. Prumerna cena = DIVIDE([Prodeje], [Pocet kusu]) (změny modelu na webu se ukládají automaticky). V pipeline klikni Compare a pak znovu Deploy — tentokrát jen semantic model.
  8. Ve stage Test spusť u modelu znovu Refresh now — teprve po něm karta s parametrem Prostredi ukáže aktuální hodnotu.
⚠️
Pozor: Report Prodeje podle regionu - StudentXX jsi vytvořil přímo ve službě, takže je pravděpodobně v novějším formátu PBIR — a PBIR reporty deployment pipelines nepodporují („PBIR reports aren't supported", dokumentace k limitacím deployment pipelines). Proto ho nenasazuješ. Report GOC686-Starter pochází z .pbix od lektora ve starším formátu PBIR-Legacy, který podporovaný je — ale jen dokud ho ve službě neupravíš: editace a uložení PBIR-Legacy reportu ve službě ho automaticky převede na PBIR, a další Deploy by pak selhal. Proto v kroku 7 místo reportu upravuješ model. Pokud by přesto deploy modelu nebo reportu selhal, nasaď jen sémantický model.
⚠️
Pozor: Přesné popisky v UI deployment pipelines (preview) jsou neověřeno — popisek se v UI může lišit od kroků výše.
⚠️
Pozor: Model ve stage Test nejde po nasazení editovat na webu ani stáhnout jako .pbix — je to limitace deployment pipelines, ne chyba tvého postupu.
✓
Ověření: Po druhém Deploy a refreshi otevři report v GOC686-StudentXX-TEST a najdi na něm kartu s parametrem Prostredi — má hodnotu TEST, zatímco ve stage Development zůstává DEV.
11.5

Krok 4 — Usage metrics

  1. Otevři svůj report → … → View usage metrics report.
  2. Projdi stránky reportu a vyzkoušej přepínač New usage report (pokud je v nabídce).
ℹ️
Poznámka: Data v usage metrics mohou mít zpoždění až 24 hodin. Protože jsi report vytvořil a otevíral teprve dnes, report bude nejspíš prázdný nebo skoro prázdný — to je očekávané chování, ne chyba nastavení. Strukturu reportu (stránky, vizuály, co měří) si projdi i tak; starší data s reálným provozem ukáže lektor na svém demo reportu v GOC686-Demo.
✓
Ověření: Umíš pojmenovat, co která stránka usage metrics ukazuje, i když dnešní data ještě nejsou vidět.
11.6

Závěrečné otázky

Na konci kurzu si připrav odpovědi na tyto otázky. Nemusí být perfektní — slouží k diskuzi.

1. Ve firmě máte 50 reportů a 200 uživatelů. Jak zajistíš, aby každý uživatel viděl jen data své pobočky — bez nutnosti udržovat 50 kopií modelu?▼

Řešení pro kontrolu: Jeden sdílený sémantický model s dynamickou RLS (viz cvičení 2 a 3) — role s DAX filtrem podle USERPRINCIPALNAME() namapovaná na pobočku přes pomocnou tabulku. Reporty se pak stavějí jako thin reporty (Live Connection) nad tímto jedním modelem místo 50 samostatných importů. Výhoda: jedna definice bezpečnosti a byznys logiky na jednom místě; nevýhoda, se kterou je třeba počítat, je breaking change v modelu, který se projeví ve všech 50 reportech najednou.

2. Vývojář udělal chybu v produkčním reportu. Jak by vypadal správný deployment proces, aby se to příště nestalo?▼

Řešení pro kontrolu: Deployment pipeline se stages Development → Test → Production (viz krok 3 výše), kde se změny nejdřív nasadí a ověří v nižší stage přes Compare a teprve pak Deploy dál. Parameter rules a data source rules zajistí, že se v každé stage sahá na jiný zdroj dat (např. testovací vs. produkční). Ideálně doplněno o Git integraci, aby šly změny verzovat a revertovat, a o omezení práv Admin na produkční workspace jen pro úzký okruh lidí.

3. Máš Power BI Pro a F2 kapacitu v start/stop režimu. Uživatelé refreshují data v noci. Je možné kapacitu v noci vypnout a refresh přesto fungoval? Za jakých podmínek?▼

Řešení pro kontrolu: Ne, ne v takto popsané podobě. Pozastavená (paused) kapacita znamená, že obsah workspace na ní je nedostupný — refresh na pozastavené F2 neproběhne. Aby refresh v noci fungoval, musel by se workspace před pauzou kapacity přesunout na jinou kapacitu (Pro/shared) nebo by kapacita nesměla být v danou dobu pozastavená. Tvrzení, že import modely po zastavení F2 „běží dál na shared capacity" automaticky, je chybné — bez explicitního přesunu workspace zůstává obsah nedostupný.

11.7

Shrnutí a reference

✓
Shrnutí: Máš naplánovaný refresh bez gateway, model označený jako Promoted, funkční deployment pipeline se dvěma stage a parameter rule, a víš, proč mohou být usage metrics v den kurzu prázdné. Tím uzavíráš celý životní cyklus obsahu — od workspace a rolí (cvičení 1), přes zabezpečení a distribuci (cvičení 2), sdílený model (cvičení 3), až po refresh, verzování a monitoring.
📚 Do hloubky na Learn: Scheduled refresh (EN) · Deployment rules (EN) · Monitor a paused capacity (EN)
← Cvičení 3: Sdílený model Stránka 11 z 11 🏠 Rozcestník →