Continuous Integration (CI) ist ein bekanntes Konzept in der Softwareentwicklung. Es bezeichnet die regelmäßige Integration von Quellcode in das Hauptprogramm, um die Lauffähigkeit und Qualität zu testen. Continuous Deployment (CD) hingegen beschreibt die kontinuierliche Bereitstellung der entwickelten Lösungen an den Auftraggeber, damit diese getestet und validiert werden können. CD ist eng mit der CI-Technik verknüpft.

Im Umfeld von Microsoft Power BI wurde lange nach geeigneten Lösungen für CI/CD gesucht, was oft zu individuellen Ansätzen führte. Nun können mit Hilfe der sogenannten Power-BI-Projekte (PBIP) die Anforderungen an einen CI-Prozess realisiert werden. Obwohl CI ein wichtiger Bestandteil dieses Themas ist, liegt der Fokus dieses Artikels auf CD. Der Beitrag konzentriert sich auf die regelmäßige Bereitstellung der erstellten Artefakte (wie Berichte und Dashboards) auf verschiedenen Ebenen. Das CI-Thema wird im Zusammenhang mit PBIP behandelt, steht aber nicht im Mittelpunkt dieses Artikels. Stattdessen wird beleuchtet, wie Berichte und andere Artefakte in Test- und Produktionsumgebungen (nachfolgend als Ebenen bezeichnet) bereitgestellt werden. Die Anzahl der Ebenen kann variieren, jedoch sind mindestens zwei erforderlich. Ob diese Technologie vorhanden ist, hängt auch von der eingesetzten Lizenzierung ab, was ebenfalls in diesem Artikel noch näher erläutert werden wird.

Der Zweck dieses Prozesses besteht in der Regel darin, dass Entwickler:innen in ihrer persönlichen Entwicklungsumgebung oder in Teams gemeinsam an Berichten und Lösungen arbeiten, diese dann in einer allgemeinen Entwicklungsumgebung zentral bereitstellen und anschließend dem Auftraggeber zum Testen zur Verfügung stellen. Wenn der Test erfolgreich war und alle Anforderungen erfüllt sind, wird der Bericht oder das Artefakt in die Produktionsumgebung übertragen (Abb. 1).

Bereitstellungsmöglichkeiten

Die Integration von Microsoft-Power-BI-Berichten und weiteren Artefakten wie paginierten Berichten in den CD-Prozess kann je nach Anforderungen im Testprozess und den vorhandenen Lizenzen stark variieren. Dabei spielen nicht nur die Art der Lizenzen, sondern auch die verfügbaren Fähigkeiten eine wichtige Rolle. Für die Nutzung der Bereitstellungspipelines ist eine Premium- oder Fabric-Lizenz erforderlich. Die Verbindung zu Microsoft Azure DevOps setzt auch eine Fabric-Lizenz voraus, die schrittweise die Premiumlizenzen ersetzt – diese Lösung kann nicht mit einer Premiumlizenz durchgeführt werden. Es gibt verschiedene technische Möglichkeiten wie die Nutzung unterschiedlicher Zweige (in Quellcodeverwaltungssystemen auch als Branches bekannt, um Quellcode für unterschiedliche Features zu entwickeln) und Entwicklungsprozesse. Einige dieser Methoden und die zugehörigen Microsoft-Technologien werden nachfolgend genauer beleuchtet.

Microsoft Azure DevOps als Ablage- und Speicherort

Um Berichte und Artefakte effizient zu verwalten, sollten diese zuerst in einer Quellcodeverwaltung gespeichert werden. Eine bewährte Plattform dafür ist Microsoft Azure DevOps. Sie ermöglicht eine nahtlose Integration mit Microsoft Power BI, einschließlich Funktionen wie dem Auslösen einer Bereitstellungspipeline beim Hochladen neuer Dateien. Zwar bieten auch andere Quellcodeverwaltungssysteme teilweise Unterstützung für Microsoft Power BI, jedoch nicht in vollem Umfang. Daher ist die Kombination von Microsoft Power BI mit Azure DevOps besonders empfehlenswert, um eine vollständige Unterstützung und Integration zu gewährleisten.

