Einführung

Abgeschlossen

Dieses Modul beschreibt, wie Sie die Funktionalität von benutzerdefinierten Konnektoren mit Triggerdefinitionen erweitern können.

In diesem Modul lernen Sie Folgendes:

  • Mehr über Trigger in benutzerdefinierten Konnektoren erfahren

  • Gängige Szenarien entdecken, in denen Trigger verwendet werden können

  • Die verschiedenen Typen von Triggern identifizieren

  • Erfahren Sie, wie Sie eine benutzerdefinierte Konnektordefinition auf Trigger erweitern, die von einer Service-API definiert werden.

Mit Triggern können Sie die Konnektorfunktionalität in Microsoft Power Automate und Microsoft Azure Logic Apps erweitern, bei denen ein System auf die Änderungen der zugrunde liegenden Daten oder Dienste reagieren muss. Das häufigste Szenario für die Verwendung von Triggern ist das Erstellen eines Cloud-Flows, der beginnt, wenn sich die zugrunde liegenden Daten ändern, z. B. „Wenn ein Datensatz erstellt wird“ oder wenn ein bestimmtes Ereignis in dem vom benutzerdefinierten Konnektor definierten Dienst stattfindet, z. B. „Wenn ein Alarm ausgelöst wird“.

Triggers in Power Automate und Logic Apps

Power Automate und Logic Apps Einen Trigger definieren als Ereignis, das einen Cloud-Flow oder einen Logic Apps-Workflow startet. Diese Ereignisse können von einem Benutzer initiiert, geplant oder von einem Konnektor generiert werden, einschließlich eines benutzerdefinierten. Triggerdefinitionen erweitern benutzerdefinierte Konnektoren und ermöglichen die Verwendung dieser Konnektoren zum Initiieren von Cloud-Flows und Logic Apps-Workflows.

Screenshot der ersten Eingabeaufforderung, wenn Sie einen automatisierten Cloud-Flow erstellen und einen Trigger für den Flow auswählen

Die meisten Konnektoren definieren eine Triggerzusammenfassung als „Wenn <object> verb <ist>“, und eine typische Konnektorimplementierung enthält einen Trigger für eine oder mehrere Aktionen.

Triggertypen

Betrachten Sie ein Voicemail-Verwaltungssystem. Ein Trigger in einem solchen System könnte ein Ereignis „Neue Voicemail-Nachricht empfangen“ sein. Sie können zwei Methoden definieren, um festzustellen, ob eine neue Voicemail empfangen wurde:

  • Rufen Sie regelmäßig die Voicemailbox an, und suchen Sie nach neuen Nachrichten. Dieses Verhalten beschreibt einen Abfrage-Trigger, d. h. die Implementierung, in der Daten vom zugrunde liegenden Dienst abgefragt werden. Ein Abruftrigger ist eine zeitgesteuerte Aktivität, die in einem regelmäßigen, konfigurierbaren Intervall einen Aufruf der Service-API initiiert, um festzustellen, ob neue Daten verfügbar sind. Um Abruftrigger zu unterstützen, kann die API die Ergebnisse basierend auf einem Status filtern. Der Status ist normalerweise zeitbasiert, z. B. „Alle seit gestern empfangenen Voicemails zurückgeben“.

  • Lassen Sie sich von Ihrem Voicemail-System eine E-Mail senden, wenn eine neue Sprachnachricht empfangen wird. Dieser Ansatz definiert einen Webhook-Trigger oder eine ‑Implementierung, bei der der Dienst die Daten überträgt. Der Dienst, der Webhook-Trigger unterstützt, muss in der Lage sein, eine Liste der zurückzurufenden Teilnehmer zu führen und zu wissen, wie er zurückruft. Im Voicemail-Beispiel handelt es sich um eine Liste von E-Mail-Adressen und die Möglichkeit, eine Benachrichtigungs-E-Mail zu senden.

Grundsätzlich unterscheiden sich diese beiden Arten von Triggern darin, welche Seite für das Betriebsmanagement verantwortlich ist.

Abruf Webhook
Beginnt mit dem Festlegen eines Status Beim Dienst registriert
Überprüft regelmäßig, ob Aktualisierungen vorliegen Signalisiert, wenn ein Ereignis eintritt
Fordert alle neuen Daten seit der letzten Statusaktualisierung an Wird automatisch entfernt
Service behält den Zustand bei Power Automate oder Logic Apps verwaltet den Prozess des Registrierens und Aufhebens der Registrierung von Webhooks

Wichtig

Die Verfügbarkeit einer REST-API für einen Service bedeutet nicht, dass benutzerdefinierte Konnektortrigger definiert werden können. Der zugrunde liegende Dienst muss in der Lage sein, die Daten inkrementell zurückzugeben oder eine Webhook-Implementierung bereitzustellen. Wenn Trigger erforderlich sind, die Service-API jedoch keine der beiden Funktionen besitzt, muss ein Entwickler den Service erweitern, damit Benutzer einen Trigger definieren können.

Einen Trigger definieren

Ähnlich wie bei der Konnektordefinition werden beide Arten von Triggern durch ein OpenAPI-Dokument (Swagger) definiert, in dem die Endpunkte, Parameter, Bedingungen und Antworten angegeben sind. Die OpenAPI-Spezifikationsversion, die von Microsoft Power Platform verwendet wird, unterscheidet jedoch keine Aktionen und Trigger. Microsoft Power Platform fügt Benutzerdefinierte OpenAPI-Erweiterungen hinzu, um die Spezifikationen zu erweitern, um Trigger und deren Inhalt zu definieren.

Ein schrittweiser Assistent für Trigger ist verfügbar und folgt demselben allgemeinen Layout wie der Aktionsassistent.

Screenshot des Definitionsschritts in einem benutzerdefinierten Konnektorassistenten. In diesem Beispiel wird ein neuer Trigger „Wenn eine Rechnung erstellt wird“ definiert.

Wie bei den benutzerdefinierten Konnektoraktionen ist die Auswahl einer guten Triggerzusammenfassung wichtig. Die Zusammenfassung wird verwendet, wenn ein Entwickler die Konnektoren durchsucht. Wenn ein Trigger ausgewählt ist, wird seine Zusammenfassung zum Standardschritttitel in Power Automate und Logic Apps.

Im Gegensatz zu Aktionen, von denen die meisten vollständig im benutzerdefinierten Konnektor-Designer erstellt werden können, ist es möglich, dass Trigger komplexer sind und häufig manuelle Änderungen erfordern. In diesem Modul wird beschrieben, wie Triggerdefinitionen in Abfrage‑ und Webhook-Szenarien erstellt werden.