Azure Logic Apps – ein Anwendungsszenario

22. Juni 2016

Mit Azure Logic Apps lassen sich getriggerte Workflows erstellen und betreiben, deren einzelne Schritte von verschiedenen Web Services erledigt werden, die zu einem Geschäftsprozess orchestriert werden können. Azure Logic Apps können mit einem visuellen Designer im Azure Portal und einer JSON-basierten Definition Language entwickelt werden.

image

Azure Logic Apps, sind seit März 2015 offiziell verfügbar und seitdem im Preview-Status. Sie gehören zu den angebotenen Services des Azure App Service, zu dem auch API Apps, Web Apps und Mobile Apps gehören.

Die Idee zum Einsatz der Logic Apps entstand aus dem Konzept einer Art Microservices-Architektur. Die Aufgabenstellung: Konsolidiere Daten aus verschiedenen Backendsystemen und stelle sie für mobile Applikationen bereit. Leite Informationen aus mobilen Applikationen an zuständige Backendsysteme weiter. Daraus ergaben sich verschiedene Zuständigkeiten:

  • Schnittstellenadaption an verschiedene Backends sowie Transformation von Daten
  • Speichern konsolidierter Daten
  • Bereitstellung von Daten für Client-Anwendungen
  • Regelmäßige Datenaktualisierung
  • Ausführung von Operationen

 

Anwendungsszenario für Logic Apps

 Das Architekturkonzept stellt diese Zuständigkeiten in einen Zusammenhang, aus dem konkrete Dienste abgeleitet werden können.

clip_image002

Spezifische Adapter-Web Services stellen die Verbindung zu verschiedenen Backendsystemen (Backend A und B) her. Sie lesen und aktualisieren deren Daten und stellen diese zur Konsolidierung und Anzeige in einer Client-Anwendung bereit.

Die Client-Anwendung bezieht die konsolidierten Daten von einem zentralen Anwendungs-Web Service.

In der Mitte sitzen zwei Workflows für Datenaktualisierung und die Ausführung von backendspezifischen Aktionen. Sie sind als Azure Logic Apps implementiert. Die beiden Workflows tun nichts weiter, als Requests an Web Services zu senden und auf deren Responses zu reagieren. OK, sie benötigen einen Zeitplan und müssen gewisse Bedingungen auswerten, aber viel mehr Logik haben sie nicht. Jetzt könnte man diese Workflows mit .NET-Mitteln selbst implementieren, Logic Apps bieten die benötigten Funktionen aber bereits an und sind prädestiniert für die Erstellung von Workflows. Das benötigte Verhalten lässt sich rein deklarativ erstellen.

Das folgende Bild stellt das oben abgebildete Konzept mit den entsprechenden Azure Services dar, die für die Umsetzung geeignet sind (Empfehlung):

clip_image003

Was sind nun die wesentlichen Schritte, um eine derartige Architektur mit Hilfe von Logic Apps auf die Beine zu stellen? Vorausgesetzt es steht eine Azure Subscription zur Verfügung, lautet ein mögliches Vorgehen:

  1. Entwicklung der einzelnen Web Services (API Apps) und Deployment in die Azure Subscription
  2. Anlegen der Logic Apps und Einbindung der zuvor erstellten API Apps

Eigentlich einfach. Wenn denn alles, wie in den einschlägigen Tutorials erklärt, funktioniert.

Immer noch Preview

Aufgrund des Preview-Status der Technologie unterliegen Logic Apps immer noch einer hohen Änderungshäufigkeit. Schnittstellen ändern sich, einmal deployte API Apps stehen auf einmal nicht mehr im Logic App Designer zur Auswahl, und ähnliche “Überraschungen” warten auf den interessierten Entwickler. Ob man Logic Apps bereits in kritischen Projekten einsetzen will, sollte daher gut überlegt sein. Die allgemeine Verfügbarkeit der Logic Apps, d. h. das Verlassen des Preview-Status wird von Microsoft für Q2 2016 angekündigt.

Wie schon erwähnt, können Logic Apps mit einem visuellen Designer “zusammengeklickt” werden. Der Designer hat jedoch noch Grenzen, und es sind noch nicht alle Features vom Designer unterstützt.. Sämtliche Möglichkeiten hingegen stehen dem Entwickler offen, wenn er sich vorab intensiv mit der Logic App Definition Language auseinandersetzt. Ist ein Workflow damit einmal entwickelt, unterstützt der Designer wieder bei der Visualisierung desselben. Auch Änderungen lassen sich im Designer durchführen, aber eben nur in gewissen Grenzen. Daher lautet die Empfehlung, einen Workflow zunächst rudimentär im Designer aufzusetzen, so dass die wesentlichen Services (Schritte) enthalten sind, und danach im Code weiterzuarbeiten. Zur Kontrolle kann schlussendlich der Workflow wieder im Designer geöffnet und verifiziert werden.

Visual Studio unterstützt bei der Entwicklung von Logic Apps. Mit dem Azure SDK kommen Projekt-Templates und Publishing-Mechanismen ins Studio.

Noch ein Wort zu den API Apps. Azure unterscheidet mittlerweile zwischen Managed APIs und Custom APIs. Die eigenen entwickelten Web Services fallen unter die Custom APIs. Aus .NET-Entwicklersicht handelt es sich um gewöhnliche Web APIs, die jedoch zusätzlich ihre Schnittstelle als Swagger-Definition exportieren. Mit Hilfe dieser Swagger-Definition können entsprechende Clients generiert werden. Azure nutzt dies z. B. für die Generierung eines entsprechenden UI für die Parameterdefinition im Logic App Designer. Erstellt man im Visual Studio eine neue API App, so wird automatisch eine Swagger-Definition durch das Projekt-Template hinzugefügt (NuGet).

Zur weiteren Lektüre und zum vertiefenden Einstieg in die Materie seien die relativ gut dokumentierenden Blog-Artikel auf der Azure Website empfohlen.