Publikálás és megosztás a Power BI Service-ben

Munkaterületek (workspace)

A munkaterület az a hely, ahol a riportok, szemantikai modellek és dataflow-k élnek. Két típust érdemes megkülönböztetni:

• Saját munkaterület (My workspace): személyes tárhely. Kizárólag fejlesztésre és kísérletezésre való – éles riport soha ne itt éljen, mert a kollégák nem érik el, és a szerző távozásával elveszhet.
• Megosztott munkaterület: csoportos hely, saját jogosultsági rendszerrel. Minden éles riport ide való.

A munkaterületi szerepkörök határozzák meg, ki mit tehet:

A közzététel menete

1. A Power BI Desktopban Közzététel (Publish), majd a cél munkaterület kiválasztása.
2. A Service-ben megjelenik a riport és mellette a szemantikai modell (a kettő külön elem).
3. A modellnél meg kell adni a forrás hitelesítő adatait – enélkül nem fut a frissítés.
4. Beállítjuk az ütemezett frissítést.
5. Összeállítjuk és publikáljuk az appot a végfelhasználóknak.

Fontos: az újbóli közzététel felülírja a Service-ben lévő riportot. Ezért a .pbix forrásfájlt verziókövetve (vagy legalább rendezett mappaszerkezetben) kell tárolni – enélkül egy véletlen felülírás után nincs mihez visszatérni.

Appok és megosztási módok

Több módon el lehet juttatni a riportot a felhasználókhoz – érdemes tudatosan választani:

• App (ajánlott): a munkaterület tartalmából összeállított, csomagolt nézet. A felhasználó csak a véglegesített változatot látja, a fejlesztés közben lévő riportokat nem. Nagyobb közönségnél ez a helyes megoldás.
• Munkaterületi hozzáférés (Viewer szerep): kisebb csapatnál elég lehet, de a felhasználó ilyenkor a munkaterület minden tartalmát látja.
• Közvetlen megosztás (link): egyedi esetekre. Sok ilyen link idővel átláthatatlanná teszi a jogosultságokat.
• Beágyazás Teamsbe vagy SharePointra: kényelmes, de a licenc- és jogosultsági szabályok ugyanúgy érvényesek – a beágyazás nem kerüli meg őket.

Ütemezett frissítés

Import módú modellnél az adat annyira friss, amennyire a legutóbbi frissítés. Ezt a Service-ben lehet ütemezni.

• Időzítés: a forrásrendszer napi zárása után fusson – különben hiányos adatot tölt be.
• Gyakoriság: a naponta engedélyezett frissítések száma licencfüggő (a Pro szűkebb keretet ad, mint a PPU vagy a kapacitás) – az aktuális korlátokat a Microsoft dokumentációjában érdemes ellenőrizni.
• Hibaértesítés: állítson be e-mail értesítést sikertelen frissítésről, és lehetőleg ne csak egyetlen személynek.
• Inkrementális frissítés: nagy tábláknál csak a változó időszakot tölti újra – lényegesen rövidebb futásidő.
• Időzóna: ellenőrizze a beállított időzónát, különösen ha a forrás más zónában dolgozik.

Adatátjáró (gateway)

Cégen belüli (on-premise) adatforráshoz a felhő csak adatátjárón keresztül fér hozzá. Néhány gyakorlati szempont:

• Mindig standard (nem személyes) módban telepítse, hogy több felhasználó is használhassa.
• Olyan gépre kerüljön, amely folyamatosan be van kapcsolva – szerverre, ne laptopra.
• Legyen kijelölt gazdája: ki frissíti, ki kap értesítést, ha leáll.
• Több átjáró fürtbe (cluster) szervezhető, hogy egy gép kiesése ne állítsa le a frissítést.
• A hitelesítéshez dedikált technikai felhasználót használjon, ne egy kolléga személyes fiókját.

Sorszintű jogosultság (RLS)

Az RLS-sel ugyanaz a riport felhasználónként más adatot mutat: az értékesítő csak a saját régióját látja, a régióvezető az egészet.

• Statikus RLS: a Desktopban definiált szerepkörökhöz fix szűrő tartozik (pl. „Északi régió"). Kevés, ritkán változó szerepkörnél egyszerű megoldás.
• Dinamikus RLS: egy jogosultsági tábla köti a bejelentkezett felhasználót az adataihoz, jellemzően a USERPRINCIPALNAME() függvénnyel. Sok felhasználónál ez a fenntartható út.

-- A Jogosultsag tábla Email oszlopa a bejelentkezett felhasználóra szűr,
-- ez a szűrés terjed tovább a régióra, onnan a ténytáblára.
[Email] = USERPRINCIPALNAME()

Fontos: a szerepkör-hozzárendelést a Service-ben kell elvégezni (Security menüpont a szemantikai modellnél), és a beállítást tesztelni kell a „Nézet mint" (View as) funkcióval. Az RLS a munkaterületen szerkesztési joggal rendelkezőkre nem vonatkozik – ők mindent látnak.

Verziók és környezetek

Nagyobb szervezetnél érdemes elválasztani a fejlesztést az élestől. Erre valók a telepítési folyamatok (deployment pipelines): fejlesztői, teszt- és éles munkaterület között lehet velük szabályozottan léptetni a tartalmat (ez a funkció kapacitáshoz kötött).

Kisebb szervezetnél elegendő két munkaterület – „Fejlesztés" és „Éles" –, és az a szabály, hogy élesbe csak tesztelt riport kerül.

Gyakori kérdések

Kapcsolódó útmutatók

• Licencek és költségek
• Adatforrások és Power Query
• Riportkészítés lépésről lépésre
• Teljesítmény-optimalizálás