Schemareferenzhandbuch zu Trigger- und Aktionstypen für Azure Logic Apps

  • Artikel

In dieser Referenz werden die allgemeinen Typen beschrieben, die zum Identifizieren von Triggern und Aktionen in der Ihrer Logik-App zugrunde liegenden Workflowdefinition verwendet werden, die durch die Definitionssprache für Workflows beschrieben und validiert werden. Um bestimmte Connector-Trigger und -Aktionen aufzufinden, die Sie in Ihren Logik-Apps verwenden können, sehen Sie in der Liste unter der Connectorübersicht nach.

Übersicht über Trigger

Jeder Workflow enthält einen Trigger, mit dem die Aufrufe definiert werden, die den Workflow instanziieren und starten. Hier sind die allgemeinen Triggerkategorien angegeben:

  • Ein Abruftrigger, der den Endpunkt eines Diensts in regelmäßigen Abständen überprüft.

  • Ein Pushtrigger, mit dem ein Abonnement für einen Endpunkt erstellt und eine Rückruf-URL bereitgestellt wird, damit der Endpunkt den Trigger benachrichtigen kann, wenn das angegebene Ereignis eintritt oder Daten verfügbar sind. Der Trigger wartet dann auf die Antwort des Endpunkts, bevor er ausgelöst wird.

Trigger besitzen auf oberster Ebene die folgenden Elemente (einige davon sind optional):

"<trigger-name>": {
   "type": "<trigger-type>",
   "inputs": { "<trigger-inputs>" },
   "recurrence": { 
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "conditions": [ "<array-with-conditions>" ],
   "runtimeConfiguration": { "<runtime-config-options>" },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
},

Erforderlich

Wert type BESCHREIBUNG
<trigger-name> String Name des Triggers
<trigger-type> String Triggertyp, z.B. „Http“ oder „ApiConnection“
<trigger-inputs> JSON-Objekt Eingaben, die das Verhalten des Triggers definieren
<time-unit> String Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
<number-of-time-units> Integer Ein Wert, der angibt, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird. Dies ist die Anzahl der Zeiteinheiten, die gewartet werden sollen, bis der Trigger erneut ausgelöst wird.

Hier sind die minimalen und maximalen Intervalle:

- Month: 1–16 Monate
- Day: 1–500 Tage
- Hour: 1–12.000 Stunden
- Minute: 1–72.000 Minuten
- Second: 1–9.999.999 Sekunden

Wenn das Intervall also beispielsweise auf „6“ und die Häufigkeit auf „Month“ festgelegt ist, erfolgt die Wiederholung alle sechs Monate.

Optional

Wert type BESCHREIBUNG
<array-with-conditions> Array Array mit mindestens einer Bedingung, die bestimmt, ob der Workflow ausgeführt wird. Derzeit nur für Trigger verfügbar.
<runtime-config-options> JSON-Objekt Sie können das Verhalten der Triggerlaufzeit ändern, indem Sie die Eigenschaften für runtimeConfiguration festlegen. Weitere Informationen finden Sie unter den Einstellungen für die Laufzeitkonfiguration.
<splitOn-expression> String Für Trigger, die ein Array zurückgeben, können Sie einen Ausdruck angeben, mit dem Arrayelemente für die Verarbeitung in mehrere Workflowinstanzen aufgeteilt bzw. aufgelöst werden.
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Liste mit Triggertypen

Jeder Triggertyp verfügt über eine andere Schnittstelle sowie über Eingaben, die sein Verhalten definieren.

Integrierte Trigger

Triggertyp BESCHREIBUNG
HTTP Überprüft alle Endpunkte bzw. fragt diese ab. Der Endpunkt muss einem bestimmten Triggervertrag entsprechen, und zwar durch Verwendung eines asynchronen Musters (202) oder durch Rückgabe eines Arrays.
HTTPWebhook Erstellt einen aufrufbaren Endpunkt für Ihre Logik-App, aber ruft die angegebene URL auf, um die Registrierung bzw. die Aufhebung der Registrierung durchzuführen.
Recurrence Wird auf der Grundlage eines definierten Zeitplans ausgelöst. Sie können ein Datum und eine Uhrzeit in der Zukunft festlegen, um diesen Trigger auszulösen. Je nach Häufigkeit können Sie auch Zeiten und Tage für die Ausführung Ihres Workflows angeben.
Request Erstellt einen aufrufbaren Endpunkt für Ihre Logik-App und wird auch als „manueller“ Trigger bezeichnet. Weitere Informationen finden Sie unter Aufrufen, Auslösen oder Schachteln von Workflows mit HTTP-Endpunkten.

Verwaltete API-Trigger

Triggertyp BESCHREIBUNG
ApiConnection Überprüft einen Endpunkt mithilfe der von Microsoft verwalteten APIs oder „Connectors“ oder fragt diesen ab.
ApiConnectionWebhook Erstellt einen aufrufbaren Endpunkt für Ihren Logik-App-Workflow, indem von Microsoft verwaltete APIs oder „Connectors“ zum Abonnieren und Abbestellen aufgerufen werden.

Trigger – Detaillierte Referenz

APIConnection-Trigger

Mit diesem Trigger wird ein Endpunkt überprüft bzw.abgefragt, indem von Microsoft verwaltete APIs oder „Connectors“ verwendet werden. Die Parameter für diesen Trigger können sich also basierend auf dem Endpunkt unterscheiden. Viele Abschnitte dieser Triggerdefinition sind optional. Das Verhalten des Triggers hängt davon ab, ob bestimmte Abschnitte enthalten sind.

"<APIConnection_trigger_name>": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<connection-name>']['connectionId']"
         }
      },
      "method": "<method-type>",
      "path": "/<api-operation>",
      "retryPolicy": { "<retry-behavior>" },
      "queries": { "<query-parameters>" }
   },
   "recurrence": { 
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
}

Erforderlich

Wert type BESCHREIBUNG
<APIConnection_trigger_name> String Name des Triggers
<connection-name> String Name für die Verbindung mit der verwalteten API, die vom Workflow verwendet wird
<method-type> String HTTP-Methode für die Kommunikation mit der verwalteten API: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<api-operation> String Aufzurufender API-Vorgang
<time-unit> String Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
<number-of-time-units> Integer Ein Wert, der angibt, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird. Dies ist die Anzahl der Zeiteinheiten, die gewartet werden sollen, bis der Trigger erneut ausgelöst wird.

Hier sind die minimalen und maximalen Intervalle:

- Month: 1–16 Monate
- Day: 1–500 Tage
- Hour: 1–12.000 Stunden
- Minute: 1–72.000 Minuten
- Second: 1–9.999.999 Sekunden

Wenn das Intervall also beispielsweise auf „6“ und die Häufigkeit auf „Month“ festgelegt ist, erfolgt die Wiederholung alle sechs Monate.

Optional

Wert type BESCHREIBUNG
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<query-parameters> JSON-Objekt Alle Abfrageparameter, die in den API-Aufruf einbezogen werden sollen. Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
<max-runs> Integer Standardmäßig werden Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
<max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
<splitOn-expression> String Für Trigger, die Arrays zurückgeben, verweist dieser Ausdruck auf das zu verwendende Array, damit Sie für jedes Arrayelement eine Workflowinstanz erstellen und ausführen können, anstatt eine „for each“-Schleife zu verwenden.

Dieser Ausdruck stellt beispielsweise ein Element im Array dar, das mit dem Inhalt des Triggers zurückgegeben wird: @triggerbody()?['value']
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Ausgaben

Element type BESCHREIBUNG
headers JSON-Objekt Header aus der Antwort
body JSON-Objekt Text aus der Antwort
status code Integer Der Statuscode aus der Antwort

Beispiel

Diese Triggerdefinition prüft den Posteingang eines Geschäfts-, Schul- oder Unikontos jeden Tag auf E-Mails:

"When_a_new_email_arrives": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "get",
      "path": "/Mail/OnNewEmail",
      "queries": {
          "fetchOnlyWithAttachment": false,
          "folderPath": "Inbox",
          "importance": "Any",
          "includeAttachments": false
      }
   },
   "recurrence": {
      "frequency": "Day",
      "interval": 1
   }
}

ApiConnectionWebhook-Trigger

Dieser Trigger sendet eine Abonnementanforderung an einen Endpunkt, indem eine von Microsoft verwaltete API verwendet wird, gibt eine Rückruf-URL an, an die der Endpunkt eine Antwort senden kann, und wartet auf die Antwort des Endpunkts. Weitere Informationen finden Sie unter Endpunktabonnements.

"<ApiConnectionWebhook_trigger_name>": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "body": {
          "NotificationUrl": "@{listCallbackUrl()}"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<connection-name>']['connectionId']"
         }
      },
      "retryPolicy": { "<retry-behavior>" },
      "queries": "<query-parameters>"
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-run-queue>
      }
   },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
}

Erforderlich

Wert type BESCHREIBUNG
<connection-name> String Name für die Verbindung mit der verwalteten API, die vom Workflow verwendet wird
<body-content> JSON-Objekt Nachrichteninhalt, der als Nutzlast an die verwaltete API gesendet wird

Optional

Wert type BESCHREIBUNG
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<query-parameters> JSON-Objekt Alle Abfrageparameter, die in den API-Aufruf eingeschlossen werden sollen

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
<max-runs> Integer Standardmäßig werden Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
<max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
<splitOn-expression> String Für Trigger, die Arrays zurückgeben, verweist dieser Ausdruck auf das zu verwendende Array, damit Sie für jedes Arrayelement eine Workflowinstanz erstellen und ausführen können, anstatt eine „for each“-Schleife zu verwenden.

Dieser Ausdruck stellt beispielsweise ein Element im Array dar, das mit dem Inhalt des Triggers zurückgegeben wird: @triggerbody()?['value']
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Beispiel

Diese Triggerdefinition abonniert die Office 365-Outlook-API, gibt eine Rückruf-URL für den API-Endpunkt an und wartet darauf, dass der Endpunkt antwortet, wenn eine neue E-Mail eintrifft.

"When_a_new_email_arrives_(webhook)": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "body": {
         "NotificationUrl": "@{listCallbackUrl()}" 
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "path": "/MailSubscription/$subscriptions",
      "queries": {
          "folderPath": "Inbox",
          "hasAttachment": "Any",
          "importance": "Any"
      }
   },
   "splitOn": "@triggerBody()?['value']"
}

HTTP-Trigger

Dieser Trigger sendet eine Anforderung an den angegebenen HTTP- oder HTTPS-Endpunkt, basierend auf dem angegebenen Wiederholungszeitplan. Dieser Trigger überprüft dann die Antwort, um zu bestimmen, ob der Workflow ausgeführt wird. Weitere Informationen finden Sie unter Aufrufen von Dienstendpunkten per HTTP oder HTTPS aus Azure Logic Apps.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<HTTP-or-HTTPS-endpoint-URL>",
      "headers": { "<header-content>" },
      "queries": "<query-parameters>",
      "body": "<body-content>",
      "authentication": { "<authentication-type-and-property-values>" },
      "retryPolicy": {
         "type": "<retry-behavior>"
      }
   },
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Erforderlich

Eigenschaft Wert type BESCHREIBUNG
method <method-type> String Die zum Senden der ausgehenden Anforderung zu verwendende Methode: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
uri <HTTP-or-HTTPS-endpoint-URL> String Die HTTP- oder HTTPS-Endpunkt-URL, an die die ausgehende Anforderung gesendet werden soll. Maximale Zeichenfolgengröße: 2 KB

Für einen Azure-Dienst oder eine Azure-Ressource enthält diese URI-Syntax die Ressourcen-ID und den Pfad zu der Ressource, auf die Sie zugreifen möchten.
frequency <time-unit> String Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
interval <number-of-time-units> Integer Ein Wert, der angibt, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird. Dies ist die Anzahl der Zeiteinheiten, die gewartet werden sollen, bis der Trigger erneut ausgelöst wird.

Hier sind die minimalen und maximalen Intervalle:

- Month: 1–16 Monate
- Day: 1–500 Tage
- Hour: 1–12.000 Stunden
- Minute: 1–72.000 Minuten
- Second: 1–9.999.999 Sekunden

Wenn das Intervall also beispielsweise auf „6“ und die Häufigkeit auf „Month“ festgelegt ist, erfolgt die Wiederholung alle sechs Monate.

Optional

Eigenschaft Wert type BESCHREIBUNG
headers <header-content> JSON-Objekt Alle Header, die Sie in die Anforderung einschließen müssen

So legen Sie z. B. die Sprache und den Typ fest:

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries <query-parameters> JSON-Objekt Alle Abfrageparameter, die Sie in der Anforderung verwenden müssen

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird der Anforderung beispielsweise ?api-version=2018-01-01 hinzugefügt.
body <body-content> JSON-Objekt Nachrichteninhalt, der als Nutzlast mit der Anforderung gesendet wird
authentication <authentication-type-and-property-values> JSON-Objekt Das Authentifizierungsmodell, das von der Anforderung zum Authentifizieren ausgehender Anforderungen verwendet wird. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung zu ausgehenden Aufrufen. Über den Scheduler hinaus wird die authority-Eigenschaft unterstützt. Ohne Angabe wird standardmäßig der Wert https://management.azure.com/ verwendet. Sie können aber einen anderen Wert verwenden.
retryPolicy > type <retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
runs <max-runs> Integer Standardmäßig werden Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
maximumWaitingRuns <max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
operationOptions <operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Ausgaben

Element type BESCHREIBUNG
headers JSON-Objekt Header aus der Antwort
body JSON-Objekt Text aus der Antwort
status code Integer Der Statuscode aus der Antwort

Erforderliche Voraussetzungen für eingehende Anforderungen

Damit der Endpunkt gut mit Ihrer Logik-App funktioniert, muss er einem bestimmten Triggermuster oder -vertrag entsprechen und diese Antworteigenschaften erkennen:

Eigenschaft Erforderlich BESCHREIBUNG
Statuscode Ja Der Statuscode „200 OK“ startet eine Ausführung. Alle anderen Statuscodes starten keine Ausführung.
Retry-After-Header Nein Die Anzahl von Sekunden bis zur erneuten Abfrage des Endpunkts durch Ihre Logik-App.
Adressheader Nein Die URL, die im nächsten Abfrageintervall aufgerufen werden soll. Ohne Angabe wird die ursprüngliche URL verwendet.

Beispielverhalten für unterschiedliche Anforderungen

