Aufrufen von Dienstendpunkten per HTTP oder HTTPS aus Azure Logic Apps

Mit Azure Logic Apps und dem integrierten HTTP-Trigger oder einer HTTP-Aktion können Sie automatisierte Tasks und Workflows erstellen, die ausgehende Anforderungen an Endpunkte für andere Dienste über HTTP oder HTTPS senden können. Um stattdessen eingehende HTTPS-Aufrufe zu empfangen und darauf zu reagieren, verwenden Sie den integrierten Anforderungstrigger und die Antwortaktion.

Sie können 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 das Ereignis den Workflow Ihrer Logik-App aus und führt die darin enthaltenen Aktionen aus.

  • 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 der Workflow der Logik-App ausgeführt wird. Der Trigger übergibt alle Inhalte aus der Antwort des Endpunkts an die Aktionen in Ihrer Logik-App.

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

Dieser Artikel zeigt, wie Sie den HTTP-Trigger und die HTTP-Aktion verwenden können, damit Ihre Logik-App ausgehende Aufrufe an andere Dienste und Systeme senden kann.

Informationen zu Verschlüsselung, Sicherheit und Autorisierung für ausgehende Aufrufe Ihrer Logik-App, etwa Transport Layer Security (TLS) (früher bekannt als Secure Sockets Layer (SSL)), selbstsignierte Zertifikate oder Azure Active Directory Open Authentication (Azure AD OAuth), finden Sie unter Sicherer Zugriff und Daten: Zugriff für ausgehende Aufrufe anderer Dienste und Systeme.

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

  • Grundlegende Kenntnisse über das Erstellen von Logik-Apps. Falls Sie noch nicht mit Logik-Apps vertraut sind, finden Sie weitere Informationen unter Was ist Azure Logic Apps?.

  • Die Logik-App, von der aus Sie den Zielendpunkt aufrufen möchten. Um mit dem HTTP-Trigger zu beginnen, erstellen Sie eine leere Logik-App. Um die HTTP-Aktion zu verwenden, starten Sie Ihre Logik-App mit einem beliebigen Trigger. Dieses Beispiel verwendet den HTTP-Trigger als ersten Schritt.

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.

  1. Melden Sie sich beim Azure-Portal an. Öffnen Sie Ihre leere Logik-App im Logik-App-Designer.

  2. Wählen Sie im Suchfeld des Designers die Option Integriert aus. Geben Sie im Suchfeld den Begriff http als Filter ein. Wählen Sie in der Liste Trigger den HTTP-Trigger aus.

    Select HTTP trigger

    Dieses Beispiel benennt den Trigger in „HTTP trigger“ um, damit der Schritt über einen aussagekräftigeren Namen verfügt. Darüber hinaus fügt das Beispiel später eine HTTP-Aktion hinzu, und beide Namen müssen eindeutig sein.

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

    Enter HTTP trigger parameters

    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:

  4. Öffnen Sie zum Hinzufügen weiterer verfügbarer Parameter die Liste Neuen Parameter hinzufügen, und wählen Sie die gewünschten Parameter aus.

  5. Fahren Sie mit dem Erstellen des Workflows Ihrer Logik-App fort, und fügen Sie weitere Aktionen hinzu, die bei Auslösung des Triggers ausgeführt werden.

  6. Speichern Sie die Logik-App unbedingt, wenn Sie fertig sind. 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.

  1. Melden Sie sich beim Azure-Portal an. Öffnen Sie Ihre Logik-App im Logik-App-Designer.

    Dieses Beispiel verwendet den HTTP-Trigger als ersten Schritt.

  2. Wählen Sie im Schritt zum Hinzufügen der HTTP-Aktion die Option Neuer Schritt aus.

    Wenn Sie zwischen Schritten eine Aktion einfügen möchten, bewegen Sie den Mauszeiger über den Pfeil zwischen den Schritten. Wählen Sie das angezeigte Pluszeichen (+) und dann Aktion hinzufügen aus.

  3. Wählen Sie unter Aktion auswählen die Option Integriert aus. Geben Sie im Suchfeld den Begriff http als Filter ein. Wählen Sie in der Liste Aktionen die HTTP-Aktion aus.

    Select HTTP action

    Dieses Beispiel benennt die Aktion in „HTTP action“ um, damit der Schritt über einen aussagekräftigeren Namen verfügt.

  4. Geben Sie die Werte für die HTTP-Aktionsparameter ein, die Sie in den Aufruf des Zielendpunkts aufnehmen möchten.

    Enter HTTP action parameters

    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:

  5. Öffnen Sie zum Hinzufügen weiterer verfügbarer Parameter die Liste Neuen Parameter hinzufügen, und wählen Sie die gewünschten Parameter aus.

  6. Speichern Sie die Logik-App unbedingt, wenn Sie fertig sind. 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 diese Informationen zurückgeben:

