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

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. Informationen zu bestimmten Connectortriggern und Aktionen, die Sie in Ihren Logik-Apps verwenden können, finden Sie in der Liste unter der Übersicht über Connectors.

Ü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 , der ein Abonnement für einen Endpunkt erstellt und eine Rückruf-URL bereitstellt, damit der Endpunkt den Trigger benachrichtigen kann, wenn das angegebene Ereignis auftritt 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>"
},

Required

Value	Type	Description
< Triggername>	String	Name des Triggers
< Triggertyp>	String	Triggertyp, z.B. „Http“ oder „ApiConnection“
< Triggereingaben>	JSON-Objekt	Eingaben, die das Verhalten des Triggers definieren
< Zeiteinheit>	String	Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
< Anzahl der Zeiteinheiten>	Integer	Wert, mit dem angegeben wird, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird (Anzahl von Zeiteinheiten der Wartezeit, bis der Trigger erneut ausgelöst wird) Zulässige Mindest- und Maximalintervalle: - 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

Value	Type	Description
< Array mit Bedingungen>	Array	Ein Array, das eine oder mehrere Bedingungen enthält, die bestimmen, ob der Workflow ausgeführt werden soll. 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 "Vorgangsoptionen".

Liste mit Triggertypen

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

Integrierte Trigger

Triggertyp	Description
HTTP	Überprüft oder fragt jeden Endpunkt 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	Description
ApiConnection	Überprüft oder abruft einen Endpunkt mithilfe von von Microsoft verwalteten APIs oder "Connectors".
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

Dieser Trigger überprüft oder abruft einen Endpunkt mithilfe von microsoftverwalteten APIs oder "Connectors" , sodass sich die Parameter für diesen Trigger je nach Endpunkt unterscheiden können. 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>"
}

Required

Property	Value	Type	Description
None	< APIConnection_trigger_name>	String	Name des Triggers
host.connection.name	< Verbindungsname>	String	Name für die Verbindung mit der verwalteten API, die vom Workflow verwendet wird
method	< Methodentyp>	String	Die HTTP-Methode für die Kommunikation mit der verwalteten API: GET, PUT, POST, PATCH, DELETE
path	< API-Operation>	String	Aufzurufender API-Vorgang
recurrence.frequency	< Zeiteinheit>	String	Die Zeiteinheit, die beschreibt, wie oft der Trigger ausgelöst wird: Second, Minute, Hour, Day, Week, Month
recurrence.interval	< Anzahl der Zeiteinheiten>	Integer	Wert, mit dem angegeben wird, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird (Anzahl von Zeiteinheiten der Wartezeit, bis der Trigger erneut ausgelöst wird) Zulässige Mindest- und Maximalintervalle: - 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 beispielsweise 6 ist und die Häufigkeit "Monat" lautet, beträgt die Wiederholung alle 6 Monate.

Optional

Property	Value	Type	Description
retryPolicy	< Wiederholungsverhalten>	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.
queries	< Abfrageparameter>	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.
runtimeConfiguration.concurrency.runs	< max-Runs>	Integer	Standardmäßig werden Workflowinstanzen gleichzeitig (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
runtimeConfiguration.maximumWaitingRuns	< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, werden alle neuen Läufe in dieser Warteschlange bis zum Standardgrenzwert platziert. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen. Um die maximale Anzahl von Instanzen zu ändern, geben Sie einen Wert für die eigenschaft "runtimeConfiguration.concurrency.runs " an. Hinweis: Wenn Sie die
splitOn	< 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']
operationOptions	< Operation-Option>	String	Sie können das Standardverhalten ändern, indem Sie die operationOptions-Eigenschaft festlegen. Weitere Informationen finden Sie unter "Vorgangsoptionen".

Outputs

Element	Type	Description
headers	JSON-Objekt	Header aus der Antwort
body	JSON-Objekt	Text aus der Antwort
Statuscode	Integer	Der Statuscode aus der Antwort

Example

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 mithilfe einer von Microsoft verwalteten API, stellt eine Rückruf-URL bereit, 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>"
}

Required

Value	Type	Description
< Verbindungsname>	String	Name für die Verbindung mit der verwalteten API, die vom Workflow verwendet wird
< Textkörperinhalt>	JSON-Objekt	Nachrichteninhalt, der als Nutzlast an die verwaltete API gesendet wird

Optional