Statuscode Wiederholungsintervall Verhalten
200 {keine} Führt den Workflow aus und sucht erst nach der definierten Wiederholung wieder nach weiteren Inhalten.
200 10 Sekunden Führt den Workflow aus und sucht nach zehn Sekunden nach weiteren Inhalten.
202 60 Sekunden Der Workflow wird nicht ausgelöst. Der nächste Versuch erfolgt gemäß der definierten Wiederholung in einer Minute. Wenn die definierte Wiederholung weniger als eine Minute beträgt, hat der Retry-After-Header Vorrang. Andernfalls wird die definierte Wiederholung verwendet.
400 {keine} Ungültige Anforderung. Der Workflow wird nicht ausgeführt. Wenn keine retryPolicy definiert ist, wird die Standardrichtlinie verwendet. Wenn die Anzahl von Wiederholungen erreicht ist, sucht der Trigger nach der definierten Wiederholung erneut nach Inhalten.
500 {keine} Serverfehler. Der Workflow wird nicht ausgeführt. Wenn keine retryPolicy definiert ist, wird die Standardrichtlinie verwendet. Wenn die Anzahl von Wiederholungen erreicht ist, sucht der Trigger nach der definierten Wiederholung erneut nach Inhalten.

HTTPWebhook-Trigger

Mit diesem Trigger wird Ihre Logik-App aufrufbar, indem ein Endpunkt erstellt wird, der durch das Aufrufen der angegebenen Endpunkt-URL ein Abonnement registrieren kann. Wenn Sie diesen Trigger in Ihrem Workflow erstellen, wird bei einer ausgehenden Anforderung der Aufruf für die Registrierung des Abonnements durchgeführt. Auf diese Weise kann der Trigger mit dem Lauschen auf Ereignisse beginnen. Wenn ein Vorgang diesen Trigger ungültig macht, führt eine ausgehende Anforderung automatisch den Aufruf zum Kündigen des Abonnements durch. Weitere Informationen finden Sie unter Endpunktabonnements.

Sie können auch asynchrone Limits für einen HTTPWebhook-Trigger angeben. Das Verhalten des Triggers hängt davon ab, welche Abschnitte Sie verwenden bzw. entfernen.

"HTTP_Webhook": {
   "type": "HttpWebhook",
   "inputs": {
      "subscribe": {
         "method": "<method-type>",
         "uri": "<endpoint-subscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "retryPolicy": { "<retry-behavior>" }
         },
      },
      "unsubscribe": {
         "method": "<method-type>",
         "url": "<endpoint-unsubscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" }
      }
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Einige Werte, z.B. <method-type>, sind sowohl für das Objekt "subscribe" als auch für "unsubscribe" verfügbar.

Erforderlich

Wert type BESCHREIBUNG
<method-type> String HTTP-Methode für die Abonnementanforderung: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<endpoint-subscribe-URL> String Endpunkt-URL, an die die Abonnementanforderung gesendet werden soll

Optional

Wert type BESCHREIBUNG
<method-type> String HTTP-Methode für die Kündigungsanforderung: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<endpoint-unsubscribe-URL> String Endpunkt-URL, an die die Kündigungsanforderung gesendet werden soll
<body-content> String Beliebiger Nachrichteninhalt, der in der Abonnement- oder Kündigungsanforderung gesendet werden soll
<authentication-type> JSON-Objekt Das Authentifizierungsmodell, das von der Anforderung zum Authentifizieren ausgehender Anforderungen verwendet wird. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung zu ausgehenden Aufrufen.
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<max-runs> Integer Standardmäßig werden alle Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
<max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Ausgaben

Element type BESCHREIBUNG
headers JSON-Objekt Header aus der Antwort
body JSON-Objekt Text aus der Antwort
status code Integer Der Statuscode aus der Antwort

Beispiel

Dieser Trigger erstellt ein Abonnement mit dem angegebenen Endpunkt, stellt eine eindeutige Rückruf-URL bereit und wartet auf neu veröffentlichte Technologieartikel.

"HTTP_Webhook": {
   "type": "HttpWebhook",
   "inputs": {
      "subscribe": {
         "method": "POST",
         "uri": "https://pubsubhubbub.appspot.com/subscribe",
         "body": {
            "hub.callback": "@{listCallbackUrl()}",
            "hub.mode": "subscribe",
            "hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
         },
      },
      "unsubscribe": {
         "method": "POST",
         "url": "https://pubsubhubbub.appspot.com/subscribe",
         "body": {
            "hub.callback": "@{workflow().endpoint}@{listCallbackUrl()}",
            "hub.mode": "unsubscribe",
            "hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
         }
      }
   }
}

Recurrence-Trigger

Dieser Trigger wird basierend auf dem angegebenen Wiederholungszeitplan ausgeführt und ist eine einfache Möglichkeit zum Erstellen eines Workflows, der regelmäßig ausgeführt wird.

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
      "startTime": "<start-date-time-with-format-YYYY-MM-DDThh:mm:ss>",
      "timeZone": "<time-zone>",
      "schedule": {
         // Applies only when frequency is Day or Week. Separate values with commas.
         "hours": [ <one-or-more-hour-marks> ], 
         // Applies only when frequency is Day or Week. Separate values with commas.
         "minutes": [ <one-or-more-minute-marks> ], 
         // Applies only when frequency is Week. Separate values with commas.
         "weekDays": [ "Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday" ] 
      }
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Erforderlich

Wert type BESCHREIBUNG
<time-unit> String Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
<number-of-time-units> Integer Ein Wert, der angibt, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird. Dies ist die Anzahl der Zeiteinheiten, die gewartet werden sollen, bis der Trigger erneut ausgelöst wird.

Hier sind die minimalen und maximalen Intervalle:

- Month: 1–16 Monate
- Day: 1–500 Tage
- Hour: 1–12.000 Stunden
- Minute: 1–72.000 Minuten
- Second: 1–9.999.999 Sekunden

Wenn das Intervall also beispielsweise auf „6“ und die Häufigkeit auf „Month“ festgelegt ist, erfolgt die Wiederholung alle sechs Monate.

Optional

Wert type BESCHREIBUNG
<start-date-time-with-format-YYYY-MM-DDThh:mm:ss> String Das Startdatum und die Startzeit in diesem Format:

JJJJ-MM-DDThh:mm:ss, wenn Sie eine Zeitzone angeben

Oder

JJJJ-MM-DDThh:mm:ssZ, wenn Sie keine Zeitzone angeben

Für „18. September 2017, 14:00 Uhr“ müssten Sie also beispielsweise „2017-09-18T14:00:00“ und eine Zeitzone (etwa „Pacific Standard Time“) angeben oder „2017-09-18T14:00:00Z“ ohne eine Zeitzone.

Hinweis: Diese Startzeit kann maximal 49 Jahre in der Zukunft liegen und muss dem ISO 8601-Format für Datums-/Uhrzeitangaben entsprechen und im UTC-Datums-/Zeitformat angegeben werden, jedoch ohne UTC-Abweichung. Wenn Sie keine Zeitzone angeben, müssen Sie den Buchstaben „Z“ ohne Leerzeichen anhängen. „Z“ bezieht sich auf die entsprechende nautische Zeit.

Bei einfachen Zeitpläne ist die Startzeit das erste Vorkommen. Bei komplexeren Zeitplänen wird der Trigger nicht vor der Startzeit ausgelöst. Weitere Informationen zu Startdatum und -uhrzeit finden Sie unter Schedule tasks and workflows that run regularly with logic apps (Planen von regelmäßig ausgeführten Aufgaben und Workflows mit Logik-Apps).
<time-zone> String Nur relevant, wenn Sie eine Startzeit angeben, da dieser Trigger keine UTC-Abweichung akzeptiert. Geben Sie die anzuwendende Zeitzone an.
<one-or-more-hour-marks> Ganze Zahl oder Ganzzahlarray Wenn Sie für frequency die Option „Day“ oder „Week“ angeben, können Sie eine ganze Zahl oder eine kommagetrennte Liste mit ganzen Zahlen von 0 bis 23 als die Stunden des Tages angeben, zu denen der Workflow ausgeführt werden soll.

Wenn Sie also etwa „10“, „12“ und „14“ angeben, erhalten Sie die vollen Stunden „10 Uhr“, „12 Uhr“ und „14 Uhr“.
<one-or-more-minute-marks> Ganze Zahl oder Ganzzahlarray Wenn Sie für frequency die Option „Day“ oder „Week“ angeben, können Sie eine ganze Zahl oder eine kommagetrennte Liste mit ganzen Zahlen von 0 bis 59 als die Minuten der Stunde angeben, zu denen der Workflow ausgeführt werden soll.

Wenn Sie also beispielsweise „30“ als Minutenwert angeben und das vorherige Beispiel für Stunden des Tages verwenden, erhalten Sie „10:30 Uhr“, „12:30 Uhr“ und „14:30 Uhr“.
weekDays Zeichenfolge oder Zeichenfolgenarray Wenn Sie für frequency die Option „Week“ angeben, können Sie einen Tag oder eine durch Trennzeichen getrennte Liste mit Tagen für die Workflowausführung angeben: „Monday“, „Tuesday“, „Wednesday“, „Thursday“, „Friday“, „Saturday“, „Sunday“
<max-runs> Integer Standardmäßig werden alle Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
<max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Beispiel 1

Dieser grundlegende Wiederholungstrigger wird täglich ausgeführt:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1
   }
}

Beispiel 2

Sie können ein Startdatum und eine -uhrzeit für die Auslösung des Triggers festlegen. Dieser Wiederholungstrigger wird am angegebenen Datum gestartet und anschließend täglich ausgelöst:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1,
      "startTime": "2017-09-18T00:00:00Z"
   }
}

Beispiel 3

Dieser Wiederholungstrigger startet am 9. September 2017 um 14:00 Uhr und wird wöchentlich jeden Montag um 10:30 Uhr, 12:30 Uhr und 14:30 Uhr Pacific Standard Time ausgelöst:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Week",
      "interval": 1,
      "schedule": {
         "hours": [ 10, 12, 14 ],
         "minutes": [ 30 ],
         "weekDays": [ "Monday" ]
      },
      "startTime": "2017-09-07T14:00:00",
      "timeZone": "Pacific Standard Time"
   }
}

Weitere Informationen zu diesem Trigger sowie Beispiele finden Sie unter Erstellen und Planen der regelmäßigen Ausführung von Aufgaben.

Anforderungstrigger

Durch diesen Trigger wird Ihre Logik-App aufrufbar, indem ein Endpunkt erstellt wird, der eingehende Anforderungen annehmen kann. Geben Sie für diesen Trigger ein JSON-Schema an, das die Nutzlast oder die Eingaben, die der Trigger aus der eingehenden Anforderung empfängt, beschreibt und überprüft. Mit dem Schema kann für spätere Aktionen des Workflows außerdem leichter auf Triggereigenschaften verwiesen werden.

Um diesen Trigger aufrufen zu können, müssen Sie die listCallbackUrl-API verwenden, die in der Workflow Service-REST-API beschrieben ist. Informationen zum Verwenden dieses Triggers als HTTP-Endpunkt finden Sie unter Aufrufen, Auslösen oder Schachteln von Workflows mit HTTP-Endpunkten in Logik-Apps.

"manual": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "<method-type>",
      "relativePath": "<relative-path-for-accepted-parameter>",
      "schema": {
         "type": "object",
         "properties": { 
            "<property-name>": {
               "type": "<property-type>"
            }
         },
         "required": [ "<required-properties>" ]
      }
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-run-queue>
      },
   },
   "operationOptions": "<operation-option>"
}

Erforderlich

Wert type BESCHREIBUNG
<property-name> String Name einer Eigenschaft im JSON-Schema, mit der die Nutzlast beschrieben wird
<property-type> String Typ der Eigenschaft

Optional

Wert type BESCHREIBUNG
<method-type> String Methode, die eingehende Anforderungen verwenden müssen, um Ihre Logik-App aufzurufen: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<relative-path-for-accepted-parameter> String Relativer Pfad für den Parameter, der von der URL Ihres Endpunkts akzeptiert werden kann
<required-properties> Array Mindestens eine Eigenschaft, die Werte erfordert.
<max-runs> Integer Standardmäßig werden alle Workflowinstanzen gleichzeitig (oder parallel) bis zum Standardlimit ausgeführt. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Triggerparallelität.
<max-runs-queue> Integer Wenn Ihr Workflow bereits auf der maximalen Anzahl von Instanzen ausgeführt wird (die Sie basierend auf der runtimeConfiguration.concurrency.runs-Eigenschaft ändern können), werden alle neuen Ausführungen bis zum Standardlimit in diese Warteschlange eingereiht. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.
<operation-option> String Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Beispiel

Dieser Trigger gibt an, dass eine eingehende Anforderung die HTTP POST-Methode verwenden muss, um den Trigger aufzurufen. Außerdem enthält er ein Schema, mit dem die Eingabe aus der eingehenden Anforderung überprüft wird:

