Im folgenden Artikel betrachten wir einen beispielhaften Aufbau eines Power BI Reports, der mittels anderer Tools der Power Platform um eine Kommentierungs/Korrekturfunktion und einen Freigabeprozess erweitert wurde.

Power Platform

Die Microsoft Power Platform ist ein codearmes Toolset (Low-Code-Plattform). Sie bietet statt den üblichen textbasierten Programmiertechniken visuelle Methoden für die Softwareenetwicklung. Hauptsächlich setzt sich Microsoft Power Platform aus den vier Schlüsselprodukten Power Apps, Power Automate, Power BI und Power Virtual Agents zusammen. Unter den aufgeführten Programmen gibt es Querschnittsfunktionen und verschiedene Konnektoren, die die Kommunikation untereinander ermöglichen. Weiterhin gehören das Microsoft Dataverse und Microsoft Azure zur Microsoft Power Platform. Microsoft Azure nimmt hierbei eine besondere Rolle ein, denn die Services der vier Schlüsselprodukte basieren auf Microsoft Azure und Azure kann genutzt werden, um die Kapazitäten der Microsoft Power Platform zu erweitern. Zusätzlich kann man die bekannten Services von Microsoft 365 in Power Platform integrieren und Nutzen.

Power Apps

Power Apps ist ein abonnementbasierter Dienst zur Erstellung von Anwendungen. Er bietet eine "Low-Code"-Entwicklungsumgebung und ist daher auch für Benutzer ohne Programmierkenntnisse geeignet. Man muss kein ausgebildeter Softwareentwickler sein, um Power Apps zu nutzen. Microsoft verwendet den Ausdruck "Citizen Developer", um den Zielbenutzer des Produkts zu beschreiben. Das kann ein Manager, ein Büroangestellter oder ein Mitarbeiter mit einer Hauptaufgabe außerhalb der IT sein. Eine typische App stellt eine Verbindung zu Daten her und enthält Bildschirme zur Anzeige und Bearbeitung von Daten. Power Apps ist ein Business-Tool zur Erstellung von Anwendungen, die Geschäftsprozesse erleichtern. Es handelt sich nicht um ein Werkzeug für die Erstellung von Anwendungen für Verbraucher, z. B. Spiele für den Verkauf über App Stores oder mobile Anwendungen, die einen nativen Low-Level-Zugriff auf Hardware-Geräte erfordern. Für diese Zwecke gibt es andere Tools und Plattformen, die besser geeignet sind.

Power Automate

Power Automate ist ein Workflow-Tool, das die Automatisierung von Prozessen innerhalb und außerhalb der Microsoft 365-Suite Technologien ermöglicht. Es bietet externe Konnektoren und die Möglichkeit zur Erstellung benutzerdefinierter externer Konnektoren zu und von anderen Technologien. Power Automate ist cloudbasiert und bietet eine Möglichkeit zur Prozessautomatierung von Abläufen, welche ständig wiederholt werden müssen. Dafür werden sogenannte Trigger (zu Deutsch Auslöser) festgelegt, welche bei ihrem Auftreten eine automasierte Reaktion bewirken.

Power BI

Power BI ist ein Self Service BI Tool der Office 365 Produktfamilie von Microsoft, dessen Ziel es ist, interaktive Visualisierungen mit einer Oberfläche bereitzustellen, über die der Endbenutzer seine eigenen Berichte und Dashboards erstellen kann. Zudem wird durch die Vollintegration im Microsoft Umfeld die Kommunikation unter den verschiedenen Produkten gewährleistet. Eine große Auswahl von Konnektoren ermöglicht, interne und externe Quellen anzubinden und die jeweiligen Daten entsprechend aufzubereiten.

Datenkonnektoren

Konnektoren bilden eine Schnittstelle, die es der Power Plattform ermöglicht, mit den zugrunde liegenden Diensten zu kommunizieren. Dabei stellt der Konnektor eine Verbindung zwischen der App und der jeweiligen Datenquelle her. Es wird zwischen zwei Arten von Datenquellen unterschieden – tabellarisch und aktionsbasiert. Tabellarische Datenquellen liefern Daten strukturiert im Tabellenformat, wohingegen mit aktionsbasierten Datenquellen über vorgefertigte Funktionen interagiert werden kann.

