eBizTalk - Berichten, Unterhalten, Weiterbilden

Dieser Artikel ist der Erste in einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe ist es meine Sicht darauf zu geben, wie API Management im Enterprise-Kontext eingesetzt werden kann.

Die Rolle des API Managements (APIM)

Das API-Management ist der Prozess der Überwachung von Application Programming Interfaces (APIs) in einer sicheren, skalierbaren Umgebung. Das Ziel von des API Managements ist es den Lebenszyclus und die Verwendung einer API zu überwachen. Sie können so sicherstellen, dass Anforderungen von Entwicklern eingehalten werden.[1]

Um diesen Prozess zu unterstützen haben viele Unternehmen eine Softwarelösung geschaffen. Gartner hat diese am 09.Oktober 2019 in einem Magic Quadrant for Full Life Cycle API Management bewertet. Zu den „Leaders“ gehören unter anderem:

· AWS (Amazon Web Services)

· Google (mit Apigee)

· Microsoft (Azure API Management)

· Uvm.

Für technische Beispiele im Laufe der Blog-Serie zu API Management werde ich Azure API Management von Microsoft verwenden. Die meisten Konzepte sind jedoch meist problemlos übertragbar auf andere Anbieter.

Wenn das API-Management in einem Unternehmen richtig implementiert ist, führt es zu folgenden Ergebnissen:

· besser verwaltete Entwickler-Community

· gute Kontrolle über die API-Verwendung

· Entdecken von potenziellen Monetarisierungsmöglichkeiten

· robuster Sicherheits- und Governance-Prozess

· Geldeinsparung durch Vermeidung von Neuentwicklungen

Aufbau eines API Management Systems

Häufig sieht man, dass die Systeme von der logischen Architektur her aufgeteilt sind in einen API Developer und in einen API-Konsumenten fokussierten Teil; auch wenn diese Parteien nicht überall gleich benannt sind.

Figure 1: Architektur eines API Managements (Azure APIM). Quelle: azure.microsoft.com/en-us/services/api-management

Der Grund für diese Aufteilung liegt nicht nur in der zweiseitigen Natur von APIs. Ziel ist auch APIs, je nach Unternehmensstrategie verfügbar, auffindbar und insbesondere wiederverwendbar zu machen. In einem späteren Artikel werde ich näher auf die Best-Practices von API Management eingehen. So „stay tuned“!

API Gateway

Das API-Gateway ist der Endpunkt, der folgende Aufgaben übernimmt:

· Akzeptieren von API-Aufrufen und Weiterleiten dieser Aufrufe an Ihre Back-Ends

· Überprüfen von API-Schlüsseln, JWT-Token, Zertifikaten und anderen Anmeldeinformationen

· Erzwingen von Nutzungskontingenten und Übertragungsratenlimits

· Dynamisches Transformieren Ihrer API ohne Codeänderungen

· Zwischenspeichern von Back-End-Antworten, falls eingerichtet

· Protokollieren von Aufrufmetadaten zu Analysezwecken

Developer Portal

Das Developer Portal dient als wichtigste Webpräsenz für Veröffentlicher von APIs und als wichtigste Informationsquelle für Konsumenten/Entwickler. Es ermöglicht Folgendes:

· Lesen der API-Dokumentation

· Ausprobieren einer API mithilfe der interaktiven Konsole

· Erstellen eines Kontos und Anfordern von API-Zugriffsdaten

· Zugriff auf Nutzungsanalysen

Management Plane

Diese Oberfläche ist die Verwaltungsebene, über die das “API Management” durch die API-Administratoren verwaltet wird. Dazu gehört unter anderem:

· Definieren oder Importieren des API-Schemas

· Paketieren von APIs in Produkten

· Konfigurieren von Richtlinien wie z. B. Kontingenten oder Transformationen für die APIs

· Gewinnen von Erkenntnissen mithilfe von Analysen

· Verwalten von Benutzern

Sicherheit

Mit dem API Management lassen sich die backend-Services schützen. Eine typische Aufgabe ist die des „Edge“ Gateways, das zwischen Unternehmen und dem Internet typischerweise in einer demilitarisierten Zone (DMZ) angesiedelt ist. Ein API-Gateway kann Konsumenten authentifizieren und Anfragen autorisieren. Das Format und der Inhalt von Anfragen kann gegen Formatbeschreibungen (Schema) geprüft (validiert) werden. Die Transportverschlüsselung mit TLS bzw. SSL kann ebenfalls ein API Gateway übernehmen. Dadurch können sogar nicht explizit abgesicherte APIs sicher zur Nutzung angeboten werden.

Monitoring

Da das Gateway, wie der Name bereits vermuten lässt, die Anfragen entgegennimmt und validiert, werden dabei Metriken erfasst. Standartmäßig werden Last auf das Gateway, Anzahl der Verbindungen, Verfügbarkeit und Antwortzeiten erfasst. Diese werden in der Management Plane visualisiert. Es ist hier dann möglich „Alarme“ basierend auf den Metriken zu erstellen, um zum Beispiel schnell über kritische Probleme informiert zu werden.

Logging

Es ist möglich Logeinträge für alle Aufrufe des Gateways zu schreiben. Meist ist es jedoch üblich die Logs für einzelne APIs und Operationen zu gesonderten Log-Umgebungen zu senden, damit jeder API-Entwickler gesondert auf die für ihn relevanten Logs Zugriff hat.

Routing

Aufrufe können vom API Management Gateway an verschiedene Systeme weitergeleitet werden. Diese Regeln können den Inhalt des Aufrufes verwenden, um beispielsweise Aufrufe an verschiedene Versionen des Backendsystems zu senden.

Transformation

Häufig möchte man nicht, dass das Datenformat des Back-Ends auch in den Aufrufen verwendet wird. Hierfür bietet das API Management eine Funktion an, die es ermöglicht den Inhalt der Aufrufe zu transformieren, um Back-End-kompatibel zu sein.

Access Management

Durch die Aufteilung in API-Entwickler und API-Konsumenten ist das Zugriffsmanagement ähnlich aufgeteilt. So kann man beiden Gruppen in ihrem Bereich getrennt per RBAC (Role Based access controll) Zugriff auf die APIs geben.

Damit kann man genau definieren welcher Konsument welche APIs oder API-Produkte sehen darf und auf API-Entwickler Seite ebenso kontrollieren wer welche Eigenschaften einer API verändern darf.

Abrechnung/Monetarisierung

Für viele Firmen gehört es dazu die Nutzung von APIs an ein Bezahl-Model zu koppeln. Zur Limitierung der Anzahl an Aufrufen pro Konsumenten bieten API Management Systeme entsprechende Funktionalität an. Dadurch müssen solch aufwändig zu implementierende Limitierungen nicht in den Back-End APIs implementiert werden.

Fazit

Wenn du es bis hierhin geschafft hast, hast du ein gutes Grundverständnis erlangt um nun in jedes einzelne Thema gesondert einsteigen zu können.

Ein API Management als Tool ist vielseitig und gibt eine breite Palette an Funktionen vor, die von Unternehmen verwendet werden können, um nicht nur APIs zu sichern und zu verwalten, sondern auch um eine Strategie zu verfolgen, die über ein “einfaches Verwalten” von APIs hinausgeht.

Im Laufe der Serie plane ich unter anderem die folgenden Aspekte zu betrachten:

· APIs als Produkte

· API Live-Cycle

· Policy

· Monitoring & Logging

· Sicherheit

· Routing

· APIM mit Microservices oder Serverless

· …

[1] searchsoa.techtarget.com/definition/API-management

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.