"manual": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "POST",
      "schema": {
         "type": "object",
         "properties": {
            "customerName": {
               "type": "String"
            },
            "customerAddress": { 
               "type": "Object",
               "properties": {
                  "streetAddress": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

Triggerbedingungen

Für jeden Trigger – und nur für Trigger – können Sie ein Array mit Ausdrücken für Bedingungen einbinden, mit denen bestimmt wird, ob der Workflow ausgeführt werden soll. Öffnen Sie Ihre Logik-App im Codeansicht-Editor, um die conditions-Eigenschaft einem Trigger in Ihrem Workflow hinzuzufügen.

Sie können beispielsweise angeben, dass ein Trigger nur dann ausgeführt wird, wenn eine Website einen internen Serverfehler zurückgibt. Hierzu verweisen Sie in der conditions-Eigenschaft auf den Statuscode des Triggers:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Hour",
      "interval": 1
   },
   "conditions": [ {
      "expression": "@equals(triggers().code, 'InternalServerError')"
   } ]
}

Standardmäßig wird ein Trigger nur ausgelöst, wenn die Antwort „200 OK“ empfangen wird. Wenn ein Ausdruck auf den Statuscode eines Triggers verweist, wird das Standardverhalten des Triggers ersetzt. Falls der Trigger bei mehr als einem Statuscode ausgelöst werden soll, z.B. „200“ und „201“, müssen Sie diesen Ausdruck als Ihre Bedingung einfügen:

@or(equals(triggers().code, 200),equals(triggers().code, 201))

Lösen Sie mehrere Läufe auf einem Array aus

Wenn Ihr Trigger ein Array zur Verarbeitung durch Ihren Workflow empfängt, kann es manchmal zu lange dauern, bis die einzelnen Array-Elemente mit einer „for each“-Schleife verarbeitet werden. Stattdessen können Sie die SplitOn-Eigenschaft in Ihrem Trigger zur debatch-Ausführung für das Array verwenden. Bei der Batchauflösung werden das Array in seine Elemente aufgeteilt und eine neue Logik-App-Instanz gestartet, die für jedes Arrayelement ausgeführt wird. Dieser Ansatz ist beispielsweise hilfreich, wenn Sie einen Endpunkt abfragen möchten, der zwischen Abfrageintervallen mehrere neue Elemente zurückgeben könnte.

Wenn die Swagger-Datei Ihres Triggers eine Nutzlast beschreibt, die ein Array ist, wird die SplitOn-Eigenschaft automatisch zu Ihrem Trigger hinzugefügt. Fügen Sie diese Eigenschaft andernfalls in der Antwortnutzlast hinzu, die das Array enthält, für das Sie die Batchauflösung ausführen möchten.

Bevor Sie die SplitOn-Funktion verwenden, prüfen Sie die folgenden Überlegungen:

  • Wenn die Trigger-Parallelität aktiviert ist, wird das SplitOn-Limit erheblich reduziert. Wenn die Anzahl der Elemente dieses Limit überschreitet, wird die SplitOn-Funktion deaktiviert.

  • Sie können die SplitOn-Funktion nicht mit einem synchronen Antwortmuster verwenden. Jeder Workflow, der die SplitOn-Eigenschaft verwendet und eine Antwortaktion enthält, wird asynchron ausgeführt und sendet sofort eine 202 ACCEPTED Antwort.

  • Informationen zur maximalen Anzahl von Array-Elementen, die SplitOn in einem einzelnen Workflow-Lauf verarbeiten kann, finden Sie unter Limits and configuration.

Beispiel

Angenommen, Sie haben einen HTTP-Trigger, der eine API aufruft und diese Antwort erhält:

{
   "Status": "Succeeded",
   "Rows": [ 
      { 
         "id": 938109380,
         "name": "customer-name-one"
      },
      {
         "id": 938109381,
         "name": "customer-name-two"
      }
   ]
}

Ihr Workflow benötigt nur den Inhalt aus dem Array in Rows, sodass Sie einen Trigger wie in diesem Beispiel erstellen können:

"HTTP_Debatch": {
   "type": "Http",
    "inputs": {
        "uri": "https://mydomain.com/myAPI",
        "method": "GET"
    },
   "recurrence": {
      "frequency": "Second",
      "interval": 1
    },
    "splitOn": "@triggerBody()?.Rows"
}

Hinweis

Mit dem SplitOn-Befehl können Sie keine Eigenschaften außerhalb des Arrays abrufen. In diesem Beispiel können Sie also nicht die status-Eigenschaft in der von der API zurückgegebenen Antwort abrufen.

Um einen Fehler zu vermeiden, wenn die ?-Eigenschaft nicht vorhanden ist, wird in diesem Beispiel der Rows-Operator verwendet.

Ihre Workflowdefinition kann nun @triggerBody().name verwenden, um die name-Werte abzurufen. Dies sind "customer-name-one" aus der ersten Ausführung und "customer-name-two" aus der zweiten Ausführung. Ihre Triggerausgaben sehen nun wie diese Beispiele aus:

{
   "body": {
      "id": 938109380,
      "name": "customer-name-one"
   }
}

{
   "body": {
      "id": 938109381,
      "name": "customer-name-two"
   }
}

Übersicht über Aktionen

Für Azure Logic Apps werden verschiedene Aktionstypen bereitgestellt. Diese verfügen jeweils über unterschiedliche Eingaben, mit denen das eindeutige Verhalten einer Aktion definiert wird. Aktionen verfügen über diese allgemeinen Elemente, von denen einige aber optional sind:

"<action-name>": {
   "type": "<action-type>",
   "inputs": { 
      "<input-name>": { "<input-value>" },
      "retryPolicy": "<retry-behavior>" 
   },
   "runAfter": { "<previous-trigger-or-action-status>" },
   "runtimeConfiguration": { "<runtime-config-options>" },
   "operationOptions": "<operation-option>"
},

Erforderlich

Wert type BESCHREIBUNG
<action-name> String Name für die Aktion
<action-type> String Aktionstyp, z.B. „Http“ oder „ApiConnection“
<input-name> String Name für eine Eingabe, mit der das Verhalten der Aktion definiert wird
<input-value> Verschiedene Eingabewert, bei dem es sich um eine Zeichenfolge, eine Ganzzahl, ein JSON-Objekt usw. handeln kann
<previous-trigger-or-action-status> JSON-Objekt Name und sich ergebender Status für den Trigger oder die Aktion, die sofort ausgeführt werden muss, bevor diese aktuelle Aktion ausgeführt werden kann

Optional

Wert type BESCHREIBUNG
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter „Wiederholungsrichtlinien“.
<runtime-config-options> JSON-Objekt Für einige Aktionen können Sie das Verhalten der Aktion zur Laufzeit ändern, indem Sie die runtimeConfiguration-Eigenschaften festlegen. Weitere Informationen finden Sie unter den Einstellungen für die Laufzeitkonfiguration.
<operation-option> String Für einige Aktionen können Sie das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter Optionen für Vorgänge.

Liste mit Aktionstypen

Hier sind einige häufig verwendete Aktionstypen angegeben:

Integrierte Aktionen

Aktionstyp BESCHREIBUNG
Compose Erstellt aus Eingaben, die verschiedene Typen aufweisen können, eine einzelne Ausgabe.
Ausführen von JavaScript-Code Führen Sie JavaScript-Codeausschnitte aus, die bestimmten Kriterien entsprechen. Informationen zu Codeanforderungen und weitere Informationen finden Sie unter Hinzufügen und Ausführen von Codeausschnitten mit Inlinecode.
Function Ruft eine Azure-Funktion auf.
HTTP Ruft einen HTTP-Endpunkt auf.
Join Erstellt eine Zeichenfolge aus allen Elementen in einem Array und trennt diese Elemente mit einem angegebenen Trennzeichen.
Parse JSON Erstellt benutzerfreundliche Token aus Eigenschaften in JSON-Inhalten. Sie können dann auf diese Eigenschaften verweisen, indem Sie die Token in Ihre Logik-App einfügen.
Query Erstellt basierend auf einer Bedingung oder einem Filter ein Array aus den Elementen eines anderen Arrays.
Response Erstellt eine Antwort auf einen eingehenden Aufruf oder eine Anforderung.
Select Erstellt ein Array mit JSON-Objekten, indem Elemente aus einem anderen Array basierend auf der angegebenen Zuordnung transformiert werden.
Table Erstellt aus einem Array eine CSV- oder HTML-Tabelle.
Terminate Beendet einen aktiv ausgeführten Workflow.
Wait Hält Ihren Workflow für einen angegebenen Zeitraum bzw. bis zum angegebenen Zeitpunkt (Datum und Uhrzeit) an.
Workflow Schachtelt einen Workflow innerhalb eines anderen Workflows.

Aktionen mit verwalteter API

Aktionstyp BESCHREIBUNG
ApiConnection Ruft einen HTTP-Endpunkt auf, indem eine von Microsoft verwaltete API verwendet wird.
ApiConnectionWebhook Vergleichbar mit „HTTP Webhook“, aber es wird eine von Microsoft verwaltete API verwendet.

Aktionen zur Workflowsteuerung

Mit diesen Aktionen können Sie die Workflowausführung steuern und andere Aktionen einbinden. Von außerhalb einer Aktion zur Workflowsteuerung können Sie direkt auf Aktionen innerhalb der jeweiligen Aktion zur Workflowsteuerung verweisen. Wenn Sie beispielsweise eine Http-Aktion innerhalb eines Bereichs verwenden, können Sie von überall im Workflow aus auf den Ausdruck @body('Http') verweisen. Aktionen, die innerhalb einer Aktion zur Workflowsteuerung vorhanden sind, können nur nach anderen Aktionen ausgeführt werden, die sich in derselben Struktur für die Workflowsteuerung befinden.

Aktionstyp BESCHREIBUNG
ForEach Führt die gleichen Aktionen für jedes Element eines Arrays als Schleife aus.
If Führt Aktionen in Abhängigkeit davon aus, ob die angegebene Bedingung wahr oder falsch ist.
Scope Führt Aktionen basierend auf dem Gruppenstatus eines Satzes mit Aktionen aus.
Switch Führt Aktionen aus, die zu Fällen zusammengefasst sind, wenn Werte aus Ausdrücken, Objekten oder Token mit den für jeden Fall angegebenen Werten übereinstimmen.
Until Führt Aktionen in einer Schleife aus, bis die angegebene Bedingung wahr ist.

Aktionen – Detaillierte Referenz

APIConnection-Aktion

Diese Aktion sendet eine HTTP-Anforderung an eine von Microsoft verwaltete API. Hierfür sind Informationen zur API und zu den Parametern sowie ein Verweis auf eine gültige Verbindung erforderlich.

"<action-name>": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<api-name>']['connectionId']"
         },
         "<other-action-specific-input-properties>"        
      },
      "method": "<method-type>",
      "path": "/<api-operation>",
      "retryPolicy": "<retry-behavior>",
      "queries": { "<query-parameters>" },
      "<other-action-specific-properties>"
    },
    "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<action-name> String Name der vom Connector bereitgestellten Aktion
<api-name> String Name der von Microsoft verwalteten API, die für die Verbindung verwendet wird
<method-type> String HTTP-Methode zum Aufrufen der API: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<api-operation> String Aufzurufender API-Vorgang

Optional

Wert type BESCHREIBUNG
<other-action-specific-input-properties> JSON-Objekt Alle anderen Eingabeeigenschaften, die für die spezifische Aktion gelten
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<query-parameters> JSON-Objekt Alle Abfrageparameter, die in den API-Aufruf einbezogen werden sollen.

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
<other-action-specific-properties> JSON-Objekt Alle anderen Eigenschaften, die für die spezifische Aktion gelten

Beispiel

Mit dieser Definition wird die Aktion Send an email für den Office 365-Outlook-Connector beschrieben, bei dem es sich um eine von Microsoft verwaltete API handelt:

"Send_an_email": {
   "type": "ApiConnection",
   "inputs": {
      "body": {
         "Body": "Thank you for your membership!",
         "Subject": "Hello and welcome!",
         "To": "Sophie.Owen@contoso.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "POST",
      "path": "/Mail"
    },
    "runAfter": {}
}

APIConnectionWebhook-Aktion

Diese Aktion sendet eine Abonnementanforderung per HTTP an einen Endpunkt, indem eine von Microsoft verwaltete API verwendet wird, gibt eine Rückruf-URL an, an die der Endpunkt eine Antwort senden kann, und wartet auf die Antwort des Endpunkts. Weitere Informationen finden Sie unter Endpunktabonnements.

"<action-name>": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "subscribe": {
         "method": "<method-type>",
         "uri": "<api-subscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "retryPolicy": "<retry-behavior>",
         "queries": { "<query-parameters>" },
         "<other-action-specific-input-properties>"
      },
      "unsubscribe": {
         "method": "<method-type>",
         "uri": "<api-unsubscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "<other-action-specific-properties>"
      },
   },
   "runAfter": {}
}

Einige Werte, z.B. <method-type>, sind sowohl für das Objekt "subscribe" als auch für "unsubscribe" verfügbar.

Erforderlich

Wert type BESCHREIBUNG
<action-name> String Name der vom Connector bereitgestellten Aktion
<method-type> String HTTP-Methode zum Abonnieren oder Kündigen des Abonnements über einen Endpunkt: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
<api-subscribe-URL> String URI, der zum Abonnieren der API verwendet wird

Optional

Wert type BESCHREIBUNG
<api-unsubscribe-URL> String URI, der zum Kündigen des API-Abonnements verwendet wird
<header-content> JSON-Objekt Alle Kopfzeilen, die in der Anforderung gesendet werden sollen

Verwenden Sie beispielsweise Folgendes, um Sprache und Typ für eine Anforderung festzulegen:

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
<body-content> JSON-Objekt Beliebiger Nachrichteninhalt, der in der Anforderung gesendet wird
<authentication-type> JSON-Objekt Das Authentifizierungsmodell, das von der Anforderung zum Authentifizieren ausgehender Anforderungen verwendet wird. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung zu ausgehenden Aufrufen.
<retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<query-parameters> JSON-Objekt Alle Abfrageparameter, die in den API-Aufruf eingeschlossen werden sollen

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
<other-action-specific-input-properties> JSON-Objekt Alle anderen Eingabeeigenschaften, die für die spezifische Aktion gelten
<other-action-specific-properties> JSON-Objekt Alle anderen Eigenschaften, die für die spezifische Aktion gelten

Sie können auch Grenzwerte für eine ApiConnectionWebhook-Aktion angeben, wie Sie dies für asynchrone Grenzwerte für HTTP tun.

Compose-Aktion

Diese Aktion erstellt eine einzelne Ausgabe aus mehreren Eingaben, z.B. Ausdrücken. Sowohl die Ausgabe als auch die Eingaben können einen beliebigen Typ aufweisen, der von Azure Logic Apps nativ unterstützt wird, z.B. Arrays, JSON-Objekte, XML und Binärdateien. Sie können die Ausgabe der Aktion dann in anderen Aktionen verwenden.

"Compose": {
   "type": "Compose",
   "inputs": "<inputs-to-compose>",
   "runAfter": {}
},

Erforderlich

Wert type BESCHREIBUNG
<inputs-to-compose> Any Eingaben für die Erstellung einer einzelnen Ausgabe

Beispiel 1

Bei dieser Aktionsdefinition werden abcdefg mit einer nachgestellten Leerstelle und der Wert 1234 zusammengeführt:

"Compose": {
   "type": "Compose",
   "inputs": "abcdefg 1234",
   "runAfter": {}
},

Hier ist die Ausgabe angegeben, die mit dieser Aktion erstellt wird:

abcdefg 1234

Beispiel 2

Bei dieser Aktionsdefinition werden eine Zeichenfolgenvariable, die abcdefg enthält, und eine Integer-Variable zusammengeführt, die 1234 enthält:

"Compose": {
   "type": "Compose",
   "inputs": "@{variables('myString')}@{variables('myInteger')}",
   "runAfter": {}
},

Hier ist die Ausgabe angegeben, die mit dieser Aktion erstellt wird:

"abcdefg1234"

Aktion „JavaScript-Code ausführen“

Diese Aktion führt einen JavaScript-Codeausschnitt aus und gibt die Ergebnisse über ein Token zurück, auf das nachfolgende Aktionen im Workflow verweisen können.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "<JavaScript-code-snippet>",
      "explicitDependencies": {
         "actions": [ <preceding-actions> ],
         "includeTrigger": true
      }
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<JavaScript-Codeausschnitt> Varies Der JavaScript-Code, der ausgeführt werden soll. Codeanforderungen und weitere Informationen finden Sie unter Hinzufügen und Ausführen von Codeausschnitten mit Inlinecode in Azure Logic Apps.

