Power BI sablonfájl

Az egyik ügyfelemmel elkezdtünk közösen összerakni egy olyan Power BI sablonfájlt, ami kiindulópontként szolgál majd minden Power BI riport fejlesztéséhez. A terv az volt, hogy ebbe a sablonfájlba az adatokon és a vizualizációkon kívül beleteszünk mindent, ami egy riport fejlesztéshez szükséges: Arculati elemeket, dátum- és referencia táblákat, infó oldalt, fejlesztési irányelveket, olyan kötelező elemeket, mint a riport utolsó frissítésének dátuma, stb.

Mi az a Power BI sablonfájl?

A Power BI sablonfájl egy olyan *.pbit vagy *.pbix kiterjesztésű üres Power BI fájl, amely az adatokon és riportokon kívül tartalmaz mindent, amit a riportfejlesztés során használni fogunk, vagy használni akarunk. Nevezik mesterfájlnak is vagy template fájlnak is. Anno mi is template fájlnak hívtuk, de amikor a Power BI lefoglalta magának a template fájl szót a *.pbit kiterjesztésű fájlokra, akkor váltottunk sablon-, vagy mesterfájlra.

A sablonfájl ott lesz nagyon fontos, ahol többen is fejlesztenek Power BI riportokat, vagy egy fejlesztő 10-20 riportot is készít. Az ugyanis a tapasztalat, hogy iszonyat mennyiségű időt töltenek a fejlesztők a dizájnnal, a színezéssel, a formázással. Ha ezek egy sablonfájlban előre be vannak állítva, akkor csak a fő feladatra kell koncentrálniuk, nem a körítésre. És ugyanez igaz lehet majd a Copilot-ra is. Neki is nagy segítség lesz valószínűleg, ha adunk neki egy sablonfájlt mintának és úgy fogalmazzuk meg a promptot, hogy az elkésztendő mű a sablonfájl alapján készüljön.  

A sablonfájl nagyon nagy segítség lesz a fejlesztői vénával nem rendelkező üzleti felhasználóknak is. Egy kontroller valószínűleg semmit sem tud a deployment folyamatról, és csak pislogni fog, amikor élesbe akarja tetetni a riportot IT-val. Nekik óriási segítség lesz, ha a sablonfájl elő van már készítve a deployment folyamatra.

A sablonfájlt használjuk arra is, hogy megkülönböztessük a saját munkánkat a „botcsinálta felhasználók szutykaitól”. Ha megszokják a riporthasználók, hogy a rózsaszín riport tőlünk jön, és ehhez társul a fejükben a magas minőség és a megbízhatóság, akkor nyert ügyünk van: már a megjelenéssel is bizalmat építünk. A sablonfájl tehát remek brand építő eszköz is. Épp ezért BI és adatos csapatoknak, szállítóknak kötelező.

Nem akarok többet papolni a sablonfájlok fontosságáról, tényleg fontos na.

Mit tartalmazzon a Power BI sablonfájl?

A konzultációt úgy kezdtük, hogy az alábbi tartalmi elemeket gondoltuk fontosnak:

  • Globális/lokális beállítások a Power BI desktop fájlban
  • Power Query mappák, paraméterek
  • Placeholder táblák lokális measure-öknek, címeknek, metaadatoknak
  • Referencia táblák adatokkal: régió bontás, dátum, idő, ….
  • Arculati elemek
  • Egy db mintariport
  • Info lap, tartalomjegyzék oldal, ...

Innen indultunk, aztán ezeket elkezdtük kibontani: 

Globális, lokális beállítások

Azzal kezdtük a munkát, hogy átnéztük közösen egy üres Power BI desktop fájlan található globális és lokális beállításokat. Megbeszéltük mi fontos, mi nem.

  • Auto Date/time-ot kikapcsoltuk
  • Ignore privacy levels-t kikapcsoltuk
  • Export Data: Allow end user to export both summarized and underlying data: Bekapcsoltuk
  • Q&A: kikapcsoltuk

Átnéztük a preview feature-öket is. Ezeket kikapcsoltuk, de látókör tágítónak behoztam a Discourage implicit measures feature-t és TMDL-t. Ezek fontosságán elfilóztunk.

Power Query mappák

Átbeszéltük, hogy Power Query-ben és STAGE-elni fogunk, azaz a nyers táblák lekérdezéseit külön mappákba gyűjtjük:

Power Query Staging mappák