Die Ablage in einer Quellcodeverwaltung bietet zwar keine nativen Continuous-Deployment-(CD)-Möglichkeiten, aber der Bericht einschließlich des Modells ist zentral verfügbar. Er muss nicht von einem lokalen Laufwerk gelesen werden. Das schützt die Dateien in einer Quellcodeverwaltung und das Modell vor ungewolltem Verlust durch Hardwaredefekte oder unvollständige Änderungen. Zudem können verschiedene Revisionen einfach verwaltet werden.

Ein häufiges Problem bei der Verwendung von Microsoft Power BI in Azure DevOps ist die Dateigröße. Bei Verwendung einer Liveverbindung tritt dieses Problem nur selten auf, da die Daten in der Quelle verbleiben. Bei hybriden Modellen, die teilweise importierte Daten enthalten, muss jedoch auch auf die Dateigröße geachtet werden. Der Importmodus kann die Dateigröße erheblich erhöhen, wodurch das Laden in Azure DevOps oft nicht mehr möglich ist. Hier kann auf Entwicklungsdaten zurückgegriffen werden, die nur einen Ausschnitt der Daten enthalten, oder es können Parameter genutzt werden, um beispielsweise nur die ersten 10 000 Zeilen zu importieren.

Es empfiehlt sich zudem, den Import auf nur die notwendigen Tabellen und Spalten zu beschränken, die auch in der Analyse verwendet werden. Das kann jedoch schwierig sein, wenn die Anforderungen noch nicht feststehen. Für die ersten Schritte gibt es unter anderem kostenfreie Werkzeuge, die anzeigen, welche Objekte nicht verwendet werden. Ein Parameter kann steuern, wie viele Daten aus der Datenquelle importiert werden, um die Datei auf einer unterstützten Größe zu halten. Dieser kann in späteren Bereitstellungsphasen angepasst werden, damit der Bericht für den Fachbereich alle Daten beinhaltet.

Es ist oft nicht notwendig, den kompletten Datenbestand in der Entwicklungsumgebung verfügbar zu haben. Häufig wird jedoch der Produktionsdatenbestand für die Entwicklung genutzt, was jedoch meistens nicht ideal ist. Entwicklungsdaten, die nur ein Subset der Produktionsdaten darstellen, sind meist ausreichend und bieten Vorteile, da die Entwicklung im Frontend schneller und effizienter ist. Es können auch individuelle Testdaten für die Entwicklung erstellt werden, allerdings müssen diese Daten alle Besonderheiten und Qualitätsprobleme der Produktionsdaten widerspiegeln. Die Entwicklung mit solchen Daten kann zeitaufwendiger sein, zahlt sich aber bei der weiteren Lösungs- oder Berichtsentwicklung aus und erfüllt Datenschutzanforderungen sowie interne Richtlinien.

Bei der Bereitstellung auf weiteren Ebenen kann die Quelle der Daten entsprechend angepasst werden. Diese Möglichkeit wird im Abschnitt über Bereitstellungspipelines detaillierter erklärt. Vorab sei erwähnt, dass andere Quellcodeverwaltungssysteme möglicherweise weniger strikte Größenbeschränkungen haben – jedoch auf Kosten anderer Funktionen im Microsoft-Power-BI-Umfeld.

Bereitstellung mit Hilfe von PowerShell

Mit PowerShell können Berichte und Microsoft-Power-BI-Dateien bereitgestellt werden. Das Skript in Listing 1 veröffentlicht sowohl den Bericht als auch das semantische Modell im angegebenen Arbeitsbereich. Auf diese Weise kann auch eine Continuous-Deployment-Lösung implementiert werden, jedoch muss dieser Prozess vollständig manuell eingerichtet werden. Das bedeutet, dass für die Bereitstellung in einer Test- oder Produktionsumgebung entweder Parameter verwendet oder separate Skripte erstellt werden müssen. Der hierfür notwendige Code kann auch einfach mit Hilfe von ChatGPT generiert werden. Anschließend müssen lediglich die Werte und die Anmeldung eingetragen werden.

# Installierung des Power-BI-PowerShell-Modul (wenn noch nicht installiert)

Install-Module-Name-MicrosoftPowerBIMgmt-Force-AllowClobber

# Authentifizierung des Power BI

Login-PowerBI
# Definierung des Pfads zur .pbix-Datei und den Zielarbeitsbereich

$filePath = "C:\Pfad\zu\IhrerDatei.pbix"

$workspaceName = "IhrArbeitsbereichName"

