Freigeben über

Empfangen und Beantworten eingehender HTTPS-Aufrufe an Workflows in Azure Logic Apps

  • Artikel

Gilt für: Azure Logic Apps (Verbrauch + Standard)

In dieser Anleitung wird gezeigt, wie Sie einen Logik-App-Workflow erstellen, der eine eingehende HTTPS-Anforderung oder einen Anruf von einem anderen Dienst mithilfe des integrierten Triggers "Anforderung" empfangen und verarbeiten kann. Wenn Ihr Workflow diesen Trigger verwendet, können Sie dann mithilfe der integrierten Antwortaktion auf die HTTPS-Anforderung reagieren.

Hinweis

Die Gegenmaßnahme funktioniert nur, wenn Sie den Trigger Anforderung verwenden.

Zum Beispiel beschreibt die folgende Liste einige Beispielaufgaben, die Ihr Arbeitsablauf ausführen kann, wenn Sie den Anforderung und die Gegenmaßnahme verwenden:

  • Empfangen von und Antworten auf eine HTTPS-Anforderung von Daten in einer lokalen Datenbank.

  • Eine HTTPS-Anforderung, die von einem anderen Logik-App-Workflow gesendet wurde empfangen und beantworten

  • Eine Workflow-Ausführung auslösen, wenn ein externes Webhook-Ereignis eintritt

Um Ihren Workflow stattdessen durch Senden einer ausgehenden oder ausgehenden Anforderung auszuführen, verwenden Sie den integrierten HTTP-Trigger oder die integrierte HTTP-Aktion.

Voraussetzungen

  • Ein Azure-Konto und ein Azure-Abonnement. Falls Sie kein Abonnement besitzen, können Sie sich für ein kostenloses Azure-Konto registrieren.

  • Der Logik-App-Workflow, in dem Sie die eingehende HTTPS-Anforderung empfangen möchten. Um Ihren Workflow mit dem Trigger Anforderung starten zu können, müssen Sie mit einem leeren Workflow beginnen. Um die Gegenmaßnahme verwenden zu können, muss Ihr Workflow mit dem Trigger Anforderung beginnen.

  • Installieren oder verwenden Sie ein Tool, das HTTP-Anforderungen senden kann, um Ihre Lösung zu testen, z. B.:

    Achtung

    Für Szenarien, in denen Sie über vertrauliche Daten wie Anmeldeinformationen, Geheimnisse, Zugriffstoken, API-Schlüssel und andere ähnliche Informationen verfügen, sollten Sie ein Tool verwenden, das Ihre Daten mit den erforderlichen Sicherheitsfunktionen schützt, offline oder lokal funktioniert, Ihre Daten nicht mit der Cloud synchronisiert und keine Anmeldung bei einem Onlinekonto erfordert. Auf diese Weise verringern Sie das Risiko, dass vertrauliche Daten an die Öffentlichkeit gelangen.

Hinzufügen eines Anforderungstriggers

