| von Patricia Bobe

Tableau im Standard Reporting: Ein Deployment-Prozess über die Rest API via Python

Einleitung

Tableau wird insbesondere im Bereich des Ad-hoc-Reportings eingesetzt, wobei durch einfaches Drag and Drop schnell die ersten Analyseergebnisse sichtbar werden. Die Software erlaubt dem Anwender oder der Anwenderin ein selbstständiges Arbeiten auf dessen/deren Daten. Dadurch entfällt der oftmals langwierigen Weg über die IT, bei dem bestimmte Daten oder sogar fertiggestellte Reports angefordert werden müssen. Doch auch im Standard Reporting kommt Tableau immer häufiger zum Einsatz. In diesem Fall gibt es jedoch stärkere Richtlinien, an die sich der Report-Entwickler oder die Report-Entwicklerin halten muss. Insbesondere in Unternehmen, bei denen Abläufe stark standardisiert sind, muss auch für das Reporting ein den Standards entsprechender Prozess geschaffen und eingehalten werden. Um den Spagat zwischen Self-Service BI und Data Governance hinzubekommen, wurde ein Deployment-Prozess für Tableau Reports entwickelt und mit Hilfe der REST API via Python umgesetzt.

Zur Qualitätssicherung der Analysen in Tableau soll eine Deployment-Pipeline aufgebaut werden, mit deren Hilfe erstellte Workbooks mehrere Prüfungen bspw. durch Fachbereiche und Data Stuarts durchlaufen. Dadurch lässt sich sicherstellen, dass die Rezipienten und Rezipientinnen der Workbooks qualitätsgeprüfte und standardisierte Reports bekommen, welche außerdem CI/CD konform sind und nur auf valide Daten der entsprechenden Umgebung zugreifen.

Prozessbeschreibung

Der folgend beschriebene Prozess bezieht sich auf eine Infrastruktur mit insgesamt drei Umgebungen: Entwicklung, Test-/Integration und Produktion. Für diese Umgebungen gelten bereits Sicherheitsmaßnahmen, sodass nur zugelassene Daten entsprechend gespeichert werden (produktive Daten gibt es ausschließlich auf der Produktionsumgebung). Diese Architektur lässt darauf angepasste Nutzer-Berechtigungen zu. Das Berechtigungskonzept ist insbesondere wichtig, um die Qualitätsstandards und Sicherheitsanforderungen erfüllen zu können.

Los geht es mit Tableau Desktop. Der Entwickler oder die Entwicklerin des Reports verbindet sich auf eine der Entwicklungs-Datenbanken und erstellt seine/ihre Analyse in dem Desktop Client. Er/sie kennt sich mit seinen/ihren Daten aus und kann spezifische Fragestellungen beantworten. Nach der Fertigstellung des Workbooks veröffentlicht der Entwickler/die Entwicklerin dieses auf der Tableau Server Entwicklungsumgebung.

Lediglich die Nutzer und Nutzerinnen auf der Entwicklungsumgebung haben die Berechtigung, Tableau Workbooks zu erstellen, auf den Server zu laden und zu bearbeiten. Damit die Integrität der Daten sichergestellt ist, kann ein sogenannter Data Stuart die Datenquelle prüfen und zertifizieren. Dadurch weiß der Nutzer/die Nutzerin, dass es sich um verlässliche und gut aufbereitete Daten handelt.

Erst wenn diese Workbooks sowie die Datenanbindungen technisch funktionieren und falls nötig mit einer Berechtigungsstruktur wie Row-Level-Security ausgestattet sind, bekommen sie ein Release-Tag und werden mit dem nächsten Release auf die Integrationsumgebung deployed. Optional wird während jedes Deployment-Prozesses die Tableau-Datei in ein Versionierungstool (wie GIT, Harvest, etc.) eingecheckt, migriert und wieder ausgecheckt. Dementsprechend liegt auch außerhalb des Tableau-Servers eine Versionierung und Historisierung vor.