Microsoft unterteilt die Konnektoren in drei Kategorien:

• Standard-Konnektoren: Bieten Anschlussmöglichkeiten zu häufig verwendeten Datenquellen, wie SharePoint, OneDrive und Outlook. Diese sind im Standard-Benutzerplan enthalten.

• Premium-Konnektoren: Bieten Anschlussmöglichkeiten zu weiteren Datenquellen wie SQL-Servern oder Azure Key Vaults. Premium-Konnektoren erfordern eine zusätzliche Lizenzierung für die Entwicklung der App und müssen daher bei der Kostenbetrachtung einbezogen werden.

• Benutzerdefinierte Konnektoren: Dabei hat der Anwender die Möglichkeit eigene Datenquellen anzubinden, die in der Konnektorenliste nicht auftauchen

Ist-Erhebung

Aufgabe der App soll sein, die Beschreibung und Bewertung einer KPI zu vereinfachen. Im Beispiel ergeben sich die Parameter aus Kosten, die keiner bestimmten Geschäftseinheit oder Funktion zuzuordnen sind, sondern der Kostenstelle oder dem Unternehmen als Ganzes zugutekommen. Ziel der Führungsebene ist, anhand der Bewertungen der KPI die Kosten so weit wie möglich zu senken, da diese keinen direkten Einfluss auf die Waren oder Dienstleistungen haben, die den Kunden angeboten werden. In der Ist-Erhebung wird lediglich der Kommentierungsprozess betrachtet, da nur dieser automatisiert werden soll. Die vorhergehenden Schritte, wie Aggregation und Bewertung der Daten bleiben unverändert.

Datenspeicherung

Aktuell werden die KPIs in einem klassischen Data Warehouse gespeichert. Dabei werden die KPIs selbst in einer On-Premise SQL-Datenbank abgelegt. Die Kommentierungen werden separat in einer SharePoint-Liste geführt, auf die alle Mitarbeiter Zugriff haben, die am Prozess beteiligt sind. Dadurch sehen auch Mitarbeiter Daten eines Teilbereiches, welchem sie nicht zugeordnet sind. Da die Kommentierungen monatlich stattfinden sollen, muss die Liste monatlich manuell aktualisiert und die vorhergegangene Liste archiviert werden, um die Bewertungen auch nachträglich einsehbar zu halten.

Datenvisualisierung

Zur Visualisierung der KPIs wird ein Power BI-Report verwendet, welcher die Daten aggregiert und mit den Kommentierungen aus der SharePoint-Liste verknüpft. Dafür werden die Daten in regelmäßigen Zeitabständen über einen ETL-Prozess in den Report überführt. Mittels Filter werden die Daten separiert und den zugehörigen Teilbereichen zugeordnet.

Kommentierung

Um eine Kommentierung eines bestimmten KPI vorzunehmen, muss der zuständige Mitarbeiter zunächst den Report einsehen und die Daten analysieren. Anschließend muss der Kommentar, mit dem für den KPI verantwortlichen Vorgesetzten abgestimmt werden. Dieser Vorgesetzte bestimmt dann, ob der Kommentar so in den Report übernommen werden kann. Sollte der Kommentar eingebunden werden, muss der zuständige Mitarbeiter die SharePoint-Liste aufrufen und die für seinen Bereich zuständige Zeile aufsuchen. Dort kann er den Kommentar dann einfügen, der dann zeitverzögert erst mit dem nächsten Ablauf des ETL-Prozesses in den Report übertragen wird. Folgendes Abbildung zeigt einen Auszug aus der SharePoint-Liste, die zur Kommentierung bisher verwendet wird.

Projektziel

Ziel ist die Implementierung einer Kommentarfunktion direkt in den Power BI-Report. Dabei soll der vorhandene Report 1:1 abgebildet werden und das Kommentarfenster als Eingabemöglichkeit genutzt werden. Dieses Eingabefenster soll einen Freigabeprozess anstoßen, der entscheidet, ob der Kommentar final in den Report übernommen wird, oder nicht.