Der Trigger Anforderung erstellt einen manuell aufrufbaren Endpunkt, der nur eingehende Anforderungen über HTTPS verarbeitet. Wenn der Aufrufer eine Anforderung an diesen Endpunkt sendet, wird der Trigger Anforderung ausgelöst und führt den Workflow aus. Informationen zum Aufrufen dieses Triggers finden Sie unter Aufrufen, Triggern oder Verschachteln von Workflows mit HTTPS-Endpunkten in Azure Logic Apps.

  1. Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App und deren leeren Workflow im Workflow-Designer.

  2. Führen Sie im Designer die folgenden allgemeinen Schritte aus, um den integrierten Anforderungstrigger mit dem Namen Beim Empfang einer HTTP-Anforderung zu suchen und hinzuzufügen.

  3. Geben Sie nach dem Anzeigen des Triggerinformationsfelds die folgenden Informationen an:

    Eigenschaftenname JSON-Eigenschaftenname Erforderlich Beschreibung
    HTTP-POST-URL {keine} Ja Die Endpunkt-URL, die nach dem Speichern Ihres Workflows generiert und zum Senden einer Anforderung verwendet wird, die Ihren Workflow auslöst.
    JSON-Schema für Anforderungstext schema No Das JSON-Schema, das die Eigenschaften und Werte im eingehenden Anforderungstext beschreibt. Der Designer verwendet dieses Schema zum Generieren von Token für die Eigenschaften in der Anforderung. Auf diese Weise kann Ihr Workflow Ausgaben des Triggers Anforderung analysieren, verarbeiten und an Ihren Workflow weitergeben.

    Wenn Sie kein JSON-Schema haben, können Sie das Schema aus einer Beispielnutzlast generieren, indem Sie die Funktion Beispielnutzlast zum Generieren von Schema verwenden verwenden.

    Das folgende Beispiel zeigt ein JSON-Beispielschema:

    Screenshot mit Verbrauchsworkflow und Anforderungsauslöser mit einem JSON-Beispielschema

    Das folgende Beispiel zeigt das vollständige Beispiel-JSON-Schema:

    {
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

    Wenn Sie ein JSON-Schema eingeben, zeigt der Designer eine Erinnerung an, den Content-Type-Header in Ihre Anforderung aufzunehmen und diesen Header-Wert auf application/json festzulegen. Weitere Informationen finden Sie unter Behandeln von Inhaltstypen.

    Screenshot mit Verbrauchsworkflow, Anforderungsauslöser und der Erinnerung, den Header „Content-Type“ aufzunehmen

    Das folgende Beispiel zeigt, wie der Content-Type-Header im JSON-Format angezeigt wird:

    {
   "Content-Type": "application/json"
}

    Zum Generieren eines JSON-Schemas, das auf der erwarteten Nutzlast (Daten) basiert, können Sie ein Tool wie z. B. JSONSchema.net verwenden oder die folgenden Schritte ausführen:

    1. Wählen Sie im Anforderungstrigger die Option Beispielnutzlast zum Generieren eines Schemas verwenden aus.

      Screenshot mit Verbrauchsworkflow, Anforderungsauslöser und der ausgewählten Option „Beispielnutzlast zum Generieren des Schemas verwenden“

    2. Geben Sie die Beispielnutzlast ein, und wählen Sie dann Fertig aus.

      Screenshot mit Verbrauchsworkflow, Anforderungsauslöser und der zum Generieren des Schemas eingegebenem Beispielnutzlast

      Das folgende Beispiel zeigt die Beispielnutzlast:

      {
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

  4. Gehen Sie folgendermaßen vor, um zu überprüfen, ob der eingehende Aufruf einen Anforderungstext enthält, der dem angegebenen Schema entspricht:

    1. Um zu erzwingen, dass die eingehende Nachricht genau die Felder enthält, die ihr Schema beschreibt, fügen Sie in Ihrem Schema die Eigenschaft required hinzu, und geben Sie die erforderlichen Felder an. Fügen Sie die Eigenschaft additionalProperties hinzu und setzen Sie den Wert auf false.

      Das folgende Schema gibt beispielsweise an, dass die eingehende Nachricht das Feld msg und keine anderen Felder enthalten muss:

      {
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}

    2. Wählen Sie auf der Titelleiste des Triggers Anforderung auf die Schaltfläche mit den Auslassungspunkten (...).

    3. Aktivieren Sie in den Einstellungen des Triggers die Schemavalidierung, und wählen Sie Fertig aus.

      Wenn der Anforderungstext des eingehenden Aufruf nicht mit Ihrem Schema übereinstimmt, gibt der Trigger einen HTTP 400 Bad Request-Fehler zurück.

  5. Um dem Trigger weitere Eigenschaften oder Parameter hinzuzufügen, öffnen Sie die Liste Neuen Parameter hinzufügen und wählen Sie die Parameter aus, die Sie hinzufügen möchten.

    Eigenschaftenname JSON-Eigenschaftenname Erforderlich BESCHREIBUNG
    Methode method No Die Methode, die die eingehende Anforderung zum Aufrufen der Logik-App verwenden muss
    Relativer Pfad relativePath No Der relative Pfad für den Parameter, der von der Endpunkt-URL der Logik-App akzeptiert werden kann

    Im folgenden Beispiel wird die Eigenschaft Methode hinzugefügt:

    Screenshot mit Verbrauchsworkflow, Anforderungsauslöser und dem Parameter „Methode“

    Die Eigenschaft Methode wird im Trigger angezeigt, sodass Sie eine Methode aus der Liste auswählen können.

    Screenshot mit Verbrauchsworkflow, Anforderungsauslöser und der Liste „Methode“, die mit der ausgewählten Methode geöffnet wird

  6. Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.

    Dieser Schritt generiert die URL, die Sie verwenden können, um eine Anforderung zu senden, die den Workflow auslöst.

  7. Um die generierte URL zu kopieren, wählen Sie das Kopiersymbol neben der URL aus.

    Screenshot – Verbrauchs-Workflow, Anforderungsauslöser und Schaltfläche „URL kopieren“ sind ausgewählt

    Hinweis

    Wenn Sie das Hash- oder Nummernzeichen (#) im URI verwenden möchten, wenn Sie einen Aufruf an den Trigger Anforderung senden, nutzen Sie stattdessen diese codierte Version: %25%23.

Bauen Sie jetzt Ihren Workflow weiter auf, indem Sie im nächsten Schritt eine weitere Aktion hinzufügen. Beispielsweise können Sie auf die Anfrage antworten, indem Sie eine Antwortaktion hinzufügen, die Sie verwenden können, um eine benutzerdefinierte Antwort zurückzugeben, und die weiter unten in diesem Artikel beschrieben wird.

Hinweis

Ihr Workflow hält eine eingehende Anforderung nur für eine begrenzte Zeit offen. Unter der Annahme, dass Ihr Workflow auch eine Antwortaktion enthält, gibt Ihr Workflow den Status 504 GATEWAY TIMEOUT an den Anrufer zurück, wenn Ihr Workflow nach Ablauf dieser Zeit keine Antwort an den Anrufer zurückgibt. Wenn Ihr Workflow keine Response-Aktion enthält, gibt Ihr Workflow sofort den Status 202 ACCEPTED an den Anrufer zurück.

Weitere Informationen zu Sicherheit, Authentifizierung und Verschlüsselung für eingehende Aufrufe an Ihren Workflow (z. B. Transport Layer Security (TLS), früher bekannt als Secure Sockets Layer (SSL)), OAuth mit Microsoft Entra ID, SAS (Shared Access Signatures), Offenlegung Ihrer Logik-App-Ressource mit Azure API Management oder zum Einschränken der IP-Adressen, von denen eingehende Aufrufe ausgehen, finden Sie unter Sicherer Zugriff und Daten: Zugriff für eingehende Anrufe auf anforderungsbasierte Trigger.

Triggerausgaben

Die folgende Tabelle listet die Ausgaben des Triggers Anforderung auf:

JSON-Eigenschaftenname Datentyp Beschreibung
headers Objekt Ein JSON-Objekt, das die Header aus der Anforderung beschreibt
body Objekt Ein JSON-Objekt, das den Textinhalt aus der Anforderung beschreibt

Hinzufügen einer Antwortaktion

Wenn Sie den Trigger Anforderung zum Empfangen eingehender Anforderungen verwenden, können Sie die Antwort modellieren und die Nutzlastergebnisse mithilfe der integrierten Gegenmaßnahme, die nur mit dem Anforderungstrigger funktioniert, an den Aufrufer zurücksenden. Diese Kombination aus dem Trigger Anforderung und der Gegenmaßnahme bildet das Anforderung/Antwort-Muster. Außer innerhalb von Foreach-Schleifen und Until-Schleifen sowie parallelen Branches können Sie die Antwortaktion an beliebiger Stelle in Ihren Workflow hinzufügen.

Wichtig

  • Wenn Ihre Antwortaktion die folgenden Header enthält, entfernt Azure Logic Apps diese Header automatisch aus der generierten Antwortnachricht, ohne eine Warnung oder einen Fehler anzuzeigen. Azure Logic Apps enthält diese Header nicht, obwohl der Dienst Sie nicht davon abhält, Workflows mit einer Antwortaktion mit diesen Headern zu speichern.

    • Allow
    • Content-*-Header mit Ausnahme von Content-Disposition, Content-Encoding und Content-Type, wenn Sie POST- und PUT-Vorgänge verwenden, aber nicht für GET-Vorgänge
    • Cookie
    • Expires
    • Last-Modified
    • Set-Cookie
    • Transfer-Encoding

  • Wenn Sie in einem komplexen Workflow mit Verzweigungen eine oder mehrere Response-Aktionen haben, stellen Sie sicher, dass der Workflow während der Laufzeit mindestens eine Response-Aktion verarbeitet. Wenn alle Antwortaktionen übersprungen werden, erhält der Aufrufer andernfalls einen Fehler 502 Bad Gateway (Ungültiges Gateway), selbst wenn der Workflow erfolgreich abgeschlossen wurde.

  • In einem zustandslosen Workflow einer Standard-Logik-App muss die Aktion „Antwort“ als letzte in Ihrem Workflow auftreten. Wenn die Aktion an einer anderen Stelle angezeigt wird, führt Azure Logic Apps die Aktion trotzdem erst aus, wenn alle anderen Aktionen beendet sind.

  1. Führen Sie im Workflow-Designer die folgenden allgemeinen Schritte aus, um die integrierte Antwortaktion mit dem Namen Antwort zu suchen und hinzuzufügen.

    Der Einfachheit halber wird in den folgenden Beispiele ein reduzierter Trigger Anforderung dargestellt.

  2. Fügen Sie im Feld Informationen zur Aktion die erforderlichen Werte für die Antwortnachricht hinzu.

    Eigenschaftenname JSON-Eigenschaftenname Erforderlich BESCHREIBUNG
    Statuscode statusCode Ja Der in der Antwort zurückzugebende Statuscode
    Headers headers No Ein JSON-Objekt, das einen oder mehrere Header beschreibt, die in die Antwort eingeschlossen werden sollen
    Text body No Der Antworttext.

    Wenn Sie innerhalb eines Textfelds auswählen, wird die dynamische Inhaltsliste automatisch geöffnet. Anschließend können Sie Token auswählen, die alle verfügbaren Ausgaben aus vorherigen Schritten des Workflows darstellen. Die Eigenschaften aus dem von Ihnen angegebenen Schema werden auch in dieser dynamischen Inhaltsliste angezeigt. Sie können diese Eigenschaften auswählen, die in Ihrem Workflow verwendet werden sollen.

    Fügen Sie beispielsweise im Feld Headers Content-Type als Schlüsselnamen ein und legen Sie den Schlüsselwert auf application/json fest, wie weiter oben in diesem Artikel erwähnt. Für das Feld Text können Sie die Ausgabe des Triggertexts aus der Liste mit dynamischen Inhalten auswählen.

    Screenshot mit Informationen zu Azure-Portal, Verbrauchsworkflow und Antwortaktion.

    Um die Header im JSON-Format anzuzeigen, wählen Sie Zur Textansicht wechseln aus.

    Screenshot mit Headern für das Azure-Portal, den Verbrauchsworkflow und die Antwortaktion in der Ansicht „Zu Text wechseln“.

  3. Um weitere Eigenschaften für die Aktion hinzuzufügen, z. B. ein JSON-Schema für den Antworttext, aus der Liste Neuen Parameter hinzufügen wählen Sie die Parameter aus, die Sie hinzufügen möchten.

  4. Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.

Testen Ihres Workflows

Um den Workflow auszulösen, senden Sie eine HTTP-Anforderung an die für den Trigger Anforderung generierte URL, einschließlich der Methode, die der Trigger Anforderung erwartet, indem Sie Ihr HTTP-Anforderungstools und dessen Anweisungen verwenden.

Weitere Informationen zur zugrunde liegenden JSON-Definition des Triggers und zum Aufzurufen dieses Triggers finden Sie in den Themen Triggertyp Anforderung und unter Aufrufen, Auslösen oder Schachteln von Workflows mit HTTP-Endpunkten in Azure Logic Apps.

Sicherheit und Authentifizierung

In einem Standard-Logik-App-Workflow, der mit dem Anforderungstrigger beginnt (aber keinem Webhooktrigger), können Sie die Azure Functions-Bereitstellung für die Authentifizierung eingehender Aufrufe, die an den durch diesen Trigger erstellten Endpunkt gesendet wurden, mithilfe einer verwalteten Identität verwenden. Diese Bereitstellung wird auch als „Easy Auth“ (einfache Authentifizierung) bezeichnet. Weitere Informationen hierzu finden Sie unter Auslösen von Workflows in Standard-Logik-Apps mit Easy Auth.

Informationen zu Sicherheit, Autorisierung und Verschlüsselung für eingehende Aufrufe an Ihren Logic App-Workflow (z. B. Transport Layer Security (TLS), früher bekannt als Secure Sockets Layer (SSL)), Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), Offenlegung Ihrer Logik-App mit Azure API Management oder zum Einschränken der IP-Adressen, von denen eingehende Aufrufe ausgehen, finden Sie unter Sicherer Zugriff und Daten: Zugriff für eingehende Aufrufe anforderungsbasierter Trigger.

Nächste Schritte