eBizTalk - Berichten, Unterhalten, Weiterbilden

Grafiken oder Bilder mit einer guten Qualität und damit auch Größe austauschbar in einem PowerBI Report darzustellen ist durch die begrenzte Spaltengröße beim Laden der Daten gar nicht so einfach. Mit einem kleinen Trick lassen sich aber auch große Bilder dynamisch aus einer Datenbank laden.Wie ich dabei vorgegangen bin, möchte ich in diesem Artikel detailliert vorstellen.

Vorbereitung

Leider gibt es eine Größenbeschränkung für die als Datasource festgelegten Spalten. Die Spalten dürfen also eine bestimmte Größe nicht überschreiten, wodurch man auf dem im Artikel Dynamische Bilder in PowerBI beschriebenen Weg nur kleine Bilder verwenden kann.

Mein hier gezeigtes Beispiel setzt auf den in dem Artikel Dynamische Bilder in Power BI angelegten Daten auf.

Ich werde ein Projektlogo dynamisch hinzufügen. Das Logo hat aber eine Größe deutlich über 20 KB. Die Lösung ist es, das Image in viele kleine Teile zu zerlegen, sodass es pro Logo mehrere Imageteile gibt.

Für mein Beispiel habe ich folgende Tabellen hinzugefügt:

In der Project Tabelle wird die LogoID hinzugefügt.

Die Logos werden angelegt und den Projekten hinzugefügt.

Mit dem unten angegebenen Code wird das Logoimage zerlegt und in kleinen Teilen in der Tabelle LogoImage abgelegt. Der Index ist hier die Reihenfolge, in der das Bild hinterher wieder zusammengesetzt werden muss.

PowerBI Report

Im Report wird eine zweite Seite für die Projectdetails angelegt und dann muss die Datenquelle anpassen werden. Dafür gehen ich auf Edit Queries.

Die Tabellen Logo und LogoImage hinzufügen.

Für die Spalte mit den Bilddaten muss der Datentyp auf Text geändert werden.

Mit Close and Apply speichern.

In der Reportansicht muss der Logo-Tabelle ein neues Measure hinzugefügt werden

New Measure:

Nun kann der Detail-Report gebaut werden. Um das Logo hinzuzufügen, wird vom Marketplace ein Image Visual benötigt. Das simple Image hat hierfür leider nicht funktioniert. Ich habe Image by CloudScope verwendet.

Und als Ergebnis erscheint dann das vollständige Logo, obwohl es größer als 20 KB ist.

Auf diese Weise können Bilder beliebiger Größe aus einer Datenbank in den Report geladen werden und der eigentliche Report braucht zum Beispiel beim Hinzufügen eines neuen Projektes nicht mehr angefasst und neu gepublished werden.

Als ich bei der eBiz Consulting GmbH anfing, bekam ich die Gelegenheit an einem internen Projekt zu arbeiten, in dem eine Microservices Architektur verwendet werden sollte. Das Projekt, die sogenannte „eBizConSuite“, ist eine Sammlung von Services für KMUs. Die eBiz selbst ist der erste Kunde dieser „eBizConSuite“. Die im Rahmen des Projektes erarbeitete Basisplattform („Digital Plattform“) soll zukünftig auch für andere Kundenanwendungen verwendet werden. Darüber hinaus haben wir das wichtige Ziel verfolgt, unser Wissen in aktuellen Microservices Technologien wie Kubernetes, Docker und .NET Core auf- und auszubauen. Dieses neue Wissen habe ich zu verschiedenen Gelegenheiten (z.B. Company Meetings und eBizTalks) an meine Kollegen und Kolleginnen in der eBiz weitergeben können.