• Zentrales System: In einem Power BI Report sollen alle Daten zusammenlaufen. Der Bericht soll über ein Berechtigungskonzept und eine Bearbeitungsfunktion verfügen.

• Interne Anbindung: Anbindung aller Daten und Kommentare aus den betroffenen Bereichen.

• Ausbaufähigkeit: Weitere Funktionalitäten, wie Power Virtual Agents, sollen möglichst einfach und schnell zusätzlich implementiert werden können.

• Darstellung: Der Power BI Report soll die Daten ebenfalls plattformübergreifend und dem Berechtigungskonzept entsprechend visualisieren.

• Kommentarfunktion: Kernziel des Projektes ist die Kommentarfunktion, die in den Power BI Report eingebunden werden soll. Die Funktion soll automatisiert einen Freigabeprozess anstoßen, der entscheidet, ob der Kommentar in den Bericht übernommen oder verworfen wird.

• Rechteverwaltung: Das Berechtigungskonzept soll auf einer Rechteverwaltung basieren, nach der einem Nutzer oder einer Nutzergruppe Rechte erteilt und entzogen werden können.

• Mobile Ansicht: Da die Power Platform die Anbindung mobiler Endgeräte ermöglicht, sollen diese ebenfalls über dieselben Funktionen wie die Desktopansicht verfügen. Sprich Ansicht und Kommentierung der Daten.

Unterscheidung zwischen Konnektor und Datenfluss

Bei einem Konnektor handelt es sich um eine Funktion in Power Apps, mit der eine Verbindung zu Systemen und Quellen hergestellt werden kann, in denen Daten direkt abgerufen oder gespeichert werden können. Ein Datenfluss ist eine Funktion in Power Apps, die Daten aus anderen Systemen extrahiert, transformiert und in Dataverse laden kann. Hier erfolgt der Datenabruf in einem geplanten Batch und die Daten können vor der Speicherung bearbeitet, bereinigt und umgewandelt werden und müssen nicht im Istzustand abgerufen werden.

Da in der App für die Kommentierung neue Daten gespeichert und bestehende Daten verändert werden sollen, muss hier auf einen Konnektor zurückgegriffen werden, da dies mit einem Datenfluss nicht realisierbar ist. Die KPIs werden weiterhin in einem SQL-Verzeichnis abgelegt. Die Befüllung des Verzeichnisses geschieht über den bestehenden ETL-Prozess, in dem lediglich das Zielverzeichnis geändert wird. Aufgrund dessen, dass die SQL Managed Instance nicht teil des Microsoft Datverse ist, muss auch hier ein Konnektor verwendet werden. Für die Realisierung der App sollen weitestgehend im Unternehmen bereits etablierte Methoden zur Datenspeicherung verwendet werden. Da schon ein ETL-Prozess für das Beladen der aktuell genutzten Datenbank vorhanden ist, wird auf diesem aufgebaut. Dieser ist für die Einbindung in SharePoint nicht geeignet. Deswegen wird auch bei der Umsetzung der App auf eine SQL-Datenbank gesetzt. Diese soll sich in der SQL Managed Instance einer Azure Subscription befinden. Aufgrunddessen, dass die Managed Instance innerhalb der Subscription als On-Premise Dienst zu verstehen ist, muss für die Anbindung an die App ein On-Premise Datagateway genutzt werden. Zur Speicherung der Kommentare wird innerhalb der App ebenfalls dieses SQL-Verzeichnis verwendet, da die Verbindung zu diesem bereits aufgebaut werden muss.

Sicherheitskonzept

Zur Erstellung eines Sicherheitskonzepts werden zunächst Sicherheitsrollen angelegt und Berechtigungen zugeordnet. Dabei steht eine Sicherheitsrolle dafür, wie eine bestimmte Persona auf einen Datensatz zugreifen kann. Eine Sicherheitsrolle umfasst sowohl Berechtigungen auf Datensatzebene als auch auf Aufgabenebene.