Im code-Attribut kann Ihr Codeausschnitt das schreibgeschützte workflowContext-Objekt als Eingabe verwenden. Dieses Objekt weist untergeordnete Eigenschaften auf, die dem Code Zugriff auf die Ausgaben des Triggers und früherer Aktionen im Workflow gewähren. Weitere Informationen zum workflowContext-Objekt finden Sie unter Verweisen auf Ergebnisse von Triggern und Aktionen mithilfe des workflowContext-Objekts.

In einigen Fällen erforderlich

Das explicitDependencies-Attribut gibt an, dass die Ergebnisse des Triggers, Ergebnisse vorheriger Aktionen oder beides als Abhängigkeiten explizit für Ihren Codeausschnitt enthalten sein sollen. Weitere Informationen zum Hinzufügen dieser Abhängigkeiten finden Sie unter Hinzufügen von Abhängigkeiten als Parameter zu einer Inlinecodeaktion.

Für das includeTrigger-Attribut können Sie true- oder false-Werte angeben.

Wert type BESCHREIBUNG
<preceding-actions> Zeichenfolgenarray Ein Array mit den Aktionsnamen im JSON-Format als Abhängigkeiten. Verwenden Sie unbedingt die Aktionsnamen, die in Ihrer Workflowdefinition angezeigt werden, wobei Aktionsnamen Unterstriche (_) und keine Leerzeichen („ „) verwenden.

Beispiel 1

Diese Aktion führt Code aus, der den Namen Ihres Logik-App-Workflows abruft und den Text „Hello World from <Name der Logik-App>“ als Ergebnis zurückgibt. In diesem Beispiel verweist der Code auf den Namen des Workflows, indem mithilfe des schreibgeschützten workflowContext-Objekts auf die Eigenschaft workflowContext.workflow.name zugegriffen wird. Weitere Informationen zur Verwendung des workflowContext-Objekts finden Sie unter Reference trigger and action results in your code (Verweisen auf die Ergebnisse von Triggern und Aktionen in Ihrem Code).

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "var text = \"Hello world from \" + workflowContext.workflow.name;\r\n\r\nreturn text;"
   },
   "runAfter": {}
}

Beispiel 2

Diese Aktion führt Code in einem Logik-App-Workflow aus, die ausgelöst wird, wenn eine neue E-Mail in einem Outlook-Konto eingeht. Der Workflow verwendet auch die Office 365 Office-Aktion vom Typ Genehmigungs-E-Mail senden, die den Inhalt der empfangenen E-Mail zusammen mit einer Genehmigungsanforderung weiterleitet.

Der Code extrahiert die E-Mail-Adressen aus der Body-Eigenschaft der E-Mail-Nachricht und gibt die Adressen zusammen mit dem SelectedOption-Eigenschaftswert aus der Genehmigungsaktion zurück. Die Aktion schließt explizit die Aktion Genehmigungs-E-Mail senden als Abhängigkeit im actions-Objekt innerhalb des explicitDependencies-Objekts mit ein.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "var myResult = /(([^<>()\\[\\]\\\\.,;:\\s@\"]+(\\.[^<>()\\[\\]\\\\.,;:\\s@\"]+)*)|(\".+\"))@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}])|(([a-zA-Z\\-0-9]+\\.)+[a-zA-Z]{2,}))/g;\r\n\r\nvar email = workflowContext.trigger.outputs.body.Body;\r\n\r\nvar reply = workflowContext.actions.Send_approval_email.outputs.body.SelectedOption;\r\n\r\nreturn email.match(myResult) + \" - \" + reply;\r\n;",
      "explicitDependencies": {
         "actions": [
            "Send_approval_email"
         ]
      }
   },
   "runAfter": {}
}

Function-Aktion

Mit dieser Aktion wird eine zuvor erstellte Azure-Funktion aufgerufen.

"<Azure-function-name>": {
   "type": "Function",
   "inputs": {
     "function": {
        "id": "<Azure-function-ID>"
      },
      "method": "<method-type>",
      "headers": { "<header-content>" },
      "body": { "<body-content>" },
      "queries": { "<query-parameters>" } 
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<Azure-function-ID> String Die Ressourcen-ID für die Azure-Funktion, die Sie aufrufen möchten. Das Format für diesen Wert lautet wie folgt:

"/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Web/sites/<Azure-function-app-name>/functions/<Azure-function-name>"
<method-type> String Die HTTP-Methode, die zum Aufrufen der Funktion verwendet werden soll: "GET", "PUT", "POST", "PATCH" oder "DELETE"

Wenn nichts angegeben wird, wird standardmäßig die Methode „POST“ verwendet.

Optional

Wert type BESCHREIBUNG
<header-content> JSON-Objekt Alle Kopfzeilen, die mit dem Anruf gesendet werden sollen

Verwenden Sie beispielsweise Folgendes, um Sprache und Typ für eine Anforderung festzulegen:

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
<body-content> JSON-Objekt Beliebiger Nachrichteninhalt, der in der Anforderung gesendet wird
<query-parameters> JSON-Objekt Alle Abfrageparameter, die in den API-Aufruf eingeschlossen werden sollen

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
<other-action-specific-input-properties> JSON-Objekt Alle anderen Eingabeeigenschaften, die für die spezifische Aktion gelten
<other-action-specific-properties> JSON-Objekt Alle anderen Eigenschaften, die für die spezifische Aktion gelten

Beim Speichern Ihrer Logik-App führt die Logic Apps-Engine diese Überprüfungen der referenzierten Funktion durch:

  • Ihr Workflow muss auf die Funktion zugreifen können.

  • Ihr Workflow kann nur einen HTTP-Standardtrigger oder generischen JSON-Webhooktrigger verwenden.

    Die Logic Apps-Engine ruft die zur Laufzeit verwendete Trigger-URL ab und speichert sie zwischen. Sollte die zwischengespeicherte URL aufgrund eines Vorgangs ungültig werden, tritt bei der Aktion Function zur Laufzeit aber ein Fehler auf. Speichern Sie die Logik-App erneut, damit diese die Trigger-URL wieder abruft und zwischenspeichert, um dieses Problem zu beheben.

  • Für die Funktion kann keine Route definiert werden.

  • Als Autorisierungsebenen sind nur „function“ und „anonymous“ zulässig.

Beispiel

Mit dieser Aktionsdefinition wird die zuvor erstellte Funktion „GetProductID“ aufgerufen:

"GetProductID": {
   "type": "Function",
   "inputs": {
     "function": {
        "id": "/subscriptions/<XXXXXXXXXXXXXXXXXXXX>/resourceGroups/myLogicAppResourceGroup/providers/Microsoft.Web/sites/InventoryChecker/functions/GetProductID"
      },
      "method": "POST",
      "headers": { 
          "x-ms-date": "@utcnow()"
       },
      "body": { 
          "Product_ID": "@variables('ProductID')"
      }
   },
   "runAfter": {}
}

HTTP-Aktion

Diese Aktion sendet eine Anforderung an den angegebenen HTTP- oder HTTPS-Endpunkt und überprüft anhand der Antwort, ob der Workflow ausgeführt wird. Weitere Informationen finden Sie unter Aufrufen von Dienstendpunkten per HTTP oder HTTPS aus Azure Logic Apps.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<HTTP-or-HTTPS-endpoint-URL>",
      "headers": { "<header-content>" },
      "queries": { "<query-parameters>" },
      "body": "<body-content>",
      "authentication": { "<authentication-type-and-property-values>" },
      "retryPolicy": {
         "type": "<retry-behavior>"
      },
   },
   "runAfter": {}
}

Erforderlich

Eigenschaft Wert type BESCHREIBUNG
method <method-type> String Die zum Senden der ausgehenden Anforderung zu verwendende Methode: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
uri <HTTP-or-HTTPS-endpoint-URL> String Die HTTP- oder HTTPS-Endpunkt-URL, an die die ausgehende Anforderung gesendet werden soll. Maximale Zeichenfolgengröße: 2 KB

Für einen Azure-Dienst oder eine Azure-Ressource enthält diese URI-Syntax die Ressourcen-ID und den Pfad zu der Ressource, auf die Sie zugreifen möchten.

Optional

Eigenschaft Wert type BESCHREIBUNG
headers <header-content> JSON-Objekt Alle Header, die Sie in die Anforderung einschließen müssen

So legen Sie z. B. die Sprache und den Typ fest:

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries <query-parameters> JSON-Objekt Alle Abfrageparameter, die Sie in der Anforderung verwenden müssen

Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
body <body-content> JSON-Objekt Nachrichteninhalt, der als Nutzlast mit der Anforderung gesendet wird
authentication <authentication-type-and-property-values> JSON-Objekt Das Authentifizierungsmodell, das von der Anforderung zum Authentifizieren ausgehender Anforderungen verwendet wird. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung zu ausgehenden Aufrufen. Über den Scheduler hinaus wird die authority-Eigenschaft unterstützt. Ohne Angabe wird standardmäßig der Wert https://management.azure.com/ verwendet. Sie können aber einen anderen Wert verwenden.
retryPolicy > type <retry-behavior> JSON-Objekt Passt das Wiederholungsverhalten für vorübergehende Fehler, die über den Statuscode 408, 429 und 5XX verfügen, und alle Verbindungsausnahmen an. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
<other-action-specific-input-properties> <input-property> JSON-Objekt Alle anderen Eingabeeigenschaften, die für die spezifische Aktion gelten
<other-action-specific-properties> <property-value> JSON-Objekt Alle anderen Eigenschaften, die für die spezifische Aktion gelten

Beispiel

Mit dieser Aktionsdefinition werden die aktuellen Neuigkeiten abgerufen, indem eine Anforderung an den angegebenen Endpunkt gesendet werden:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest"
   }
}

Join-Aktion

Diese Aktion erstellt eine Zeichenfolge aus allen Elementen in einem Array und trennt diese Elemente mit dem angegebenen Trennzeichen.

"Join": {
   "type": "Join",
   "inputs": {
      "from": <array>,
      "joinWith": "<delimiter>"
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<array> Array Das Array oder der Ausdruck, mit dem die Quellelemente bereitgestellt werden. Setzen Sie diesen Ausdruck in doppelte Anführungszeichen, wenn Sie einen Ausdruck angeben.
<delimiter> Zeichenfolge mit nur einem Zeichen Das Zeichen, mit dem die Elemente in der Zeichenfolge getrennt werden

Beispiel

Angenommen, Sie verfügen über die zuvor erstellte Variable „myIntegerArray“, die dieses Integer-Array enthält:

[1,2,3,4]

Mit dieser Aktionsdefinition werden die Werte aus der Variablen abgerufen, indem die Funktion variables() in einem Ausdruck verwendet und die folgende Zeichenfolge mit per Komma getrennten Werten erstellt wird: "1,2,3,4"

"Join": {
   "type": "Join",
   "inputs": {
      "from": "@variables('myIntegerArray')",
      "joinWith": ","
   },
   "runAfter": {}
}

Aktion „Parse JSON“

Mit dieser Aktion werden benutzerfreundliche Felder oder Token aus den Eigenschaften im JSON-Inhalt erstellt. Sie können dann in Ihrer Logik-App auf diese Eigenschaften zugreifen, indem Sie stattdessen die Token verwenden. Wenn Sie beispielsweise die JSON-Ausgabe von Diensten verwenden möchten, z.B. Azure Service Bus und Azure Cosmos DB, können Sie diese Aktion in Ihre Logik-App einfügen, damit Sie einfacher auf die Daten in dieser Ausgabe verweisen können.

"Parse_JSON": {
   "type": "ParseJson",
   "inputs": {
      "content": "<JSON-source>",
         "schema": { "<JSON-schema>" }
      },
      "runAfter": {}
},

Erforderlich

Wert type BESCHREIBUNG
<JSON-source> JSON-Objekt JSON-Inhalt, den Sie analysieren möchten
<JSON-schema> JSON-Objekt JSON-Schema, mit dem der zugrunde liegende JSON-Inhalt beschrieben wird, der von der Aktion zum Analysieren des JSON-Quellinhalts verwendet wird.

Tipp: Im Logik-App-Designer können Sie das Schema bereitstellen oder eine Beispielnutzlast angeben, damit die Aktion das Schema generieren kann.

Beispiel

Mit dieser Aktionsdefinition werden diese Token erstellt, die Sie in Ihrem Workflow verwenden können. Dies gilt aber nur für Aktionen, die nach der Aktion Parse JSON ausgeführt werden:

FirstName, LastName und Email

"Parse_JSON": {
   "type": "ParseJson",
   "inputs": {
      "content": {
         "Member": {
            "Email": "Sophie.Owen@contoso.com",
            "FirstName": "Sophie",
            "LastName": "Owen"
         }
      },
      "schema": {
         "type": "object",
         "properties": {
            "Member": {
               "type": "object",
               "properties": {
                  "Email": {
                     "type": "string"
                  },
                  "FirstName": {
                     "type": "string"
                  },
                  "LastName": {
                     "type": "string"
                  }
               }
            }
         }
      }
   },
   "runAfter": { }
},

In diesem Beispiel gibt die „content“-Eigenschaft den JSON-Inhalt für die zu analysierende Aktion an. Sie können diesen JSON-Inhalt auch als Beispielnutzlast zum Generieren des Schemas angeben.

"content": {
   "Member": { 
      "FirstName": "Sophie",
      "LastName": "Owen",
      "Email": "Sophie.Owen@contoso.com"
   }
},

Mit der „schema“-Eigenschaft wird das JSON-Schema angegeben, das zum Beschreiben des JSON-Inhalts verwendet wird:

"schema": {
   "type": "object",
   "properties": {
      "Member": {
         "type": "object",
         "properties": {
            "FirstName": {
               "type": "string"
            },
            "LastName": {
               "type": "string"
            },
            "Email": {
               "type": "string"
            }
         }
      }
   }
}

Abfrageaktion

Mit dieser Aktion wird basierend auf einer angegebenen Bedingung oder einem Filter ein Array aus den Elementen eines anderen Arrays erstellt.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": <array>,
      "where": "<condition-or-filter>"
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<array> Array Das Array oder der Ausdruck, mit dem die Quellelemente bereitgestellt werden. Setzen Sie diesen Ausdruck in doppelte Anführungszeichen, wenn Sie einen Ausdruck angeben.
<condition-or-filter> String Die Bedingung zum Filtern von Elementen im Quellarray

Hinweis: Falls keine Werte die Bedingung erfüllen, erstellt die Aktion ein leeres Array.

Beispiel

Mit dieser Aktionsdefinition wird ein Array mit Werten erstellt, die größer als der angegebene Wert (2) sind:

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": [ 1, 3, 0, 5, 4, 2 ],
      "where": "@greater(item(), 2)"
   }
}