Value	Type	Description
< Wiederholungsverhalten>	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.
< Abfrageparameter>	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 (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, die Sie basierend auf der runtimeConfiguration.concurrency.runs Eigenschaft ändern können, werden alle neuen Läufe bis zum Standardgrenzwert in diese Warteschlange eingefügt. 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 "Vorgangsoptionen".

Example

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

Required

Property	Value	Type	Description
method	< Methodentyp>	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. Maximal zulässige 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	< Zeiteinheit>	String	Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
interval	< Anzahl der Zeiteinheiten>	Integer	Wert, mit dem angegeben wird, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird (Anzahl von Zeiteinheiten der Wartezeit, bis der Trigger erneut ausgelöst wird) Zulässige Mindest- und Maximalintervalle: - 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

Property	Value	Type	Description
headers	< Headerinhalt>	JSON-Objekt	Alle Kopfzeilen, die in die Anforderung einbezogen werden müssen. Verwenden Sie beispielsweise Folgendes, um Sprache und Typ festzulegen: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	< Abfrageparameter>	JSON-Objekt	Alle Abfrageparameter, die in der Anforderung verwendet werden müssen. Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird der Anforderung beispielsweise ?api-version=2018-01-01 hinzugefügt.
body	< Textkörperinhalt>	JSON-Objekt	Nachrichteninhalt, der als Nutzlast mit der Anforderung gesendet wird
authentication	< Authentifizierungstyp-und-Eigenschaftswerte>	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	< Wiederholungsverhalten>	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 (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
maximumWaitingRuns	< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, die Sie basierend auf der runtimeConfiguration.concurrency.runs Eigenschaft ändern können, werden alle neuen Läufe bis zum Standardgrenzwert in diese Warteschlange eingefügt. 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 "Vorgangsoptionen".

Outputs

Element	Type	Description
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:

Property	Required	Description
Statuscode	Yes	Der Statuscode „200 OK“ startet eine Ausführung. Alle anderen Statuscodes starten keine Ausführung.
Retry-After-Kopfzeile	No	Die Anzahl von Sekunden bis zur erneuten Abfrage des Endpunkts durch Ihre Logik-App.
Ortskopfzeile	No	Die URL, die im nächsten Abfrageintervall aufgerufen werden soll. Ohne Angabe wird die ursprüngliche URL verwendet.

Beispielverhalten für unterschiedliche Anforderungen

Statuscode	Wiederholen nach	Behavior
200	{none}	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	{none}	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	{none}	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 Grenzwerte 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. Methodentyp>, sind sowohl für die als "subscribe" auch für Objekte "unsubscribe" verfügbar.

Required

Value	Type	Description
< Methodentyp>	String	HTTP-Methode für die Abonnementanforderung: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
< Endpunktabonnent-URL>	String	Endpunkt-URL, an die die Abonnementanforderung gesendet werden soll

Optional

Value	Type	Description
< Methodentyp>	String	HTTP-Methode für die Kündigungsanforderung: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
< endpunkt-unsubscribe-URL>	String	Endpunkt-URL, an die die Kündigungsanforderung gesendet werden soll
< Textkörperinhalt>	String	Beliebiger Nachrichteninhalt, der in der Abonnement- oder Kündigungsanforderung gesendet werden soll
< Authentifizierungstyp>	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.
< Wiederholungsverhalten>	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 (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, die Sie basierend auf der runtimeConfiguration.concurrency.runs Eigenschaft ändern können, werden alle neuen Läufe bis zum Standardgrenzwert in diese Warteschlange eingefügt. 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 "Vorgangsoptionen".

Outputs

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

Example

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

Serientrigger

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

Required

Value	Type	Description
< Zeiteinheit>	String	Die Zeiteinheit für die Häufigkeit der Triggerauslösung: „Second“, „Minute“, „Hour“, „Day“, „Week“, „Month“
< Anzahl der Zeiteinheiten>	Integer	Wert, mit dem angegeben wird, wie oft der Trigger basierend auf der Häufigkeit ausgelöst wird (Anzahl von Zeiteinheiten der Wartezeit, bis der Trigger erneut ausgelöst wird) Zulässige Mindest- und Maximalintervalle: - 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

Value	Type	Description
< start-date-time-with-format-YYYY-MM-DDThh:mm:ss>	String	Das Startdatum und die -uhrzeit im folgenden Format: JJJJ-MM-TTTHH:mm:ss (bei Angabe einer Zeitzone; beachten Sie dabei, dass „TT“ den Tag bezeichnet, während das dritte „T“ wie in den nachfolgenden Beispielen gezeigt nicht verändert werden darf) -or- JJJJ-MM-TTTHH:mm:ssZ (ohne Angabe einer Zeitzone) 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).
< Zeitzone>	String	Nur relevant, wenn Sie eine Startzeit angeben, da dieser Trigger keine UTC-Abweichung akzeptiert. Geben Sie die anzuwendende Zeitzone an.
< ein- oder mehrstündige Markierungen>	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“.
< ein- oder mehrminütige Markierungen>	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 (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, die Sie basierend auf der runtimeConfiguration.concurrency.runs Eigenschaft ändern können, werden alle neuen Läufe bis zum Standardgrenzwert in diese Warteschlange eingefügt. 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 "Vorgangsoptionen".

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.

Note

Der ursprüngliche Name für den Anforderungstrigger war manuell, was an einigen Stellen möglicherweise noch angezeigt wird. Dieser Name wurde geändert, um mehr Konsistenz um die Art des Workflowmusters zu schaffen, das Sie zum Erstellen des Triggers verwenden.

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.

"Request": {
   "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>"
}

Required

Value	Type	Description
< Eigenschaftsname>	String	Name einer Eigenschaft im JSON-Schema, mit der die Nutzlast beschrieben wird
< Eigenschaftstyp>	String	Typ der Eigenschaft

Optional

Value	Type	Description
< Methodentyp>	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
< Erforderliche Eigenschaften>	Array	Mindestens eine Eigenschaft, die Werte erfordert.
< max-Runs>	Integer	Standardmäßig werden Alle Workflowinstanzen gleichzeitig (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität des Triggers.
< max-runs-queue>	Integer	Wenn Ihr Workflow bereits die maximale Anzahl von Instanzen ausführt, die Sie basierend auf der runtimeConfiguration.concurrency.runs Eigenschaft ändern können, werden alle neuen Läufe bis zum Standardgrenzwert in diese Warteschlange eingefügt. 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 "Vorgangsoptionen".

Example

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:

"Request": {
   "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))

Auslösen mehrerer Workflows auf einem Array

In Szenarien, in denen Ihr Workflow einen Trigger verwendet, der Arrays für die Verarbeitung empfängt, kann die Verwendung einer For each-Schleife manchmal zu lange dauern. Um die Verarbeitung zu beschleunigen, besteht eine Möglichkeit darin, parallele Verzweigungen zu erstellen. Wenn der Trigger das Debattieren unterstützt, können Sie auch arrayelemente aufteilen und eine separate Workflowinstanz für jedes Arrayelement ausführen. Diese Option ist beispielsweise hilfreich, wenn Sie einen Endpunkt abfragen möchten, der möglicherweise mehrere neue Elemente zwischen Abrufintervallen zurückgibt.

Nur Trigger, die Arrays akzeptieren und Arrays zurückgeben können, unterstützen diese Funktion wie "Anforderung", "HTTP", "Azure Service Bus" oder "Office Outlook 365". Für diese Trigger können Sie im Workflow-Designer die Einstellung "Teilen " aktivieren, die die splitOn Eigenschaft zur Triggerdefinition hinzufügt.

Note

Wenn die Swagger-Datei des Triggers eine Nutzlast beschreibt, die ein Array ist, wird die splitOn Eigenschaft automatisch der Triggerdefinition hinzugefügt. Andernfalls können Sie die Eigenschaft der Antwortnutzlast hinzufügen, die das Array enthält, das Sie debatchieren möchten.

Bevor Sie die Debattierfunktion verwenden, lesen Sie die folgenden Überlegungen:

• Wenn die Parallelität des Triggers ebenfalls aktiviert ist, wird der Grenzwert für " Split on " erheblich reduziert. Wenn die Anzahl der Elemente diesen Grenzwert überschreitet, ist die Funktion "Teilen" nicht verfügbar.

• Die Funktion " Aufteilen" funktioniert nicht mit dem synchronen Antwortmuster. Wenn ein Workflow die Antwortaktion verwendet und die Einstellung " Teilen " aktiviert, wird asynchron ausgeführt und sofort eine 202 ACCEPTED Antwort gesendet.

• Es gibt einen Grenzwert für die Anzahl von Arrayelementen, die split on verarbeiten können, in einem einzelnen Workflowlauf. Weitere Informationen finden Sie unter Schleifen- und Batchverarbeitungsgrenzwerte.

• Wenn Sie die Aussprache über die Triggerdefinition mithilfe der splitOn Eigenschaft einrichten, können Sie nicht direkt auf Eigenschaften verweisen oder darauf zugreifen, die außerhalb des Arrays vorhanden sind. Um Fehler zu vermeiden, stellen Sie dem Verweis den ? Operator voran. Beispiele finden Sie unter Aktivieren der Debattierung in der Triggerdefinition.

Aktivieren des Debattierens durch den Designer

Führen Sie die folgenden Schritte im Workflow-Designer aus, um die Aussprache für einen Trigger einzurichten, der unterstützt wird:

1. Öffnen Sie im [Azure-Portal] Ihre Logik-App-Ressource.

2. Öffnen Sie Ihren Workflow im Designer.

3. Wählen Sie im Designer den Trigger aus, der das Debattieren unterstützt, um den Auslöserinformationsbereich zu öffnen.

4. Suchen Sie auf der Registerkarte "Einstellungen " unter " Allgemein" die Einstellung " Teilen ", und ändern Sie die Einstellung in "Ein ", wenn sie nicht aktiviert ist.

Aktivieren des Debattierens in der Triggerdefinition

Einige Trigger behandeln Arrays, aber die Einstellung " Teilen bei" ist über den Designer nicht verfügbar. Führen Sie für solche Trigger die folgenden Schritte aus, um die splitOn Eigenschaft in der Triggerdefinition hinzuzufügen:

Angenommen, Ihr Workflow verwendet den HTTP-Trigger zum Aufrufen einer API und ruft die folgende Antwort ab:

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

Wenn Ihr Workflow nur den Inhalt aus dem Rows Array benötigt, können Sie die splitOn Eigenschaft in der Triggerdefinition hinzufügen und einrichten, wie im folgenden Beispiel gezeigt:

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

Note

Denken Sie daran, dass Sie, wenn Sie die splitOn Eigenschaft verwenden, nicht direkt auf Eigenschaften zugreifen oder darauf verweisen können, die außerhalb des Arrays vorhanden sind. Um Fehler zu vermeiden, verwenden Sie den ? Operator wie in den Beispielen dargestellt.

Ihre Workflowdefinition kann auch werte aus der splitOn Eigenschaft abrufen und @triggerBody().name verwendenname. Diese Werte stammen "customer-name-one" aus der ersten Workflowausführung und "customer-name-two" aus der zweiten Workflowausführung. In diesem Beispiel sehen die Triggerausgänge wie die folgenden Werte 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>"
},

Required

Value	Type	Description
< Aktionsname>	String	Name für die Aktion
< Aktionstyp>	String	Aktionstyp, z.B. „Http“ oder „ApiConnection“
< Eingabename>	String	Name für eine Eingabe, mit der das Verhalten der Aktion definiert wird
< Eingabewert>	Various	Eingabewert, bei dem es sich um eine Zeichenfolge, eine Ganzzahl, ein JSON-Objekt usw. handeln kann
< Vorheriger Trigger- oder Aktionsstatus>	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

Value	Type	Description
< Wiederholungsverhalten>	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 "Vorgangsoptionen".

Liste mit Aktionstypen

Hier sind einige häufig verwendete Aktionstypen angegeben:

• Integrierte Aktionstypen, z.B. diese Beispiele und mehr:

  • HTTP zum Aufrufen von Endpunkten über HTTP oder HTTPS

  • Antwort auf Antworten auf Anforderungen

  • Ausführen von JavaScript-Code für die Ausführung von JavaScript-Codeausschnitten

  • Funktion zum Aufrufen von Azure Functions

  • Datenvorgangsaktionen wie Verknüpfung, Verfassen, Tabelle, Auswählen und andere, die Daten aus verschiedenen Eingaben erstellen oder transformieren

  • Workflow zum Aufrufen eines anderen Logik-App-Workflows

• Aktionstypen mit verwalteter API, z.B. ApiConnection und ApiConnectionWebHook, mit denen verschiedene von Microsoft verwaltete Connectors und APIs aufgerufen werden, z.B. Azure Service Bus, Office 365 Outlook, Power BI, Azure Blob Storage, OneDrive, GitHub und mehr

• Aktionstypen zur Workflowsteuerung, z.B. If, Foreach, Switch, Scope und Until, die andere Aktionen enthalten und Sie beim Organisieren der Workflowausführung unterstützen

Integrierte Aktionen

Aktionstyp	Description
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.
Analysieren von 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	Description
ApiConnection	Ruft einen HTTP-Endpunkt mithilfe einer von Microsoft verwalteten API auf.
ApiConnectionWebhook	Funktioniert wie HTTP-Webhook, verwendet aber eine von Microsoft verwaltete API.

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	Description
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 und erfordert Informationen über die API und Parameter sowie einen Verweis auf eine gültige Verbindung.

"<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": {}
}

Required

Value	Type	Description
< Aktionsname>	String	Name der vom Connector bereitgestellten Aktion
< API-Name>	String	Name der von Microsoft verwalteten API, die für die Verbindung verwendet wird
< Methodentyp>	String	HTTP-Methode zum Aufrufen der API: „GET“, „PUT“, „POST“, „PATCH“, „DELETE“
< API-Operation>	String	Aufzurufender API-Vorgang

Optional

Value	Type	Description
< other-action-specific-input-properties>	JSON-Objekt	Alle anderen Eingabeeigenschaften, die für die spezifische Aktion gelten
< Wiederholungsverhalten>	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.
< Abfrageparameter>	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

Example

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 über HTTP an einen Endpunkt mithilfe einer von Microsoft verwalteten API, stellt eine Rückruf-URL bereit, 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. Methodentyp>, sind sowohl für die als "subscribe" auch für Objekte "unsubscribe" verfügbar.

Required

Value	Type	Description
< Aktionsname>	String	Name der vom Connector bereitgestellten Aktion
< Methodentyp>	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

Value	Type	Description
< API-Unsubscribe-URL>	String	URI, der zum Kündigen des API-Abonnements verwendet wird
< Headerinhalt>	JSON-Objekt	Alle Header, 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" }
< Textkörperinhalt>	JSON-Objekt	Beliebiger Nachrichteninhalt, der in der Anforderung gesendet wird
< Authentifizierungstyp>	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.
< Wiederholungsverhalten>	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.
< Abfrageparameter>	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-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 auf die gleiche Weise angeben wie http-asynchrone Grenzwerte.

Verfassen-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": {}
},

Required

Value	Type	Description
< Eingaben zum Verfassen>	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": {}
}

Required

Value	Type	Description
< 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.

Value	Type	Description
< Vorherige Aktionen>	Zeichenfolgenarray	Ein Array mit den Aktionsnamen im JSON-Format als Abhängigkeiten. Stellen Sie sicher, dass Sie die Aktionsnamen verwenden, die in Ihrer Workflowdefinition angezeigt werden, in der 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.workflow.name-Objekts auf die Eigenschaft workflowContext 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": {}
}

