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. Angenommen, Sie möchten einen Dienstendpunkt für Ihre Website überwachen, indem Sie diesen Endpunkt in einem bestimmten Zeitplan überprüfen. Wenn ein bestimmtes Ereignis an diesem Endpunkt auftritt, wie z. B. das Ausfallen Ihrer Website, löst dieses Ereignis Ihren Workflow aus und führt die Aktionen in diesem Workflow aus.

In diesem Handbuch wird gezeigt, wie Sie den HTTP-Trigger und die HTTP-Aktion verwenden, damit Ihr Workflow ausgehende Aufrufe an andere Dienste und Systeme senden kann, z. B.:

• Um einen Endpunkt in einem wiederkehrenden Zeitplan zu überprüfen oder abzufragen , fügen Sie den integrierten Trigger namens HTTP als ersten Schritt in Ihrem Workflow hinzu. Jedes Mal, wenn der Trigger den Endpunkt überprüft, ruft der Trigger auf oder sendet eine Anforderung an den Endpunkt. 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.

• Um einen Endpunkt von überall aus in Ihrem Workflow aufzurufen, fügen Sie die integrierte Aktion "HTTP" hinzu. Die Antwort des Endpunkts bestimmt, wie die verbleibenden Aktionen Ihres Workflows ausgeführt werden.

Voraussetzungen

• Ein Azure Konto und ein 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.

• Die Logik-App-Ressource mit dem Workflow, aus dem Sie den externen Endpunkt aufrufen möchten.

  Um Den Workflow mit dem HTTP-Trigger zu starten, müssen Sie über einen leeren Workflow verfügen. Um die HTTP-Aktion zu verwenden, kann Ihr Workflow mit einem Trigger beginnen, der am besten zu Ihrem Szenario passt. In den Beispielworkflows in diesem Artikel wird der HTTP-Trigger verwendet.

  Wenn Sie nicht über eine Logik-App-Ressource und einen Workflow verfügen, erstellen Sie sie jetzt, indem Sie die Schritte für die gewünschte Logik-App ausführen:

  • Erstellen eines Beispiels für einen Logik-App-Workflow (Verbrauch)
  • Erstellen eines Beispiels für einen Standardlogik-App-Workflow

Technische Referenz für das Verbindungselement

Technische Informationen zu Trigger- und Aktionsparametern finden Sie in den folgenden Abschnitten im Schemareferenzhandbuch:

• HTTP-Trigger-Parameter
• HTTP-Aktionsparameter

Hinzufügen eines HTTP-Triggers

Dieser integrierte Trigger führt einen HTTP-Aufruf an die angegebene URL für einen Endpunkt aus und gibt eine Antwort zurück.

Hinzufügen einer HTTP-Aktion

Diese integrierte Aktion sendet einen HTTPS- oder HTTP-Aufruf an die angegebene URL für einen Endpunkt und gibt mit einer Antwort zurück.

Ausgaben aus Triggern und Aktionen

Ein HTTP-Trigger oder eine Aktion gibt die folgenden Informationen aus:

URL-Sicherheit für ausgehende Anrufe

Informationen zu Verschlüsselung, Sicherheit und Autorisierung für ausgehende Anrufe von Ihrem Workflow, z. B. Transport Layer Security (TLS), selbstsignierte Zertifikate oder die offene Microsoft Entra ID-Authentifizierung, finden Sie unter Access für ausgehende Anrufe an andere Dienste und Systeme.

Authentifizierung für eine Umgebung mit nur einem Mandanten

Wenn Sie über eine Standardlogik-App-Ressource in Azure Logic Apps mit einem Mandanten verfügen und einen HTTP-Vorgang mit einem der folgenden Authentifizierungstypen verwenden möchten, müssen Sie die zusätzlichen Einrichtungsschritte für den entsprechenden Authentifizierungstyp ausführen. Andernfalls schlägt der Aufruf fehl.

• TLS-Zertifikat: Fügen Sie die App-Einstellung WEBSITE_LOAD_ROOT_CERTIFICATEShinzu, und legen Sie den Wert auf den Fingerabdruck für Ihr TLS-Zertifikat fest.

• Clientzertifikat oder Microsoft Entra ID Open Authorization (Microsoft Entra ID OAuth) mit dem Anmeldeinformationstyp Zertifikat: Fügen Sie die App-Einstellung WEBSITE_LOAD_USER_PROFILE hinzu, und legen Sie den Wert auf 1 fest.

TLS-Zertifikatauthentifizierung

1. Fügen Sie in den App-Einstellungen Ihrer Logik-App-Ressource die App-Einstellung hinzu WEBSITE_LOAD_ROOT_CERTIFICATES, oder aktualisieren Sie sie. Spezifische Schritte finden Sie unter Verwalten von App-Einstellungen – local.settings.json.

2. Geben Sie für den Einstellungswert den Fingerabdruck für Ihr TLS-Zertifikat als vertrauenswürdiges Stammzertifikat an.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

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