Antwortaktion

Mit dieser Aktion wird die Nutzlast für die Antwort auf eine HTTP-Anforderung erstellt.

"Response" {
    "type": "Response",
    "kind": "http",
    "inputs": {
        "statusCode": 200,
        "headers": { <response-headers> },
        "body": { <response-body> }
    },
    "runAfter": {}
},

Erforderlich

Wert type BESCHREIBUNG
<response-status-code> Integer Der HTTP-Statuscode, der an die eingehende Anforderung gesendet wird. Der Standardcode lautet „200 OK“, aber es kann ein beliebiger gültiger Statuscode sein, der mit 2xx, 4xx oder 5xx beginnt (aber nicht mit 3xxx).

Optional

Wert type BESCHREIBUNG
<response-headers> JSON-Objekt Einer oder mehrere Header, die in die Antwort eingefügt werden sollen
<response-body> Verschiedene Antworttext, bei dem es sich um eine Zeichenfolge, ein JSON-Objekt oder auch Binärinhalt aus einer vorherigen Aktion handelt

Beispiel

Mit dieser Aktionsdefinition wird eine Antwort auf eine HTTP-Anforderung mit dem angegebenen Statuscode, Nachrichtentext und den Nachrichtenheadern erstellt:

"Response": {
   "type": "Response",
   "inputs": {
      "statusCode": 200,
      "body": {
         "ProductID": 0,
         "Description": "Organic Apples"
      },
      "headers": {
         "x-ms-date": "@utcnow()",
         "content-type": "application/json"
      }
   },
   "runAfter": {}
}

Einschränkungen

Im Gegensatz zu anderen Aktionen verfügt die Aktion Response über spezielle Einschränkungen:

  • Ihr Workflow kann die Aktion Response nur verwenden, wenn der Workflow mit einem HTTP-Anforderungstrigger beginnt. Dies bedeutet, dass Ihr Workflow von einer HTTP-Anforderung ausgelöst werden muss.

  • Ihr Workflow kann die Aktion Response überall verwenden, mit Ausnahme innerhalb von Foreach-Schleifen, Until-Schleifen, z.B. sequenziellen Schleifen, und parallelen Branches.

  • Die ursprüngliche Anforderung ruft die Antwort Ihres Workflows nur ab, wenn alle für die Aktion Response erforderlichen Aktionen innerhalb des HTTP-Timeoutlimits beendet wurden.

    Wenn Ihr Workflow aber eine andere Logik-App als geschachtelten Workflow aufruft, wartet der übergeordnete Workflow, bis der geschachtelte Workflow abgeschlossen ist. Hierbei spielt es keine Rolle, wie viel Zeit vergeht, bis der geschachtelte Workflow abgeschlossen ist.

  • Wenn für Ihren Workflow die Aktion Response und ein synchrones Antwortmuster verwendet werden, kann der Workflow auch den Befehl splitOn nicht in der Triggerdefinition verwenden, da mit diesem Befehl mehrere Ausführungen erstellt werden. Achten Sie bei Verwendung der PUT-Methode auf diesen Fall, und sorgen Sie dafür, dass eine Antwort vom Typ „Fehlerhafte Anforderung“ zurückgegeben wird.

    Wenn für Ihren Workflow dagegen der Befehl splitOn und die Aktion Response verwendet werden, wird der Workflow asynchron ausgeführt, und es wird sofort die Antwort „202 AKZEPTIERT“ zurückgegeben.

  • Wenn die Ausführung Ihres Workflows die Aktion Response erreicht, aber die eingehende Anforderung bereits eine Antwort erhalten hat, wird die Aktion Response aufgrund des Konflikts als „Failed“ (Fehler) gekennzeichnet. Ihre Logik-App-Ausführung erhält somit ebenfalls den Status „Failed“.

Aktion select

Diese Aktion erstellt ein Array mit JSON-Objekten, indem Elemente aus einem anderen Array basierend auf der angegebenen Zuordnung transformiert werden. Das Ausgabearray und das Quellarray verfügen immer über die gleiche Anzahl von Elementen. Sie können zwar nicht die Anzahl von Objekten im Ausgabearray ändern, aber Sie können Eigenschaften und die zugehörigen Werte für diese Objekte hinzufügen oder entfernen. Mit der select-Eigenschaft wird mindestens ein Schlüssel-Wert-Paar angegeben, mit dem die Zuordnung zum Transformieren von Elementen im Quellarray definiert wird. Ein Schlüssel-Wert-Paar steht für eine Eigenschaft und den zugehörigen Wert für alle Objekte im Ausgabearray.

"Select": {
   "type": "Select",
   "inputs": {
      "from": <array>,
      "select": { 
          "<key-name>": "<expression>",
          "<key-name>": "<expression>"        
      }
   },
   "runAfter": {}
},

Erforderlich

Wert type BESCHREIBUNG
<array> Array Das Array oder der Ausdruck, mit dem die Quellelemente bereitgestellt werden. Stellen Sie sicher, dass Sie einen Ausdruck in doppelte Anführungszeichen setzen.

Hinweis: Wenn das Quellarray leer ist, wird mit der Aktion ein leeres Array erstellt.
<key-name> String Der Eigenschaftsname, der dem Ergebnis über <expression> zugewiesen wird

Geben Sie einen Schlüsselnamen (<key-name>) für diese Eigenschaft und einen Ausdruck (<expression>) für den Eigenschaftswert an, um für alle Objekte im Ausgabearray eine neue Eigenschaft hinzuzufügen.

Lassen Sie <key-name> für diese Eigenschaft weg, um eine Eigenschaft aus allen Objekten im Array zu entfernen.
<expression> String Ausdruck, mit dem das Element im Quellarray transformiert und das Ergebnis <key-name> zugewiesen wird

Mit der Aktion Select wird ein Array als Ausgabe erstellt. Alle Aktionen, für die diese Ausgabe verwendet werden soll, müssen also entweder ein Array akzeptieren, oder Sie müssen das Array in den Typ konvertieren, der von der Consumeraktion akzeptiert wird. Um beispielsweise das Ausgabearray in eine Zeichenfolge zu konvertieren, können Sie dieses Array an die Aktion Compose übergeben und dann über die Aktion Compose in Ihren anderen Aktionen auf die Ausgabe verweisen.

Beispiel

Mit dieser Aktionsdefinition wird ein JSON-Objektarray aus einem Integer-Array erstellt. Die Aktion durchläuft das Quellarray, ruft die einzelnen ganzzahligen Werte ab, indem der Ausdruck @item() verwendet wird, und weist jeden Wert der Eigenschaft „number“ in den einzelnen JSON-Objekten zu:

"Select": {
   "type": "Select",
   "inputs": {
      "from": [ 1, 2, 3 ],
      "select": { 
         "number": "@item()" 
      }
   },
   "runAfter": {}
},

Hier sehen Sie das Array, das mit dieser Aktion erstellt wird:

[ { "number": 1 }, { "number": 2 }, { "number": 3 } ]

Übergeben Sie diese Ausgabe in eine Compose-Aktion, um die Arrayausgabe in anderen Aktionen zu verwenden:

"Compose": {
   "type": "Compose",
   "inputs": "@body('Select')",
   "runAfter": {
      "Select": [ "Succeeded" ]
   }
},

Sie können dann die Ausgabe der Aktion Compose in Ihren anderen Aktionen verwenden, z.B. der Aktion Office 365 Outlook – Send an email:

"Send_an_email": {
   "type": "ApiConnection",
   "inputs": {
      "body": {
         "Body": "@{outputs('Compose')}",
         "Subject": "Output array from Select and Compose actions",
         "To": "<your-email@domain>"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/Mail"
   },
   "runAfter": {
      "Compose": [ "Succeeded" ]
   }
},

Aktion table

Mit dieser Aktion wird aus einer CSV- oder HTML-Tabelle ein Array erstellt. Für Arrays mit JSON-Objekten erstellt diese Aktion aus den Eigenschaftennamen der Objekte automatisch die Spaltenüberschriften. Für Arrays mit anderen Datentypen müssen Sie die Spaltenüberschriften und -werte angeben. Dieses Array enthält beispielsweise die Eigenschaften „ID“ und „Product_Name“, die von dieser Aktion für die Namen von Spaltenüberschriften verwendet werden können:

[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]

"Create_<CSV | HTML>_table": {
   "type": "Table",
   "inputs": {
      "format": "<CSV | HTML>",
      "from": <array>,
      "columns": [ 
         {
            "header": "<column-name>",
            "value": "<column-value>"
         },
         {
            "header": "<column-name>",
            "value": "<column-value>"
         } 
      ]
   },
   "runAfter": {}
}

Erforderlich

Wert type Beschreibung
<CSV oder HTML> String Format für die Tabelle, die Sie erstellen möchten
<array> Array Das Array oder der Ausdruck, das die Quellelemente für die Tabelle bereitstellt

Hinweis: Wenn das Quellarray leer ist, wird mit der Aktion eine leere Tabelle erstellt.

Optional

Verwenden Sie das Array columns, um Spaltenüberschriften und -werte anzugeben bzw. anzupassen. Wenn header-value-Paare über den gleichen Überschriftennamen verfügen, werden die Werte in derselben Spalte unter diesem Überschriftennamen angezeigt. Andernfalls wird mit jedem eindeutigen Header eine eindeutige Spalte definiert.

Wert type BESCHREIBUNG
<column-name> String Headername für eine Spalte
<column-value> Any Wert in dieser Spalte

Beispiel 1

Angenommen, Sie verfügen über die zuvor erstellte Variable „myItemArray“, die derzeit dieses Array enthält:

[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]

Mit dieser Aktionsdefinition wird eine CSV-Tabelle aus der Variablen „myItemArray“ erstellt. Der von der from-Eigenschaft verwendete Ausdruck ruft das Array aus „myItemArray“ ab, indem die Funktion variables() verwendet wird:

"Create_CSV_table": {
   "type": "Table",
   "inputs": {
      "format": "CSV",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Hier ist die CSV-Tabelle angegeben, die mit dieser Aktion erstellt wird:

ID,Product_Name 
0,Apples 
1,Oranges

Beispiel 2

Mit dieser Aktionsdefinition wird eine HTML-Tabelle aus der Variablen „myItemArray“ erstellt. Der von der from-Eigenschaft verwendete Ausdruck ruft das Array aus „myItemArray“ ab, indem die Funktion variables() verwendet wird:

"Create_HTML_table": {
   "type": "Table",
   "inputs": {
      "format": "HTML",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Hier ist die HTML-Tabelle angegeben, die mit dieser Aktion erstellt wird:

idProduct_Name
0Äpfel
1Oranges

Beispiel 3

Mit dieser Aktionsdefinition wird eine HTML-Tabelle aus der Variablen „myItemArray“ erstellt. In diesem Beispiel werden die Standardnamen der Spaltenüberschriften aber durch „Stock_ID“ und „Description“ überschrieben, und in der Spalte „Description“ wird den Werten das Wort „Organic“ hinzugefügt.

"Create_HTML_table": {
   "type": "Table",
   "inputs": {
      "format": "HTML",
      "from": "@variables('myItemArray')",
      "columns": [ 
         {
            "header": "Stock_ID",
            "value": "@item().ID"
         },
         {
            "header": "Description",
            "value": "@concat('Organic ', item().Product_Name)"
         }
      ]
    },
   "runAfter": {}
},

Hier ist die HTML-Tabelle angegeben, die mit dieser Aktion erstellt wird:

Stock_IDBESCHREIBUNG
0Organic Apples
1Organic Oranges

Terminate-Aktion

Mit dieser Aktion wird die Ausführung für eine Workflowinstanz beendet, alle aktiven Aktionen werden abgebrochen, alle verbleibenden Aktionen werden übersprungen und der angegebene Status wird zurückgegeben. Sie können die Terminate-Aktion beispielsweise verwenden, wenn Ihre Logik-App nach einem Fehlerzustand vollständig beendet werden muss. Diese Aktion wirkt sich nicht auf bereits abgeschlossene Aktionen aus und kann nicht in Foreach- und Until-Schleifen, einschließlich sequenziellen Schleifen, enthalten sein.

"Terminate": {
   "type": "Terminate",
   "inputs": {
       "runStatus": "<status>",
       "runError": {
            "code": "<error-code-or-name>",
            "message": "<error-message>"
       }
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<status> String Der zurückzugebende Status für die Ausführung: „Failed“, „Cancelled“, „Succeeded“

Optional

Die Eigenschaften für das Objekt „runStatus“ gelten nur, wenn die „runStatus“-Eigenschaft auf den Status „Failed“ festgelegt ist.

Wert type BESCHREIBUNG
<error-code-or-name> String Code oder Name für den Fehler
<error-message> String Nachricht oder Text, mit der bzw. dem der Fehler und alle Aktionen beschrieben werden, die vom Benutzer durchgeführt werden können

Beispiel

Mit dieser Aktion wird eine Workflowausführung beendet und der Status der Ausführung auf „Failed“ festgelegt, und außerdem werden der Status, ein Fehlercode und eine Fehlermeldung zurückgegeben:

"Terminate": {
    "type": "Terminate",
    "inputs": {
        "runStatus": "Failed",
        "runError": {
            "code": "Unexpected response",
            "message": "The service received an unexpected response. Please try again."
        }
   },
   "runAfter": {}
}

Wait-Aktion

Mit dieser Aktion wird die Workflowausführung für den angegebenen Zeitraum oder bis zum angegebenen Zeitpunkt (aber nicht beides) unterbrochen.

Angegebener Zeitraum

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": <number-of-units>,
         "unit": "<interval>"
      }
   },
   "runAfter": {}
},

Angegebener Zeitpunkt

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "<date-time-stamp>"
      }
   },
   "runAfter": {}
},

Erforderlich

Wert type BESCHREIBUNG
<number-of-units> Integer Für die Aktion Delay die Anzahl von Zeiteinheiten für die Wartedauer
<interval> String Das zu wartende Intervall für die Aktion Delay: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
<date-time-stamp> String Für die Aktion Delay Until das Datum und die Uhrzeit zum Fortsetzen der Ausführung. Für diesen Wert muss das UTC-Format für Datum und Uhrzeit verwendet werden.

Beispiel 1

Mit dieser Aktionsdefinition wird der Workflow 15 Minuten lang angehalten:

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": 15,
         "unit": "Minute"
      }
   },
   "runAfter": {}
},

Beispiel 2

Mit dieser Aktionsdefinition wird der Workflow bis zum angegebenen Zeitpunkt angehalten:

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "2017-10-01T00:00:00Z"
      }
   },
   "runAfter": {}
},

Workflow-Aktion