# Abrufen des Arbeitsbereichs$workspace = Get-PowerBIWorkspace-Name $workspaceName

# Importieren des Berichts

Import-PowerBIReport-Path $filePath-WorkspaceId$workspace.Id

Bereitstellung mit Microsoft Azure DevOps Release Pipeline

Mit diesem Portal beziehungsweise Werkzeug können Bereitstellungspipelines entwickelt werden, um Berichte verschiedener Ebenen auf anderen Ebenen zu integrieren. Bei der Verwendung von Microsoft Azure DevOps werden gleich zwei Fliegen mit einer Klappe geschlagen: Die Pipeline kann automatisch gestartet werden, sobald neuer Inhalt eingecheckt oder hochgeladen wird und außerdem kann ein Genehmigungsverfahren implementiert werden, um die BI-Berichte gemeinsam mit dem Fachbereich ordnungsgemäß bereitzustellen (Abb. 2).

Die Pipelines sind das Kernelement in diesem Kontext, da sie unter anderem die Automatisierung von PowerShell-Skripten ermöglichen. Dabei ist zu beachten, dass sowohl Microsoft als auch andere Autor:innen Erweiterungen anbieten, um Tätigkeiten wie das Bereitstellen von Berichten zu automatisieren. Falls die Datenquellen für verschiedene Ebenen variieren, können diese beispielsweise über Parameter in den PowerShell-Skripten angepasst werden, um den Parameterwert für die Datenquelle in der Weboberfläche zu ändern.

Zusätzlich können Pipelines auch mit der Auszeichnungssprache YAML entwickelt werden. Das bietet mehr Flexibilität und ermöglicht das Einchecken der Pipeline in der Quellcodeverwaltung. Es ist wichtig zu beachten, dass YAML nur in Microsoft-Technologien verwendet werden kann. Der YAML-Code wird in der Quellcodeverwaltung gespeichert, was die Entwicklung weiterer Pipelines erleichtert. Durch die Speicherung in der Quellcodeverwaltung sind die Pipelines revisionssicher und die Fehlersuche nach Umstellungen wird vereinfacht.

Bereitstellung mit dem Tabular Editor

Die Verwendung von Tabular Editor (Abb. 3), der in verschiedenen Lizenzmodellen ähnlich wie Microsoft Power BI verfügbar ist, ermöglicht es Backend- und Frontend-Entwickler:innen, unabhängig voneinander zu arbeiten [1]. Das Werkzeug stellt lediglich das Modell online bereit, das Frontend beziehungsweise die grafische Aufbereitung des Berichts muss separat erfolgen. Das beschleunigt in der Regel die Entwicklung von Inhalten in den Teams. Allerdings gibt es eine Einschränkung: Es darf kein technischer Benutzer verwendet werden, der eine Multi-Faktor-Authentifizierung (MFA) benötigt. Diese Einschränkung gilt nicht nur für dieses Werkzeug, sondern auch für andere, die keine MFA unterstützen. Es ist wichtig zu bedenken, dass die Bereitstellung oft vollautomatisch erfolgt und daher keine Benutzerinteraktion erforderlich ist.

Beim Einsatz dieses Werkzeugs muss zudem auf die Anpassung der entsprechenden Datenquellen geachtet werden, da es keine Parametrisierung unterstützt. Hier können PowerShell-Skripte zur Anpassung genutzt werden. Es ist zu beachten, dass dieses Werkzeug nicht nativ von Microsoft bereitgestellt wird.

Bereitstellungs-Pipelines in Microsoft Power BI

Das Konzept von Bereitstellungs-Pipelines ist simpel und effektiv: Es ermöglicht die strukturierte Bereitstellung von Power-BI-Inhalten durch definierte Phasen, um Qualität und Konsistenz zu gewährleisten. In der Regel umfassen Pipelines drei Ebenen:

• Entwicklung: Hier werden Berichte, Datasets und Dashboards erstellt und getestet.

• Test: In dieser Phase erfolgt die Validierung der Inhalte auf Funktionalität und Fehlerfreiheit.

• Produktion: Die freigegebenen Inhalte werden allen Nutzern zur Verfügung gestellt.

Zusätzliche Ebenen können je nach Anwendungsfall integriert werden. Im Vergleich zur manuellen Bereitstellung bieten Pipelines zahlreiche Vorteile:

• Vereinfachte Zusammenarbeit: Teams können parallel an Inhalten arbeiten, ohne Konflikte zu verursachen.

• Verbesserte Qualität: Durch ständige Tests in jeder Phase werden Fehler frühzeitig erkannt und behoben.

• Höhere Effizienz: Automatisierungsschritte beschleunigen den Bereitstellungsprozess und sparen Zeit.

• Nachvollziehbarkeit: Die Historie aller Änderungen und Bereitstellungen ist lückenlos dokumentiert.

Funktionsweise der Bereitstellungs-Pipelines

Power-BI-Bereitstellungs-Pipelines sind eine native Lösung im Power-BI-Service und basieren auf einem deklarativen Ansatz. In einer benutzerfreundlichen Oberfläche definieren sie Aktionen, die die Pipeline ausführen soll. Diese Aktionen umfassen:

• Abrufen von Power-BI-Elementen: Berichte, Datasets, Dashboards und Datenquellen aus einem Arbeitsbereich

• Festlegen von Zielarbeitsbereichen: Bestimmung des Arbeitsbereichs, in dem die Elemente bereitgestellt werden sollen

• Verarbeiten von Elementen: Vorbereiten der Elemente für die Bereitstellung, zum Beispiel Aktualisieren von Datenquellen oder Anwenden von Sicherheitseinstellungen

• Bereitstellen von Elementen: Kopieren der Elemente in den Zielarbeitsbereich

• Benachrichtigungen: Versenden von Benachrichtigungen per E-Mail oder Teams bei Erfolg oder Misserfolg der Bereitstellung.

Zusätzlich können Bereitstellungs-Pipelines über das REST-API oder PowerShell-Skripte gesteuert werden. Die Wahl zwischen der nativen Lösung und externen Tools hängt von der Komplexität der Umgebung, dem Automatisierungsgrad, der technischen Expertise und der Integration mit anderen Tools ab.

Erstellung von Bereitstellungspipelines

Die Erstellung einer Bereitstellungspipeline erfolgt entweder direkt im Fabric-Arbeitsbereich über die Bereitstellungspipelines-Schaltfläche in der Navigationsleiste oder im Arbeitsbereich selbst, sofern eine Power-BI-Premiumlizenz vorliegt. Zuordnung von Ebenen zu Arbeitsbereichen:

• Es wird darauf geachtet, dass die bereits vorhandenen Elemente in den unterschiedlichen Arbeitsbereichen korrekt gepaart werden, um Duplikate zu vermeiden.

• Beim Neueinrichten werden automatisch Kopien in der nächsten Ebene erstellt.

• Bei der Bereitstellung wird gesteuert, ob die Elemente in allen Ebenen bereitgestellt werden oder zunächst nur in der darauffolgenden.

Vor der Bereitstellung:

• Es wird analysiert, welche Inhalte sich konkret geändert haben.

• Die Änderungen werden verglichen, um Neuanlagen, Löschungen und einzelne Elemente zu identifizieren.

• Es werden gezielt die Elemente ausgewählt, die bereitgestellt werden sollen.

Bereitstellungsregeln:

• In Power-BI-Premium-/Fabric-Arbeitsbereichen wird die Datenquelle für die verschiedenen Ebenen festgelegt (z. B. Test- vs. Produktivdaten).

• Diese Regeln werden unabhängig vom Inhalt der Berichte konfiguriert.

Erweiterte Funktionen:

• Ansprechen der Bereitstellungs-Pipelines über das API

• Automatisierung von Funktionen wie Massenbereitstellung, Rückwärtsbereitstellung und Aktualisierung von Power-BI-Apps

Best Practices für die Nutzung von Bereitstellungs-Pipelines

• Mehrere Arbeitsbereiche für Teams: Teams sollten Chaos in Pipelines vermeiden, indem sie separate Arbeitsbereiche für einzelne Teams nutzen.

• Zugriffsrechte und Repositorys: Es sollten klare Zugriffsrechte definiert und separate Repositorys für jedes Team verwendet werden.

• Testumgebung: Es sollte sichergestellt werden, dass die Testumgebung in Bezug auf Datenvolumen, Nutzerzahl und Kapazität der Produktivumgebung entspricht. Um dieselbe Kapazität für die Testumgebung nutzen zu können, ist es möglich, die bereitgestellte Kapazität nur dann zu bezahlen, wenn sie auch tatsächlich zum Testen verwendet wird.

