Azure Logic Apps – Einfach automatisch

English Version

Es ist eine Binsenwahrheit: Automatisierung von wiederkehrenden Abläufen wird immer wichtiger. Und angeblich dank ChatGPT und co. auch immer einfacher. Aber Code allein nützt nichts, es braucht Prozesse und Tools um solche Automatisierungen möglich zu machen. Ein Stichwort ist dabei ‚Low Code‘: Dabei werden Administratoren und User mit den nötigen Tools unterstützt um selber Workflows zu bauen aber ohne gleich tiefgründig Programmiersprachen lernen zu müssen. Wie das geht möchte ich an einem Beispiel aufzeigen. Dabei werden wir folgende Werkzeuge einsetzen.

• Microsoft Forms
  • Nicht immer braucht es eine grafische Benutzeroberfläche um die Inputs zu liefern, die für den automatisierten Ablauf benötigt werden. Aber gerade wenn End-User Informationen liefern müssen, dann bietet sich Microsoft Forms an um eine Eingabemaske zur Verfügung zu stellen.
• Logic App
  • Azure Logic App ist ein halb-grafisches Tool, in dem sich der IT Admin seinen Workflow zusammen stellen und anpassen kann. Dahinter steht zwar Code, aber das muss den IT Admin erstmal nicht kümmern. Ganz ohne Programmieren geht es nicht, aber der grafische Editor unterstützt den IT Admin bei seinem Vorgehen.
• On-Premises Data Gateway
  • Der On-Premise Data Gateway ist eine lokal installierte Applikation, mit dem Zweck die Verbindung zu den Systemen herzustellen, die noch nicht in der Cloud stehen. Das können unter anderem lokale Fileserver oder auch Datenbanken sein.

In der Microsoft Welt hat sich Powershell als Sprache für Scripts durchgesetzt. Warum? Alles ist sehr unkompliziert und logisch. Die Hauptbefehle (get-, set- etc) sind einfach zu verstehen und es gibt praktisch für alles ein Powershell Modul mit zahlreichen Befehlen und Optionen. Die Lernkurve ist zwar da aber nicht so steil. Sehr oft braucht es ein Inputfile über das dann ein Output generiert oder abgearbeitet wird. Was fehlt? Der grafische Teil, weil es eben eine Sprache für Admins ist und nicht für End-User. Die gute Nachricht: Diese Lücke kann mit Azure Logic Apps und Microsoft Forms überbrückt werden.

Wie könnte ein Beispielablauf aussehen?

• Ein Benutzer möchte eine Postfachvergrösserung
• Dazu füllt er ein grafisches Formular aus
• Diese Information wird in eine Datei geschrieben
• Die Datei wird von einem Powershell Script abgeholt, ausgelesen und abgearbeitet

Wie setze ich das technisch um?

Schritt 1:

• Ein Formular erstellen mit Microsoft Forms

Schritt 2:

• Einen On-Premise Data Gateway installieren

Schritt 3:

• Eine Azure Logic App bauen und an den Gateway anbinden

Schritt 4:

• Die daraus enstandenen Daten per Powershell Script abarbeiten

Erstellung des Formulars

Dieser Schritt ist denkbar einfach, denn Microsoft Forms ist Teil der M365 Cloud und kann unter https://forms.office.com aufgerufen werden. Ein ganz einfaches Formular könnte so aussehen:

• Jedes Feld, dass der Benutzer ausfüllt kann später von der Azure Logic App ausgelesen und weiter bearbeitet werden
• Die Sicherheit ist gewährleistet weil der Benutzerkreis des Formulars eingeschränkt werden kann über eine Entra Usergruppe.

Den On-Premise Data Gateway installieren

Ein On-Premise Data Gateway, ist eine lokal installierte Applikation, die im Azure registriert wird und über Port 443 (outgoing) immer wieder schaut ob es neues gibt. Ich möchte hier nicht gross darauf eingehen, weil der Setup reicht einfach und gut dokumentiert ist. Ein OPDG erlaubt uns die im Microsoft Forms eingegeben Daten per Azure Logic App auf einen lokalen Fileserver zu schreiben. Wie das geht sehen wir im Folgeschritt ‚Logic App‘.

Die Logic App bauen

Als nächstes kommt die Logic App an die Reihe. Das ist ein grafischer Workflow, denn wir uns im Azure Portal zusammen stellen und der nur wenig Programmierkenntnisse benötigt. Was soll unsere neue Logic App denn machen? Wir sehen hier, dass die Logic App im Grundsatz aus vier Schritten besteht. Wobei der letzte Schritt nicht immer ausgeführt wird, wie wir noch lernen werden.

Schritt1 – „When a new response is submitted“