Auf der Integrationsumgebung erfolgt daraufhin die Abnahme durch den Fachbereich. Nach einer erfolgreichen Prüfung, wird das Workbook mit dem nächsten Release auf die Produktionsumgebung gebracht und steht dann für alle Rezipienten und Rezipientinnen des Berichts zur Verfügung. Auf der Produktionsumgebung haben die Nutzer/innen dann lediglich Viewer-Berechtigungen, sodass die Workbooks dort nicht mehr weiter bearbeitet werden können. Damit wird ein entsprechender Qualitätsstandard sichergestellt.

 

Infrastruktur mit Entwicklung, Test/Integration und Produktion


Technische Umsetzung

Dieser Deployment-Prozess wird in erster Linie über die REST API von Tableau unter der Verwendung von Python umgesetzt. Tableau stellt eine Python Bibliothek, den Tableau Server Client, zur Verfügung, in welchem bereits viele Funktionen gekapselt werden. Dementsprechend ist das Skript übersichtlich und damit auch wartbar.

Export

Es gibt zwei verschiedene Python Skripte, welche eingebettet in ein entsprechendes Shell Skript den Deployment-Prozess ermöglichen. Das Skript, das zuerst ausgeführt wird, ist für den Download der Tableau Workbooks inklusive Datenquellen (von der Test- bzw. Integrationsumgebung) verantwortlich. Mittels eines Tokens und eines technischen Users, dessen Passwort in einer verschlüsselten Datei abgelegt ist, erfolgt eine Anmeldung auf dem Tableau Server. Das entsprechende Release-Tag wird über den Skriptaufruf mitgegeben. Daraufhin durchsucht das Skript die getaggten Tableau-Artefakte und lädt sie in ein Filesystem. Die Ordner werden im Filesystem automatisch identisch der Projektstruktur auf dem Tableau Server angelegt.

Des Weiteren werden die spezifischen Informationen wie

  • die ID
  • der Workbook Name
  • der Verbindungstyp
  • die Server-Adresse und
  • die Verbindung zur Datenquelle des Tableau Workbooks

in ein automatisch erstelltes Konfigurationsfile geschrieben. Der Name der Konfigurationsdatei ergibt sich automatisch aus dem Namen des Workbooks und dem Umgebungsnamen, z.B. Analyse_Kennzahlen_DEV.txt. Diese Datei wird ebenfalls in einem Filesystem abgelegt und beim Deployment-Prozess mitgeführt.

Konfiguration der Datenverbindungen

Um die Tableau Workbooks beim anstehenden Import auf die neue Stage wieder zu den richtigen Datenquellen zu verbinden, ist es nötig, die Verbindungsinformationen zu erfassen. Es wird zwischen Extrakten und Live-Verbindungen sowie eingebetteten und separat veröffentlichten Datenquellen differenziert. Danach unterscheidet sich auch das Konfigurationsfile des Tableau Workbooks. Für separat veröffentlichte Datenquellen muss eine eigene Konfiguration erstellt werden. Das heißt, die Erstellung des Konfigurationsfiles der Verbindungen erfolgt in diesem Fall nicht nur für die Workbooks, sondern auch für die Datenquellen selbst.

Im Konfigurationsfile des Workbooks, welches eingebettete Datenquellen beinhaltet, wird auf den Tableau Server als Datenquelle verwiesen. Bei Extrakten wird statt des Servernamens der Eintrag „localhost“ vom Tableau Server zurückgegeben und muss demnach auf den entsprechenden Datenquell-Pfad (Pfad zur Hyper Datei) zurückgeführt werden.

Konfiguration der Datenverbindungen


Anpassung der Verbindungsinformationen

Wie zuvor bereits angedeutet, gibt es nicht nur für die Tableau Server drei Umgebungen, sondern auch für die Quellsysteme. Das heißt: Je nach Umgebung muss der Bericht auf eine andere Datenbank verweisen. Im Deployment-Prozess erfolgt nicht nur ein Kopiervorgang der Tableau-Artefakte, sondern auch eine Anpassung der Verbindungsinformationen der Reports auf die Datenbank der entsprechenden Umgebung.

