Aufrufen externer HTTP- oder HTTPS-Endpunkte aus Workflows in Azure Logic Apps
Gilt für: Azure Logic Apps (Verbrauch + Standard)
Einige Szenarien erfordern möglicherweise, dass Sie einen Logik-App-Workflow erstellen, der ausgehende Anforderungen an Endpunkte auf anderen Diensten oder Systemen über HTTP oder HTTPS sendet. Sie möchten beispielsweise einen Dienstendpunkt für Ihre Website überwachen, indem Sie ihn nach einem bestimmten Zeitplan überprüfen. Wenn das angegebene Ereignis, beispielsweise ein Ausfall Ihrer Website, an diesem Endpunkt auftritt, löst dieses Ereignis den Workflow Ihrer Logik-App aus und führt die darin enthaltenen Aktionen aus.
Hinweis
Informationen zum Erstellen eines Workflows, der stattdessen eingehende HTTPS-Aufrufe empfängt und reagiert, finden Sie unter Erstellen von Workflows, die Sie mithilfe von HTTPS-Endpunkten in Azure Logic Apps und der integrierten Anforderungstrigger - und Antwortaktionaufrufen, auslösen oder verschachteln können.
Dieser Artikel zeigt, wie Sie den HTTP-Trigger und die HTTP-Aktion verwenden können, damit Ihr Workflow ausgehende Aufrufe an andere Dienste und Systeme senden kann. zum Beispiel:
Um einen Endpunkt nach einem wiederkehrenden Zeitplan zu überprüfen oder abzurufen, können Sie den HTTP-Trigger Ihrem Workflow als ersten Schritt hinzufügen. Jedes Mal, wenn der Trigger den Endpunkt überprüft, führt er einen Aufruf bzw. das Senden einer Anforderung an den Endpunkt durch. Die Antwort des Endpunkts bestimmt, ob Ihr Workflow ausgeführt wird. Der Trigger übergibt alle Inhalte aus der Antwort des Endpunkts an die Aktionen in Ihrem Workflow.
Fügen Sie die entsprechende HTTP-Aktion hinzu, um einen Endpunkt an einem anderen Punkt Ihres Workflows aufzurufen. Die Antwort des Endpunkts bestimmt, wie die restlichen Aktionen des Workflows ausgeführt werden.
Voraussetzungen
Ein Azure-Konto und ein Azure-Abonnement. Wenn Sie nicht über ein Azure-Abonnement verfügen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Die URL für den Zielendpunkt, den Sie aufrufen möchten
Der Logik-App-Workflow, von dem aus Sie den Zielendpunkt aufrufen möchten. Um mit dem HTTP-Trigger zu beginnen, benötigen Sie einen leeren Workflow. Um die HTTP-Aktion zu verwenden, starten Sie Ihren Workflow mit einem beliebigen Trigger. Dieses Beispiel verwendet den HTTP-Trigger als ersten Schritt.
Technische Referenz für den Connector
Weitere Informationen zu Trigger- und Aktionsparametern finden Sie in den folgenden Abschnitten:
Hinzufügen eines HTTP-Triggers
Dieser integrierte Trigger führt einen HTTP-Aufruf der angegebenen URL für einen Endpunkt aus und gibt eine Antwort zurück.
Öffnen Sie im Azure-Portal Ihre Standard-Logik-App und einen leeren Workflow im Designer.
-
In diesem Beispiel wird der Auslöser in HTTP-Trigger umbenannt – Endpunkt-URL aufrufen, sodass der Trigger einen aussagekräftigeren Namen hat. Außerdem muss im Beispiel später eine HTTP-Aktion hinzugefügt werden, und Vorgangsnamen in Ihrem Workflow müssen eindeutig sein.
Geben Sie die Werte für die HTTP-Triggerparameter ein, die Sie in den Aufruf des Zielendpunkts aufnehmen möchten. Geben Sie mithilfe einer Wiederholung an, wie oft der Trigger den Zielendpunkt überprüfen soll.
Wenn Sie einen anderen Authentifizierungstyp als Keinerauswählen, unterscheiden sich die Authentifizierungseinstellungen je nach Ihrer Auswahl. Weitere Informationen zu verfügbaren Authentifizierungstypen für HTTP finden Sie unter den folgenden Themen:
Öffnen Sie zum Hinzufügen weiterer verfügbarer Parameter die Liste Erweiterte Parameter hinzufügen, und wählen Sie die gewünschten Parameter aus.
Fügen Sie alle anderen Aktionen hinzu, die ausgeführt werden sollen, wenn der Trigger ausgelöst wird.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
Hinzufügen einer HTTP-Aktion
Diese integrierte Aktion führt einen HTTP-Aufruf der angegebenen URL für einen Endpunkt aus und gibt eine Antwort zurück.
Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App und deren Workflow im Workflow-Designer.
In diesem Beispiel wird der im vorherigen Abschnitt hinzugefügte HTTP-Trigger als erster Schritt verwendet.
-
Dieses Beispiel benennt die Aktion in HTTP Aktion - Endpunkt URL Abrufen um, damit der Schritt über einen aussagekräftigeren Namen verfügt. Außerdem müssen Vorgangsnamen in Ihrem Workflow eindeutig sein.
Geben Sie die Werte für die HTTP-Aktionsparameter ein, die Sie in den Aufruf des Zielendpunkts aufnehmen möchten.
Wenn Sie einen anderen Authentifizierungstyp als Keinerauswählen, unterscheiden sich die Authentifizierungseinstellungen je nach Ihrer Auswahl. Weitere Informationen zu verfügbaren Authentifizierungstypen für HTTP finden Sie unter den folgenden Themen:
Öffnen Sie zum Hinzufügen weiterer verfügbarer Parameter die Liste Erweiterte Parameter hinzufügen, und wählen Sie die gewünschten Parameter aus.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
Ausgaben aus Triggern und Aktionen
Hier finden Sie weitere Informationen zu den Ausgaben aus einem HTTP-Trigger oder einer -Aktion, die folgende Informationen zurückgeben:
| Eigenschaft | Typ | BESCHREIBUNG |
|---|---|---|
headers |
JSON-Objekt | Die Header aus der Anforderung |
body |
JSON-Objekt | Das Objekt mit dem Inhalt des Texts aus der Anforderung |
status code |
Ganzzahl | Der Statuscode aus der Anforderung |
| Statuscode | BESCHREIBUNG |
|---|---|
| 200 | OK |
| 202 | Akzeptiert |
| 400 | Bad request (Ungültige Anforderung) |
| 401 | Nicht autorisiert |
| 403 | Verboten |
| 404 | Nicht gefunden |
| 500 | Interner Serverfehler. Unbekannter Fehler. |
URL-Sicherheit für ausgehende Anrufe
Informationen zu Verschlüsselung, Sicherheit und Autorisierung für ausgehende Aufrufe Ihres Workflows, etwa Transport Layer Security (TLS) (früher bekannt als Secure Sockets Layer (SSL)), selbstsignierte Zertifikate oder Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), finden Sie unter Sicherer Zugriff und Daten: Zugriff für ausgehende Aufrufe anderer Dienste und Systeme.
Authentifizierung für eine Umgebung mit nur einem Mandanten
Wenn Sie über eine Standard Logik-App-Ressource in Azure Logic Apps mit nur einem Mandanten verfügen und einen HTTP-Vorgang mit einem der folgenden Authentifizierungstypen verwenden möchten, stellen Sie sicher, dass Sie die zusätzlichen Einrichtungsschritte für den entsprechenden Authentifizierungstyp ausführen. Andernfalls tritt bei dem Aufruf ein Fehler auf.
TLS/SSL-Zertifikat: Fügen Sie die App-Einstellung
WEBSITE_LOAD_ROOT_CERTIFICATEShinzu, und legen Sie den Wert auf den Fingerabdruck für Ihr TLS/SSL-Zertifikat fest.Clientzertifikat oder Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) mit dem Anmeldeinformationstyp"Zertifikat": Fügen Sie die App-Einstellung hinzu,
WEBSITE_LOAD_USER_PROFILEund legen Sie den Wert auf1.
TLS/SSL-Zertifikat-Authentifizierung
In den App-Einstellungen Ihrer Logic App-Ressource fügen Sie die App-Einstellung
WEBSITE_LOAD_ROOT_CERTIFICATEShinzu, oder aktualisieren Sie sie.Geben Sie als Einstellungswert den Thumbprint für Ihr TLS/SSL-Zertifikat als vertrauenswürdiges Stammzertifikat an.
"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"
Wenn Sie z. B. in Visual Studio Code arbeiten, führen Sie die folgenden Schritte aus:
Öffnen Sie die Datei local.settings.json des Logic App-Projekts.
Fügen Sie im JSON-Objekt
Valuesdie EinstellungWEBSITE_LOAD_ROOT_CERTIFICATEShinzu, oder aktualisieren Sie diese:{ "IsEncrypted": false, "Values": { <...> "AzureWebJobsStorage": "UseDevelopmentStorage=true", "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>", <...> } }Hinweis
Führen Sie die folgenden Schritte aus, um den Fingerabdruck zu finden:
Wählen Sie im Ressourcenmenü Ihrer Logik-App unter Einstellungen die Option TLS/SSL-Einstellungen>Private Schlüsselzertifikate (PFX) oder Öffentliche Schlüsselzertifikate (CER) aus.
Suchen Sie das Zertifikat, das Sie verwenden möchten, und kopieren Sie den Fingerabdruck.
Weitere Informationen finden Sie unter Suchen des Fingerabdrucks – Azure App Service.
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Bearbeiten von Einstellungen für Hosts und Apps für Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten
- Private Clientzertifikate – Azure App Service
Clientzertifikat oder Microsoft Entra ID OAuth mit Authentifizierung vom Anmeldeinformationstyp Zertifikat
In den App-Einstellungen Ihrer Logic App-Ressource fügen Sie die App-Einstellung
WEBSITE_LOAD_USER_PROFILEhinzu, oder aktualisieren Sie sie.Geben Sie als Einstellungswert
1an."WEBSITE_LOAD_USER_PROFILE": "1"
Wenn Sie z. B. in Visual Studio Code arbeiten, führen Sie die folgenden Schritte aus:
Öffnen Sie die Datei local.settings.json des Logic App-Projekts.
Fügen Sie im JSON-Objekt
Valuesdie EinstellungWEBSITE_LOAD_USER_PROFILEhinzu, oder aktualisieren Sie diese:{ "IsEncrypted": false, "Values": { <...> "AzureWebJobsStorage": "UseDevelopmentStorage=true", "WEBSITE_LOAD_USER_PROFILE": "1", <...> } }
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Bearbeiten von Einstellungen für Hosts und Apps für Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten
- Private Clientzertifikate – Azure App Service
Inhalt des Typs „multipart/form-data“
Für die Verarbeitung von Inhalt mit dem Typ multipart/form-data in HTTP-Anforderung können Sie ein JSON-Objekt hinzufügen, das die Attribute $content-type und $multipart im HTTP-Anforderungstext enthält, indem Sie dieses Format verwenden.
"body": {
"$content-type": "multipart/form-data",
"$multipart": [
{
"body": "<output-from-trigger-or-previous-action>",
"headers": {
"Content-Disposition": "form-data; name=file; filename=<file-name>"
}
}
]
}
Angenommen, Sie verfügen über einen Workflow, die eine HTTP POST-Anforderung für eine Excel-Datei an eine Website sendet, indem sie die API der Website nutzt, die den Typ multipart/form-data unterstützt. Das folgende Beispiel zeigt, wie diese Aktion angezeigt werden kann:
Standardworkflow
Verbrauchsworkflow
Das folgende Beispiel entspricht der JSON-Definition der HTTP-Aktion in der zugrundeliegenden Workflowdefinition:
"HTTP_action": {
"inputs": {
"body": {
"$content-type": "multipart/form-data",
"$multipart": [
{
"body": "@trigger()",
"headers": {
"Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
}
}
]
},
"method": "POST",
"uri": "https://finance.contoso.com"
},
"runAfter": {},
"type": "Http"
}
Inhalt des Typs „application/x-www-form-urlencoded“
Um „form-urlencoded“-Daten im Text für eine HTTP-Anforderung bereitzustellen, müssen Sie angeben, dass die Daten den Inhaltstyp application/x-www-form-urlencoded aufweisen. Fügen Sie im HTTP-Trigger oder in der Aktion den content-type-Header hinzu. Legen Sie den Headerwert auf application/x-www-form-urlencoded fest.
Angenommen, Sie verfügen über eine Logik-App, die eine HTTP POST-Anforderung an eine Website sendet, die den Typ application/x-www-form-urlencoded unterstützt. Diese Aktion könnte folgenderweise aussehen:
Standardworkflow
Verbrauchsworkflow
Asynchrones Anforderungs-Antwort-Verhalten
Für zustandsabhängige Workflows in Azure Logic Apps mit mehreren Mandanten und Einzelmandanten folgen alle HTTP-basierten Aktionen dem Standardmuster asynchroner Operationen als Standardverhalten. Laut diesem Muster gibt der Empfänger sofort eine 202 ACCEPTED-Antwort zurück, wenn eine HTTP-Aktion einen Endpunkt, einen Dienst, das System oder die API aufruft oder eine Anforderung an ebendiese sendet. Dieser Code bestätigt, dass der Empfänger die Anforderung akzeptiert, aber die Verarbeitung noch nicht abgeschlossen hat. Die Antwort kann einen location Header enthalten, der den URI und eine Refresh-ID angibt, mit der Aufrufer den Status der asynchronen Anforderung abfragen oder überprüfen kann, bis der Empfänger die Verarbeitung beendet und eine "200 OK" Erfolgsmeldung oder eine andere Nicht-202-Antwort zurückgibt. Der Aufrufer muss jedoch nicht darauf warten, dass die Verarbeitung der Anforderung abgeschlossen wird, und kann mit der Ausführung der nächsten Aktion fortfahren. Weitere Informationen finden Sie unter Gegenüberstellung von synchronem und asynchronem Messaging.
Für zustandslose Workflows in Azure Logic Apps mit einem Mandanten verwenden HTTP-basierte Aktionen nicht das asynchrone Operationsmuster. Stattdessen werden sie nur synchron ausgeführt, geben die "202 ACCEPTED" Antwort unverändert zurück und fahren mit dem nächsten Schritt in der Workflow-Ausführung fort. Wenn die Antwort einen locationHeader enthält, wird ein zustandsloser Arbeitsablauf die angegebene URI nicht abfragen, um den Status zu überprüfen. Um dem Standardmuster für asynchrone Operationen zu folgen, verwenden Sie stattdessen einen zustandsbehafteten Workflow.
In der JSON-Definition (JavaScript Object Notation), die der HTTP-Aktion zugrunde liegt, folgt implizit dem Muster für asynchrone Vorgänge.
Die HTTP-Aktion, nicht der Trigger, verfügt über eine Einstellung für das asynchrone Muster, die automatisch aktiviert ist. Diese Einstellung gibt an, dass der Aufrufer nicht auf den Abschluss der Verarbeitung wartet, sondern mit der nächsten Aktion fortfahren kann, dass er aber weiterhin den Status überprüft, bis die Verarbeitung beendet wird. Wenn diese Einstellung deaktiviert ist, gibt sie an, dass der Aufrufer auf den Abschluss der Verarbeitung wartet, bevor mit der nächsten Aktion fortfährt.
Um die Einstellung "Asynchrones Muster " zu finden, führen Sie die folgenden Schritte aus, je nachdem, ob Sie über einen Standard- oder Verbrauchsworkflow verfügen:
Standardworkflow*
Wählen Sie im Workflow-Designer die HTTP-Aktion aus. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus.
Suchen Sie unter "Netzwerk" die Einstellung Asynchrones Muster.
Verbrauchsworkflow
Klicken Sie im Workflow-Designer in der Titelleiste der HTTP-Aktion auf die Schaltfläche mit den Auslassungspunkten (...). Daraufhin werden die Einstellungen der Aktion geöffnet.
Suchen Sie die Einstellung Asynchrones Muster.
Deaktivieren asynchroner Vorgänge
In bestimmten Szenarios sollten Sie das asynchrone Verhalten von HTTP-Aktionen deaktivieren, z. B.:
- Vermeiden von HTTP-Timeouts bei Aufgaben mit langer Ausführungszeit
- Deaktivieren der Überprüfung von Location-Headern
Deaktivieren der Einstellung Asynchrones Muster
Wählen Sie im Workflow-Designer die HTTP-Aktion aus, und wählen Sie im daraufhin geöffneten Informationsbereich Einstellungenaus.
Suchen Sie unter "Netzwerk" die Einstellung Asynchrones Muster. Aktivieren Sie die Einstellung auf "Aus ", wenn sie aktiviert ist.
Deaktivieren des asynchronen Musters in der JSON-Definition einer Aktion
Fügen Sie in der JSON-Definitionsdatei, die der HTTP-Aktion zugrunde liegt, die Option für den Vorgang "DisableAsyncPattern" zur Aktionsdefinition hinzu, damit die Aktion stattdessen das synchrone Vorgangsmuster befolgt. Weitere Informationen finden Sie unter Ausführen von Aktionen in einem synchronen Vorgangsmuster.
Vermeiden von HTTP-Timeouts bei Aufgaben mit langer Ausführungszeit
HTTP-Anforderungen unterliegen einem Timeoutlimit. Wenn eine Ihrer HTTP-Aktionen mit langer Ausführungszeit aufgrund dieses Timeoutlimits beendet wird, haben Sie die folgenden Möglichkeiten:
Deaktivieren des Musters für asynchrone Vorgänge, das die HTTP-Aktion befolgt, damit die Aktion nicht fortlaufend den Anforderungsstatus abfragt oder überprüft. Die Aktion wartet dann stattdessen darauf, dass der Empfänger den Status und die Ergebnisse in der Antwort sendet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde.
Ersetzen der HTTP-Aktion durch eine HTTP-Webhook-Aktion, die darauf wartet, dass der Empfänger den Status und die Ergebnisse in der Antwort sendet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde
Intervall zwischen Wiederholungsversuchen mit dem Retry-After-Header einrichten
Um die Anzahl der Sekunden zwischen den Wiederholungsversuchen festzulegen, können Sie der HTTP-Aktionsantwort die Kopfzeile Retry-After hinzufügen. Wenn der Zielendpunkt beispielsweise den Statuscode 429 - Too many requests zurückgibt, können Sie ein längeres Intervall zwischen den Wiederholungsversuchen festlegen. Der Retry-After-Header funktioniert auch mit dem 202 - Accepted-Statuscode.
Das folgende Beispiel zeigt die Antwort der HTTP-Aktion, die Retry-After enthält:
{
"statusCode": 429,
"headers": {
"Retry-After": "300"
}
}
Unterstützung der Paginierung
Manchmal antwortet der Zieldienst, indem er die Ergebnisse seitenweise zurückgibt. Wenn die Antwort die nächste Seite mit der Eigenschaft nextLink oder @odata.nextLink festlegt, können Sie die Einstellung Paginierung für die HTTP-Aktion aktivieren. Diese Einstellung bewirkt, dass die HTTP-Aktion automatisch diesen Links folgt und die nächste Seite abruft. Wenn die Antwort jedoch die nächste Seite mit einem anderen Tag angibt, müssen Sie möglicherweise eine Schleife in Ihrem Workflow hinzufügen. Lassen Sie die Schleife diesem Tag folgen, und rufen Sie jede Seite manuell ab, bis das Tag NULL ist.
Deaktivieren der Überprüfung von Location-Headern
Einige Endpunkte, Dienste, Systeme oder APIs geben eine Antwort mit dem Code 202 ACCEPTED zurück, die keinen location-Header enthält. Damit eine HTTP-Aktion nicht fortlaufend den Anforderungsstatus überprüft, obwohl kein location-Header vorhanden ist, können Sie wie folgt vorgehen:
Deaktivieren des Musters für asynchrone Vorgänge, das die HTTP-Aktion befolgt, damit die Aktion nicht fortlaufend den Anforderungsstatus abfragt oder überprüft. Die Aktion wartet dann stattdessen darauf, dass der Empfänger den Status und die Ergebnisse in der Antwort sendet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde.
Ersetzen der HTTP-Aktion durch eine HTTP-Webhook-Aktion, die darauf wartet, dass der Empfänger den Status und die Ergebnisse in der Antwort sendet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde
Bekannte Probleme
Ausgelassene HTTP-Header
Wenn ein HTTP-Trigger oder eine HTTP-Aktion diese Header enthält, entfernt Azure Logic Apps sie aus der generierten Anforderungsnachricht, ohne eine Warnung oder einen Fehler anzuzeigen:
Accept-*-Header, außer fürAccept-versionAllowContent-*-Header außer fürContent-Disposition,Content-EncodingundContent-Type, die berücksichtigt werden, wenn Sie die POST- und PUT-Vorgänge verwenden. Azure Logic Apps löscht diese Header jedoch, wenn Sie den GET-Vorgang verwenden.Cookie-Header, aber Azure Logic Apps berücksichtigt jeden Wert den Sie mithilfe der Cookie-Eigenschaft angeben.ExpiresHostLast-ModifiedOriginSet-CookieTransfer-Encoding
Azure Logic Apps verhindert nicht, dass Sie Logik-Apps speichern, in denen ein HTTP-Trigger oder eine HTTP-Aktion mit diesen Headern verwendet wird, sondern diese Header werden von Azure Logic Apps ignoriert.
Der Antwortinhalt stimmt nicht mit dem erwarteten Inhaltstyp überein
Die HTTP-Aktion löst einen BadRequest-Fehler aus, wenn die HTTP-Aktion die Back-End-API aufruft, wobei der Content-Type Header auf "application/json" festgelegt ist, die Antwort aus dem Back-End jedoch keinen Inhalt im JSON-Format enthält, was eine interne JSON-Formatüberprüfung fehlschlägt.