1. Öffnen Sie die local.settings.json Datei ihres Logik-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-certificate>",
         <...>
      }
   }
   

Weitere Informationen finden Sie unter Verwalten von App-Einstellungen – local.settings.json.

Clientzertifikat oder Microsoft Entra ID OAuth mit Authentifizierung über den Anmeldeinformationstyp Zertifikat

1. Fügen Sie in den App-Einstellungen Ihrer Logik-App-Ressource die App-Einstellung hinzu WEBSITE_LOAD_USER_PROFILE, oder aktualisieren Sie sie. Spezifische Schritte finden Sie unter Verwalten von App-Einstellungen – local.settings.json

2. Geben Sie 1für den Einstellungswert an.

   "WEBSITE_LOAD_USER_PROFILE": "1"

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

1. Öffnen Sie die local.settings.json Datei ihres Logik-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",
         <...>
      }
   }
   

Wenn Sie im Azure-Portal arbeiten, öffnen Sie Ihre Logik-App. Wählen Sie unter "Einstellungen" im Randleistenmenü " Umgebungsvariablen" aus. Fügen Sie unter "App-Einstellungen" die Einstellung hinzu, oder bearbeiten Sie sie.

Inhalt mit Multipart/Formulardaten-Typ

Um Inhalte zu verarbeiten, die den Typ multipart/form-data in HTTP-Anforderungen haben, können Sie ein JSON-Objekt im Anforderungstext der HTTP-Anfrage hinzufügen, das die Attribute $content-type und $multipart 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, der eine HTTP POST-Anforderung für eine Excel-Datei mithilfe der API dieser Website an eine Website sendet, die den multipart/form-data Typ unterstützt. Das folgende Beispiel zeigt, wie diese Aktion angezeigt werden kann:

Im folgenden Beispiel wird die JSON-Definition der HTTP-Aktion in der zugrunde liegenden Workflowdefinition veranschaulicht:

"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 mit dem Typ application/x-www-form-urlencoded

Um Formular-urlencodierte Daten im Textkörper für eine HTTP-Anforderung bereitzustellen, müssen Sie angeben, dass die Daten den application/x-www-form-urlencoded Inhaltstyp aufweisen. Fügen Sie im HTTP-Trigger oder der Aktion den content-type Header hinzu. Legen Sie den Kopfzeilenwert auf application/x-www-form-urlencoded.

Angenommen, Sie haben eine Logik-App, die eine HTTP POST-Anforderung an eine Website sendet, die den application/x-www-form-urlencoded Typ unterstützt. Hier erfahren Sie, wie diese Aktion aussehen kann:

Asynchrones Anforderungsantwortverhalten

Für zustandsbehaftete Workflows in Mehrinstanzen- und Einzelmandanten-Azure Logic Apps folgen alle HTTP-basierten Aktionen dem standardasynchronen Vorgangsmuster als Standardverhalten. Dieses Muster gibt an, dass der Empfänger sofort eine 202 AKZEPTIERT-Antwort zurückgibt, nachdem eine HTTP-Aktion aufgerufen oder eine Anforderung an einen Endpunkt, einen Dienst, ein System oder eine API gesendet hat. 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 Aktualisierungs-ID angibt, die der Aufrufer verwenden kann, um den Status der asynchronen Anforderung abzufragen oder zu überprüfen, bis der Empfänger die Verarbeitung beendet und eine 200 OK-Erfolgsantwort 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 Synchrones und asynchrones Messaging.

Bei zustandslosen Workflows in Azure Logic Apps mit einem Mandanten verwenden HTTP-basierte Aktionen nicht das asynchrone Vorgangsmuster. Stattdessen werden sie nur synchron ausgeführt, geben die Antwort 202 ACCEPTED unverändert zurück und fahren mit dem nächsten Schritt in der Workflowausführung fort. Wenn die Antwort einen location Header enthält, fragt ein zustandsloser Workflow nicht den angegebenen URI ab, um den Status zu überprüfen. Verwenden Sie stattdessen einen zustandsbehafteten Workflow, um dem standardmäßigen asynchronen Vorgangsmuster zu folgen.

• Die zugrunde liegende JSON-Definition der HTTP-Aktion folgt implizit dem asynchronen Vorgangsmuster.

• Die HTTP-Aktion, jedoch kein Trigger, weist eine asynchrone Mustereinstellung auf, die standardmäßig aktiviert ist. Diese Einstellung gibt an, dass der Aufrufer nicht auf den Abschluss der Verarbeitung wartet und zur nächsten Aktion wechseln kann, aber den Status weiterhin ü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 er mit der nächsten Aktion fortfährt.

  Um die Einstellung Asynchrones Muster zu finden:

  1. Wählen Sie im Workflow-Designer die HTTP-Aktion aus.
  2. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus.
  3. Suchen Sie unter "Netzwerk" die Einstellung "Asynchrones Muster ".