• Endbenutzerperspektive einbeziehen: Es sollten Apps für jede Ebene der Pipeline erstellt werden, um Benutzerfreundlichkeit und Konsistenz für die Nutzer zu gewährleisten.

• Sorgfältige Berechtigungsplanung für Git und Pipelines: Sichere Git- und Pipeline-Integration erfordert detaillierte Zugriffskontrolle für Code, Aktionen und Ebenen.

Microsoft Power BI, Azure DevOps und Power BI Projects (PBIP)

Die Integration von Power BI mit DevOps ermöglicht die Versionskontrolle und Zusammenarbeit an Power-BI-Inhalten mit Hilfe von Git-Repositorys. Das optimiert den Entwicklungsprozess und gewährleistet die Nachvollziehbarkeit von Änderungen.

Voraussetzungen:

• Vorhandenes Git-Repository: ein Git-Repository, in dem die Power-BI-Projektdateien gespeichert werden sollen

• Power BI Desktop: die Power-BI-Desktopanwendung zum Erstellen und Bearbeiten von Power-BI-Inhalten

• Code Editor: ein beliebiger Codeeditor zur Arbeit mit Git-Repositorys (beispielsweise Visual Studio Code)

• Power BI Service: ein Power-BI-Service-Premium- oder -Pro-Abonnement

• Azure-DevOps-Konto: ein Azure-DevOps-Konto zum Verwalten von Git-Repositorys und Pipelines

Schritte zur Integration:

1. Initialisierung des lokalen Repositorys:

   1. Die .pbix-Datei wird als .pbip-Datei abgespeichert

   2. Es wird zu dem Ordner navigiert, der die Power-BI-Datei (.pbip) enthält

   3. Die Befehle git config user.name 'Ihr Name' und git config user.email 'Ihre E-Mail-Adresse' werden ausgeführt

2. Erstellen eines Repositorys in Azure DevOps:

   1. Anmeldung beim Azure-DevOps-Konto

   2. Navigation zum entsprechenden Projekt

   3. Ein neues Git-Repository wird erstellt

   4. Der URL des neuen Repositorys wird kopiert

3. Verbinden des lokalen Repositorys mit Azure DevOps:

   1. Visual Studio Code wird geöffnet und zum Projektordner navigiert

   2. Das Git-Repository wird initialisiert

   3. Der URL des erstellten Repositorys in Azure DevOps wird kopiert

   4. In Visual Studio Code wird eine Remoteverbindung mit dem URL hergestellt

   5. Lokale Änderungen werden gepusht/hochgeladen

4. Konfiguration der Git-Integration im Power BI Service:

   1. Anmeldung beim Power BI Service

   2. Navigation zum Arbeitsbereich, der die Power-BI-Inhalte enthält

   3. Es wird auf die Schaltfläche Source Control geklickt

   4. Die Organisation, das Projekt, das Repository und der Remotezweig aus Azure DevOps werden ausgewählt

   5. Es wird auf Verbinden und synchronisieren geklickt

PBIP-Dateien in Azure DevOps

PBIP-Dateien (Power-BI-Project-Dateien) enthalten sowohl den Bericht als auch das semantische Modell eines Power-BI-Projekts in separaten Ordnern, um eine granulare Versionskontrolle zu ermöglichen. Wichtige Dateien sind die folgenden:

• Dataset-Ordner:

  • model.bim: Enthält die Spezifikationen des Datenmodells (diese Datei kann auch mit dem Tabular Editor bearbeitet werden).

• Report-Ordner:

  • report.json: Enthält Informationen über die Darstellung des Berichts.

  • definition.pbir: Öffnet den Bericht zur Bearbeitung.

Konkretes Beispiel

Angenommen, eine Person fügt eine Visualisierung in der definition.pbir-Datei und ein neues Measure hinzu. Durch Speichern der Datei werden die Änderungen in VS-Code angezeigt. Um die Änderungen zu verfolgen:

1. Es wird ein neuer Remotezweig erstellt und benannt.

2. Es wird angegeben, aus welchem Zweig die Informationen übertragen werden sollen. Das ist meistens der Hauptzweig.

