Das Aufteilen einer Power BI Anwendung in eine DATASET-Anwendung und eine oder mehrere damit verbundene REPORT-Anwendungen ist eine sehr wichtige Architekturoption für die Realisierung zahlreicher Praxisanforderungen mit Power BI. Einerseits wird damit das arbeitsteilige gleichzeitige Arbeiten am Dataset (durch das "Daten Team") und an den Reports (durch die "Reporting Teams") möglich. Andererseits können damit auch differenzierte Zugangsberechtigungen zu Reports umgesetzt werden, die alle mit dem gleichen (zentralen) Dataset verbunden sind und damit garantiert die gleichen Daten anzeigen.
In Teil 1 dieser Blogbeitragsserie wurde die Vorgehensweise beim Splitting eines PBIX-Anwndung in eine DATASET- und eine REPORT-Anwendung vorgestellt, in diesem Teil 2 geht es jetzt um den Umgang mit Shared Datasets in der Praxis.
Architekturoptionen in Power BI
Nochmals zur Orientierung: in Power BI stehen über den "Normalfall" der kombinierten PBIX-Anwendung mehrere Architekturoptionen zur Verfügung, das "Shared Dataset" ist dabei die am einfachsten umzusetzende fortgeschrittene Option:
#1 Aktualisierung der Dataset- und der Report-Anwendung(en)
Die Aktualisierung des Datasets löst den Import aus den Datenquellen ("Processing") aus und erfolgt über diese Funktion, die ausschließlich den Power Usern am Workspaces zur Verfügung steht:
Die Aktualisierung des Reports löst den Refresh der Daten aus dem (eventuell in der Zwischenzeit aktualisierten) Dataset aus, die Funktion steht allen Usern zur Verfügung:
#2 Data Lineage View
Shared Dataset Architekturen werfen schnell die Frage auf, welche Reports Daten aus welchen Shared Datasets erhalten. Diese Frage wird optisch sehr ansprechend durch den sog. Data Lineage View beantwortet:
Diese Darstellung wird in der Standardansicht am Workspace über die Anzeigeoptionen aufgerufen:
#3 Report Level Measures
Die "Live Connection" zum Shared Dataset bedingt grundsätzlich, daß das Datenmodell des Datasets nicht verändert werden kann. Daher sind die meisten Modellierungsfunktionen in Power BI Desktop in der REPORT-Anwendung deaktiviert. Ausnahmsweise können aber in der REPORT-Anwendung neue (dezentrale) Measures angelegt werden - ergänzend zu den bereits bestehenden (zentralen) Measures aus der DATASET-Anwendung:
Diese Report Level Measures können derzeit nicht in Display Folder organisiert werden. Als Best Practice hat sich bei uns bewährt, die Measures in der DATASET-Anwendung vollständig in Ordnerstrukturen zu organisieren -> damit sind die Report Level Measures dann außerhalb dieser Ordnerstrukturen optisch leicht als solche zu erkennen.
Die Report Level Measures sind unserer Einschätzung nach ein sehr wichtiges Instrument, um möglichst agil neue Berichtsanwendungen entwickeln zu können.
#4 Gleichnamige Measures in beiden Anwendungen
Was geschieht, wenn ein (dezentrales) Report Level Measure unter dem gleichen Namen auch in der (zentralen) DATASET-Anwendung angelegt wird?
Die Lösung dazu ist gut gemacht: Das gleichnamige Report Level Measure wird mit einer Fehlermeldung deaktiviert, das Measure aus der DATASET-Anwendung hat also Vorrang bekommen. Leider aktualisieren sich die bereits auf das Report Level Measure erstellten Visuals automatisch auf das neue zentrale Measure.
Diese Visuals müssen also manuell auf das neue Meausure umgestellt werden:
Es gibt hier einen kleinen Bug: wird das Visual markiert, werden in der Feldliste beide gleichnamigen Measures als aktiv angezeigt.
Das inaktive Report Level Measure sollte schließlich gelöscht werden.
#5 Einschränkungen in der REPORT-Anwendung durch das Splitting
Einschränkungen sind uns nur iZm den Report Level Measures bekannt, hier gibt es leider gleich mehrere.
In der Textbox können keine dynamischen Links zu Report Level Measures erstellt werden, zumindest haben wir bislang keinen Kniff diesbezüglich entdeckt. Die Report Level Measures werden nicht vorgeschlagen und auch nicht erkannt, wenn diese getippt werden:
Best Practice: immer den Tabellennamen vor den Measurenamen tippen, damit funktioniert das Matching nach unseren (noch jungen) Erfahrungen immer.
Im Q&A Visual tritt der gleiche Effekt ein, das Report Level Measure wird auch hier nicht vorgeschlagen:
Das Smart Narratives Visual funktioniert - konsequenterweise - auch nicht nicht, sobald (nur noch) Report Level Measures auf der Berichtsseite verwendet werden:
#6 Neuerstellen des Shared Datasets im gleichen oder in einem anderen Workspace
Solange die DATASET-Anwendung durch einen Publish am gleichen Workspace lediglich aktualisiert wird, gibt es keine Probleme.
Wird die DATASET-Anwendung aber vom Workspace gelöscht und neu hochgeladen oder in einen anderen Workspace verlegt, wird eine neue interne ID für die DATASET-Anwendung vergeben und die bestehenden REPORT-Anwendungen können sich nicht mehr verbinden:
Beim Klick auf den Button Edit sollte dieser Dialog für den Reconnect erscheinen:
Best Practice: in unserer Praxis gibt es hier oft das Problem, daß der Dialog nicht erscheint und sich die PBIX-Anwendung aufhängt ... mit etwas Glück funktioniert der Reconnect bei späteren Versuchen. Wir hatten aber auch schon den Fall, daß sich eine Anwendung nicht mehr verbinden hat lassen und die Anwendung aus einer alten Sicherung (vor dem Splitting) neu aufgebaut werden mußte. Daher am besten die bestehende DATASET-Anwendung nicht löschen sondern zuerst die neue DATASET-Anwendung parallel bereitstellen und das alte Dataset erst nach dem erfolgreichen Wechsel der Live Connection löschen.
Übrigens: wird die DATASET-Anwendung vom Workspace gelöscht, werden auch die aktuell verbundenen REPORT-Anwendungen gelöscht ... falls keine PBIX-Entwicklungsdateien für diese Reports vorhanden sind, diese unbedingt vor einem solchen Schritt sichern!
#7 Cross Workspace Connections
Ein tolles Feature sind die Cross Workspace Connections. Das heißt, die REPORT-Anwendungen müssen nicht im gleichen Workspace wie die zugrundeliegende DATASET-Anwendung deployed werden, das eröffnet wichtige Möglichkeiten bei der Umsetzung von differenzierten Zugangsberechtigungen. In der Data Lineage View wird die Cross Worksapce Connection so dargestellt:
#8 Best Practices
Melissa Coats liefert in ihrem Blogbeitrag 5 Tips for separating Power BI Datasets and Reports sehr nützliche Best Practices zu diesem Thema:
- Tip 1: Publish Datasets to Separate "Data Workspaces" from "Report Workspaces"
- Tip 2: Use Report Pages to Document the Dataset
- Tip 3: Manage and Audit the Dataset Permissions
- Tip 4: Use Certified & Promoted Endorsements on Important Datasets and Dataflows
- Tip 5: Teach report creators how to use live connection mode
Quellen
https://www.coatesdatastrategies.com/blog/5-tips-for-separating-power-bi-datasets-and-reports
https://exceleratorbi.com.au/new-power-bi-reports-golden-dataset
https://data-marc.com/2019/01/24/move-from-single-to-a-multi-file-strategy
1 Gedanke zu „Power BI Shared Datasets: Teil 2 Praxisthemen“
Danke für den Artikel!
Die Links in den Quellen funktionieren nicht.