Aangepaste Power BI visualisaties met Deneb
Met enige regelmaat krijgen wij de vraag om bepaalde data te visualiseren op een manier die niet mogelijk is met de standaard visualisaties van Power BI. Je kunt natuurlijk vanuit de AppSource marktplaats verschillende aanvullende visualisaties installeren maar toch vind je daar niet altijd precies wat je voor ogen hebt. Nu heb je de mogelijkheid om zelf een volledig nieuwe visualisatie te programmeren maar dat is voor de meesten van ons niet weggelegd. Gelukkig zijn er ook goede middenwegen, zoals Charticulator of Deneb. Dit artikel gaat over Deneb. Lees ook het artikel over Charticulator.
Waarschuwing! Voordat je verder gaat…
Voordat je een rapport maakt met een niet-standaard meegeleverde visualisatie, is het verstandig je te realiseren dat de ondersteuning van bijna iedere andere visualisatie ophoudt “bij de deur”. Je introduceert dus een technische onderhoudsschuld door deze te gebruiken.
Wat is Deneb?
Deneb is een gecertificeerde visualisatie voor Power BI, waarin je met declaratieve JSON-syntax van de programmeertalen Vega of Vega-Lite jouw eigen datavisualisaties maakt.
Deneb installeren
Klik in Power BI Desktop of de Power BI Service in het visualisatiepaneel op de drie puntjes, kies ‘Get more visuals’ en zoek naar Deneb. In het volgende scherm klik je ‘Add’ en Deneb wordt als visualisatie toegevoegd aan het paneel om te gebruiken in je rapport.
Hoe werkt Deneb?
Wanneer je de Deneb visualisatie op je canvas sleept, verschijnt een beknopte handleiding met links naar de online documentatie.
Voeg tenminste een meetwaarde en een dimensie-attribuut toe aan de gegevens voor de visualisatie, net zoals je met de standaard-visualisaties doet. Klik vervolgens in het Header-menu op ‘Edit’ om naar de Deneb-configuratie te gaan.
Je krijgt het setup-scherm gepresenteerd, waarin je kunt kiezen of je Vega of Vega-Lite wilt gebruiken. Deze keuze kunt je later aanpassen. Kies een voorbeeld-template, of laadt een eerder opgeslagen of van het internet gedownload template.
Configuratie
Voor dit artikel kiezen we voor Vega-Lite en selecteren we het meegeleverde template ‘Interactief staafdiagram’.
Voeg het dimensie-attribuut toe aan het categorie-veld en de meetwaarde in het measure-veld.
Na de basis-setup van het gekozen template, kom je in het gedetailleerde configuratiescherm. Links kun je kiezen uit de specificatie (het template), eventuele configuratie daarvan en algemene visualisatie-instellingen.
De editor
Rechts is een voorbeeld van de visualisatie weergegeven met daaronder de geselecteerde data, inclusief metadata, eventuele signalen vanuit de rest van het rapport (denk aan filters en slicers) en log-regels die tijdens het verwerken van de data en het template door de Deneb render-engine gegenereerd zijn.
Een beperkt deel van de opmaak van de uiteindelijke visual is via het normale Power BI opmaak-paneel vorm te geven. Daarin kun je ook de weergave van de Deneb editor aanpassen aan jouw eigen voorkeuren. Houd er rekening mee dat je verder alles van jouw visual zelf moet ‘declareren’. Deneb weet niet hoe jij de data wilt visualiseren, dat zul je dus zelf moeten definiëren.
Wanneer je klaar bent met de configuratie, klik je ‘Back to report’ linksboven de editor om terug te gaan naar het Power BI canvas, waar de nieuw gedefinieerde visualisatie nu zichtbaar is.
Deneb visualisaties kunnen in principe net als andere visualisaties reageren op selecties in andere visualisaties, zowel via filtering als via highlighting. Standaard staat deze functionaliteit echter uit. Voordat je deze functies aanzet voor jouw zelfgemaakte visualisatie, is het goed om de documentatie hierover door te nemen.
Vega en Vega-Lite
Zoals als genoemd, definieer je de visualisatie zelf in de programmeertalen Vega of Vega-Lite. Dit zijn beschrijvende talen in JSON-syntax. Dat wil zeggen dat je in JSON-formaat definieert hoe het eindresultaat eruit moet zien. Deneb regelt de daadwerkelijke visualisatie vervolgens.
Het voert voor dit artikel te ver om in te gaan op alle mogelijkheden die Vega en Vega-Lite bieden. Online is hierover ruime documentatie vindbaar. Een goed startpunt is het GitHub repository van Adrzej Leszkiewicz met tientallen vrij te gebruiken templates (MIT-licentie).
Hergebruik van configuratie
Wanneer je zelf een mooie visualisatie gemaakt hebt, wil je deze waarschijnlijk vaker gebruiken. Hiervoor heeft Deneb in het configuratiescherm een export-knop gemaakt. Klik op de knop en sla jouw definitie op als JSON template om in een volgend rapport opnieuw te gebruiken.
Tot slot
De leercurve van zelfs Vega-Lite is vrij steil. Bereid je daarom voor op analyse van wat anderen maakten, het lezen van de online documentatie en veel experimenteren. Als je het echter eenmaal onder de knie hebt, is de sky the limit, getuige onderstaande afbeeldingen.
| |
|
|
|
Row-level security en security filtering behavior
Met row-level security kan eenvoudig op data gebaseerde filtering worden toegevoegd aan een semantisch model. Door gebruik te maken van de gebruikersnaam van de ingelogde gebruiker kan dit ook dynamisch worden gemaakt. Hier is natuurlijk al veel over geschreven. Laatst werd me echter gevraagd om de security zo in te richten dat men op een hoger niveau altijd alle data mocht zien, maar alleen de detail informatie van het eigen team of afdeling. Ter verduidelijking: Op hoofdniveau mag men alle omzet zien, maar op detailniveau alleen de klanten van Nederland.
Wat is RLS
Rol-level security is het filteren van de data op basis van bepaalde security regels. Dit wordt binnen Power BI vaak toegepast door middel van het definiëren van verschillende rollen. Binnen deze rollen kan de data dan gefilterd worden. Men mag alleen data zien van een bepaald bedrijf, een bepaald land of een bepaalde Business Unit. Door deze security afhankelijk te maken van de gebruiker kan het onderhoud en de hoeveelheid rollen sterk worden verminderd.
Security filtering behavior
De manier waarop de security wordt geïnterpreteerd door het model kan beïnvloed worden met de setting "security filtering behavior". Deze setting kan per relatie worden ingesteld. Door middel van scripting kan dit eventueel worden geautomatiseerd. In de basis zijn er 3 instellingen mogelijk:
- OneDirection
De records die zijn gefilterd aan de "To" kant van de relatie filteren automatisch de records aan de "From" kant - BothDirections
De filtering aan beide kanten van de relatie heeft invloed op de filtering aan de andere kant. - None
Er vindt geen filtering plaats aan beide kanten van de relatie.
Als voorbeeld heb ik een model genomen met dynamische filtering op het land van de klant. De row-level filtering is ingesteld op de klanttabel. De testgebruiker heeft alleen toegang tot de klanten in Nederland. De overige klanten mag deze gebruiker niet zien.
OneDirection
De standaard instelling voor de security setting is "OneDirection". Dit betekent dus dat de klanttabel wordt gefilterd op de klanten in Nederland. De relatie ligt vanaf de feitentabel (omzet) naar de klant. Dus de feiten tabel wordt ook gefilterd op de klanten uit Nederland. De omzet die getoond wordt in de verschillende tabellen is dus alleen de omzet ven Nederland. De filtering werkt alleen op de relaties met de klanttabel, dus de slicer met functies van contactpersonen wordt niet gefilterd.
BothDirections
Door de setting "BothDirections" te gebruiken worden de tabellen aan beide kanten van een relatie gefilterd. De relatie tussen de feitentabel en de klantentabel wordt met RLS aan de "To" kant al gefilterd. Deze relatie hoeft dus niet op "BothDirections" te worden gezet. Als we echter de relatie tussen de feitentabel en de contacttabel op "BothDirections" zetten zien we dat ook de slicer op de functie van de klant wordt gefilterd. De gebruiker ziet nu dus ook alleen nog maar contacten gerelateerd aan Nederlandse klanten.
None
Door de security setting op "None" te zetten wordt er dus niet meer gefilterd door middel van een relatie. Omdat de row-level security op de klanttabel staat kan men in de feitentabel dus de volledige omzet zien, maar zodra deze op klantniveau wordt bekeken ziet men alleen Nederland. Op deze manier kan er dus voor worden gezorgd dat de volledige cijfers wel op hoofdniveau te raadplegen zijn, maar niet op detailniveau.
Security testen
Met de Power BI service kan de security eenvoudig worden getest. Daarover kan je meer lezen in een eerdere blog die ik geschreven heb. https://www.ensior.com/actueel/blogs/1566-security-in-de-power-bi-service Inmiddels is het testen van de security iets aangepast. Tegenwoordig kan er ook geschakeld worden tussen rapporten bij het testen van de rol als een bepaalde gebruiker. De rapporten moeten dan wel in dezelfde werkruimte staan.
Conclusie
Door met de verschillende security parameters te spelen kan de filtering volledig naar eigen hand worden ingeregeld. Vaak voldoet de standaard filtering al voor de meeste behoeftes, maar indien nodig kan dit gedrag worden aangepast. Vooral voor het verbergen van bepaalde detail informatie kan dit erg handig zijn.
Power BI - Deployment Pipelines
Binnen Power BI kunnen Deployment Pipelines (Implementatiepijplijnen) worden gebruikt om content naar verschillende werkruimtes te deployen. Deze pipelines worden veelal gebruikt om rapporten en/of modellen de promoten van development naar bijvoorbeeld test en productie werkruimtes. In het begin was het gebruik van pipelines uitsluitend mogelijk met een Premium Capacity licentie, maar tegenwoordig zijn de ook beschikbaar voor Premium Per User gebruikers.
Power BI Field Parameters en Calculation Groups
In deze blog kijken we eens naar de nieuwe functies Field parameters en Calculation Groups in Power BI en hoe we deze zowel in Power Desktop als in Tabular Editor kunnen gebruiken.
