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:

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

• vizualizációkhoz használt lokális számított mezőktől (mert a visual calculation nem váltja be maradéktalanul a hozzá fűzött reményeket, és Power BI Report Server-es vááltzatában még nem támogatott)
• a szeletelők szinkronizálására használt számított mezőtől (mert ebből a célból sosem használunk kétirányú kapcsolatokat)
• A dinamikusan frissülő diagram címeket előállító számított mezőktől (Részletek itt)

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

• DATATABLE ("Oszlop neve", STRING, {{BLANK()}})
• vagy a ROW() függvénnyel.

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 egyfelö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

• Ellenőrző riport: Ide tesszük majd az összes olyan adatellenőrzést, amely segítségével a a riport gazdája meggyőződhet az adatok helyességéről, teljességéről. Itt jellemzően előző napi, heti, havi adatokhoz hasonlítjuk az utolsó adatot, kimutatjuk, hogy hol van adathiány (meg nem érkezett adatok, ki nem töltött kategóriák, hiányzó árak, stb) és megmutatjuk, hogy hol találunk kiugró értéket, vagy az átlagtól több szórással eltérő számot.  
• 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.