Funktionsaktion

Diese Aktion ruft eine zuvor erstellte Azure-Funktion auf.

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

Required

Value	Type	Description
< 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>"
< Methodentyp>	String	HTTP-Methode, die zum Aufrufen der Funktion verwendet wird: „GET“, „PUT“, „POST“, „PATCH“ oder „DELETE“ Wenn nichts angegeben wird, wird standardmäßig die Methode „POST“ verwendet.

Optional

Value	Type	Description
< Headerinhalt>	JSON-Objekt	Alle Header, die mit dem Aufruf 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" }
< Textkörperinhalt>	JSON-Objekt	Beliebiger Nachrichteninhalt, der in der Anforderung gesendet wird
< Abfrageparameter>	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-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 Azure Logic Apps die folgenden Überprüfungen für die referenzierte Funktion aus:

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

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

  Azure Logic Apps ruft die zur Laufzeit verwendete Trigger-URL ab und speichert sie zwischen. Wenn jedoch ein Vorgang die zwischengespeicherte URL ungültig macht, schlägt die Funktionsaktion zur Laufzeit fehl. 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.

Example

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": {}
}

Required

Property	Value	Type	Description
method	< Methodentyp>	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. Maximal zulässige 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

Property	Value	Type	Description
headers	< Headerinhalt>	JSON-Objekt	Alle Kopfzeilen, die in die Anforderung einbezogen werden müssen. Verwenden Sie beispielsweise Folgendes, um Sprache und Typ festzulegen: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	< Abfrageparameter>	JSON-Objekt	Alle Abfrageparameter, die in der Anforderung verwendet werden müssen. Mit dem "queries": { "api-version": "2018-01-01" }-Objekt wird dem Aufruf beispielsweise ?api-version=2018-01-01 hinzugefügt.
body	< Textkörperinhalt>	JSON-Objekt	Nachrichteninhalt, der als Nutzlast mit der Anforderung gesendet wird
authentication	< Authentifizierungstyp-und-Eigenschaftswerte>	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	< Wiederholungsverhalten>	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>	< Eigenschaftswert>	JSON-Objekt	Alle anderen Eigenschaften, die für die spezifische Aktion gelten