A STAGE típusos stage lesz, azaz csak típuskonverziókat tartalmaz, más transzformációkat nem. Az oszlopok nevét nem bántjuk, a táblákat nem materializáljuk a memóriába, amig két vagy több tábla nem hivatkozik rá.

Létrehoztunk a connection stringek tárolására is egy mappát és megbeszéltük, hogy a connection string összeállításához szükséges paramétereket itt tároljuk majd.

Power Query paraméterek

Megbeszéltük, hogy a deployment folyamat támogatására a conmnection string elemeit paraméterekben tároljuk, a leggyakrabban használt forrásrendszerek kapcsolati adatait előre kitöltjük.

Referencia táblák

Átbeszéltük, hogy milyen referencia táblákra lesz szükségünk. Az alábbiakban állapodtunk

  • Dátum
  • Áthelyezett munkanapok
  • Idő
  • Régió

Megbeszéltük, hogy ezeket generálhatjuk is vagy tárolhatjuk beégetve a Power BI fájlban is, de úgy döntöttünk, hogy inkább betesszük őket az adattárba, rendelünk hozzájuk karbantartó felelőst, és onnan importáljuk majd be a Power BI-ba.

Power BI-ban beállítjuk a referencia táblák oszlopainak rendezési sorrendjét, elrejtjük a rendezési célt szolgáló oszlopokat.

A dátum táblát megjelöljük dátum táblaként.

Technikai táblák

Power BI ban létrehozunk DAX-szal generált „placeholder” táblákat, amelyek azt a célt szolgálják, hogy elkülönítsük egymástól az általánosan használt modell szintű számított mezőket a

A fentieken kívül létrehozunk a metaadatok tárolásra is egy táblát is, melynek tartalmát az info oldalon jelenítjük meg. Úgy ahogy itt le van írva

A technikai táblákat DAX-ból generáljuk  a

Riport lap minta

Elrendezés

Megbeszéltük, hogy hogyan épüljenek fel a standard riport lapok. Hol legyenek a szeletelők, középen legyen a cím vagy balra rendezve, hol legyenek a kötelező elemek: Utolsó frissítés dátuma, forrás megjelölés, gomb a további infó lapra, stb.

Megnéztünk pár céges Power Point prezentációt, átnéztük az arculati kézikönyvet és megbeszéltük, hogy mit vihetünk el az ott látott dizájnból, és mivel fogunk szakítani. Beszéltünk a a céges logókról, annak fontosságáról, vagy haszontalanságáról, és az adat/tinta arányáról

Megbeszéltük, hogy nem érdemes az elrendezés szabályozását túltolni, mert az élet úgyis felülírja azt. Helyette csinálunk összesen egy db riport lap mintát, ahol úgy jelennek meg a kötelező elemek, ahogy azt standard jónak gondoljuk. Láttunk rá példát ahol az elrendezést túlszabályozták és emiatt senki sem használta a sablonfájlt. Szóval csak óvatosan, egy riport lap rajta a kötelező elemekkel elég hogy mutassa az irányt.

Riport lapok beállítása

Jelentés nézetben kikapcsoltuk a szűrőpanel megjelenítését, mondván hogy ha valahol lehetőséget akarunk biztosítani a felhasználóknak a szűrések megváltoztatására, akkor arra szeletelőket fogunk használni.

Kötelező elemek

Megbeszéltük, hogy milyen kötelező elemei lesznek a riport lapnak:

  • Cím, ami lehetőleg legyen kérdés, beleszínkódolva a jelmagyarázat
  • Utolsó frissítés dátuma: Megbeszéltük hogy mi legyen: A frissítés dátuma? Vagy az utolsó adat? Vagy a zárás dátuma?
  • Forrásmegjelölés: Megbeszéltük, hogy a csapat által készített riportokon mindig ott lesz, hogy „forrás: Adatmenedzsment csoport” Ez egyfeleöl brand-, másfelöl bizalomépítő eszköz is.
  • link az infó oldalra: Megbeszéltük, hogy gomb lesz az utolsó frissítés dátuma mellett ami átrepít minket az info lapra.

További Lapok