3. Der neue Remotezweig wird im Azure-DevOps-Repository veröffentlicht.

4. Die Pull-Anfragen werden in Azure DevOps angezeigt und der Remotezweig wird ausgewählt.

5. Es wird sichergestellt, dass der Zweig im Hauptzweig zusammengeführt wird.

6. Es wird auf Konflikte geprüft und diese gelöst.

7. Die Zusammenführung wird durchgeführt.

8. Der Hauptzweig wird im Power BI Service synchronisiert, der bei der Git-Integration verbunden wurde.

9. Die Artefakte im Arbeitsbereich werden aktualisiert.

Lizensierung

Seit Ende Juni 2024 ist es nicht mehr möglich, Microsoft-Power-BI-Premium-Kapazitäten zu erwerben. Diese Kapazitäten stellten Arbeitsspeicher und virtuelle CPU-Zeit bereit und wurden bisher auf jährlicher Basis gemietet. Durch diese Kapazitäten war es möglich, Benutzern ohne Microsoft-Power-BI-Pro-Lizenz Zugriff auf Arbeitsbereiche zu gewähren. Alle beschriebenen Funktionen, mit Ausnahme der Microsoft-Azure-DevOps-Integration, waren mit dieser Lizenz nutzbar. Die Azure-DevOps-Integration ist erst mit der Einführung von Microsoft Fabric verfügbar geworden. Power-BI-Pro-Lizenzen bleiben für Berichtsersteller weiterhin erforderlich.

Wer bereits über eine Premiumkapazität verfügt, kann diese weiterhin nutzen oder mieten, nur ist ein Neuerwerb nicht mehr möglich. Microsoft Fabric mag auf den ersten Blick teurer erscheinen als die Premiumkapazität, bietet jedoch erheblich mehr Funktionen. Fabric basiert auf einem Data Lake, wodurch die Datenverarbeitung beschleunigt wird, und unterstützt unter anderem die Erstellung von Streaminglösungen und Data Warehouses. Kurz gesagt, Microsoft Fabric integriert die gesamte Datenplattform im Microsoft-Ökosystem.

Die Lizenzierung bei Fabric unterscheidet sich ebenfalls: Man kann Kapazitäten in Azure erstellen und Arbeitsbereichen zuordnen oder monatlich die Kapazitäten buchen. Mit einer Microsoft Azure-Kapazität hat man zudem die Möglichkeit, diese zu pausieren und je nach Bedarf zu skalieren, was natürlich bedeutet, dass Dienste bei einer Reduzierung der Kapazität nicht mehr verfügbar sind. Dies kann zu variablen Kosten führen. Für das Erstellen von Microsoft-Power-BI-Artefakten ist eine F64-Lizenz erforderlich, ebenso wenn Copilot, eine in vielen anderen Microsoft-Produkten geschätzte Technologie, genutzt werden soll. Es stehen verschiedene Pläne mit unterschiedlichen Kosten und Rechenkapazitäten zur Auswahl. Für die reine Nutzung der Microsoft-Azure-DevOps-Integration reicht der einfachste und günstigste Plan aus [2].

Zusammenfassung

Der optimale Weg lässt sich nicht pauschal bestimmen, da er stark von der vorhandenen Infrastruktur und den spezifischen Anforderungen abhängt. Zusätzlich spielen die Fähigkeiten der Mitarbeitenden im Projekt eine entscheidende Rolle, ebenso wie die verfügbaren Lizenzen im Unternehmen. Die eingesetzten Technologien erfordern umfassendes Know-how seitens der Entwickler:innen und Administrator:innen, die mit den genutzten Werkzeugen für Continuous Deployment (CD) vertraut sein müssen, sowohl in der Administration als auch in der Überwachung der Prozesse.

Die aufgezeigten Möglichkeiten lassen sich größtenteils kombinieren. Die meisten Werkzeuge können ausschließlich mit dem Onlineservice genutzt werden. Das bedeutet, dass bei Verwendung des Microsoft-Power-BI-Berichtsservers, der eine rein lokale Plattform darstellt, einige der beschriebenen Funktionen nicht verfügbar sind. Dennoch bietet die Microsoft-PowerShell-Technologie viele der Möglichkeiten in dieser Technologiewelt an. Das erfordert jedoch eine eigenständige Entwicklung für die Bereitstellung der Berichte.