Example

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

Teilnehmen-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": {}
}

Required

Value	Type	Description
< Anordnung>	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.
< Trennzeichen>	Zeichenfolge mit nur einem Zeichen	Das Zeichen, mit dem die Elemente in der Zeichenfolge getrennt werden

Example

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“

Diese Aktion erstellt benutzerfreundliche Felder oder Token aus den Eigenschaften in JSON-Inhalten. 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": {}
},

Required

Value	Type	Description
< JSON-Quelle>	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 Workflow-Designer können Sie entweder das Schema bereitstellen oder eine Beispielnutzlast bereitstellen, damit die Aktion das Schema generieren kann.

Example

Diese Aktionsdefinition erstellt diese Token, die Sie in Ihrem Workflow verwenden können, jedoch nur in Aktionen, die nach der JSON-Analyseaktion 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": {}
}

Required

Value	Type	Description
< Anordnung>	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	Bedingung, die zum Filtern von Elementen im Quellarray verwendet wird Hinweis: Wenn keine Werte die Bedingung erfüllen, erstellt die Aktion ein leeres Array.

Example

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": {}
},

Required

Value	Type	Description
< Antwortstatuscode>	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

Value	Type	Description
< Antwortheader>	JSON-Objekt	Einer oder mehrere Header, die in die Antwort eingefügt werden sollen
< Antworttext>	Various	Antworttext, bei dem es sich um eine Zeichenfolge, ein JSON-Objekt oder auch Binärinhalt aus einer vorherigen Aktion handelt