Deaktivieren asynchroner Vorgänge

Manchmal möchten Sie das asynchrone Verhalten der HTTP-Aktion in bestimmten Szenarien deaktivieren, z. B. bei Bedarf:

• Vermeiden von HTTP-Timeouts bei Aufgaben mit langer Ausführungszeit
• Deaktivieren der Überprüfung von Location-Headern

Deaktivieren der asynchronen Mustereinstellung

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

2. 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 zugrunde liegenden JSON-Definition der HTTP-Aktion die DisableAsyncPattern Vorgangsoption zur Definition der Aktion hinzu, sodass die Aktion stattdessen dem synchronen Vorgangsmuster folgt. Weitere Informationen finden Sie auch unter Ausführen von Aktionen in einem synchronen Vorgangsmuster.

HTTP-Timeouts bei lang laufenden Aufgaben vermeiden

HTTP-Anforderungen haben ein Timeoutlimit. Wenn Sie eine lang andauernde HTTP-Aktion haben, die aufgrund dieses Grenzwerts zu einem Timeout führt, haben Sie folgende Optionen:

• Deaktivieren Sie das asynchrone Vorgangsmuster der HTTP-Aktion , damit die Aktion den Status der Anforderung nicht kontinuierlich abruft oder überprüft. Stattdessen wartet die Aktion, bis der Empfänger mit dem Status und den Ergebnissen antwortet, nachdem die Anforderung die Verarbeitung abgeschlossen hat.

• Ersetzen Sie die HTTP-Aktion durch die HTTP-Webhook-Aktion, die wartet, bis der Empfänger mit dem Status und den Ergebnissen antwortet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde.

Einrichten des Intervalls zwischen Wiederholungsversuchen mit dem Retry-After Header

Um die Anzahl der Sekunden zwischen Wiederholungsversuchen anzugeben, können Sie der HTTP-Aktionsantwort den Retry-After Header hinzufügen. Wenn beispielsweise der Zielendpunkt den 429 - Too many requests Statuscode zurückgibt, können Sie ein längeres Intervall zwischen Wiederholungen angeben. Die Retry-After Kopfzeile funktioniert auch mit dem 202 - Accepted Statuscode.

Hier ist dasselbe Beispiel, das die HTTP-Aktionsantwort zeigt, die Folgendes enthält Retry-After:

{
    "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 angibt, können Sie die Einstellung zur Paginierung im Bereich der HTTP-Aktion aktivieren. Diese Einstellung bewirkt, dass die HTTP-Aktion diesen Links automatisch folgt und die nächste Seite erhält. Wenn die Antwort jedoch die nächste Seite mit einem anderen Tag angibt, müssen Sie dem Workflow möglicherweise eine Schleife hinzufügen. Lassen Sie die Schleife diesem Tag folgen, und rufen Sie jede Seite manuell ab, bis das Tag NULL ist.

Deaktivieren der Prüfung von Standort-Headern

Einige Endpunkte, Dienste, Systeme oder APIs geben eine 202 ACCEPTED Antwort zurück, die nicht über einen location Header verfügt. Um zu vermeiden, dass eine HTTP-Aktion den Anforderungsstatus kontinuierlich überprüft, wenn der location Header nicht vorhanden ist, können Sie folgende Optionen haben:

• Deaktivieren Sie das asynchrone Vorgangsmuster der HTTP-Aktion , damit die Aktion den Status der Anforderung nicht kontinuierlich abruft oder überprüft. Stattdessen wartet die Aktion, bis der Empfänger mit dem Status und den Ergebnissen antwortet, nachdem die Anforderung die Verarbeitung abgeschlossen hat.

• Ersetzen Sie die HTTP-Aktion durch die HTTP-Webhook-Aktion, die wartet, bis der Empfänger mit dem Status und den Ergebnissen antwortet, nachdem die Verarbeitung der Anforderung abgeschlossen wurde.

Bekannte Probleme

Ausgelassene HTTP-Header

Wenn ein HTTP-Trigger oder eine Aktion diese Header enthält, entfernt Azure Logic Apps diese Header aus der generierten Anforderungsmeldung, ohne dass warnungs- oder fehlermeldungen angezeigt werden:

• Accept-* Kopfzeilen mit Ausnahme von Accept-version
• Allow
• Content-* Header mit Ausnahme von Content-Disposition, Content-Encoding und Content-Type, die beachtet werden, wenn Sie die POST- und PUT-Operationen verwenden. Azure Logic Apps legt diese Header jedoch ab, 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

Obwohl Sie von Azure Logic Apps nicht daran gehindert werden, Logik-Apps zu speichern, die einen HTTP-Trigger oder eine Aktion mit diesen Headern verwenden, ignoriert Azure Logic Apps diese Header.

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.

Verwandte Inhalte

• Verwaltete Connectors für Azure Logic Apps-Connectors
• Integrierte Konnektoren für Azure Logic Apps