Mit dieser Aktion wird eine andere zuvor erstellte Logik-App aufgerufen. Dies bedeutet, dass Sie andere Logik-App-Workflows einfügen und wiederverwenden können. Sie können auch die Ausgaben aus der untergeordneten oder geschachtelten Logik-App in Aktionen verwenden, die auf die geschachtelte Logik-App folgen, solange die untergeordnete Logik-App eine Antwort zurückgibt.

Die Logic Apps-Engine überprüft den Zugriff auf den Trigger, den Sie aufrufen möchten. Stellen Sie also sicher, dass Sie auf diesen Trigger zugreifen können. Darüber hinaus muss die geschachtelte Logik-App die folgenden Kriterien erfüllen:

  • Ein Trigger macht die geschachtelte Logik-App aufrufbar, z.B. ein Anforderungstrigger oder HTTP-Trigger.

  • Es wird dasselbe Azure-Abonnement wie für Ihre übergeordnete Logik-App verwendet.

  • Die geschachtelte Logik-App muss über eine Response-Aktion verfügen, damit die Ausgaben der geschachtelten Logik-App in Ihrer übergeordneten Logik-App verwendet werden können.

"<nested-logic-app-name>": {
   "type": "Workflow",
   "inputs": {
      "body": { "<body-content" },
      "headers": { "<header-content>" },
      "host": {
         "triggerName": "<trigger-name>",
         "workflow": {
            "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Logic/<nested-logic-app-name>"
         }
      }
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<nested-logic-app-name> String Name für die Logik-App, die Sie aufrufen möchten
<trigger-name> String Name für den Trigger in der geschachtelten Logik-App, die Sie aufrufen möchten
<Azure-subscription-ID> String Azure-Abonnement-ID für die geschachtelte Logik-App
<Azure-resource-group> String Name der Azure-Ressourcengruppe für die geschachtelte Logik-App

Optional

Wert type BESCHREIBUNG
<header-content> JSON-Objekt Alle Header, die mit dem Aufruf gesendet werden sollen
<body-content> JSON-Objekt Beliebiger Nachrichteninhalt, der mit dem Aufruf gesendet werden soll

Ausgaben

Die Ausgaben dieser Aktion variieren je nach der Aktion „Response“ der geschachtelten Logik-App. Falls die geschachtelte Logik-App keine Aktion „Response“ enthält, sind die Ausgaben leer.

Beispiel

Nachdem die Aktion „Start_search“ erfolgreich abgeschlossen wurde, wird mit dieser Workflow-Aktionsdefinition eine andere Logik-App mit dem Namen „Get_product_information“ aufgerufen, mit der die angegebenen Eingaben übergeben werden:

"actions": {
   "Start_search": { <action-definition> },
   "Get_product_information": {
      "type": "Workflow",
      "inputs": {
         "body": {
            "ProductID": "24601",
         },
         "host": {
            "id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/InventoryManager-RG/providers/Microsoft.Logic/Get_product_information",
            "triggerName": "Find_product"
         },
         "headers": {
            "content-type": "application/json"
         }
      },
      "runAfter": { 
         "Start_search": [ "Succeeded" ]
      }
   }
},

Details zu den Aktionen zur Steuerung des Workflows

ForEach-Aktion

Diese Schleifenaktion durchläuft ein Array und führt Aktionen für die einzelnen Arrayelemente aus. Standardmäßig wird die „for each“-Schleife bis zu einer maximalen Schleifenanzahl parallel ausgeführt. Informationen zu dieser maximalen Anzahl finden Sie unter Grenzwerte und Konfiguration. Informieren Sie sich darüber, wie Sie „for each“-Schleifen erstellen.

"For_each": {
   "type": "Foreach",
   "actions": { 
      "<action-1>": { "<action-definition-1>" },
      "<action-2>": { "<action-definition-2>" }
   },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": <count>
      }
    },
    "operationOptions": "<operation-option>"
}

Erforderlich

Wert type BESCHREIBUNG
<action-1...n> String Namen der Aktionen, die für jedes Arrayelement ausgeführt werden
<action-definition-1...n> JSON-Objekt Definitionen der ausgeführten Aktionen
<for-each-expression> String Ausdruck, mit dem im angegebenen Array auf die einzelnen Elemente verwiesen wird

Optional

Wert type BESCHREIBUNG
<count> Integer Standardmäßig werden die Iterationen für „for each“-Schleifen gleichzeitig (oder parallel) ausgeführt, bis das Standardlimit erreicht ist. Informationen dazu, wie Sie dieses Limit ändern, indem Sie einen neuen <count>-Wert festlegen, finden Sie unter Ändern der Parallelität von „for each“-Schleifen.
<operation-option> String Wenn Sie eine „for each“-Schleife nicht parallel, sondern sequenziell durchführen möchten, legen Sie entweder <operation-option> auf Sequential oder <count> auf 1 fest (aber nicht beides). Weitere Informationen finden Sie unter Sequenzielles Ausführen von „for each“-Schleifen.

Beispiel

Diese „for each“-Schleife sendet eine E-Mail für jedes Element des Arrays, das Anlagen einer eingehenden E-Mail enthält. Die Schleife sendet eine E-Mail, einschließlich Anlage, an eine Person, die die Anlage überprüft.

"For_each": {
   "type": "Foreach",
   "actions": {
      "Send_an_email": {
         "type": "ApiConnection",
         "inputs": {
            "body": {
               "Body": "@base64ToString(items('For_each')?['Content'])",
               "Subject": "Review attachment",
               "To": "Sophie.Owen@contoso.com"
                },
            "host": {
               "connection": {
                  "id": "@parameters('$connections')['office365']['connectionId']"
               }
            },
            "method": "post",
            "path": "/Mail"
         },
         "runAfter": {}
      }
   },
   "foreach": "@triggerBody()?['Attachments']",
   "runAfter": {}
}

Um nur ein Array anzugeben, das als Ausgabe des Triggers übergeben wird, ruft dieser Ausdruck das Array <array-name> aus dem Triggertext ab. Im Ausdruck wird der Operator ? verwendet, um einen Ausfall zu vermeiden, falls das Array nicht vorhanden ist:

@triggerBody()?['<array-name>']

If-Aktion

Mit dieser Aktion, bei der es sich um eine bedingte Anweisung handelt, wird ein Ausdruck ausgewertet. Dieser stellt eine Bedingung dar und führt in Abhängigkeit davon, ob die Bedingung wahr oder falsch ist, jeweils eine andere Branch aus. Wenn die Bedingung wahr ist, erhält die Bedingung den Status „Succeeded“. Informieren Sie sich darüber, wie Sie bedingte Anweisungen erstellen.

"Condition": {
   "type": "If",
   "expression": { "<condition>" },
   "actions": {
      "<action-1>": { "<action-definition>" }
   },
   "else": {
      "actions": {
        "<action-2>": { "<action-definition" }
      }
   },
   "runAfter": {}
}
Wert type BESCHREIBUNG
<condition> JSON-Objekt Auszuwertende Bedingung, bei der es sich auch um einen Ausdruck handeln kann
<action-1> JSON-Objekt Aktion, die ausgeführt werden soll, wenn <condition> als „true“ ausgewertet wird
<action-definition> JSON-Objekt Definition für die Aktion
<action-2> JSON-Objekt Aktion, die ausgeführt werden soll, wenn <condition> als „false“ ausgewertet wird

Die Aktionen in den Objekten actions oder else erhalten die folgenden Status:

  • „Erfolgreich“, wenn sie erfolgreich ausgeführt wurden
  • „Fehlerhaft“, wenn sie nicht erfolgreich ausgeführt wurden
  • „Übersprungen“, wenn die entsprechende Verzweigung nicht ausgeführt wird

Beispiel

Mit dieser Bedingung wird angegeben, dass der Workflow eine Website überprüft, wenn der Wert der Integer-Variable größer als null ist. Wenn die Variable null oder kleiner ist, überprüft der Workflow eine andere Website.

"Condition": {
   "type": "If",
   "expression": {
      "and": [ {
         "greater": [ "@variables('myIntegerVariable')", 0 ] 
      } ]
   },
   "actions": { 
      "HTTP - Check this website": {
         "type": "Http",
         "inputs": {
         "method": "GET",
            "uri": "http://this-url"
         },
         "runAfter": {}
      }
   },
   "else": {
      "actions": {
         "HTTP - Check this other website": {
            "type": "Http",
            "inputs": {
               "method": "GET",
               "uri": "http://this-other-url"
            },
            "runAfter": {}
         }
      }
   },
   "runAfter": {}
}

Verwendung von Ausdrücken durch Bedingungen

Die folgenden Beispiele veranschaulichen die Verwendung von Ausdrücken in Bedingungen:

JSON Ergebnis
"expression": "@parameters('<hasSpecialAction>')" Ausschließlich für boolesche Ausdrücke wird die Bedingung für alle Werte übergeben, die als „true“ ausgewertet werden.

Andere Typen können mithilfe der Funktion empty() oder equals() in boolesche Werte konvertiert werden.
"expression": "@greater(actions('<action>').output.value, parameters('<threshold>'))" Für Vergleichsfunktionen wird die Aktion nur ausgeführt, wenn die Ausgabe von <action> größer als der <threshold>-Wert ist.
"expression": "@or(greater(actions('<action>').output.value, parameters('<threshold>')), less(actions('<same-action>').output.value, 100))" Für Logikfunktionen und die Erstellung von geschachtelten booleschen Ausdrücken wird die Aktion ausgeführt, wenn die Ausgabe von <action> größer als der <threshold>-Wert bzw. kleiner als 100 ist.
"expression": "@equals(length(actions('<action>').outputs.errors), 0))" Sie können Arrayfunktionen verwenden, um zu überprüfen, ob das Array über Elemente verfügt. Die Aktion wird ausgeführt, wenn das Array errors leer ist.

Scope-Aktion

Mit dieser Aktion werden Aktionen logisch zu Bereichen (Scopes) gruppiert, die einen eigenen Status erhalten, nachdem die Ausführung der Aktionen in diesem Bereich beendet ist. Sie können den Status des Bereichs dann verwenden, um zu ermitteln, ob andere Aktionen ausgeführt werden. Informieren Sie sich darüber, wie Sie Bereiche erstellen.

"Scope": {
   "type": "Scope",
   "actions": {
      "<inner-action-1>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      },
      "<inner-action-2>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      }
   }
}

Erforderlich

Wert type BESCHREIBUNG
<inner-action-1...n> JSON-Objekt Eine oder mehrere Aktionen, die innerhalb des Bereichs ausgeführt werden
<action-inputs> JSON-Objekt Eingaben für jede Aktion

Switch-Aktion

Mit dieser Aktion, die auch als switch-Anweisung bezeichnet wird, werden andere Aktionen als Fälle organisiert. Jedem Fall, mit Ausnahme des Standardfalls (sofern vorhanden), wird ein Wert zugewiesen. Wenn Ihr Workflow ausgeführt wird, vergleicht die Aktion Switch den Wert eines Ausdrucks, Objekts oder Tokens mit den Werten, die für jeden Fall angegeben wurden. Falls die Aktion Switch einen übereinstimmenden Fall findet, führt Ihr Workflow nur die Aktionen für diesen Fall aus. Bei jeder Ausführung der Aktion Switch ist entweder nur ein übereinstimmender Fall vorhanden, oder es sind keine Übereinstimmungen vorhanden. Falls keine Übereinstimmungen vorhanden sind, werden mit der Aktion Switch die Standardaktionen ausgeführt. Erfahren Sie, wie Sie switch-Anweisungen erstellen.

"Switch": {
   "type": "Switch",
   "expression": "<expression-object-or-token>",
   "cases": {
      "Case": {
         "actions": {
           "<action-name>": { "<action-definition>" }
         },
         "case": "<matching-value>"
      },
      "Case_2": {
         "actions": {
           "<action-name>": { "<action-definition>" }
         },
         "case": "<matching-value>"
      }
   },
   "default": {
      "actions": {
         "<default-action-name>": { "<default-action-definition>" }
      }
   },
   "runAfter": {}
}

Erforderlich

Wert type BESCHREIBUNG
<expression-object-or-token> Varies Ausdruck, JSON-Objekt oder Token für die Auswertung
<action-name> String Name der Aktion, die für den übereinstimmenden Fall ausgeführt werden soll
<action-definition> JSON-Objekt Definition für die Aktion, die für den übereinstimmenden Fall ausgeführt werden soll
<matching-value> Varies Wert, der mit dem Auswertungsergebnis verglichen werden soll

Optional

Wert type BESCHREIBUNG
<default-action-name> String Name der Standardaktion, die ausgeführt wird, wenn keine übereinstimmenden Fälle vorhanden sind
<default-action-definition> JSON-Objekt Definition für die Aktion, die ausgeführt wird, wenn kein übereinstimmender Fall vorhanden ist

Beispiel

Mit dieser Aktionsdefinition wird ausgewertet, ob die Person, die auf die E-Mail mit der Genehmigungsanforderung die Option „Approve“ (Genehmigen) oder „Reject“ (Ablehnen) ausgewählt hat. Basierend auf dieser Auswahl führt die Switch-Aktion die Aktionen für den übereinstimmenden Fall aus. Hierbei geht es um das Senden einer weiteren E-Mail an die antwortende Stelle, die aber jedes Mal einen anderen Text enthält.

"Switch": {
   "type": "Switch",
   "expression": "@body('Send_approval_email')?['SelectedOption']",
   "cases": {
      "Case": {
         "actions": {
            "Send_an_email": { 
               "type": "ApiConnection",
               "inputs": {
                  "Body": "Thank you for your approval.",
                  "Subject": "Response received", 
                  "To": "Sophie.Owen@contoso.com"
               },
               "host": {
                  "connection": {
                     "name": "@parameters('$connections')['office365']['connectionId']"
                  }
               },
               "method": "post",
               "path": "/Mail"
            },
            "runAfter": {}
         },
         "case": "Approve"
      },
      "Case_2": {
         "actions": {
            "Send_an_email_2": { 
               "type": "ApiConnection",
               "inputs": {
                  "Body": "Thank you for your response.",
                  "Subject": "Response received", 
                  "To": "Sophie.Owen@contoso.com"
               },
               "host": {
                  "connection": {
                     "name": "@parameters('$connections')['office365']['connectionId']"
                  }
               },
               "method": "post",
               "path": "/Mail"
            },
            "runAfter": {}     
         },
         "case": "Reject"
      }
   },
   "default": {
      "actions": { 
         "Send_an_email_3": { 
            "type": "ApiConnection",
            "inputs": {
               "Body": "Please respond with either 'Approve' or 'Reject'.",
               "Subject": "Please respond", 
               "To": "Sophie.Owen@contoso.com"
            },
            "host": {
               "connection": {
                  "name": "@parameters('$connections')['office365']['connectionId']"
               }
            },
            "method": "post",
            "path": "/Mail"
         },
         "runAfter": {} 
      }
   },
   "runAfter": {
      "Send_approval_email": [ 
         "Succeeded"
      ]
   }
}