• Die LogicApp wartet 365 Tage und 24h am Tag darauf, dass jemand das Formular ausfüllt. Sobald jemand den ‚Absenden‘ Knopf drückt wird der Workflow ausgelöst.
• Wichtig ist hier der Parameter ‚Form ID‘, der auf das vorgängig erstellte Formular verweisen muss.

• Schritt 2 – „Get response details“
• Damit die Informationen weiter verarbeitet werden können, müssen diese für weitere Schritte zur Verfügung stehen. Die Eingaben aus den einzelnen Feldern können nachher über die Feldnamen angesprochen werden. Dafür ist dieser Baustein zuständig.

Schritt 3 – „Append File“

• Das Formular kann beliebige Male ausgefüllt werden. Jede neue Eingabe ergänzt die Datei um eine weitere Zeile. Dabei geht es um ein simples Textfile bei dem auf jeder Zeile eine e-mail Adresse steht.
• Wir definieren jetzt den Pfad zur Datei. Hier kommt der On-Premise Data Gateway ins Spiel, denn es geht um einen Dateipfad der nicht im Azure liegt sondern auf einem lokalen Fileserver. Die Funktion ‚Append File‘ ist nur verfügbar wenn mindestens ein OPDG angelegt wurde. Selbstverständlich könnte man auch Dateien im Azure ablegen, aber das wäre ein anderes Szenario.

• Es gibt folgende Möglichkeiten Inhalte zur Datei zuzufügen oder zu bearbeiten
  • Dynamic Content: Das sind die Felder und Eigenschaften von vorgehenden Aktionen (die Felder aus ‚Get Response Details im Schritt 2)
  • Insert Expression: Erweiterte Funktionsmöglichkeiten wie Textmanipulationen sind damit möglich. In unserem Beispiel wollen wir eine e-mail Adresse pro Zeile und müssen darum nach jedem Eintrag auf die nächste Zeile umschalten:
    • uriComponentToString(‚%0D%0A‘)

Schritt 4 – „Create File“

• Wieso kommt dieser Schritt mit der Erstellung jetzt? Bei Schritt 3 wurde die Datei doch schon ergänzt? Das besondere an diesem Schritt ist, er wird nur ausgeführt wenn Schritt drei (Append File) nicht funktioniert hat. Warum das so ist sehen wir später auch unter Schritt 5. Unter Powershell wäre das ein ‚Try – Catch‘ Block, der hier auf einfache Weise mit dem grafischen Editor erledigt werden kann, wie wir im Bild sehen.

Schritt 5 – Abholen und Bearbeiten des Files mit Powershell

Ich gehe mit Absicht nicht auf die Details des Powershell Scripts ein weil es mir im Beitrag um die Logic App Möglichkeiten geht. Als Starthilfe ergänze ich unten die Logik mit der Erwähnung der relevanten Kommandos.

• Dank Schritt 3 / 4 gibt es ein Textfile mit e-mail Adressen. Nutzen wir nun einen ‚Scheduled Task‘ in Verbindung mit einem Powershell Script um regelmässig folgendes zu tun:
  • Gibt es ein Textfile? (get-item, copy-item… )
    • Wenn ja: Namen in der Liste abarbeiten (foreach ….)
    • Versand eines e-mails, dass die Bearbeitung durchgeführt wurde (send-mailmessage…)
    • Löschen des Files (remove-item…)
• Hier erklärt sich warum in Schritt 4, dass File erstellt werden muss falls nicht vorhanden. Läuft der Task alle Stunde kann innerhalb einer Stunde ein neuer Name zum bestehenden File zugefügt werden (Schritt 3) und sonst wird ein neues File erstellt (Schritt 4).

Wie sieht es mit der Nachvollziehbarkeit aus?

• Dank ‚Run History‘ und ‚Trigger History‘ wissen wir wann und wie oft die Logic App durchgelaufen ist und warum
• Ueber ‚Versions‘ können wir zu vorherigen Versionen zurückkehren und Aenderungen erkennen

Fazit

Ganz ohne Programmieren geht es nicht. Das Error Handling und die Plausibilitätsprüfung etc. müssen spätestens im Powershell Script unter Schritt 5 abgehandelt werden. Aber wir können so in kurzer Zeit und ohne grossen Aufwand bereits bestehende Abläufe oder Scripts um eine grafische Komponente mit Eingabeformular erweitern.

Und zuletzt

Zum guten Schluss noch einmal eine Erinnerung an wichtige Seiten:

• Die Feedbackseite „Vorschlaghammer“ – hier kannst Du Fragen stellen oder Wünsche oder Ideen einbringen
• Die T-Shirt Seite – hier kannst Du das ClickCoach Team unterstützen und dabei noch gut aussehen