Example

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": {}
}

Restrictions

Im Gegensatz zu anderen Aktionen weist die Antwortaktion besondere Einschränkungen auf:

• Ihr Workflow kann die Antwortaktion nur verwenden, wenn der Workflow mit einem HTTP-Anforderungstrigger beginnt, d. h. Ihr Workflow muss von einer HTTP-Anforderung ausgelöst werden.

• Ihr Workflow kann die Antwortaktion an beliebiger Stelle verwenden, außer in Foreach-Schleifen , Bis-Schleifen , einschließlich sequenzieller Schleifen und paralleler Verzweigungen.

• Die ursprüngliche Anforderung ruft die Antwort Ihres Workflows nur ab, wenn alle aktionen, die von der Antwortaktion erforderlich sind, innerhalb des HTTP-Timeoutlimits abgeschlossen sind.

  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 Ihr Workflow die Antwortaktion und ein synchrones Antwortmuster verwendet, kann der Workflow nicht auch den SplitOn-Befehl in der Triggerdefinition verwenden, da dieser Befehl mehrere Ausführungen erstellt. 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.

  Andernfalls wird der Workflow asynchron ausgeführt, wenn Ihr Workflow den Befehl "splitOn " und eine Antwortaktion verwendet und sofort eine Antwort "202 AKZEPTIERT" zurückgibt.

• Wenn die Ausführung Des Workflows die Antwortaktion erreicht, aber die eingehende Anforderung bereits eine Antwort empfangen hat, wird die Antwortaktion aufgrund des Konflikts als "Fehlgeschlagen" markiert. Ihre Logik-App-Ausführung erhält somit ebenfalls den Status „Failed“.

Aktion auswählen

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": {}
},

Required

Value	Type	Description
< Anordnung>	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, erstellt die Aktion ein leeres Array.
< Schlüsselname>	String	Der Eigenschaftsname, der dem Ergebnis aus <dem Ausdruck zugewiesen ist> Um eine neue Eigenschaft für alle Objekte im Ausgabearray hinzuzufügen, geben Sie einen <Schlüsselnamen> für diese Eigenschaft und einen <Ausdruck> für den Eigenschaftswert an. Wenn Sie eine Eigenschaft aus allen Objekten im Array entfernen möchten, geben Sie den <Schlüsselnamen> für diese Eigenschaft aus.
< Ausdruck>	String	Der Ausdruck, der das Element im Quellarray transformiert und dem < das Ergebnis zuweist >

Die Auswahlaktion erstellt ein Array als Ausgabe. Daher muss jede Aktion, die diese Ausgabe verwenden möchte, entweder ein Array akzeptieren, oder Sie müssen das Array in den Typ konvertieren, den die Consumeraktion akzeptiert. Wenn Sie beispielsweise das Ausgabearray in eine Zeichenfolge konvertieren möchten, können Sie dieses Array an die Verfassen-Aktion übergeben und dann in ihren anderen Aktionen auf die Ausgabe der Verfassen-Aktion verweisen.

Example

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 } ]

Um diese Arrayausgabe in anderen Aktionen zu verwenden, übergeben Sie diese Ausgabe an eine Verfassen-Aktion :

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

Anschließend können Sie die Ausgabe aus der Aktion zum Verfassen in Ihren anderen Aktionen verwenden, z. B. office 365 Outlook – Eine E-Mail-Aktion senden :

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

Tabellenaktion

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": {}
}

Required

