Abruftrigger
Ein Abruftrigger ist eine Implementierung, die Ihren REST-API-Service regelmäßig aufruft und nach neuen Daten sucht. Nachdem die Plattform festgestellt hat, dass neue Daten verfügbar sind, wird der Trigger ausgelöst und leitet die neu gesammelten Daten an einen Cloud-Flow oder einen Logic Apps-Workflow weiter.
Das folgende Diagramm zeigt einen grundlegenden Prozessablauf, in dem gezeigt wird, wie ein Abruftrigger neue Daten erfasst.
Ein Abruftrigger beginnt mit dem Abrufen der Daten und dem Festlegen eines Status. Anschließend wird regelmäßig nach Aktualisierungen gesucht, indem alle Daten seit der letzten Statusaktualisierung angefordert werden. Nachdem die neuen Daten abgerufen wurden, wird der neue Status festgelegt und der Vorgang fortgesetzt. Die API muss in der Lage sein, die Daten basierend auf einem Parameterwert inkrementell zurückzugeben. Power Automate oder Azure Logic Apps behält den Status bei, sodass für die API keine besonderen Anforderungen für die Statusverwaltung gelten.
Im Gegensatz zu einem Webhook-Trigger gelten für einen Abruftrigger keine Anforderungen zum Einrichten oder Herunterfahren, und die Verarbeitung kann jederzeit gestoppt werden. Die Einfachheit der Anforderungen ist ein Hauptvorteil des Abruftriggers.
API-Anforderungen
Für einen Abruftrigger muss eine API nur über eine Datenabrufmethode verfügen, mit der die Daten mithilfe eines Abfragezeichenfolgenparameters gefiltert werden können. Es muss auch eine Möglichkeit vorhanden sein, den nächsten Wert des Parameters aus den zurückgegebenen Daten zu extrahieren. Die Implementierung kann entweder durch eine dedizierte oder eine vorhandene Aktionsmethode bereitgestellt werden.
Stellen Sie sich beispielsweise eine Online-Shop-Implementierung vor, bei der Bestellungen immer mehr Bestellnummern haben. Die Store-API kann eine Methode mit der Bezeichnung ListOrders enthalten, die Bestellungen zurückgibt, die im Geschäft erstellt wurden.
ListOrders gibt die Bestellungen zurück, die nach Auftragsnummer in absteigender Reihenfolge sortiert sind. Infolgedessen gehört die höchste Bestellnummer zur ersten Bestellung in der Liste.
ListOrders akzeptiert einen Abfragezeichenfolgenparameter, um die Bestellungen abzurufen, bei denen die Bestellnummer größer als der Parameterwert ist.
Diese beiden Eigenschaften ermöglichen es, die Aktion als Abruftrigger zu verwenden. Die Plattform kann die höchste Bestellnummer aus den zurückgegebenen Daten extrahieren und als Parameter an die nächste Anforderung übergeben. Tatsächlich wählt die Methode „alle Aufträge aus, die seit der letzten Ausführung erstellt wurden“.
Implementierung
Ein Abruftrigger wird mithilfe eines Assistenten in Power Automate erstellt. Der Prozess umfasst die folgenden Schritte:
Die HTTP-Anforderung definieren, die zum Abrufen der Daten verwendet wird
Die Abfragezeichenfolge der Anforderung enthält den Parameter fromWidget, der das Vorabgenerieren der Parameterdefinition ermöglicht. Dieser Parameter stellt sicher, dass die zurückgegebenen Daten inkrementell sind und „alle Widgets zurückgeben werden, die ersteldie seit dem vom Parameter angegebenen Widget erstellt wurden“.
Ändern Sie die Sichtbarkeit des Parameters in Internal. Dies verhindert, dass Benutzer Änderungen an diesem Parameter vornehmen, der nur intern vom Konnektor verwendet wird.
Definieren Sie die Daten, die vom Service zurückgegeben werden. Diese Daten sollten die Eigenschaft enthalten, die als Wert für fromWidget in den aufeinander folgenden Anfragen verwendet werden sollen.
In diesem Beispiel wird die Eigenschaft als ID bezeichnet.
Schließen Sie die Triggerkonfiguration ab. Wählen Sie den Abfrageparameter aus, definieren Sie einen Wert oder Ausdruck, der einen Wert zurückgibt, und wählen Sie dann eine Sammlung aus, die die Triggerdaten enthält.
Dieses Beispiel enthält die folgenden Parameter:
fromWidget wird als Abfrageparameter ausgewählt, der den aus den Lab-Ergebnissen extrahierten Wert erhält.
Der Ausdruck @{triggerBody().widgets[0].id} extrahiert die aktuell höchste Widget-ID. Da die zurückgegebene Sammlung nach absteigendem ID-Wert sortiert ist, können Sie durch Extrahieren des Werts aus dem ersten Element sicherstellen, dass es sich um die höchste aktuelle ID handelt.
Der Ausdruck @triggerBody().widgets definiert die Datensammlung.
Parameter müssen extrahiert und verarbeitet werden, und diese Transformation kann nur mithilfe einer Konnektorrichtlinie implementiert werden. Folglich wird die Konfiguration des Abruftriggers als Richtlinienvorlage gespeichert, die von der OpenAPI-Konnektordefinition getrennt ist. Eine Auswirkung ist, dass es nicht möglich ist, alle Konfigurationen des Abruftriggers im Swagger-Editor manuell zu bearbeiten.
Sie müssen als Einschränkung beachten, dass der Triggertext kein Array sein kann. Stellen Sie sich zum Beispiel eine Methode mit dem Namen ListOrders vor, das die folgenden Daten zurückgibt:
[
{"value" : 42.00, "id" : "2", ... },
{"value" : 10.00, "id" : "1", ... }
]
Dieser Triggertext wird nicht verarbeitet, und der Trigger generiert einen Fehler im Power Automate-Flow oder im Logic Apps-Workflow zur Laufzeit.
Stattdessen muss die Methode eine Eigenschaft zurückgeben, die das Array von Datensätzen enthält, z. B.:
{
"orders": [
{ "value" : 42.00, "id" : "2", ... },
{ "value" : 10.00, "id" : "1", ... }
]
}
Diese Datenstruktur kann als Teil der Implementierung des Abruftriggers verwendet werden.
Batchverarbeitung
Ähnlich wie beim Webhook-Trigger wird der Abruftrigger durch die Erweiterung x-ms-trigger in OpenAPI definiert. Der Wert, der durch einen Abruftrigger definiert wird, ist ein Batch. Dies gibt an, dass die Methode ein Array anstelle eines einzelnen Objekts zurückgibt, wie dies in einer Webhook-Antwort der Fall ist.
/trigger/ListInvoices:
post:
x-ms-trigger: batch
Dieser Prozess findet statt, da mehrere Datensätze von einem einzelnen Aufruf an den Dienst zurückgegeben werden können. Bei Verwendung eines Abruftriggers in Power Automate oder Logic Apps können Sie mit der Triggereinstellung Split On die Verarbeitungsmethode konfigurieren.
Die Aufteilung des eingehenden Arrays in mehrere parallele Implementierungen erfolgt aus Leistungsgründen. Jede Instanz des Cloud-Flows in diesem Szenario erhält ein einzelnes Objekt. Wenn die Option Split On nicht festgelegt ist, erhält eine einzelne Instanz des Cloud-Flows ein Array von Werten.
Abruftrigger sind einfacher zu definieren als Webhook-Trigger. Sie sind jedoch weniger detailliert und funktionieren oft auch nicht. Die Entscheidung, den einen oder anderen Triggertyp zu erstellen und zu verwenden, hängt von den Merkmalen, der Struktur und der Funktionalität der Service-API ab.