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.

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:

• HTTP-Triggerparameter
• HTTP-Aktionsparameter

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.

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.

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:

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_CERTIFICATES hinzu, 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 auf 1.

TLS/SSL-Zertifikat-Authentifizierung

1. In den App-Einstellungen Ihrer Logic App-Ressource fügen Sie die App-Einstellung WEBSITE_LOAD_ROOT_CERTIFICATES hinzu, oder aktualisieren Sie sie.

2. 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:

1. Öffnen Sie die Datei local.settings.json des Logic App-Projekts.

2. Fügen Sie im JSON-Objekt Values die Einstellung WEBSITE_LOAD_ROOT_CERTIFICATES hinzu, 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:

   1. 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.

   2. 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

1. In den App-Einstellungen Ihrer Logic App-Ressource fügen Sie die App-Einstellung WEBSITE_LOAD_USER_PROFILE hinzu, oder aktualisieren Sie sie.

2. Geben Sie als Einstellungswert 1 an.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Wenn Sie z. B. in Visual Studio Code arbeiten, führen Sie die folgenden Schritte aus:

1. Öffnen Sie die Datei local.settings.json des Logic App-Projekts.

2. Fügen Sie im JSON-Objekt Values die Einstellung WEBSITE_LOAD_USER_PROFILE hinzu, 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*

  1. Wählen Sie im Workflow-Designer die HTTP-Aktion aus. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus.

  2. Suchen Sie unter "Netzwerk" die Einstellung Asynchrones Muster.

  Verbrauchsworkflow

  1. 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.

  2. 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

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ür Accept-version
• Allow
• Content-*-Header außer für Content-Disposition, Content-Encoding und Content-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.
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-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.

Nächste Schritte

• Integrierte Trigger und Aktionen für Azure Logic Apps
• Integrierte Connectors für Azure Logic Apps