Megbeszéltük, hogy a következő oldalakat tesszük a sablonfájlba:

  • Kezdőlap: Minden riportunknak lesz egy kezdőlapja, a felhasználók ide lépnek be, innen navigálnak tovább. Ez lehet egy tartalomjegyzék, egy összefoglaló oldal KPI-okkal, jöhetnek ide szöveges összefoglalók is, stb. Ezt majd mindenki eldönti maga.
  • Riportlap: Csinálunk egy üres riportoldalt rajta a kötelező elemekkel és a standard elrendezéssel. (Ezt az oldalt fogják majd a fejlesztők másolni, ha új riportot akarnak létrehozni.). Lásd az említett riport lap minta

Megbeszéltük, hogy beteszünk a sablonba pár rejtett, de linkekkel elérhető oldalt is:

  • Info oldal: Megnéztük, hogy milyen infó oldalt használ az MNB és Parlament, megbeszéltük hogy az infó oldalra jönnek majd a mutatószámok definíciója és a módszertani definíciók is.
  • meta oldal: Ez lesz a riport kisérőlapja. Olyan információk lesznek itt, mint a ki rendelte a riportot, ki fejlesztette a riportot, ki az üzleti és az IT kapcsolattartó akit keresni lehet, mikor várható a riport következő frissítése, hogyan kérhetek hozzá jogosultságot másoknak, stb. Mutattam is rá egy példát

És megbeszéltük, hogy beteszünk a sablonfájlba pár rejtett, linkekkel sem elérhető árva technikai oldalt

  • fejlesztői dokumentáció: Ide írjuk majd a fejlesztői dokumentációt, szokásostól eltérő megoldásokat, fejlesztési irányelveket, névkonvenciókat. Ha utóbbiaknak lesz majd dokumentumtára, akkor ide csak egy linket teszünk, ami a dokumentumokra mutat.
  • Verziók: Itt követjük majd nyomon a verzióváltozásokat

Stílusfájl (Power BI theme/téma fájl)

Megbeszéltük, hogy minden formázási stílust kiteszünk külön stílusfájlba (Power BI theme fájl). A stílusfájl egy olyan JSON fájl, ami leírja a riportokon használt objektumok alapértelmezett beállításait.

Megbeszéltük, hogy a sablonfájl nem tartalmaz semmilyen formázást, mindent egy szeparált stílusfájlban definiálunk és onnan importálunk be. 

Megnéztük, hogy hogyan lehet stílusfájlt (Power BI theme/téma fájl) definiálni. Megbeszéltük, hogy a Power BI theme/téma szerkesztőjén keresztül csak kevés formázást tudunk beállítani, de a JSON fájlban minden alapértelmezett formázási lehetőséget meg lehet változtatni, úgyhogy mindent a JSON fájlban fogunk megvalósítani. Ehhez vittem egy könyvet (Pro Power BI Theme Creation), amiben minden le van írva, ami ehhez szükséges.

A stílussal kapcsolatban megbeszéltük a színeket (harmónia, kontraszt, színtévesztők) és hogy az identitást nem csak azzal lehet kifejezni, hogy a grafikonokon csak az arculati kézikönyvben szereplő színeket használjuk. Vannak ennél sokkal fontosabb szempontok is, mint pl. a kontraszt, vagy a színek jelentése.

Megbeszéltük, hogy grafikust nem vonunk be. Akárhányszor kértük a segítségüket, sosem azt kaptuk amit kértünk. Az adatvizualizációs legjobb gyakorlatokat nem ismerik, nekik sokkal fontosabb a dizájn mint a jelentés. Nekünk nem.

Legjobb adatvizualizációs gyakorlatok

És végül beszéltünk pár szót az adatvizualiációs best practice-ekről: Hogyan lehet grafikonokkal hazudni, hogyan dolgozza fel az emberi agy a dashboardokat, stb. Mert bár ez nem tartozik szigorúan a sablonfájl témához, de úgy éreztem, hogy a csapatnak fontos lenne erről is beszélni.

 

Háát valahogy így ment egy sablonfájl közös tervezése :-)  Tanulságos volt abból a szempontból, hogy bár a sablon fájl volt a téma, de nagyon sok best practice-t el tudtam magyarázni az építés közben. Azon még gondolkodom, hogy a haladó Power BI képzés tematikájába beillesszem-e, mert nagyon sok időt vesz el. De kihelyezett, vagy on-the-job Power BI képzéseken kérhetitek, ha Ti is fontosnak érzitek.

Kővári Attila - BI projekt

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2024. június 13.-i Power BI workshopra vagy rendeljen kihelyezett képzést! Részletek >>

 

Új hozzászólás