Erkennen eines externen Ereignisses mithilfe eines Triggers

Abgeschlossen

In Azure Logic Apps startet ein Trigger immer einen Workflow als ersten Schritt. Um Ihren Workflow ordnungsgemäß auszuführen, müssen Sie den besten Trigger finden und die Eigenschaften des Triggers für Ihr Szenario einrichten. Für das Beispiel wird verwenden Sie einen Twitter-Trigger, der den Workflow ausführt, wenn ein Tweet mit dem Produktnamen veröffentlicht wird.

In dieser Lerneinheit befassen Sie sich mit Triggertypen sowie den Stärken und Schwächen der am häufigsten verwendeten Optionen. Dabei erfahren Sie, wie Sie einen Logik-App-Workflow im Azure-Portal erstellen und ihr einen Trigger im Workflow-Designer hinzufügen.

Triggertypen

Berücksichtigen Sie die verschiedenen Triggerbedingungen, mit denen Unternehmen ihre Logik-App-Workflows ausführen können. Die meisten bisherigen Beispiele sind Trigger, die erkennen, ob Daten oder ein Ereignis in einem Dienst oder System bestimmte Bedingungen erfüllt. Beispiele: wenn ein neuer Tweet gepostet, ein Datensatz in die Datenbank eingefügt, eine E-Mail gesendet oder eine Datei in Ihren Cloudspeicher hochgeladen wird. Trigger, die Daten oder Ereignisse erkennen, werden nach den folgenden Techniken unterteilt:

  • Trigger, die regelmäßig einen Dienst oder ein System auf Daten oder Ereignisse gemäß bestimmten Bedingungen abfragen oder überprüfen
  • Trigger, die Pushbenachrichtigungen von einem Dienst oder System erwarten und empfangen, wenn Daten oder Ereignisse bestimmte Bedingungen erfüllen

Wie ist jedoch vorzugehen, wenn Sie einen Trigger benötigen, der nicht an Daten oder Ereignisse im Dienst oder System gebunden ist? Angenommen, Sie möchten Ihren Workflow jeden Samstag um Mitternacht oder nach einem anderen Zeitplan ausführen. Sie können den Wiederholungstrigger verwenden, um Aktionen in einem Workflow zu planen und auszuführen. Beispielsweise können Sie Workflows planen, die administrative Aufgaben übernehmen, etwa das Ausführen von Sicherungen oder das Archivieren alter Daten. Angenommen, Sie möchten Ihren Workflow nur beim Aufruf durch Code oder eine andere Quelle ausführen? Sie können den Trigger Anforderung oder „manuell“ verwenden, um auf Anforderungen zu warten, z. B. solche, die von Code in Ihrer Web-App oder Ihrer mobilen App gesendet werden.

Im folgenden Diagramm werden die zuvor beschriebenen Triggertypen zusammengefasst:

An illustration showing the four types of triggers: polling, push, recurrence, and manual.

In den folgenden Abschnitten finden Sie weitere Informationen zu Abfragetriggern und Pushtriggern.

Was ist ein Abfragetrigger?

Ein Abfragetrigger überprüft regelmäßig einen Dienst oder ein System auf Daten oder Ereignisse, die bestimmte Bedingungen erfüllen. Wenn der Trigger nach dieser Überprüfung Daten oder Ereignisse findet, die die Bedingungen erfüllen, startet er eine neue Workflowausführung. Der RSS-Connector verfügt beispielsweise über einen Abfragetrigger, der regelmäßig nach neuen Beiträgen in einem RSS-Feed suchen kann.

Nachdem Sie Ihrem Workflow einen solchen Trigger hinzufügen, legen Sie eine Häufigkeit und ein Intervall fest, um zu steuern, wie oft der Trigger ausgeführt wird. Die Häufigkeit ist eine Zeiteinheit wie Sekunde, Minute, Stunde, Tag, Woche oder Monat. Das Intervall ist die Anzahl der Zeiteinheiten, die verstreichen, bevor der Trigger erneut auf Daten oder Ereignisse überprüft. Ein Abfragetrigger, für den die Häufigkeit Minute und das Intervall 5 festgelegt wird, führt die Überprüfung also alle fünf Minuten durch.

Bei Abfragetriggern müssen Sie zwischen der Anzahl der Triggerausführungen und deren Kosten abwägen. Häufig gibt es eine Verzögerung zwischen dem Zeitpunkt, zu dem neue Daten oder Ereignisse auftreten, und dem Erkennen dieser Daten oder Ereignisse durch den Trigger. Nehmen Sie beispielsweise an, ein Abfragetrigger überprüft alle fünf Minuten auf Daten. Neue Daten werden nach sieben Minuten verfügbar. Der Trigger erkennt die neuen Daten erst nach der nächsten Abfrage, die bei 10 Minuten erfolgt. Im folgenden Diagramm wird gezeigt, wie diese Abfrage funktioniert:

Diagram shows a timeline and a polling trigger checking for new data every five minutes. New data becomes available after seven minutes. The trigger doesn't detect the new data until the next poll, which happens at 10 minutes.

Im schlimmsten Fall entspricht die potenzielle Verzögerung bis zur Erkennung der neuen Daten dem Abrufintervall. Warum sollte also nicht einfach ein kürzeres Intervall verwendet werden? Zum Überprüfen auf neue Daten muss die Ausführungs-Engine von Azure Logic Apps Ihren Workflow ausführen. Bei diesem Vorgang fallen Kosten an. Allgemein sind mit einem kürzeren Intervall höhere Kosten verbunden, aber der Trigger reagiert schneller auf neue Daten oder Ereignisse. Welches Abrufintervall für Ihren Trigger am besten geeignet ist, hängt von Ihrem Geschäftsprozess und der Toleranz für Verzögerungen ab.

Was ist ein Pushtrigger?

Ein Pushtrigger wartet auf Benachrichtigungen von einem Dienst oder System, wenn Daten oder Ereignisse bestimmte Bedingungen erfüllen. Der Trigger abonniert einen Endpunkt in einem externen Dienst oder System. Wenn neue Daten oder Ereignisse die Bedingungen erfüllen, benachrichtigt der Dienst oder das System den Trigger, der dann sofort eine neue Workflowausführung startet. Beispielsweise weist der Azure Service Bus-Connector einen Pushtrigger auf, der erkennt, wenn einer Azure Service Bus-Warteschlange eine Nachricht hinzugefügt wird.

Hinweis

Pushtrigger verwenden Webhooks, mit denen Trigger den externen Dienst oder das System abonnieren können. Zum Zeitpunkt des Abonnementabschlusses generiert Azure Logic Apps eine Rückruf-URL für den Trigger und registriert die URL beim externen Dienst oder System. Ebenso meldet Azure Logic Apps die Rückruf-URL ab und hebt ihre Registrierung auf, wenn Sie das Abonnement nicht mehr benötigen, z. B. wenn Sie Ihren Workflow deaktivieren oder löschen.

Der Vorteil besteht darin, dass Pushtrigger nicht ausgeführt werden, wenn keine Daten oder Ereignisse verfügbar sind. Sie verursachen somit keine Kosten für die Abfrage. Diese Trigger reagieren auch sofort, wenn neue Daten oder Ereignisse vorhanden sind. Das folgende Diagramm zeigt, wie dieser Pushvorgang funktioniert:

Diagram shows a timeline where a marker indicates when new data becomes available. The push trigger detects the data and immediately responds.

Warum werden Pushtrigger nicht immer verwendet, wenn sie schneller reagieren und weniger kosten als Abfragetrigger? Leider stellt nicht jeder Connector einen Pushtrigger bereit. Möglicherweise unterstützt der externe Dienst keine Pushtrigger, oder der Autor des Connectors hat keinen Pushtrigger implementiert. Connectors stellen normalerweise entweder Push- oder Abfragetrigger bereit, jedoch nicht beide. In den seltenen Fällen, in denen ein Connector beide Optionen bietet, sollten Sie aufgrund der besseren Effizienz die Verwendung des Pushtriggers in Betracht ziehen.

In diesem Modul beschäftigen Sie sich mit Abfragetriggern. Diese Trigger werden am häufigsten eingesetzt und eignen sich sehr gut für die bisher betrachteten Szenarios, in denen Daten weitergeleitet und verarbeitet werden.

Parameter und Rückgabewerte von Triggern

Triggervorgänge lassen sich mit Funktionsaufrufen vergleichen, die über Parameter und Rückgabewerte verfügen. Mit Triggerparametern können Sie den Vorgang konfigurieren. Der Twitter-Trigger mit dem Namen Wenn ein neuer Tweet gepostet wird weist einen Parameter Suchtext auf. Der Trigger verwendet diesen Parameter, um passende Tweets auszuwählen. Für einige Vorgänge gibt es sowohl erforderliche als auch optionale Parameter. Der SQL Server-Trigger Wenn ein Element erstellt wird enthält den erforderlichen Parameter Tabellenname und verschiedene optionale Parameter wie Sortieren nach und SELECT-Abfrage.