Bevor ich mit dem Projekt beginnen konnte, habe ich das Best Practices Beispielprojekt "eShopOnContainers" von Microsoft (siehe https://github.com/dotnet-architecture/eShopOnContainers) analysiert und schließlich die Erfahrungen aus diesem Projekt für uns immer wieder als Referenz herangezogen. Es war für mich sehr hilfreich, ein solches Best Practices Projekt vorliegen zu haben, um die Grundlagen der Microservices Architektur zu verstehen, da ich zu diesem Zeitpunkt noch relativ wenig Wissen dazu hatte.

Abbildung 1: Monolithische Architekturen und Microservices Architekturen

Nachdem ich mir das Projekt "eShopOnContainers" angesehen hatte, hatte ich das Gefühl mich auf einem anderen Planeten zu befinden. Bis dahin hatte ich nur mit monolithischen Architekturen gearbeitet, in denen typischerweise fast alle Softwarekomponenten in einer Gesamtanwendung zusammengefasst waren. Aber in Microservices Architekturen sind diese Komponenten einer Anwendung durch bestimmte logische (meistens fachliche Kriterien, manchmal technische Kriterien) Kriterien getrennt, so wie es im obigen Bild (Abbildung 1) grob dargestellt ist.

Diese Komponenten (=Microservices) sind autonom und laufen unabhängig voneinander. Dieser Unterschied wirkt sich auf viele Bereiche aus, wie z.B. auf die zu verwendenden Tools und Bibliotheken. Zum Beispiel das Konzept der „Containerisierung“, das Kubernetes-Ökosystem oder die Notwendigkeit der Nutzung eines Service Bus sind ganz neue relevante Bereiche.

Daher dauerte es einige Wochen, bis ich diese neue Architektur und die Komponenten in diesem Umfeld richtig verstanden hatte.

Nachdem die neu erstellten Microservices mit Hilfe von Docker-Compose erfolgreich in der lokalen Umgebung entwickelt und debugged wurden, stellte sich das Deployment der Anwendung in Kubernetes ebenfalls als eine Herausforderung dar, die es zu nehmen galt.

Die Herausforderung, die Deployment Konfiguration mit YAML zu formulieren ergab sich aufgrund der vielen Funktionen und Einstellungen, die man in einer Kubernetes Umgebung vornehmen kann und beachten muss. Aber nachdem es einmal funktionierte, war es erstaunlich zu sehen, wie mächtig Kubernetes ist. Dazu gehört die Replikation und das Load Balancing von Services, die Health Checks, usw.. All dies dient dazu minimale Ausfallzeiten der Services und damit der Gesamtanwendung sicherzustellen.

Rückblickend betrachtet bin ich sehr zufrieden damit, dass ich mich mit diesen modernen Technologien und der Microservices Architektur beschäftigen konnte und habe dabei viele neue Erkenntnisse gewinnen können.

Obwohl ich einige Bereiche des Best Practices Projekts "eShopContainers" (z.B. Akzeptanz von Code-Redundanzen, minimale Codebasis usw.) zunächst als falsch empfunden habe, habe ich während meiner Lernphase die dahinterstehenden Gründe (aufgrund der Microservices Architektur) nach und nach verstanden. Es ist offensichtlich, dass Containerisierung zukünftig eine noch viel größere Bedeutung haben wird, und meiner Meinung nach wird Kubernetes die Rolle des führenden Orchestrierungstools und Hosting-Ökosystems weiter ausbauen.

Bilder in einen PowerBI Report zu integrieren ist eine leichte Aufgabe. Die Bilder abhängig von z.B. einem Status einzubinden wird schon etwas kniffliger. In diesem Beitrag möchte ich zeigen, wie man kleine Bilder, die in einer Datenbank gespeichert sind, dynamisch in einen Report einfügt.

Vorbereitung

Als Beispiel erstelle ich einen Projektreport. Für das Anzeigen eines Status habe ich hier folgende Bilder erzeugt:

Die Größe je Bild liegt bei ca. 11KB. Auf Grund der Größenbeschränkung von 32766 Byte beim Laden einer Spalte in den Report dürfen die Bilder eine bestimmte Größe nicht überschreiten. Meine Erfahrung hier ist, dass das Bild kleiner 20 KB sein sollte. Alles was darüber liegt, wird obwohl es unterhalb der Größenbeschränkung liegt, abgeschnitten.

Diese Bilder möchte ich nun in meinem Report als Projektstatus anzeigen lassen. Dafür habe ich die folgenden Tabellen angelegt.

Die State-Tabelle habe ich dann mit den Bildern befüllt

Daraufhin habe ich ein paar Beispielprojekte angelegt.

Mit diesen Daten bekommt man sicher keinen ganzen Report gefüllt, aber ich denke, das Prinzip des dynamischen Anzeigens der Bilder wird deutlich.

PowerBI Report

Im PowerBI Desktop wird ein neuer Report geöffnet und die gerade angelegte Datenquelle ausgewählt.

Die zwei Tabellen Project and State werden ausgewählt.

An den Queries müssen nun noch ein paar kleine Anpassungen gemacht werden. Dafür muss Edit Queries geöffnet werden.

In der State-Tabelle wird der Datentyp des Bildes auf Text geändert.

Und eine neue Spalte wird hinzugefügt. Diese neue Spalte muss wie folgt aussehen:

Mit Close and Apply diesen Schritt abschließen.

Dann wird auf die Tabellenansicht gewechselt.

Dort wird die Data Category der neuen Spalte auf Image URL geändert.

Auf der ersten Reportseite wird dann eine Tabellenansicht mit den Projekdaten und dem Statusbild angelegt.

Das Ergebnis ist eine Übersicht der Projeke und der Status wird als Ampel dargestellt.

Wird ein neues Projekt hinzugefügt oder ein bestehendes geändert, ändert sich das Statusbild im Report automatisch. Man muss bei diesem Vorgehen nur beachten, dass die zu verwendenden Bilder die Größe von ca. 20 KB nicht überschreiten, da sie sonst durch die Spaltengrößenbeschränkung beim Laden in den Report abgeschnitten werden.

Wie man bei größeren Bildern vorgeht, folgt in einem nächsten Beitrag.

In den letzten Monaten habe ich einen unserer Kunden bei der Entwicklung einer Azure Cloud Lösung unterstützt. Kern dieser Lösung ist Azure Service Bus, der dank seiner horizontalen Skalierbarkeit, dem zuverlässigen Messaging und der einfachen Nutzung in hybriden Szenarien, ein integraler Bestandteil vieler Integrationslösungen geworden ist.

Für Azure Service Bus existiert eine lange Liste an Beschränkungen (Quotas), z. B. was Kontingente und Drosselungsschwellenwerte angeht. Das Nichtbeachten einer dieser Quotas kann schwerwiegende Folgen haben. In unserem Fall war das System jeden zweiten Tag nicht mehr erreichbar und ein Neustart war der einzige Workaround.

Die Fehlermeldung lautete folgendermaßen: „Cannot allocate more handles. The maximum number of handles is 4999”. Wenn man die Meldung näher betrachtet, erkennt man, dass es sich um eine Limitierung handelt.

Für uns war aus den folgenden Gründen nicht klar, warum der Fehler aufgetreten ist:

• Der Fehler ist auch an Uhrzeiten aufgetreten, an denen sehr wahrscheinlich keine 5000 Verbindungen zum Service Bus bestanden.
• Laut der Beschreibung, sind nur NetMessaging und AMQP Verbindungen mit 1000 bzw. 5000 jeweils bestehenden Verbindungen betroffen: Der Fehler ist aber auch an Stellen aufgetreten, an denen wir keine AMQP Verbindungen erstellt haben. Das dachten wir zumindest…

Fast alle unserer Aufrufe machen von der Klasse „ClientEntity“ Gebrauch. Durch die Instanziierung und die Nutzung dieser Klasse werden implizit AMQP Verbindungen aufgebaut.

Die Lösung war zum Glück einfacher als gedacht, die Fehlersuche auf einem Test-System jedoch intensiv und komplex: AMQP Verbindungen werden implizit aufgebaut und müssen explizit geschlossen werden. D.h. da, wo eine Instanz von „ClientEntity“ nicht mehr gebraucht wird, soll die Verbindung explizit geschlossen werden. In der Dokumentation ist dieses Verhalten nirgendwo dokumentiert. Das lässt sich zum Glück mittels des Aufrufs von „ClientEntity.CloseAsync()“ einfach lösen.

Fazit

Das Motto „Kenne deine Grenzen“ war in meinem Fall leider nicht hilfreich, um diesen schwerwiegenden Fehler in der Produktionsumgebung zu vermeiden. Ich musste diese Grenzen zunächst selbst erforschen, um eine passende Lösung zu finden.

Letztes Jahr stand ich vor der großen Frage wo ich mich denn beruflich sehe und wie ich mich gerne weiterentwickeln würde. Schnell war klar: Ich möchte in die Projektmanagementwelt eintauchen. Die Vielschichtigkeit und die doch sehr unterschiedlichen Aufgabenbereiche, die mit Projektmanagement verbunden sind, haben mich neugierig gemacht, mich tiefer in dieses Thema einzuarbeiten.

Die Suche nach der richtigen Wissens-“Quelle”

Als diese wichtige Entscheidung gefällt war, stand ich vor der nächsten großen Herausforderung: Wo bekomme ich für den Wissensaufbau unter anderem gute Literatur, die nicht allzu trocken ist und man trotzdem einiges an Wissen mitnimmt, her. Die Suche nach der für mich richtigen Literatur gestaltete sich nicht ganz so einfach- bis ich eines Tages auf das Buch von Mario Neumann aufmerksam geworden bin: „Projekt-Safari - Das Handbuch für souveränes Projektmanagement“. Die Beschreibung von Mario Neumann zum Buch:

Was haben Kolumbus, Lindbergh und ein Projektmanager gemeinsam? - Ihre Abenteuer sind Projekte, überall lauern Gefahren, doch bei Erfolg winken Ruhm und Ehre! […]

Dieser Guide zeigt, wie Sie die abenteuerliche Reise durchs Projekt vorbereiten, Hürden überwinden und nie das Ziel aus dem Blick verlieren. Tipps für den Ernstfall, Erlebnisse erfahrener Projektleiter und theoretische Hintergründe fügen sich zu einem völlig neuartigen Handbuch für Projektmanager. So wird jedes Projekt aufregend und inspirierend wie eine Safari!

Okay, cool, scheint mal ein etwas anderer Ansatz zu sein. So schnell war das Buch auch schon bestellt und ich mitten in der Projektsafari eingetaucht.

Der Aufbau des Buches

Eine Etappenüberschrift mit einer kurzen Erklärung, auf welches Abenteuer man sich gerade begibt. Untergliedert wird das Ganze in verschiedene Etappenziele, welche einen Bezug zu einem fiktiven Projekt haben und in „Toms Tagebuch“ erläutert werden sowie eine kurze Zusammenfassung des Etappenziels und einer (negativen) Situation mit dazugehörigem Tipp, wie man diese vermeiden bzw. meistern kann.

Gerade für Neulinge (aber auch für gestandene Projektleiter) auf dem Gebiet eine super Sache, denn man kann sich direkt in die Situation hineinversetzen und kurz darüber nachdenken wie man selbst wohl mit dieser Herausforderung umgegangen wäre. Auch bekommt man durch die Tipps eine mögliche Herangehensweise vorgestellt. Natürlich muss man diese Tipps der Situation anpassen, aber zumindest als Anregung sind sie super.

Welche Etappen gibt es?

• Etappe 1: Lust auf ein Abenteuer? » Von der Idee zum Projektauftrag
• Etappe 2: Der Abenteuer-Plan » Das Geheimnis erfolgreicher Projektplanung
• Etappe 3: Das Abenteuer beginnt » Einen Fehlstart vermeiden
• Etappe 4: Das Umfeld gewinnen » Widerstände managen
• Etappe 5: Alles hört auf mein Kommando » Führen, ohne Chef zu sein
• Etappe 6: Kurs halten in gefährlichen Gewässern » Konflikte und Krisen meistern
• Etappe 7: Zum Endspurt ansetzen » Das Projekt erfolgreich abschließen

Die Etappen werden von einem kurzen Beispiel von „früher“ (z.B. wie Kolumbus ein Projekt gestartet hat) eingeleitet und dann auf die heutige Zeit bezogen, auch diese Segmente lockern das Projektmanagementthema etwas auf. Es wird also ein kompletter Projektzyklus, von der Idee, über die Planung bis hin zum Abschluss beschrieben.

Zusätzlich kann man sich, anhand der Beispiele im Buch, ein komplettes Workbook zusammenstellen. Auf folgende Dokumente wird eingegangen und anhand eines Beispiels vorgestellt:

• Statusbericht
• Projektplan
• Risikologbuch
• Änderungsantrag
• Projekttagebuch
• AIL (Action Item List)

In wie weit man alle Dokumente genauso einsetzt, ist jedem selbst überlassen, aber als Anregung ist es wirklich gut und man lernt zumindest die Begriffe und den Aufbau kennen.

Mein Fazit

Alles in allem hat mir die Projektsafari wirklich Spaß gemacht und was fast noch wichtiger ist: Ich habe sehr viel von diesem Buch gelernt und konnte doch einiges an Tipps mitnehmen und auch im Projekt einsetzen. Auch heute schlage ich immer mal wieder darin nach, wenn ich einen anderen Blick auf meine Herangehensweise haben möchte, oder mir wieder mal ein Thema vor Augen führen möchte. Ich würde das Buch definitiv (gerade für Junior PL / PMO) weiterempfehlen.