Until-Aktion

Diese Schleifenaktion enthält Aktionen, die so lange ausgeführt werden, bis die angegebene Bedingung „true“ ist. Mit der Schleife wird die Bedingung als letzter Schritt überprüft, nachdem alle anderen Aktionen ausgeführt wurden. Sie können mehr als eine Aktion in das "actions"-Objekt einfügen, und mit der Aktion muss mindestens ein Limit definiert werden. Erfahren Sie, wie Sie „until“-Schleifen erstellen.

 "Until": {
   "type": "Until",
   "actions": {
      "<action-name>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      },
      "<action-name>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      }
   },
   "expression": "<condition>",
   "limit": {
      "count": <loop-count>,
      "timeout": "<loop-timeout>"
   },
   "runAfter": {}
}
Wert type BESCHREIBUNG
<action-name> String Name für die Aktion, die Sie in der Schleife ausführen möchten
<action-type> String Aktionstyp, den Sie ausführen möchten
<action-inputs> Verschiedene Eingaben für die auszuführende Aktion
<condition> String Die Bedingung oder der Wert, die bzw. der ausgewertet wird, nachdem die Ausführung aller Aktionen der Schleife beendet ist
<loop-count> Integer Der Grenzwert für die maximale Anzahl von Schleifen, die von der Aktion ausgeführt werden können. Weitere Informationen zum Standardgrenzwert und Maximalgrenzwert finden Sie unter Grenzwerte und Konfiguration für Azure Logic Apps.
<loop-timeout> String Der Grenzwert für längste Ausführungsdauer, die für die Schleife möglich ist. Der Standardwert für timeout lautet PT1H. Dies ist das erforderliche ISO 8601-Format.

Hinweis

Wenn der Ausdruck von der Ausgabe einer Aktion innerhalb der Until-Schleife abhängig ist, stellen Sie sicher, dass Sie alle Fehler berücksichtigen, die aus dieser Aktion resultieren.

Beispiel

Mit dieser Schleifenaktionsdefinition wird eine HTTP-Anforderung an die angegebene URL gesendet, bis eine dieser Bedingungen erfüllt ist:

  • Die Anforderung erhält eine Antwort mit dem Statuscode „200 OK“.
  • Die Schleife wurde sechzig Mal ausgeführt.
  • Die Schleife wurde eine Stunde lang ausgeführt.
 "Run_until_loop_succeeds_or_expires": {
    "type": "Until",
    "actions": {
        "HTTP": {
            "type": "Http",
            "inputs": {
                "method": "GET",
                "uri": "http://myurl"
            },
            "runAfter": {}
        }
    },
    "expression": "@equals(outputs('HTTP')['statusCode'], 200)",
    "limit": {
        "count": 60,
        "timeout": "PT1H"
    },
    "runAfter": {}
}

Webhooks und Abonnements

Webhook-basierte Trigger und Aktionen führen keine regelmäßigen Überprüfungen von Endpunkten durch, sondern warten stattdessen auf bestimmte Ereignisse oder Daten an diesen Endpunkten. Diese Trigger und Aktionen abonnieren die Endpunkte, indem sie eine Rückruf-URL bereitstellen, an die der Endpunkt Antworten senden kann.

Der subscribe-Aufruf wird bei jeder Veränderung des Workflows ausgeführt (beispielsweise bei einer Erneuerung der Anmeldeinformationen oder bei einer Änderung der Eingabeparameter für einen Trigger oder eine Aktion). Für diesen Aufruf werden die gleichen Parameter wie bei HTTP-Standardaktionen verwendet.

Der unsubscribe-Aufruf erfolgt automatisch, wenn ein Vorgang dazu führt, dass der Trigger oder die Aktion ungültig wird, z.B.:

  • Löschen oder Deaktivieren des Triggers
  • Löschen oder Deaktivieren des Workflows
  • Löschen oder Deaktivieren des Abonnements

Zur Unterstützung dieser Aufrufe gibt der @listCallbackUrl()-Ausdruck eine eindeutige „Rückruf-URL“ für den Trigger oder die Aktion zurück. Diese URL stellt einen eindeutigen Bezeichner für die Endpunkte dar, die die REST-API des Diensts verwenden. Die Parameter für diese Funktion entsprechen denen des Webhook-Triggers bzw. der -Aktion.

Ändern der asynchronen Dauer

Sowohl für Trigger als auch für Aktionen können Sie die Dauer für das asynchrone Muster auf ein bestimmtes Zeitintervall begrenzen, indem Sie die limit.timeout-Eigenschaft hinzufügen. Auf diese Weise wird der Status der Aktion als Cancelled mit dem Code ActionTimedOut gekennzeichnet, falls die Aktion nach Ablauf des Intervalls noch nicht beendet war. Für die timeout-Eigenschaft wird das ISO 8601-Format verwendet.

"<trigger-or-action-name>": {
   "type": "Workflow | Webhook | Http | ApiConnectionWebhook | ApiConnection",
   "inputs": {},
   "limit": {
      "timeout": "PT10S"
   },
   "runAfter": {}
}

Einstellungen für Laufzeitkonfiguration

Sie können das Standardlaufzeitverhalten für Trigger und Aktionen ändern, indem Sie diese runtimeConfiguration-Eigenschaften in der Trigger- oder Aktionsdefinition hinzufügen.

Eigenschaft Type BESCHREIBUNG Trigger oder Aktion
runtimeConfiguration.concurrency.runs Integer Ändern Sie das Standardlimit für die Anzahl von Workflowinstanzen, die gleichzeitig (oder parallel) ausgeführt werden können. Das Anpassen dieses Werts kann die Anzahl von Anforderungen reduzieren, die auf Back-End-Systemen eingehen.

Das Festlegen der runs-Eigenschaft auf 1 funktioniert genauso wie das Festlegen der operationOptions-Eigenschaft auf SingleInstance. Sie können jeweils eine Eigenschaft festlegen, aber nicht beide.

Informationen zum Ändern des Standardlimits finden Sie unter Ändern der Triggerparallelität oder Sequenzielles Auslösen von Instanzen.

 Alle Trigger
runtimeConfiguration.concurrency.maximumWaitingRuns Integer Ändern Sie das Standardlimit für die Anzahl von Workflowinstanzen, die auf die Ausführung warten müssen, wenn für Ihre Logik-App bereits die maximale Anzahl von gleichzeitigen Instanzen ausgeführt wird.

Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.

 Alle Trigger
runtimeConfiguration.concurrency.repetitions Integer Ändern Sie das Standardlimit für die Anzahl von Iterationen der „for each“-Schleife, die gleichzeitig (oder parallel) ausgeführt werden können.

Das Festlegen der repetitions-Eigenschaft auf 1 funktioniert genauso wie das Festlegen der operationOptions-Eigenschaft auf SingleInstance. Sie können jeweils eine Eigenschaft festlegen, aber nicht beide.

Informationen zum Ändern des Standardlimits finden Sie unter Ändern der „for each“-Parallelität oder Sequenzielles Ausführen von „for each“-Schleifen.

 Aktion:

Foreach
runtimeConfiguration.paginationPolicy.minimumItemCount Integer Für bestimmte Aktionen, die die Paginierung unterstützen und diese aktiviert haben, gibt dieser Wert die minimale Anzahl der abzurufenden Ergebnisse an.

Informationen für das Aktivieren der Paginierung finden Sie unter Get bulk data, items, or results by using pagination (Abrufen von Massendaten, Elementen oder Ergebnissen mithilfe der Paginierung).

 Aktion: Verschiedene
runtimeConfiguration.secureData.properties Array Bei vielen Triggern und Aktionen blenden diese Einstellungen Eingaben, Ausgaben oder beides im Ausführungsverlauf der Logik-App aus.

Informationen zum Schützen dieser Daten finden Sie unter Ausblenden von Ein- und Ausgaben im Ausführungsverlauf.

 Gilt für die meisten Trigger und Aktionen
runtimeConfiguration.staticResult JSON-Objekt Für Aktionen, die die statische Ergebniseinstellung unterstützen und aktiviert sind, weist das staticResult Objekt die folgenden Attribute auf:

- name, das auf den Definitionsnamen des statischen Ergebnisses der aktuelle Aktion verweist, der innerhalb des staticResults-Attributs im definition-Attribut des Workflows Ihrer Logik-App vorkommt. Weitere Informationen finden Sie unter Statische Ergebnisse – Schemareferenz zur Definitionssprache für Workflows.

- staticResultOptions, das angibt, ob statische Ergebnisse Enabled sind oder nicht für die aktuelle Aktion.

Informationen zum Aktivieren statischer Ergebnisse finden Sie unter Testen von Logik-Apps mit Simulationsdaten durch die Einrichtung von statischen Ergebnissen.

 Aktion: Verschiedene

Optionen für den Vorgang

Sie können das Standardverhalten für Trigger und Aktionen mit der operationOptions-Eigenschaft in der Trigger- oder Aktionsdefinition ändern.

Vorgangsoption type BESCHREIBUNG Trigger oder Aktion
DisableAsyncPattern String Dient zum synchronen Ausführen von HTTP-basierten Aktionen (anstatt asynchron).

Informationen zum Festlegen dieser Option finden Sie unter Synchrones Ausführen von Aktionen.

 Aktionen:

API Verbinden ion,
HTTP,
Antwort
IncludeAuthorizationHeadersInOutputs String Fügen Sie für Logik-Apps, die OAuth mit Microsoft Entra-ID aktivieren, den Zugriff auf eingehende Anrufe an einen anforderungsbasierten Triggerendpunkt zu autorisieren, den Authorization Header aus dem OAuth-Zugriffstoken in die Triggerausgabe ein. Weitere Informationen finden Sie unter Einschließen des „Authorization“-Headers in Anforderungstriggerausgaben. Trigger:

Anforderung,
HTTP Webhook
Sequential String Dient zum einzelnen Ausführen der Iterationen von „for each“-Schleifen, anstatt alle auf einmal parallel.

Diese Option funktioniert genauso wie das Festlegen der runtimeConfiguration.concurrency.repetitions-Eigenschaft auf 1. Sie können jeweils eine Eigenschaft festlegen, aber nicht beide.

Informationen zum Festlegen dieser Option finden Sie unter Sequenzielles Ausführen von „for each“-Schleifen.

 Aktion:

Foreach
SingleInstance String Dient zum sequenziellen Ausführen des Triggers für jede Logik-App-Instanz. Es wird gewartet, bis die zuvor aktive Ausführung beendet ist, bevor die nächste Logik-App-Instanz ausgelöst wird.

Diese Option funktioniert genauso wie das Festlegen der runtimeConfiguration.concurrency.runs-Eigenschaft auf 1. Sie können jeweils eine Eigenschaft festlegen, aber nicht beide.

Informationen zum Festlegen dieser Option finden Sie unter Sequenzielles Auslösen von Instanzen.

 Alle Trigger
SuppressWorkflowHeaders String Senden Sie keine x-ms-*-Metadaten in ausgehenden Anforderungen. Der Azure Logic Apps-Dienst enthält standardmäßig zusätzliche Metadatenheader mit dem Präfix x-ms- im Headernamen als Teil von ausgehenden Anforderungen. Einige Legacydienste akzeptieren jedoch keine Anforderungen mit zusätzlichen unbekannten Headern. Dies führt zu fehlerhaften Anforderungen. Aktionen:

HTTP,
Funktion,
APIManagement
SuppressWorkflowHeadersOnResponse String Senden Sie keine x-ms-*-Metadatenheader in Antworten auf eingehende Triggeranforderungen. Der Azure Logic Apps-Dienst sendet standardmäßig Antworten auf eingehende Anforderungen, die Metadatenheader mit dem Präfix x-ms- im Headernamen enthalten. Einige Legacydienste akzeptieren jedoch keine Anforderungen oder Antworten mit zusätzlichen unbekannten Headern. Dies führt zu fehlerhaften Anforderungen. Trigger:

Anforderung,
HTTP Webhook

Ändern der Triggerparallelität

Standardmäßig werden alle Logik-App-Workflowinstanzen gleichzeitig (oder parallel) ausgeführt. Dieses Verhalten bedeutet, dass jede Triggerinstanz ausgelöst wird, bevor die Ausführung der zuvor aktiven Workflowinstanz beendet ist. Die Anzahl der gleichzeitig ausgeführten Instanzen hat jedoch ein Standardlimit. Wenn die Anzahl von gleichzeitig ausgeführten Workflowinstanzen dieses Limit erreicht, müssen alle anderen neuen Instanzen auf ihre Ausführung warten. Mit diesem Limit wird die Anzahl von Anforderungen gesteuert, die auf Back-End-Systemen eingehen.

Wenn Sie die Parallelitätssteuerung des Auslösers aktivieren, werden Auslöserinstanzen parallel bis zum Standardlimit ausgeführt. Zum Ändern des Standardparallelitätslimits können Sie entweder den Codeansicht-Editor oder den Logik-App-Designer nutzen, da durch das Ändern der Parallelitätseinstellung über den Designer die runtimeConfiguration.concurrency.runs-Eigenschaft in der zugrunde liegenden Triggerdefinition hinzugefügt bzw. aktualisiert wird (und umgekehrt). Diese Eigenschaft steuert die maximale Anzahl von neuen Workflowinstanzen, die parallel ausgeführt werden können.

