Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03210.jsonl.gz/254

Ein häufiges Szenario in der Verwendung von Logic Apps sind wiederkehrende Prozesse, die beispielsweise Daten auf einem Drittsystem aktualisieren. Dies wird häufig in einem regelmäßigen Zyklus (beispielsweise jede Nacht) durchgeführt. Sowohl für Entwickler als auch für Interessenten aus dem Business kann das Ergebnis dieses nächtlichen Prozesses interessant sein. Zudem kommen in solchen Szenarien häufig mehrere Systeme zum Einsatz, bei denen nicht immer sichergestellt werden kann, dass die Daten aufgrund von Wartungsarbeiten o.ä. richtig verarbeitet wurden. Um die Transparenz und Wartbarkeit dieser Szenarien zu vereinfachen, bieten Logic Apps die Möglichkeit, mit einer „Adaptive Card“ für Microsoft Teams zu arbeiten. Der Teams-Connector ermöglicht es, eine Status-Nachricht an eine Person oder einen Channel zu senden und ggf. auf eine Antwort zu warten.
Logic App Aufbau
Hierfür werden zwei Workflows in einer Logic App verwendet. Der erste verwendet einen „Recurrence“-Trigger, welcher nächtlich Daten zur Verarbeitung abholt und diese Daten in einen ServiceBus legt.
Der zweite Workflow verrichtet mit diesen Daten eine beliebige Arbeit und gibt das Ergebnis in einem Teams-Channel aus. Nachfolgend ist dieser Workflow zu sehen.
Adaptive Cards für Microsoft Teams
Eine Adaptive Card bietet viele verschiedene Möglichkeiten der Darstellung und des Inhalts. Diese Karten können in einem Online-Designer generiert werden (https://adaptivecards.io/designer/). Hier besteht die Möglichkeit, verschiedene Bilder, Texte, Links und Buttons hinzuzufügen. Die fertige Karte kann als JSON-Objekt exportiert werden. Dieses Objekt wird anschließend in dem Connector verwendet.
Konfiguration für einen erfolgreichen Durchlauf
Der Connector hat einige Einstellmöglichkeiten. Zunächst wird jedoch ein registrierter Microsoft-Account benötigt. Die Logic-App verwendet diesen Account, um die Nachricht in dem entsprechenden Channel zu veröffentlichen.
Zunächst wird ausgewählt, in welchem Teams-Channel und in welchem Team diese Nachricht veröffentlicht wird. Abschließend wird das generierte JSON-Objekt mit der Adaptive Card eingetragen. Dies kann hier nachträglich noch um dynamische Werte erweitert werden. Sollte der Durchlauf erfolgreich sein, so wird nicht zwingend eine Reaktion auf diese Benachrichtigung benötigt. Hierfür bietet sich also der „Post“-Connector an, welcher nicht auf eine Antwort wartet.
In diesem Beispiel wird ein erfolgreicher Durchlauf gezeigt. Hier ist zu sehen, dass die Adaptive Card vom eingetragenen Microsoft-Benutzer abgesendet wird. Zudem wurde ein Link angegeben, welcher zu dem entsprechenden Durchlauf im Azure-Portal zeigt. Dadurch kann schnell auf den entsprechenden Durchlauf geschaut werden, falls notwendig.
Konfiguration für einen fehlgeschlagenen Durchlauf
Für den Fall, dass die zu erledigende Arbeit fehlschlägt, wird ein Connector verwendet, welcher eine Teams-Nachricht absendet und auf eine Antwort wartet.
Dieser Connector hat neben den Einstellungen des vorherigen Connectors ein Input-Feld, welches den Text für die Aktualisierung des Texts der Adaptive Card angibt. Der Ablauf in diesem Fall ist das Betätigen eines Buttons in der Adaptive Card, woraufhin die Nachricht geändert wird. Dadurch wird verhindert, dass der Bestätigungs-Button mehrfach betätigt wird.
In diesem Beispiel wird die Adaptive Card eines fehlgeschlagenen Durchlaufs aufgezeigt. Hierbei wird zusätzlich ein Fehler Code dynamisch angegeben. Zudem wurde ein Button eingefügt, der es erlaubt, den ErrorLog, welcher vorab auf einem Sharepoint gespeichert wurde, herunterzuladen. Der entscheidende Unterschied ist allerdings der „Rerun“-Button. Er dient als Bestätigung der Adaptive-Card. Nach dieser Betätigung wird der Workflow fortgesetzt. Um dies zu ermöglichen, muss der Button allerdings folgendem Format folgen:
Durch den Typ „Action.Submit“ wird der Button als Bestätigung anerkannt, woraufhin sich die Teams-Nachricht entsprechend ändert und der Text aus dem eingestellten Feld „Update message“ angezeigt wird.
In diesem Fall wird die Nachricht ein weiteres Mal in den Service Bus gelegt und versucht die entsprechende Arbeit erneut zu tätigen.
Sollte dieses Rerun nicht erwünscht sein, wird der Button nicht gedrückt. In diesem Szenario muss man allerdings beachten, dass der Workflow weiterhin auf eine Antwort wartet. Hierfür bietet der Connector jedoch die Möglichkeit, einen Timeout einzustellen.
Hierbei wird der „Action Timeout“ in den Settings des Connectors entsprechend eingestellt. Hier gilt der Wert „P15M“ beispielsweise als ein Timeout nach 15 Minuten ohne Reaktion. Für ein sauberes Verarbeiten des Workflows wird parallel zum Versenden der ServiceBus ein „Terminate“-Connector auf den Timeout konfiguriert, sodass der Workflow wie gewünscht endet und keine weitere Nachricht in den Service Bus schickt.
Dieses Vorgehen ermöglicht es verschiedenen Nutzern, auch ohne Zugang zum Azure Portal, einen Rerun des Workflows durchzuführen und ggf. fehlgeschlagene Datensynchronisationen durchzuführen.
Dieser quiTeq-Tipp kommt aus Stuttgart von Maic Schellig.