Value	Type	Description
<CSV oder HTML>	String	Format für die Tabelle, die Sie erstellen möchten
< Anordnung>	Array	Array oder Ausdruck, mit dem die Quellelemente für die Tabelle bereitgestellt werden Hinweis: Wenn das Quellarray leer ist, erstellt die Aktion eine leere Tabelle.

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.

Value	Type	Description
< Spaltenname>	String	Headername für eine Spalte
< Spaltenwert>	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:

ID	Product_Name
0	Apples
1	Oranges

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_ID	Description
0	Bio-Äpfel
1	Bio-Orangen

Aktion beenden

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 z. B. die Beenden-Aktion verwenden, wenn Die Logik-App vollständig aus einem Fehlerzustand beendet werden muss. Diese Aktion wirkt sich nicht auf bereits abgeschlossene Aktionen aus und kann nicht innerhalb von "Foreach " und "Until "-Schleifen angezeigt werden, einschließlich sequenzieller Schleifen.

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

Required

Value	Type	Description
< Status>	String	Der zurückzugebende Status für die Ausführung: „Failed“, „Cancelled“, „Succeeded“

Optional

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

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

Example

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": {}
}

Wartefunktion

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

Angegebenes Intervall

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

Angegebene Uhrzeit

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

Required

Value	Type	Description
< Anzahl der Einheiten>	Integer	Für die Verzögerungsaktion die Anzahl der zu wartenden Einheiten
< Intervall>	String	Für die Verzögerungsaktion wartet das zu wartende Intervall: "Second", "Minute", "Hour", "Day", "Week", "Month"
< Datums-/Uhrzeitstempel>	String	Für die Aktion "Verzögerung bis " 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": {}
},

Workflowaktion

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 die Ausgaben der untergeordneten oder geschachtelten Logik-App auch in Aktionen verwenden, die der geschachtelten Logik-App folgen, vorausgesetzt, die untergeordnete Logik-App gibt eine Antwort zurück.

Azure Logic Apps ü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. einen Anforderungs - oder HTTP-Trigger .

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

• Damit die Ausgaben aus der geschachtelten Logik-App in Ihrer übergeordneten Logik-App verwendet werden können, muss die geschachtelte Logik-App über eine Antwortaktion verfügen.

"<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": {}
}

Required

Value	Type	Description
< Nested-logic-app-name>	String	Name für die Logik-App, die Sie aufrufen möchten
< Triggername>	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

Value	Type	Description
< Headerinhalt>	JSON-Objekt	Alle Header, die mit dem Aufruf gesendet werden sollen
< Textkörperinhalt>	JSON-Objekt	Beliebiger Nachrichteninhalt, der mit dem Aufruf gesendet werden soll

Outputs

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.

Example

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

Required

Value	Type	Description
< 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

Value	Type	Description
< zählen>	Integer	Standardmäßig werden die Iterationen für jede Schleife gleichzeitig (gleichzeitig oder parallel) bis zum Standardgrenzwert ausgeführt. Informationen zum Ändern dieses Grenzwerts durch Festlegen eines neuen <Anzahlwerts> finden Sie unter Ändern der Parallelität "für jede Schleife".
< Operation-Option>	String	Wenn Sie eine "for each"-Schleife sequenziell anstelle parallel ausführen möchten, legen Sie entweder <die Vorgangsoption> auf Sequential<> die Anzahl auf 1, aber nicht auf beides fest. Weitere Informationen finden Sie unter Sequenzielles Ausführen von „for each“-Schleifen.

Example

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 mit Arraynamen> aus dem Triggertext ab. Im Ausdruck wird der Operator ? verwendet, um einen Ausfall zu vermeiden, falls das Array nicht vorhanden ist:

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

Wenn Aktion

Diese Aktion, bei der es sich um eine bedingte Anweisung handelt, wertet einen Ausdruck aus, der eine Bedingung darstellt, und führt eine andere Verzweigung basierend darauf aus, ob die Bedingung wahr oder falsch ist. 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": {}
}

Value	Type	Description
< Zustand>	JSON-Objekt	Auszuwertende Bedingung, bei der es sich auch um einen Ausdruck handeln kann
< Action-1>	JSON-Objekt	Die auszuführende Aktion, wenn die <Bedingung> als wahr ausgewertet wird
< Aktionsdefinition>	JSON-Objekt	Definition für die Aktion
< Action-2>	JSON-Objekt	Die auszuführende Aktion, wenn die <Bedingung> als falsch 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

Example

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	Result
"ausdruck": "@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.
"ausdruck": "@greater(actions(<'action>').output.value, parameters('<threshold>'))")	Bei Vergleichsfunktionen wird die Aktion nur ausgeführt, wenn die Ausgabe der <Aktion> größer als der <Schwellenwert> ist.
"ausdruck": "@or(greater(actions(<'action>').output.value, parameters('<threshold>')), less(actions('<same-action>').output.value, 100))"	Bei Logikfunktionen und beim Erstellen geschachtelter boolescher Ausdrücke wird die Aktion ausgeführt, wenn die Ausgabe der <Aktion> größer als der <Schwellenwert> oder unter 100 ist.
"ausdruck": "@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.

Bereichsaktion

Diese Aktion gruppiert Aktionen logisch in Bereiche, die ihren eigenen Status erhalten, nachdem die Aktionen in diesem Bereich ausgeführt wurden. 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": {}
      }
   }
}

Required

Value	Type	Description
< inner-action-1... n>	JSON-Objekt	Eine oder mehrere Aktionen, die innerhalb des Bereichs ausgeführt werden
< Aktionseingaben>	JSON-Objekt	Eingaben für jede Aktion