Bevor Sie Parallelität für einen Trigger aktivieren, prüfen Sie die folgenden Überlegungen:

  • Die Parallelität kann nicht deaktiviert werden, nachdem Sie die Parallelitätssteuerung aktiviert haben.

  • Wenn die maximale Anzahl gleichzeitiger Triggerausführungen den maximalen Grad an Parallelität erreicht, kann es bei nachfolgenden Triggerausführungen zu Drosselungen oder Fehlern vom Typ „429 – Zu viele Anforderungen“ kommen. Wenn Sie eine Wiederholungsrichtlinie einrichten, die 429-Fehler behandelt, kann es beim Trigger zu einem Wiederholungs- und Drosselungszyklus kommen, der zu langen Verzögerungen bei der Verarbeitung neuer Trigger-Anforderungen führt.

  • Wenn Parallelität aktiviert ist, wird das SplitOn-Limit für das Auflösen von Arraybatches wesentlich reduziert. Wenn die Anzahl der Elemente dieses Limit überschreitet, wird die SplitOn-Funktion deaktiviert.

  • Wenn Parallelität aktiviert ist, könnte eine Logik-App-Instanz mit langer Ausführungszeit dazu führen, dass neue Logik-App-Instanzen in den Wartezustand wechseln. Dieser Zustand verhindert, dass Azure Logic Apps neue Instanzen erstellt, und er tritt auch dann ein, wenn die Anzahl gleichzeitiger Ausführungen kleiner als die angegebene maximale Anzahl gleichzeitiger Ausführungen ist.

    • Um diesen Zustand zu unterbrechen, brechen Sie die frühesten Instanzen ab, die noch ausgeführt werden.

      1. Wählen Sie im Menü Ihrer Logik-App die Option Übersicht aus.

      2. Wählen Sie im Abschnitt Ausführungsverlauf die früheste Instanz aus, die noch ausgeführt wird, z. B.:

        Select earliest running instance

        Tipp

        Um nur Instanzen anzuzeigen, die noch ausgeführt werden, öffnen Sie die Liste Alle, und wählen Sie Wird ausgeführt aus.

      3. Wählen Sie unter Logik-App-Ausführung die Option Ausführung abbrechen aus.

        Find earliest running instance

    • Um diese Möglichkeit zu umgehen, fügen Sie jeder Aktion einen Timeout hinzu, der diese Ausführungen aufhalten könnte. Wenn Sie im Code-Editor arbeiten, finden Sie weitere Informationen unter Ändern der asynchronen Dauer. Andernfalls, wenn Sie den Designer verwenden, führen Sie diese Schritte aus:

      1. Wählen Sie in Ihrem Logik-App-Workflow die Aktion aus, in der Sie ein Timeout hinzufügen möchten. Wählen Sie in der rechten oberen Ecke der Aktion die Schaltfläche mit den Auslassungspunkten (...) und dann Einstellungen aus.

        Open action settings

      2. Geben Sie unter Timeout die Timeoutdauer im ISO 8601-Format an.

        Specify timeout duration

  • Um Ihre Logik-App sequenziell auszuführen, legen Sie die Parallelität des Triggers entweder mithilfe des Codeansicht-Editors oder des Designers auf 1 fest. Stellen Sie sicher, dass Sie nicht auch die operationOptions-Eigenschaft des Triggers im Codeansicht-Editor auf SingleInstance festlegen. Andernfalls erhalten Sie einen Validierungsfehler. Weitere Informationen finden Sie unter Sequenzielles Auslösen von Instanzen.

Bearbeiten in der Codeansicht

Fügen Sie in der zugrunde liegenden Triggerdefinition die runtimeConfiguration.concurrency.runs-Eigenschaft hinzu, und legen Sie den Wert auf Grundlage der Limits für die Triggerparallelität fest. Um den Workflow sequenziell auszuführen, legen Sie den Eigenschaftswert auf 1 fest.

In diesem Beispiel werden gleichzeitige Ausführungen auf 10 Instanzen beschränkt:

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": 10
      }
   }
}

Weitere Informationen finden Sie unter den Einstellungen für die Laufzeitkonfiguration.

Bearbeiten im Logik-App-Designer

  1. Wählen Sie in der oberen rechten Ecke des Triggers die Ellipsenschaltfläche ( ... ) und dann Einstellungen aus.

  2. Legen Sie unter Gleichzeitigkeitssteuerung die Option Grenzwert auf Ein fest.

  3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den gewünschten Wert. Um Ihre Logik-App sequenziell auszuführen, ziehen Sie den Schieberegler auf 1.

Ändern der „for each“-Parallelität

Standardmäßig werden alle Iterationen für „for each“-Schleifen gleichzeitig (oder parallel) ausgeführt. Dieses Verhalten bedeutet, dass die Ausführung jeder Iteration gestartet wird, bevor die Ausführung der vorherigen Iteration abgeschlossen ist. Die Anzahl der gleichzeitig ausgeführten Iterationen hat jedoch ein Standardlimit. Wenn die Anzahl von gleichzeitig ausgeführten Iterationen dieses Limit erreicht, müssen alle anderen Iterationen auf ihre Ausführung warten.

Zum Ändern des Standardlimits können Sie entweder den Codeansicht-Editor oder den Logik-App-Designer nutzen, da durch das Ändern der Parallelitätseinstellung über den Designer die runtimeConfiguration.concurrency.repetitions-Eigenschaft in der zugrunde liegenden „for each“-Aktionsdefinition hinzugefügt bzw. aktualisiert wird (und umgekehrt). Diese Eigenschaft steuert die maximale Anzahl von Iterationen, die parallel ausgeführt werden können.

Hinweis

Wenn Sie für die „for each“-Aktion die sequenzielle Ausführung festlegen, indem Sie entweder den Designer oder den Codeansicht-Editor verwenden, sollten Sie die operationOptions-Eigenschaft der Aktion im Codeansicht-Editor nicht auf Sequential festlegen. Andernfalls erhalten Sie einen Validierungsfehler. Weitere Informationen finden Sie unter Sequenzielles Ausführen von „for each“-Schleifen.

Bearbeiten in der Codeansicht

In der zugrunde liegenden „for each“-Definition fügen Sie die Eigenschaft runtimeConfiguration.concurrency.repetitions hinzu, die einen Wert zwischen 1 und 50 besitzen kann, oder aktualisieren sie.

Hier ist ein Beispiel angegeben, in dem gleichzeitige Ausführungen auf zehn Iterationen begrenzt werden:

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": 10
      }
   }
}

Weitere Informationen finden Sie unter den Einstellungen für die Laufzeitkonfiguration.

Bearbeiten im Logik-App-Designer

  1. Wählen Sie in der Aktion For each oben rechts die Schaltfläche mit den Auslassungspunkten ( ... ) und dann Einstellungen aus.

  2. Legen Sie unter Gleichzeitigkeitssteuerung die Option Gleichzeitigkeitssteuerung auf Ein fest.

  3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den gewünschten Wert. Um Ihre Logik-App sequenziell auszuführen, ziehen Sie den Schieberegler auf 1.

Ändern des Limits für wartende Ausführungen

Standardmäßig werden alle Logik-App-Workflowinstanzen gleichzeitig (oder parallel) ausgeführt. Dieses Verhalten bedeutet, dass jede Triggerinstanz ausgelöst wird, bevor die Ausführung der zuvor aktiven Workflowinstanz beendet ist. Es ist jedoch ein Standardlimit für die Anzahl gleichzeitig ausgeführter Workflowinstanzen vorhanden. Wenn die Anzahl der gleichzeitigen Ausführungen diesen Grenzwert erreicht, müssen alle anderen neuen Workflowinstanzen auf die Ausführung warten. Ein Standardgrenzwert ist auch für die Anzahl der wartenden Workflowinstanzen vorhanden. Wenn die Anzahl der Warteinstanzen diesen Grenzwert erreicht, akzeptiert das Azure Logic Apps-Modul keine neuen Workflowinstanzen mehr, die ausgeführt werden sollen. Anforderungs- und Webhook-Trigger geben 429 zurück – Zu viele Anforderungenfehler, und wiederkehrende Trigger starten das Überspringen von Abrufversuchen.

Sie können den Standardgrenzwert für die Triggerkoncurrency sowie den Standardgrenzwert für Warteläufe ändern. Diese Änderung verlangsamt jedoch in erster Linie den Auslöser, um den Druck aufgrund der Parallelität zu lindern. Wenn Sie z. B. einen Abruftrigger haben und die Warteschleife aufgrund laufender Ausführungen voll ist, beendet Azure Logic Apps die Abfrage. Wenn Ihr Workflow einen anforderungsbasierten Trigger verwendet und die Warteschleife voll ist, beginnt Azure Logic Apps mit der Rückgabe des Fehlers 429. Einige Szenarien sind vorhanden, in denen Azure Logic Apps den Auslöser nicht beenden können, ohne Fehler einzufügen und diese Läufe trotzdem zur Warteschleife hinzuzufügen, ohne dass die Aufrufe ausgeführt werden.

In der zugrunde liegenden Triggerdefinition fügen Sie die Eigenschaft runtimeConfiguration.concurrency.maximumWaitingRuns hinzu, die einen Wert zwischen 1 und 100 besitzen kann.

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "maximumWaitingRuns": 50
      }
   }
}

Weitere Informationen finden Sie unter den Einstellungen für die Laufzeitkonfiguration.

Sequenzielles Auslösen von Instanzen

Legen Sie für den Trigger die sequenzielle Ausführung fest, damit jede Logik-App-Workflowinstanz erst nach Beendigung der vorherigen Instanz ausgeführt wird. Sie können entweder den Codeansicht-Editor oder den Logik-App-Designer nutzen, da durch das Ändern der Parallelitätseinstellung über den Designer auch die runtimeConfiguration.concurrency.runs-Eigenschaft in der zugrunde liegenden Triggerdefinition hinzugefügt bzw. aktualisiert wird (und umgekehrt).

Hinweis

Wenn Sie für den Trigger die sequenzielle Ausführung festlegen, indem Sie entweder den Designer oder den Codeansicht-Editor verwenden, sollten Sie die operationOptions-Eigenschaft des Triggers im Codeansicht-Editor nicht auf Sequential festlegen. Andernfalls erhalten Sie einen Validierungsfehler.

Bearbeiten in der Codeansicht

Legen Sie in der Triggerdefinition eine dieser Eigenschaften fest, aber nicht beide.

Legen Sie die runtimeConfiguration.concurrency.runs-Eigenschaft auf 1 fest:

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": 1
      }
   }
}

-oder-

Legen Sie die operationOptions-Eigenschaft auf SingleInstance fest:

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "operationOptions": "SingleInstance"
}

Weitere Informationen finden Sie unter Einstellungen für die Laufzeitkonfiguration und Vorgangsoptionen.

Bearbeiten im Logik-App-Designer

  1. Wählen Sie in der oberen rechten Ecke des Triggers die Ellipsenschaltfläche ( ... ) und dann Einstellungen aus.

  2. Legen Sie unter Gleichzeitigkeitssteuerung die Option Grenzwert auf Ein fest.

  3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den Wert 1.

Sequenzielles Ausführen von „for each“-Schleifen

Legen Sie für die Aktion „for each“ die sequenzielle Ausführung fest, damit die Iteration einer „for each“-Schleife erst nach Abschluss der vorherigen Iteration ausgeführt wird. Sie können entweder den Codeansicht-Editor oder den Logik-App-Designer nutzen, da durch das Ändern der Parallelität der Aktion über den Designer auch die runtimeConfiguration.concurrency.repetitions-Eigenschaft in der zugrunde liegenden Aktionsdefinition hinzugefügt bzw. aktualisiert wird (und umgekehrt).

Hinweis

Wenn Sie für eine „for each“-Aktion die sequenzielle Ausführung festlegen, indem Sie entweder den Designer oder den Codeansicht-Editor verwenden, sollten Sie die operationOptions-Eigenschaft der Aktion im Codeansicht-Editor nicht auf Sequential festlegen. Andernfalls erhalten Sie einen Validierungsfehler.

Bearbeiten in der Codeansicht

Legen Sie in der Aktionsdefinition eine dieser Eigenschaften fest, aber nicht beide.

Legen Sie die runtimeConfiguration.concurrency.repetitions-Eigenschaft auf 1 fest:

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": 1
      }
   }
}

-oder-

Legen Sie die operationOptions-Eigenschaft auf Sequential fest:

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "operationOptions": "Sequential"
}

Weitere Informationen finden Sie unter Einstellungen für die Laufzeitkonfiguration und Vorgangsoptionen.

Bearbeiten im Logik-App-Designer

  1. Wählen Sie in der Aktion For each oben rechts die Schaltfläche mit den Auslassungspunkten ( ... ) und dann Einstellungen aus.

  2. Legen Sie unter Gleichzeitigkeitssteuerung die Option Gleichzeitigkeitssteuerung auf Ein fest.

  3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den Wert 1.

Ausführen von Aktionen in einem synchronen Vorgangsmuster

Standardmäßig folgen die HTTP-Aktion und die APIConnection-Aktionen in Azure Logic Apps dem standardmäßigen asynchronen Vorgangsmuster, während die Response-Aktion (Antwort) dem synchronen Vorgangsmuster folgt. Das asynchrone Muster gibt an, dass der Empfänger, nachdem eine Aktion eine Anforderung aufgerufen oder an den Endpunkt, Dienst, das System oder die API gesendet hat, sofort eine „202 ACCEPTED“-Antwort zurückgibt. 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, in dem die URL und eine Aktualisierungs-ID angegeben sind, die der Aufrufer zum fortlaufenden Abrufen oder Überprüfen des Status der asynchronen Anforderung verwenden kann, bis der Empfänger die Verarbeitung beendet und eine „200 OK“-Erfolgsantwort oder eine andere Nicht-202-Antwort zurückgibt. Weitere Informationen finden Sie unter Asynchrone Microservice-Integration erzwingt Microservice-Autonomie.

  • Im Logik-App-Designer verfügen die HTTP-Aktion, die APIConnection-Aktionen und die Response-Aktion über die Einstellung Asynchrones Muster. Wenn diese Einstellung aktiviert ist, gibt sie 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. 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 Aktion zugrunde liegt, folgen die HTTP-Aktion und die APIConnection-Aktionen implizit dem asynchronen Vorgangsmuster.

In einigen Szenarien möchten Sie eventuell, dass eine Aktion stattdessen dem synchronen Muster folgt. Beispielsweise, wenn Sie die HTTP-Aktion verwenden, möchten Sie möglicherweise Folgendes:

In diesen Fällen können Sie veranlassen, dass eine Aktion synchron ausgeführt wird, indem Sie diese Optionen verwenden:

Deaktivieren der Einstellung Asynchrones Muster

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

  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.

    Turn off

Deaktivieren des asynchronen Musters in der JSON-Definition einer Aktion

Fügen Sie in der JSON-Definition, die der Aktion zugrunde liegt, die Eigenschaft „operationOptions“ hinzu, und legen Sie sie auf "DisableAsyncPattern" im Abschnitt "inputs" der Aktion fest, z. B.:

"<some-long-running-action>": {
   "type": "Http",
   "inputs": { "<action-inputs>" },
   "operationOptions": "DisableAsyncPattern",
   "runAfter": {}
}

Authentifizieren von Triggern und Aktionen

HTTP- und HTTP-Endpunkte unterstützen verschiedene Arten der Authentifizierung. Basierend auf dem Trigger oder der Aktion, mit dem/der Sie ausgehende Aufrufe oder Anforderungen ausführen, um auf diese Endpunkte zuzugreifen, können Sie aus verschiedenen Bereichen von Authentifizierungstypen auswählen. Weitere Informationen finden Sie unter Hinzufügen der Authentifizierung zu ausgehenden Aufrufen.

Nächste Schritte