Triggerrückgabewerte sind die Ergebnisse des Vorgangs. Der Bitbucket-Connector weist beispielsweise einen Trigger namens When a pull request is merged (Wenn ein Pull Request gemergt wird) auf. Der Trigger gibt ein Objekt zurück, das Daten enthält, z. B. die Repositoryidentität und den Akteur, der die Mergeaktion genehmigt hat. Die meisten Trigger geben eine Objektsammlung zurück und nicht ein einzelnes Objekt. Der Twitter-Trigger Wenn ein neuer Tweet gepostet wird gibt beispielsweise ein Array mit TweetModel-Objekten zurück. Jedes Objekt enthält Werte wie Tweet-Text, Benutzername und Anzahl der Follower. Das folgende Diagramm zeigt eine Sammlung, die aus einem Trigger zurückgegeben wird:

Diagram shows Twitter trigger interacting with Twitter. The trigger sends the search text to Twitter, and Twitter returns an object array. Each object in the array contains information about one of the matching tweets.

Sie können für die Verarbeitung der einzelnen Elemente eine Schleife verwenden oder den Trigger dazu einrichten, das Array zur Verarbeitung aufzuteilen. Für die meisten Trigger, darunter der Twitter-Trigger, besteht das Standardverhalten darin, das Array automatisch aufzuteilen. Die Azure Logic Apps-Engine erstellt eine Workflowinstanz für jedes Element, und alle Instanzen werden parallel ausgeführt. Das folgende Diagramm zeigt, wie jedes Element im zurückgegebenen Array für die Verarbeitung an eine andere Workflowinstanz geleitet wird:

Diagram shows three tweets returned from the Twitter trigger and three workflow instances in the social media monitoring logic app. An arrow connects each tweet in the array with each workflow instance in the logic app.

Erstellen eines Logik-App-Workflows im Azure-Portal

Suchen Sie im Azure-Portal den Ressourcentyp Logik-App, wählen Sie ihn aus, und geben Sie Informationen zur Ressource an, z. B. Name, Abonnement, Ressourcengruppe und Standort. Nach Abschluss der Bereitstellung können Sie zur Logik-App-Ressource wechseln.

Wenn Sie Ihre neue Logik-App-Ressource öffnen, finden Sie eine Seite für die ersten Schritte. Diese Seite enthält häufig verwendete Trigger und einen Vorlagenkatalog mit gängigen Workflowmustern und App-Typen. Beispielsweise finden Sie dort Vorlagen für Workflows wie In Slack posten, wenn ein neuer Tweet mit einem bestimmten Hashtag übereinstimmt und Tägliche Erinnerungen per E-Mail erhalten bereit.

Auf der Seite für die ersten Schritte können Sie einen allgemeinen Trigger für Ihren Workflow auswählen, oder Sie können eine Vorlage auswählen, um einen vollständigen Workflow zu generieren. Wenn eine Vorlage zu Ihrem Szenario passt, können Sie bei der Einrichtung Ihrer App einige Zeit einsparen. Wenn Sie die gesamte Arbeit selbst erledigen möchten, können Sie die Vorlage Leere Logik-App auswählen.

Nachdem Sie eine Vorlage ausgewählt haben, wird automatisch der Workflow-Designer geöffnet.

Hinzufügen eines Triggers mithilfe des Designers

Der Workflow-Designer zeigt einen Connectorkatalog mit den Triggern und Aktionen, die Sie in Ihrem Workflow verwenden können. Wenn Sie mit einem leeren Workflow beginnen, verwenden Sie das Suchfeld, um nach einem interessanten Connector zu suchen. Anschließend überprüfen Sie die Trigger, die der Connector bereitstellt. Wählen Sie in unserem Beispiel den Twitter-Trigger Wenn ein neuer Tweet gepostet wird aus. Für Twitter muss auch eine Verbindung erstellt werden, indem Sie sich bei Ihrem Twitter-Konto anmelden.

Nachdem Sie einen Trigger hinzugefügt und bei Bedarf eine Verbindung mit dem Dienst oder System erstellt haben, werden im Designer die Triggereigenschaften angezeigt. Legen Sie für Twitter die Parameter Suchtext, Häufigkeit und Intervall fest. Der folgende Screenshot zeigt den Workflow der Social-Media-Überwachungs-Logik-App im Designer, in dem der Twitter-Trigger als erster Schritt angezeigt wird.

Screenshot shows example logic app workflow in the designer. A box for each step represents the trigger and each action. Arrows connect the boxes to show execution through the workflow.