Umschaltaktion

Diese Aktion, auch als Switch-Anweisung bezeichnet, organisiert andere Aktionen in Fällen und weist jedem Fall einen Wert zu, mit Ausnahme des Standardfalls, wenn vorhanden. Wenn Ihr Workflow ausgeführt wird, vergleicht die Switch-Aktion den Wert aus einem Ausdruck, Objekt oder Token mit den für jeden Fall angegebenen Werten. Wenn die Switch-Aktion einen übereinstimmenden Fall findet, führt Ihr Workflow nur die Aktionen für diesen Fall aus. Jedes Mal, wenn die Switch-Aktion ausgeführt wird, ist entweder nur ein übereinstimmende Groß-/Kleinschreibung vorhanden, oder es sind keine Übereinstimmungen vorhanden. Wenn keine Übereinstimmungen vorhanden sind, führt die Switch-Aktion die Standardaktionen aus. 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": {}
}

Required

Value	Type	Description
< expression-object-or-token>	Varies	Ausdruck, JSON-Objekt oder Token für die Auswertung
< Aktionsname>	String	Name der Aktion, die für den übereinstimmenden Fall ausgeführt werden soll
< Aktionsdefinition>	JSON-Objekt	Definition für die Aktion, die für den übereinstimmenden Fall ausgeführt werden soll
< Abgleichswert>	Varies	Wert, der mit dem Auswertungsergebnis verglichen werden soll

Optional

Value	Type	Description
< Standardaktionsname>	String	Name der Standardaktion, die ausgeführt wird, wenn keine übereinstimmenden Fälle vorhanden sind
< Standardaktionsdefinition>	JSON-Objekt	Definition für die Aktion, die ausgeführt wird, wenn kein übereinstimmender Fall vorhanden ist

Example

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, bei der eine weitere E-Mail an den Antwortenden gesendet werden soll, jedoch mit unterschiedlichen Formulierungen in jedem Fall.

"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"
      ]
   }
}

Bis 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": {}
}

Value	Type	Description
< Aktionsname>	String	Name für die Aktion, die Sie in der Schleife ausführen möchten
< Aktionstyp>	String	Aktionstyp, den Sie ausführen möchten
< Aktionseingaben>	Various	Eingaben für die auszuführende Aktion
< Zustand>	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.
< Looptimeout>	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.

Note

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.

Example

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, über 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.

Property	Type	Description	Trigger oder Aktion
runtimeConfiguration.concurrency.runs	Integer	Ändern Sie den Standardgrenzwert für die Anzahl der Workflowinstanzen, die gleichzeitig (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 Auslöser
runtimeConfiguration.concurrency.maximumWaitingRuns	Integer	Ändern Sie den Standardgrenzwert für die Anzahl der Workflowinstanzen, die warten müssen, bis die Logik-App bereits die maximalen gleichzeitigen Instanzen ausführt. Informationen zum Ändern des Standardlimits finden Sie unter Ändern des Limits für wartende Ausführungen.	Alle Auslöser
runtimeConfiguration.concurrency.repetitions	Integer	Ändern Sie den Standardgrenzwert für die Anzahl der "für jede" Schleifeniteration, die gleichzeitig (gleichzeitig oder parallel) ausgeführt werden kann. 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.	Action: Foreach
runtimeConfiguration.paginationPolicy.minimumItemCount	Integer	Für bestimmte Aktionen, die die Paginierung unterstützen und aktiviert sind, gibt dieser Wert die mindestanzahl 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: Abwechslungsreich
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: Abwechslungsreich

Vorgangsoptionen

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

Vorgangsoption	Type	Description	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.	Actions: ApiConnection, HTTP, Response
IncludeAuthorizationHeadersInOutputs	String	Schließen Sie für Logik-Apps, die OAuth mit Microsoft Entra ID aktivieren, um den Zugriff für eingehende Aufrufe an einen anforderungsbasierten Triggerendpunkt zu autorisieren, den Authorization-Header aus dem OAuth-Zugriffstoken in die Triggerausgaben ein. Weitere Informationen finden Sie unter Einschließen des „Authorization“-Headers in Anforderungstriggerausgaben.	Triggers: Request, 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.	Action: 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 Auslöser
SuppressWorkflowHeaders	String	Senden Sie keine x-ms-*-Metadaten in ausgehenden Anforderungen. Azure Logic Apps 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.	Actions: HTTP, Function, APIManagement
SuppressWorkflowHeadersOnResponse	String	Senden Sie keine x-ms-*-Metadatenheader in Antworten auf eingehende Triggeranforderungen. Azure Logic Apps sendet standardmäßig Antworten auf eingehende Anforderungen, die zusätzliche 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.	Triggers: Request, 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 einen Standardgrenzwert. 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 das Parallelitätssteuerelement des Triggers aktivieren, werden Triggerinstanzen parallel bis zum Standardgrenzwert ausgeführt. Zum Ändern dieses Standardparallelitätsgrenzwerts können Sie entweder den Codeansicht-Editor oder den Workflow-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 die Parallelität aktiviert ist, wird der Grenzwert für " Split on " für die Debattierarrays erheblich reduziert. Wenn die Anzahl der Elemente diesen Grenzwert überschreitet, ist die Funktion " Teilen" 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.:

       

       Tip

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

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

       

  • 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 oberen rechten Ecke der Aktion die Auslassungspunkte (...) und dann "Einstellungen" aus.

       

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

       

• 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 Workflow-Designer

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

2. Legen Sie unter "Parallelitätssteuerelement" den Grenzwert auf "Ein" fest.

3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den gewünschten Wert. Um die Logik-App sequenziell auszuführen, ziehen Sie den Schiebereglerwert 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 weist jedoch einen Standardgrenzwert auf. Wenn die Anzahl von gleichzeitig ausgeführten Iterationen dieses Limit erreicht, müssen alle anderen Iterationen auf ihre Ausführung warten.

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

Note

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 Workflow-Designer

1. Wählen Sie in der Schaltfläche "Für jede Aktion" in der oberen rechten Ecke die Schaltfläche mit den Auslassungszeichen (...) und dann "Einstellungen" aus.

2. Legen Sie unter "Parallelitätssteuerelement" "Parallelitätssteuerelement" auf "Ein" fest.

3. Ziehen Sie den Schieberegler Parallelitätsgrad auf den gewünschten Wert. Um die Logik-App sequenziell auszuführen, ziehen Sie den Schiebereglerwert 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 von gleichzeitigen Ausführungen diesen Grenzwert erreicht, müssen alle anderen neuen Workflowinstanzen auf ihre Ausführung warten. Ein Standardgrenzwert ist auch für die Anzahl der wartenden Workflowinstanzen vorhanden. Wenn die Anzahl der wartenden Instanzen diesen Grenzwert erreicht, akzeptiert Azure Logic Apps keine neuen Workflowinstanzen mehr für die Ausführung. Anforderungs- und Webhook-Trigger geben Fehler vom Typ 429 – Zu viele Anforderungen zurück, und sich wiederholende Trigger beginnen damit, Abrufversuche zu überspringen.

Sie können den Standardgrenzwert für die Triggerparallelität sowie den Standardgrenzwert für wartende Ausführungen ändern. Diese Änderung verlangsamt jedoch in erster Linie den Trigger, um die Auslastung aufgrund der Parallelität zu verringern. Wenn Sie beispielsweise einen Abruftrigger haben und die Warteschleife für wartende Ausführungen aufgrund aktiver Ausführungen voll ist, beendet Azure Logic Apps die Abfrage. Wenn Ihr Workflow einen anforderungsbasierten Trigger verwendet und die Warteschleife für wartende Ausführungen voll ist, beginnt Azure Logic Apps mit der Rückgabe des Fehlers 429. Es gibt einige Szenarien, in denen Azure Logic Apps den Abruf durch den Trigger nicht beenden kann, ohne dass es zu Fehlern kommt, und sich dafür entscheidet, solche Ausführungen trotzdem zur Warteschleife hinzuzufügen, ohne dass bei den Aufrufausführungen Fehler auftreten.

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 Workflow-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).

