Azure Functions „“ Vollgas mit dem Service-Bus

In „Azure Functions „“ Simple JavaScript Tutorial“ haben wir unsere erste Azure Funktion geschrieben. Die erstellte Funktion lädt Random-User-Daten über einen Rest Endpoint und zeigt diese aktuell als Log-Mitteilung im Azure Portal an. Unser Wunsch ist es aber, die erstellte Funktion als Importer zu nutzen, der die Daten anderen Applikationen und Funktionen zur Verfügung stellt.

Um das Bereitstellen der Daten zu verwirklichen, werden wir in unserem heutigen Beispiel den Azure Service Bus nutzen. Der Service Bus besteht aus einer Komponente für die asynchrone unidirektionale Kommunikation (Brokermessaging) und einer Komponente für die synchrone bidirektionale Kommunikation (Relays). Vergleichbare Broker-Messaging-Lösungen wären z. B. ActiveMQ, Kafka etc. Der Service Bus ist Microsofts cloudbasiertes Messaging-as-a-Service Lösung.
Weitere führende Informationen findet man unter https://docs.microsoft.com/de-de/azure/service-bus-messaging/service-bus-fundamentals-hybrid-solutions.

Im Rahmen des Beispiels werden wir den Service Bus als Messaging Broker nutzen und zu diesem Zweck eine Warteschlange (Queue) erstellen.

Lasst uns nun aber endlich mit dem Beispiel beginnen 😊. Ich erwähnte ja schon im Beitrag „Azure Functions „“ Simple JavaScript Tutorial“ , dass man Funktionen entweder direkt im Portal oder auch lokal entwickeln kann. Wir werden uns mal anschauen, wie das lokale Entwickeln aussehen könnte und wie man den „Code“ auf die Azure Plattform bekommt. Um den letztgenannten Punkt zu erfüllen, müssen wir zuerst ein leeres Git Repository erstellen. Für dieses Beispiel habe ich der Einfachheit halber auf GitHub ein neues Repository erstellt, man kann auch ein lokales Repository erstellen oder Bitbucket nutzen.

Das erstellte Git Repository legen wir nun erst einmal beiseite und erstellen zunächst den benötigten Service Bus. Dazu begeben wir uns ins Azure Portal und erstellen eine neue Ressource. Der Service Bus ist unter Enterprise Integration zu finden (Abbildung 1).

Abbildung 1

Im nächsten Schritt wählen wir einen sprechenden Namen aus und ändern die Pricing Tier auf „Basis“. Falls noch nicht vorhanden, erstellen wir eine neue Ressourcen-Gruppe und zu guter Letzt vergewissern wir uns, dass als Standort Westeuropa ausgewählt ist (Abbildung 2).

Abbildung 2

Nach einer gefühlten kleinen Ewigkeit sollte die Bereitstellung beendet sein, und wir können zu unserem neuen Service Bus wechseln. Jetzt fehlt uns nur noch eine Queue, die wir später mit Nachrichten füllen können. Um eine solche zu erstellen drücken wir in der Overview auf das „+Queue“ . Der Queue geben wir den Namen „userDataQueue“ und setzen die Lock Duration auf eine Minute (Abbildung 3). Zum Schluss müssen wir noch den Primary Connection String des Service Bus zwischenspeichern, diesen werden wir anschließend beim Konfigurieren unserer Funktions-App benötigen. Der Primary Connection String ist unter dem Punkt „Shared access policies“ zu finden. Dort wird uns eine Policy angeboten und zwar die „RootManageSharedAccessKey“. Wählen wir diese aus, können wir den Primary Connection String kopieren.

Das war es auch schon mit dem Service Bus. Ab sofort können wir Nachrichten verschicken und der erstellte Service Bus fungiert für uns als Messaging-Broker.

Abbildung 3

Da unser Service Bus nun steht, machen wir weiter und erstellen eine neue Azure Funktionen-App, die wir mit dem Git Repository, das wir erstellt haben, verbinden. Die Funktionen-App ist unter „Compute“ zu finden . Der Funktionen-App geben wir einen Namen, wählen als Standort Westeuropa aus und erstellen diese (Abbildung 4).

Abbildung 4

Auch hier warten wir kurz die Bereitstellung ab und wechseln dann zu der erstellten Funktion. Dort angekommen, wechseln wir zu den Plattform-Features und wählen die Bereitstellungsoptionen aus (Abbildung 5a).

In dem neu geöffneten Fenster erstellen wir ein neues Setup und wählen die Quelle aus (Abbildung 5b), in unserem Fall GitHub. Um GitHub nutzen zu können, müssen wir uns in den Bereitstellungsoptionen mit unserem Account autorisieren und das erstellte Repository als Projekt auswählen (Abbildung 5c). Ab sofort bezieht Azure alle Ü„nderungen im Master per Pull. Achtung: Alle Ü„nderungen am Master gehen sofort live. Falls man sich für diese Option beim Continuous Deployment entscheidet, sollten Entwicklungen in einem separaten Branch erfolgen und mittels Pull Request in den Master gemergt werden.

Abbildung 5a

Abbildung 5b

Abbildng 5c

Bevor wir zur eigentlichen Programmierung kommen, müssen wir den eben kopierten Primary Connection String in den Anwendungseinstellungen unserer Funktionen-App hinterlegen. Wir wechseln in der Übersicht zu den Anwendungseinstellungen (Abbildung 6a). Dort angekommen fügen wir unter dem Punkt „Anwendungseinstellungen“ eine neue Einstellung hinzu. Als Name geben wir „ServiceBusConnection“ ein und als Wert den kopierten Primary Connection String. Das Ganze speichern wir (Abbildung 6b). Mit der angelegten Eigenschaft, in diesem Fall einer Verbindungseigenschaft, können sich die Funktionen, die in dieser Funktionen-App gehostet werden, mit dem Service Bus verbinden.