Eigenschaft type BESCHREIBUNG
headers JSON-Objekt Die Header aus der Anforderung
body JSON-Objekt Das Objekt mit dem Inhalt des Texts aus der Anforderung
status code Integer Der Statuscode aus der Anforderung
Statuscode BESCHREIBUNG
200 OK
202 Zulässig
400 Ungültige Anforderung
401 Nicht autorisiert
403 Verboten
404 Nicht gefunden
500 Interner Serverfehler. Unbekannter Fehler.

Authentifizierung für eine Umgebung mit nur einem Mandanten

Wenn Sie über eine Logik-App-Ressource (Standard) 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 schlägt der Aufruf fehl.

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>",
          <...>
       }
    }
    

Weitere Informationen finden Sie in der folgenden Dokumentation:

Clientzertifikat oder Azure AD 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:

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 eine Logik-App, 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. Diese Aktion könnte folgenderweise aussehen:

Multipart form data

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:

Screenshot that shows an HTTP request with the 'content-type' header set to 'application/x-www-form-urlencoded'

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 location-Header enthält, fragt ein zustandsloser Workflow den angegebenen URI nicht ab, um den Status zu überprüfen. Um dem Standardmuster für asynchrone Operationen zu folgen, verwenden Sie stattdessen einen zustandsbehafteten Workflow.

  • Im Logik-App-Designer verfügt die HTTP-Aktion, nicht der Trigger, ü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 er mit der nächsten Aktion fortfährt.

    Führen Sie die folgenden Schritte aus, um diese Einstellung zu suchen:

    1. Wählen Sie auf der Titelleiste der HTTP-Aktion die Schaltfläche mit den Auslassungspunkten ( ... ) aus, woraufhin die Einstellungen der Aktion geöffnet werden.

    2. Suchen Sie die Einstellung Asynchrones Muster.

  • In der JSON-Definition (JavaScript Object Notation), die der HTTP-Aktion zugrunde liegt, folgt implizit dem Muster für asynchrone Vorgänge.

Deaktivieren asynchroner Vorgänge

In bestimmten Szenarios sollten Sie das asynchrone Verhalten von HTTP-Aktionen deaktivieren, z. B.:

Deaktivieren der Einstellung Asynchrones Muster

  1. Klicken Sie im Logik-App-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 Sie die Einstellung, indem Sie sie auf Aus festlegen (falls sie aktiviert ist), und wählen Sie Fertig aus.

    Disable the

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 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. Logic Apps löscht diese Header jedoch, wenn Sie den GET-Vorgang verwenden.
  • Cookie-Header, aber Logic Apps berücksichtigt jeden Wert den Sie mithilfe der Cookie-Eigenschaft angeben.
  • Expires
  • Host
  • Last-Modified
  • Origin
  • Set-Cookie
  • Transfer-Encoding

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 Logic Apps ignoriert.

Connector-Referenz

Weitere Informationen zu Trigger- und Aktionsparametern finden Sie in den folgenden Abschnitten:

Nächste Schritte