Dabei nimmt der Entwickler die gleichnamige Rolle ein, die ihn berechtigt, den kompletten Report einzusehen, zu bearbeiten und auf Datensatzebene zu arbeiten.

Die Fachseite ist lediglich berechtigt, den für die Person betreffende Ansichten einzusehen und zu kommentieren. Die Rolle wird folgend als Mitwirkender bezeichnet.

Der Abteilungsleiter und die Unternehmensführung nehmen die Rolle Besitzer ein, die sie für die Einsicht und Kommentierung des gesamten Reports berechtigt.

Alle getätigten Kommentierungen stoßen den Freigabeprozess an.

Die Personas werden nach Position und Abteilung in verschiedene Gruppen im AAD eingeordnet.

Sicherheit in der App

Der Zugriff zur App ist nur Stakeholdern gestattet, die einer der oben genannten Gruppen zugeordnet sind. Der Zugriff durch weitere Personen ist nicht möglich.

Sicherheit im Power BI Report

In Power BI wird der Report über eine Row-Level-Security abgesichert. Die Row-LevelSecurity prüft anhand einer weiteren Tabelle, welche Rolle für welche Ansichten berechtigt ist.

Sicherheit auf Datensatzebene

Auf Datensatzebene hat neben dem Entwickler nur ein weiterer technischer Nutzer Zugriff, welcher den routinemäßig ablaufenden ETL-Prozess gegenüber der Managed Instance authentifiziert.

Realisierung

App erstellen

Um eine App in Power Apps zu erstellen, kann man mit einer leeren App starten, oder aus vorgefertigten Vorlagen auswählen. Die Vorlagen unterscheiden sich in Layout oder den schon bereitgestellten Konnektoren.

Da keine Vorlage für eine App, die auf einer SQL-Datenbank basiert existiert, wird eine leere Canvas App erzeugt.

Daten anbinden

Einrichten des Datagateways

Zur Installation des Datagateways wurde eine eigene virtuelle Maschine angelegt, auf der nur das Datagateway selbst und die Nutzerverwaltung laufen. Das Gateway kann im persönlichen oder im Standardmodus eingerichtet werden. Diese unterscheiden sich darin, dass im persönlichen Modus lediglich genau ein Benutzer eine Verbindung zwischen Power BI und einer lokalen Datenquelle anlegen kann. Im Standardmodus können viele Benutzer eine Verbindung von der kompletten Power Platform zu mehreren lokalen Datenquellen anlegen. Aus diesem Grund wurde sich für den Standardmodus entschieden.

Nachdem das On-Premise Datagateway installiert und konfiguriert wurde, kann dieses in der App in der SQL-Server Datenquelle ausgewählt werden. Um das Gateway zu installieren, muss man es von der Microsoftseite herunterladen. Der Installationsassistent begleitet den Nutzer durch die Konfiguration.

Auswählen der Datenquelle

Um die Datenquelle auszuwählen, muss im linken Menüband der Zylinder ausgewählt werden. Danach erscheint das „Daten hinzufügen“ Dropdown-Menü, welches alle für die App lizenzierten Konnektoren beinhaltet. In diesem Fall wird der Microsoft SQL-Server Konnektor verwendet.

Authentifizierung und Auswahl des Datagateways

Zur Auswahl des On-Premise Datagateways muss zunächst das Feld „Verbindung mithilfe eines lokalen Datengateways“ ausgewählt werden. Im Anschluss erscheint am unteren Bildschirmrand das Dropdown-Menü zur Auswahl des zuvor eingerichteten Datagateways.

Da für die Authentifizierung gegenüber der Datenquelle ein technischer Nutzer verwendet wird, der nur für die SQL Managed Instance und die Data Factory autorisiert ist, wird der Authentifizierungstyp „SQL-Server Authentication“ gewählt. Im Feld „SQL-Server Name“ muss die Adresse eingetragen werden, unter welcher die Managed Instance erreichbar ist. Weiter muss eine spezifische Datenbank angegeben werden. In diesem Fall ist das die „GA_DATAPOOL“. Für „Username“ und „Password“ werden die Login-Daten des technischen Nutzers verwendet. Wenn das Gateway korrekt installiert wurde und die Daten fehlerfrei eingegeben wurden, erhält man nun folgende Ansicht:

In dieser Einblendung können die für die App relevanten Tabellen der Datenbank ausgewählt werden. Nach erfolgreicher Verbindung mit den Daten erscheinen diese zur Verwendung im Menüband der App.

Erstellen prototypischer Ansichten

Für das Erstellen der prototypischen Ansichten in Power BI wird der gleiche Konnektor verwendet wie für die App zuvor. Nachdem die Daten in Power BI geladen wurden, können diese den Visuals zugeordnet werden. Die folgende Abbildung zeigt einen Power BI Report, der als Prototyp dient, um zu überprüfen, ob die Verbindung funktioniert und bei Datenänderung aktualisiert wird.

Erstellen eines App Protoypen

Die App wurde wie folgt aufgebaut:

• 1: Dropdown-Menü zur Auswahl des Monats.

• 2: Dropdown-Menü zur Auswahl der Seite.

• 3: Knopf, um den Kommentar zu speichern, oder zu aktualisieren.

• 4, 5, 6, 7: Auszug der Kommentarzeile mit dem Kommentar an erster Stelle und den weiteren Werten, die zuvor eingestellt wurden, als Kontrolle.

• 8: Kommentarfeld

Der Prototyp zeigt, dass das Konzept hinter der App funktioniert und so realisierbar ist. Mit einem Klick auf den Knopf (3) überschreibt der Wert aus dem Kommentarfeld (8) den bestehenden Wert in der Tabelle (7). Ist in 7 noch kein Wert vorhanden, so wird der Wert aus 8 ebenfalls übernommen.

Einbinden der App in Power BI

Zur Einbindung der App mit dem Kommentarfeld wird das PowerApp Visual in Power BI verwendet.

Das Power App Visual in Power BI zeigt eine Auswahlmöglichkeit, eine neue App zu erstellen, oder eine bestehende App zu verwenden. Da sowohl der Report, als auch die App an der selben Datenquelle angebunden sind, wird im weiteren Vorgehen der Prototyp mit einem weiteren Screen, der nur ein Kommentarfeld und einen Knopf beinhaltet, verwendet.

Dadurch, dass sowohl die App als auch der Report auf dieselbe Datenquelle zugreifen und miteinander verknüpft sind, übertragen sich in einem der beiden angewendete Filter auch auf das Andere. Dadurch ist schon gewährleistet, dass ein Kommentar nur dem zu sehenden Report zugeordnet wird. Sobald sich die Datenquelle ändert, werden die Daten der App und des Reports automatisch aktualisiert, da das Dataset, welches verwendet wird, die Daten per Push an die Komponenten verteilt. Ein Push-Dataset aktualisiert eigenständig die Daten der anhängenden Anwendungen, sobald sich ein Wert des Datasets verändert.

Erstellen eines Power Automate Flows

Darüberhinaus soll noch ein Power Automate Flow erstellt werden, welcher einen Freigabeprozess anstößt. Dieser Freigabeprozess soll den Abteilungsleiter informieren, sobald ein Kommentar hinzugefügt, oder verändert wird.

Der Power Automate Flow ist an den „Update Value“ Button geknüpft, welcher überprüft, ob überhaupt eine Eingabe getätigt wurde. Falls eine Eingabe getätigt wurde, startet dieser den Genehmigungsprozess, bei dem der Abteilungsleiter über eine Änderung informiert wird. Der Abteilungsleiter erhält eine E-Mail mit der geplanten Änderung. Über den Zeitraum, in dem der Flow unbeantwortet bleibt, liegt die geplante Änderung in einer Staging-Tabelle innerhalb des „GA_DATAPOOL“.

Sobald der Abteilungsleiter die Änderung akzeptiert, werden die Daten aus der Staging in die Zieltabelle übertragen und der Antragsteller erhält eine Bestätigungsmail.

Sollte der Abteilungsleiter die Änderung ablehnen, verbleiben die Daten in der Staging-Tabelle, da diese zur nächsten Änderung erneut überschrieben werden und der Antragsteller erhält eine Ablehnung per E-Mail.