In diesem Zusammenhang wird beim Export der Dateien vom Tableau Server bereits eine zweite Konfigurationsdatei erstellt, welche für die Integrations-/bzw. Produktionsumgebung benutzt wird. Diese Datei muss entweder manuell angepasst werden oder es wird automatisch der neue Datenbankname eingetragen, wenn eine entsprechende Mapping-Datei existiert (wenn Testumgebung = a, dann Integrationsumgebung = b).

Import

Die Ordnerstruktur des Filesystems wird vom Skript ermittelt und die Tableau Workbooks und Datenquellen werden in einer identischen Projekt-Struktur auf der nächsten Umgebung deployed. Sollten diese Projekte noch nicht existieren, werden sie automatisch vom Skript angelegt (dies ist inklusive Rechtevergabe möglich). Während des Deployments werden die Konfigurationsdateien ausgelesen, sodass eine richtige Verbindung der Workbooks zu den Datenquellen bzw. der Datenquellen zu den Quellsystemen sichergestellt wird. Am Ende des Skripts werden die deployten Verbindungen durch die Verbindungsinformationen der umgebungsspezifischen Konfigurationsdatei ersetzt. Wird auf die Produktionsumgebung deployed, stehen nun qualitätsgesicherte Tableau Analysen mit Verbindungen zu den produktiven Daten für die Betrachter zur Verfügung.

Nutzen

In Konzernen mit stark standardisierten Prozessen ist es oft schwierig, die Vorteile der Self-Service BI unter Einschränkung fester Governance Richtlinien nutzen zu können. Einerseits sollen die Mitarbeiter durch den Self-Service-Gedanken in der Lage sein, schnell auf Daten zugreifen und selbstständig Analysen erstellen zu können. Damit wird nicht nur der Auswertungsweg flexibler, sondern auch die IT durch das Einsparen von Prozessen entlastet. Andererseits müssen die Integrität und Validität der Daten sichergestellt, der entsprechende Zugriff geregelt und die Qualitätsstandards bei produktiven Dashboards gesichert sein. Diese Herausforderung zwischen Self-Service BI und Data Governance kann ein automatisierter Deployment-Prozess meistern.

Ein solches Deployment über die Tableau REST API ist eine Möglichkeit, Tableau sowohl in das Standard Reporting eines Konzerns zu integrieren und an die Prozesse anzupassen als auch in der Entwicklungsumgebung Möglichkeiten zur explorativen Datenanalyse zu bieten. Auf dem Weg bis zur Produktionsumgebung wird durch technische und fachliche Tests sowie Berechtigungskonzepte der Zugriff auf die richtigen Datenquellen und die Qualität der Analysen garantiert. Weitere Resultate sind die Nachvollziehbarkeit sowie die Wartbarkeit des Erstellungsprozesses.

Die Frage, wie Tableau für das Standard Reporting eingesetzt werden kann, ist an dieser Stelle ausführlich beantwortet. Gleiches gilt für die Frage, ob sich der Einsatz eines automatisierten Deployment-Prozesses lohnt. Denn der hohe Nutzen ist nicht von der Hand zu weisen: Die Entwickler sind zufrieden, die IT ist entlastet und die Rezipienten und Rezipientinnen der Standard Reports sind umfassend informiert.

Teile diesen Artikel mit anderen

Über den Autor

Patricia beschäftigt sich als Tableau-Expertin insbesondere mit BI Anforderungen, Erstellung von Dashboards und Visual Analytics. Als Solution Expert bringt sie mehrjährige Projekterfahrung in verschiedenen Industriezweigen und Branchen, u.a. im Banking, Produktion und Retail, sowie Expertise im Bereich Data Discovery & Reporting bei der Woodmark ein.

Zur Übersicht Blogbeiträge