Note

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
      }
   }
}

-or-

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 Workflow-Designer

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

2. Legen Sie unter "Parallelitätssteuerelement" den 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 Workflow-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).

Note

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
      }
   }
}

-or-

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 Workflow-Designer

1. Wählen Sie in der oberen rechten Ecke der Aktion die Auslassungspunkte (...) und dann "Einstellungen" aus.

2. Legen Sie unter "Parallelitätssteuerelement" "Parallelitätssteuerelement" 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 sofort eine Antwort vom Typ "202 ACCEPTED" zurückgibt, nachdem eine Aktion aufgerufen oder eine Anforderung an den angegebenen Endpunkt, den angegebenen Dienst, das System oder die API gesendet wurde. Dieser Code bestätigt, dass der Empfänger die Anforderung akzeptiert, aber die Verarbeitung noch nicht abgeschlossen hat. Die Antwort kann einen location Header enthalten, der die URL und eine Aktualisierungs-ID angibt, die der Aufrufer verwenden kann, um den Status der asynchronen Anforderung kontinuierlich abzufragen oder zu überprüfen, bis der Empfänger die Verarbeitung beendet und eine Erfolgsantwort von "200 OK" oder eine andere Nicht-202-Antwort zurückgibt. Weitere Informationen finden Sie unter Asynchrone Microservice-Integration erzwingt Microservice-Autonomie.

• Im Logik-App-Designer weisen die HTTP-Aktion, DIE APIConnection-Aktionen und die Antwortaktion die Einstellung "Asynchrones Muster " auf. 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 Auslassungspunkte (...) aus, wodurch die Einstellungen der Aktion geöffnet werden.

  2. Suchen Sie die Einstellung für 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:

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

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

• Ersetzen Sie die Abrufversion dieser Aktion durch eine Webhookversion, falls verfügbar.

• Deaktivieren Sie das asynchrone Verhalten der Aktion, indem Sie eine der folgenden Optionen ausführen:

  • Deaktivieren Sie im Logik-App-Designer die Einstellung Asynchrone Muster.

  • Fügen Sie in der JSON-Definition, die der Aktion zugrunde liegt, die Vorgangsoption "DisableAsyncPattern" hinzu.

Deaktivieren der Einstellung für asynchrones Muster

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

2. Suchen Sie die Einstellung für asynchrones Muster , deaktivieren Sie die Einstellung, wenn sie aktiviert ist, und wählen Sie "Fertig" aus.

   

Deaktivieren des asynchronen Musters in der JSON-Definition einer Aktion

Fügen Sie in der zugrunde liegenden JSON-Definition der Aktion die Eigenschaft "DisableAsyncPattern" unter dem Abschnitt der Aktion "inputs" hinzu, und legen Sie sie 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

• Erfahren Sie mehr über das Schema der Definitionssprache für Workflows für Azure Logic Apps.