Abbildung 6a

Abbildung 6b

Jetzt können wir mit dem Programmieren loslegen. Das erstellte Repository klonen wir und importieren es in unsere Entwicklungsumgebung. In dem nun importierten Projekt erstellen wir jeweils ein Verzeichnis (directory) für „FunktionServiceBus“ und „FunktionServiceBusReader“ (Abbildung 7).

Abbildung 7

Aus jedem Unterverzeichnis des Projekts wird später eine Azure Funktion. Der Name des Verzeichnisses fungiert als Name der Funktion. Auf der gleichen Ebene wie die Unterverzeichnisse kann noch eine host.json-Datei abgelegt werden. Diese enthält globale Konfigurationsoptionen, die sich auf alle Funktionen auswirken (https://docs.microsoft.com/de-de/azure/azure-functions/functions-host-json). Eine mögliche Option wäre z. B. der Timeout der Funktionen.

Als nächstes erstellen wir in jedem Unterverzeichnis folgende Dateien (Abbildung 8):

• function.json
• index.js
• readme.md

Wie man sieht, haben die Unterverzeichnisse die gleiche Struktur wie Funktionen, die direkt im Portal erstellt werden.

Abbildung 8

Die FunktionServiceBus erweitern wir an zwei Stellen. Als erstes fügen wir der Funktion eine Bindung (binding) hinzu. Azure Funktionen können mehrere Eingabe- und Ausgabe-Bindungen beinhalten. Diese Bindungen bieten eine deklarative Möglichkeit, Verbindungen zu unterstützen Diensten zwecks Daten Austausch herzustellen. Unter https://docs.microsoft.com/de-de/azure/azure-functions/functions-triggers-bindings sind die möglichen Bindungen aufgelistet.

Wir erstellen nun eine Ausgabe-Bindung zu unserem Service Bus (Abbildung 9a). Der Wert des Attributs „name“ gibt an, unter welchem Namen wir auf das erstellte Binding im Quellcode zugreifen können. Als typ geben wir an, dass es sich um einen serviceBus handelt. Als queueName hinterlegen wir den Namen der weiter oben erstellten Queue userdataqueue. Bei connection geben wir den Namen der weiter oben erstellten Verbindungseigenschaft ein (ServiceBusConnection).

Im Anschluss wird noch angegeben, ob es sich um eine Eingabe- oder um eine Ausgabe-Bindung handelt.

Abbildung 9a

Zuletzt ändern wir die index.js so um, dass wir die Daten aus dem REST Endpoint in die Warteschlange unseres Service Bus übermitteln (Abbildung 9b). Hier nehmen wir den context und weisen unserer erstellten Bindung die zu übermittelnde Nachricht zu. Mehr müssen wir nicht tun, um eine Nachricht zu übermitteln.

Abbildung 9b

Schauen wir uns jetzt noch die andere Seite an: Um die Nachrichten in der Warteschlange zu empfangen, haben wir zu Beginn ein weiteres Unterverzeichnis („FunktionServiceBusReader“) erstellt.

Wir öffnen dort nun die function.json und erstellen einen Trigger für diese Funktion (Abbildung 10a). Achtung: Jede Funktion kann nur einen Trigger besitzen. Wir nennen in queueItem und als „typ“ hinterlegen wir serviceBusTrigger. queueName und connection sind die gleichen wie bei der FunktionServiceBus. direction ist hier nun in statt out.

Abbildung 10a

Nun müssen wir noch testen, ob wir wirklich die Nachrichten aus der Warteschlange bekommen. Dazu geben wir die erhaltenen Nachrichten im Log aus (Abbildung 10b). Haben wir alle Ü„nderungen vorgenommen, können wir diese in unser Repository pushen.

Abbildung 10b

Schauen wir nun ins Azure Portal unsere Funktionen-App an, sollten wir dort unter dem Punkt „Funktionen“ unsere beiden Funktionen wiederfinden (Abbildung 11).

Abbildung 11

Im Rahmen dieses Beispiel haben wir einen Service Bus angeschlossen und die Entwicklung aus dem Portal in unsere Entwicklungsumgebung verlagert. Mit der Anbindung von Git haben wir darüber hinaus ein Continuous Deployment eingerichtet.

Zusammenfassend kann man sagen, dass uns Microsoft sowohl mit den bereitgestellten Bindungen wie auch den Bereitstellungsoptionen einiges an Arbeit abnimmt. Möchten wir mehr Kontrolle beim Erstellen, Senden und Empfangen von Nachrichten haben, können wir den Service Bus auch mittels des Azure SDK anbinden. Für NodeJs gibt es das AzureSB Packet (https://www.npmjs.com/package/azure-sb), dass uns die nötigen Funktionen bereitstellt. Der Vorteil an diesem Paket ist, dass wir nicht das gesamte SDK in unsere Funktion laden müssen.

Abbildung 12 und 13 zeigen abschließend die Protokoll-Ansicht der beiden Funktionen. In Abbildung 12 sieht man, dass eine Nachricht geschickt wurde und in Abbildung 13 kann man erkennen, dass eine Nachricht aus der Warteschlange geladen wurde.

Im nächsten Blog gehen wir einen Schritt weiter und schauen uns an welche Möglichkeiten wir haben die nun lokal Entwickelten Funktionen zu testen und zu debuggen.

Abbildung 12

Abbildung 13