Azure Logic Apps でのトリガーとアクションの種類のスキーマ リファレンス ガイド

このリファレンスでは、ロジック アプリの基となるワークフロー定義でトリガーとアクションを識別するために使用される一般的な種類について説明します。ワークフロー定義については、ワークフロー定義言語で説明および検証されています。 ロジック アプリで使用できる特定のコネクターのトリガーおよびアクションを見つけるには、コネクタの概要にある一覧を参照してください。

トリガーの概要

すべてのワークフローにはトリガーが含まれています。トリガーには、ワークフローをインスタンス化して開始する呼び出しが定義されています。 一般的なトリガーのカテゴリを次に示します。

  • ポーリング トリガーでは、定期的にサービスのエンドポイントをチェックすることができます。

  • プッシュ トリガーでは、エンドポイントへのサブスクリプションを作成し、コールバック URL を指定して、特定のイベントが発生したかデータが使用可能になったときにエンドポイントからトリガーに通知できるようにすることができます。 このトリガーは、起動するまでの間エンドポイントの応答を待機します。

トリガーには次に示す最上位要素がありますが、一部は省略可能です。

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

必須

種類 説明
<trigger-name> String トリガーの名前
<trigger-type> String トリガーの種類 ("Http" や "ApiConnection" など)
<trigger-inputs> JSON オブジェクト トリガーのビヘイビアーを定義する入力
<time-unit> String トリガーの起動間隔を表す時間の単位: "Second"、"Minute"、"Hour"、"Day"、"Week"、"Month"
<number-of-time-units> 整数型 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。

間隔の最小値と最大値は次のとおりです。

-Month: 1-16 か月
-日: 1-500 日
-時間: 1-12,000 時間
-分: 1-72,000 分
- 秒: 1-9,999,999 秒

たとえば、間隔が 6 で頻度が "Month" の場合、6 か月ごとの繰り返しになります。

省略可能

種類 説明
<array-with-conditions> Array ワークフローを実行するかどうかを決定する 1 つまたは複数の条件を含む配列。 トリガーでのみ使用できます。
<runtime-config-options> JSON オブジェクト 実行時のトリガーのビヘイビアーは、runtimeConfigurationプロパティを設定することによって変更できます。 詳細については、「ランタイム構成の設定」を参照してください。
<splitOn-expression> String 配列を返すトリガーの場合、処理のために配列の項目を複数のワークフロー インスタンスに分割、つまりバッチ解除する式を指定できます。
<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

トリガーの種類の一覧

各トリガーの種類には、トリガーの動作を定義するさまざまなインターフェイスと入力があります。

組み込みのトリガー

トリガーの種類 説明
HTTP エンドポイントをチェックまたはポーリングします。 このエンドポイントは特定のトリガー コントラクトに準拠する必要があり、そのためには、202 非同期パターンを使用するか、配列を返す必要があります。
HTTPWebhook ロジック アプリ用の呼び出し可能なエンドポイントを作成しますが、登録または登録解除を行うために指定された URL を呼び出します。
Recurrence 定義されているスケジュールに基づいて呼び出されます。 今後このトリガーを呼び出す日時を設定できます。 頻度に基づいて、ワークフローを実行する時間数および日数を指定することもできます。
Request ロジック アプリ用の呼び出し可能なエンドポイントを作成します。"手動" トリガーとも呼ばれます。 例として、「HTTP エンドポイントを通じてワークフローを呼び出し、トリガーし、入れ子にする」をご覧ください。

マネージド API トリガー

トリガーの種類 説明
ApiConnection Microsoft マネージド API または "コネクタ" を使用して、エンドポイントのチェックまたは "ポーリング" を行います。
ApiConnectionWebhook 登録または登録解除を行う Microsoft マネージド API または "コネクタ" を呼び出して、ロジック アプリのワークフロー用の呼び出し可能なエンドポイントを作成します。

トリガー - 詳細なリファレンス

APIConnection トリガー

このトリガーでは、Microsoft マネージド API または "コネクタ" を使用してエンドポイントをチェックまたは "ポーリング" し、このトリガーのパラメーターを、エンドポイントに基づいて異なるパラメーターにすることができます。 このトリガー定義の多くのセクションは省略可能です。 このトリガーのビヘイビアーは、セクションが含まれるかどうかによって異なります。

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

必須

種類 説明
<APIConnection_trigger_name> String トリガーの名前
<connection-name> String ワークフローに使用するマネージド API への接続の名前
<method-type> String マネージド API と通信するための HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、"DELETE"
<api-operation> String 呼び出す対象の API 操作
<time-unit> String トリガーの起動間隔を表す時間の単位: "Second"、"Minute"、"Hour"、"Day"、"Week"、"Month"
<number-of-time-units> 整数型 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。

間隔の最小値と最大値は次のとおりです。

-Month: 1-16 か月
-日: 1-500 日
-時間: 1-12,000 時間
-分: 1-72,000 分
- 秒: 1-9,999,999 秒

たとえば、間隔が 6 で頻度が "Month" の場合、6 か月ごとの繰り返しになります。

省略可能

種類 説明
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<query-parameters> JSON オブジェクト API 呼び出しに含める任意のクエリ パラメーター。 たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。
<max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまでは (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
<max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
<splitOn-expression> String 配列を返すトリガーの場合、使用する配列をこの式で参照すると、"for each" ループを使わずに、配列の項目ごとにワークフローを作成して実行することができます。

たとえば、@triggerbody()?['value'] という式は、トリガー本文の内容の中に返される配列の項目を表します。

<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

出力

要素 Type 説明
headers JSON オブジェクト 応答のヘッダー
body JSON オブジェクト 応答の本文
status code Integer 応答の状態コード

このトリガー定義では、職場または学校のアカウントの受信トレイ内の電子メールを毎日チェックします。

"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 トリガー

このトリガーは、Microsoft マネージド API を使用してエンドポイントにサブスクリプション要求を送信し、エンドポイントからの応答の送信先となるコールバック URL を指定して、エンドポイントの応答を待機します。 詳細については、エンドポイントのサブスクリプションに関する説明を参照してください。

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

必須

種類 説明
<connection-name> String ワークフローに使用するマネージド API への接続の名前
<body-content> JSON オブジェクト マネージド API にペイロードとして送信するメッセージの内容

省略可能

種類 説明
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<query-parameters> JSON オブジェクト API 呼び出しに含めるクエリ パラメーター

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。

<max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまでは (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
<max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
<splitOn-expression> String 配列を返すトリガーの場合、使用する配列をこの式で参照すると、"for each" ループを使わずに、配列の項目ごとにワークフローを作成して実行することができます。

たとえば、@triggerbody()?['value'] という式は、トリガー本文の内容の中に返される配列の項目を表します。

<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

このトリガー定義では、Office 365 Outlook API への登録を行い、API エンドポイントに対してコールバック URL を指定した後、新しい電子メールが到着してエンドポイントが応答するのを待機します。

"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 トリガー

このトリガーからは、指定の繰り返しスケジュールに基づき、指定の HTTP または HTTPS エンドポイントに要求が送信されます。 その後、トリガーにより応答が確認され、ワークフローの実行状況が判断されます。 詳細については、「Azure Logic Apps から HTTP または HTTPS でサービス エンドポイントを呼び出す」を参照してください。

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

必須

プロパティ 種類 説明
method <method-type> String 外向き要求を送信するために使用するメソッド:"GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
uri <HTTP-or-HTTPS-endpoint-URL> String 外向き要求を送信する HTTP または HTTPS エンドポイント URL。 最大文字列サイズ: 2 KB (キロバイト)

Azure のサービスまたはリソースの場合、この URI 構文には、アクセスするリソース ID とパスが含まれます。

frequency <time-unit> String トリガーの起動間隔を表す時間の単位: "Second"、"Minute"、"Hour"、"Day"、"Week"、"Month"
interval <number-of-time-units> 整数型 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。

間隔の最小値と最大値は次のとおりです。

-Month: 1-16 か月
-日: 1-500 日
-時間: 1-12,000 時間
-分: 1-72,000 分
- 秒: 1-9,999,999 秒

たとえば、間隔が 6 で頻度が "Month" の場合、6 か月ごとの繰り返しになります。

省略可能

プロパティ 種類 説明
headers <header-content> JSON オブジェクト 要求に含める必要があるヘッダー

たとえば、言語と型を設定するには、次のようにします。

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }

queries <query-parameters> JSON オブジェクト 要求で使用する必要があるクエリ パラメーター

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を要求に追加します。

body <body-content> JSON オブジェクト ペイロードとして要求で送信するメッセージの内容
authentication <authentication-type-and-property-values> JSON オブジェクト 送信要求の認証のために要求で使用される認証モデル。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。 Scheduler 以外に、authority プロパティがサポートされています。 指定しない場合の既定値は https://management.azure.com/ ですが、別の値を使用できます。
retryPolicy > type <retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
runs <max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまでは (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
maximumWaitingRuns <max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
operationOptions <operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

出力

要素 Type 説明
headers JSON オブジェクト 応答のヘッダー
body JSON オブジェクト 応答の本文
status code Integer 応答の状態コード

受信要求の要件

エンドポイントがロジック アプリと適切に連携するためには、特定のトリガー パターンまたはコントラクトに準拠し、以下の応答プロパティを認識する必要があります。

プロパティ Required 説明
status code はい 状態コード "200 OK" によって実行が開始されます。 その他のすべての状態コードでは実行は開始されません。
Retry-after ヘッダー いいえ ロジック アプリがエンドポイントを再度ポーリングするまでの秒数
Location ヘッダー いいえ 次のポーリング間隔で呼び出す URL です。 指定されていない場合は、元の URL が使われます。

さまざまな要求の動作の例

status code 再試行までの時間 動作
200 {なし} ワークフローを実行し、定義済みの繰り返しの後に、まだデータがあるかどうかを再確認します。
200 10 秒 ワークフローを実行し、10 秒後に、まだデータがあるかどうかを再確認します。
202 60 秒 ワークフローをトリガーしません。 次の試行は、定義済みの繰り返しに従って 1 分後に行われます。 定義済みの繰り返しが 1 分未満の場合は、retry-after ヘッダーが優先されます。 それ以外の場合、定義済みの繰り返しが使用されます。
400 {なし} 正しくない要求です。ワークフローを実行しないでください。 retryPolicy が定義されていない場合は、既定のポリシーが使用されます。 再試行回数に達すると、定義済みの繰り返しの後に、トリガーはデータがあるかどうかを再確認します。
500 {なし} サーバー エラーです。ワークフローを実行しないでください。 retryPolicy が定義されていない場合は、既定のポリシーが使用されます。 再試行回数に達すると、定義済みの繰り返しの後に、トリガーはデータがあるかどうかを再確認します。

HTTPWebhook トリガー

このトリガーを使用すると、指定したエンドポイントの URL を呼び出してサブスクリプションを登録できるエンドポイントを作成することで、ロジック アプリを呼び出し可能にすることができます。 ワークフロー内にこのトリガーを作成すると、送信要求からサブスクリプションを登録する呼び出しを行うことができます。 そのようにして、トリガーはイベントのリッスンを開始できます。 操作によってこのトリガーが無効になったときは、送信要求においてサブスクリプションを取り消す呼び出しが自動的に行われます。 詳細については、エンドポイントのサブスクリプションに関する説明を参照してください。

HTTPWebhook トリガーに非同期制限を指定することもできます。 トリガーのビヘイビアーは、どのセクションを使用し、どのセクションを省略するかによって異なります。

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

<method-type> などの一部の値は、"subscribe" オブジェクトと "unsubscribe" オブジェクトの両方に使用できます。

必須

種類 説明
<method-type> String サブスクリプション要求に使用する HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
<endpoint-subscribe-URL> String サブスクリプション要求の送信先であるエンドポイント URL

省略可能

種類 説明
<method-type> String 取り消し要求に使用する HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
<endpoint-unsubscribe-URL> String 取り消し要求の送信先であるエンドポイント URL
<body-content> String サブスクリプションまたは取り消しの要求で送信するメッセージの内容
<authentication-type> JSON オブジェクト 送信要求の認証のために要求で使用される認証モデル。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまではすべて (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
<max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

出力

要素 Type 説明
headers JSON オブジェクト 応答のヘッダー
body JSON オブジェクト 応答の本文
status code Integer 応答の状態コード

このトリガーでは、指定したエンドポイントへのサブスクリプションを作成し、一意のコールバック URL を指定して、新たに公開される技術情報記事を待機します。

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

Recurrence トリガー

このトリガーは、指定した繰り返しスケジュールに基づいて実行され、定期実行ワークフローを作成するための簡単な方法として利用できます。

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

必須

種類 説明
<time-unit> String トリガーの起動間隔を表す時間の単位: "Second"、"Minute"、"Hour"、"Day"、"Week"、"Month"
<number-of-time-units> 整数型 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。

間隔の最小値と最大値は次のとおりです。

-Month: 1-16 か月
-日: 1-500 日
-時間: 1-12,000 時間
-分: 1-72,000 分
- 秒: 1-9,999,999 秒

たとえば、間隔が 6 で頻度が "Month" の場合、6 か月ごとの繰り返しになります。

省略可能

種類 説明
<start-date-time-with-format-YYYY-MM-DDThh:mm:ss> String この形式の開始日時:

タイム ゾーンを指定する場合は YYYY-MM-DDThh:mm:ss

または

タイム ゾーンを指定しない場合は YYYY-MM-DDThh:mm:ssZ

たとえば、2017 年 9 月 18 日午後 2 時の場合は、「2017-09-18T14:00:00」と指定し、"太平洋標準時" などのタイム ゾーンを指定します。タイム ゾーンを指定しない場合は、「2017-09-18T14:00:00Z」と指定します。

注: この開始時刻には、最大で 49 年先の時刻を指定できます。また、UTC の日付と時刻の形式 (ただし、UTC オフセットを除く) で日付と時刻に関する ISO 8601 規格に従っている必要があります。 タイム ゾーンを指定しなかった場合は、末尾にスペースを入れず、アルファベットの "Z" を追加してください。 この "Z" は、同等の航海時間を表します。

単純なスケジュールでは、開始時刻と最初の実行時刻が一致するのに対して、複雑なスケジュールでは、トリガーが作動するのは開始時刻以降となります。 開始日時の詳細については、定期的に実行されるタスクの作成とスケジュールに関するページを参照してください。

<time-zone> String 開始時刻を指定したときに限り適用されます。このトリガーに UTC オフセットを指定することはできないためです。 適用するタイム ゾーンを指定してください。
<one-or-more-hour-marks> 整数または整数配列 frequency に "Day" または "Week" を指定した場合、ワークフローを実行する時刻として 0 ~ 23 の 1 つまたは複数の整数をコンマ区切りで指定できます。

たとえば "10"、"12"、"14" を指定した場合、時刻のマークとして 10 AM、12 PM、2 PM が取得されます。

<one-or-more-minute-marks> 整数または整数配列 frequency に "Day" または "Week" を指定した場合、ワークフローを実行する時刻の分として 0 ~ 59 の 1 つまたは複数の整数をコンマ区切りで指定できます。

たとえば上の例で指定した時を使用し、分の要素に「30」を指定した場合、実行時刻は 10:30 AM、12:30 PM、2:30 PM となります。

weekDays 文字列または文字列配列 frequency に "Week" を指定した場合、ワークフローを実行する 1 日または複数の日 ("Monday"、"Tuesday"、"Wednesday"、"Thursday"、"Friday"、"Saturday"、および "Sunday") をコンマ区切りで指定できます
<max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまではすべて (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
<max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

例 1

次の基本的な Recurrence トリガーは、毎日実行されます。

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

例 2

トリガーを起動する開始日時を指定できます。 次の Recurrence トリガーは、指定した日に開始され、毎日起動します。

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

例 3

次の Recurrence トリガーは、2017 年 9 月 9 日午後 2 時に開始され、毎週月曜日の太平洋標準時の午前 10 時 30 分、午後 12 時 30 分、および午後 2 時 30 分に起動します。

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

このトリガーの詳細と例については、定期的に実行されるタスクの作成とスケジュールに関するページをご覧ください。

Request トリガー

このトリガーを使用すると、受信要求を受け入れることができるエンドポイントを作成して、ロジック アプリを呼び出し可能にすることができます。 このトリガーには、トリガーが受信要求から受信するペイロード、つまり入力を記述および検証する JSON スキーマを指定します。 そのスキーマを使用すると、ワークフロー内の後続のアクションから、より簡単にトリガーのプロパティを参照することもできます。

このトリガーを呼び出すには、listCallbackUrl API を使用する必要があります。このトリガーについては、Workflow Service REST API の説明を参照してください。 このトリガーを HTTP エンドポイントとして使用する方法については、「HTTP エンドポイントを通じてワークフローを呼び出し、トリガーし、入れ子にする」をご覧ください。

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

必須

種類 説明
<property-name> String ペイロードを記述する JSON スキーマのプロパティの名前
<property-type> String プロパティの型

省略可能

種類 説明
<method-type> String 受信要求でのロジック アプリの呼び出しに使用する必要があるメソッド: "GET"、"PUT"、"POST"、"PATCH"、"DELETE"
<relative-path-for-accepted-parameter> String 使用しているエンドポイントの URL で受け入れ可能なパラメーターの相対パス
<required-properties> Array 値が必要な 1 つ以上のプロパティ
<max-runs> Integer 既定では、ワークフロー インスタンスは、既定の制限に達するまではすべて (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。
<max-runs-queue> Integer ワークフローで既に最大数のインスタンスが実行されている場合 (最大数は runtimeConfiguration.concurrency.runs プロパティに基づいて変更可能)、新たな実行は、既定の制限に達するまでこのキューに入れられます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。
<operation-option> String operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

このトリガーでは、受信要求から HTTP POST メソッドを使用してこのトリガーを呼び出す必要があることを指定し、受信要求からの入力を検証するスキーマを含めています。

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

トリガーの条件

トリガーのみですが、どのトリガーにも、ワークフローを実行するかどうかを決める条件を表した 1 つまたは複数の式を含む配列を追加できます。 ワークフロー内のトリガーに conditions プロパティを追加するには、ロジック アプリをコード ビュー エディターで開きます。

たとえば、Web サイトから内部サーバー エラーが返されたときに限ってトリガーが起動するように指定する場合は、次のように conditions プロパティ内のトリガーの状態コードを参照します。

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

既定では、"200 OK" の応答を受信した後に限り、トリガーが起動します。 式でトリガーの状態コードを参照すると、トリガーの既定のビヘイビアーが置き換えられます。 そのため、状態コード "200" と "201" など、複数の状態コードに対してトリガーを起動させるには、この式を条件として含める必要があります。

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

配列で複数の実行をトリガーする

トリガーがワークフローで処理する配列を受け取った場合、"for each" ループが各配列項目を処理するのに時間がかかりすぎることがあります。 この場合は、トリガーで SplitOn プロパティを使用すると、配列を "バッチ解除" できます。 バッチ解除すると、配列の項目が分割されて、配列の項目ごとに実行される新しいワークフロー インスタンスが開始されます。 このアプローチが役立つのは、たとえば、エンドポイントをポーリングするときに、ポーリング間隔のたびに複数の新しい項目が返される場合です。

トリガーの Swagger ファイルに、配列であるペイロードが記述されている場合、SplitOn プロパティが自動的にトリガーに追加されます。 それ以外の場合は、バッチ解除する配列を含む応答ペイロード内にこのプロパティを追加します。

SplitOn 機能を使用する前に、以下の考慮事項を確認してください。

  • トリガー コンカレンシーが有効な場合、SplitOn 上限が大幅に下がります。 項目数がこの上限を超えると、SplitOn 機能は無効になります。

  • 同期応答パターンで SplitOn 機能を使用することはできません。 SplitOn プロパティを使用し、応答アクションを含むワークフローは非同期に実行され、202 ACCEPTED 応答を直ちに送信します。

  • SplitOn が 1 回のワークフロー実行で処理できる配列項目の最大数については、「制限と構成」を参照してください。

API を呼び出して次の応答を受信する HTTP トリガーがあるとします。

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

ワークフローに必要なのは Rows の配列のコンテンツだけなので、次の例のようなトリガーを作成できます。

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

注意

SplitOn コマンドを使う場合、配列の外側にあるプロパティを取得することはできません。 つまり、この例では、API から返される応答で status プロパティを取得できません。

Rowsプロパティが存在しない場合のエラーを回避するために、この例では ? 演算子を使用しています。

これで、このワークフロー定義では、@triggerBody().name を使用して name の値 (最初の実行から "customer-name-one"、2 番目の実行から "customer-name-two") を取得できます。 つまり、トリガーの出力は次の例のようになります。

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

アクションの概要

Azure Logic Apps には、さまざまなアクションの種類があります。アクションの種類ごとに異なる入力を使用して、アクションの固有のビヘイビアーを定義します。 アクションには以下の最上位要素がありますが、一部は省略可能です。

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

必須

種類 説明
<action-name> String アクションの名前
<action-type> String アクションの種類 ("Http" や "ApiConnection" など)
<input-name> String アクションのビヘイビアーを定義する入力の名前
<input-value> 各種 文字列、整数、JSON オブジェクトなどを入力値にすることができます
<previous-trigger-or-action-status> JSON オブジェクト 現在のこのアクションを実行する前に直ちに実行しなければならない、トリガーまたはアクションの名前と結果の状態

省略可能

種類 説明
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「再試行ポリシー」を参照してください。
<runtime-config-options> JSON オブジェクト 一部のアクションについては、runtimeConfiguration プロパティを設定してアクションのビヘイビアーを実行時に変更できます。 詳細については、「ランタイム構成の設定」を参照してください。
<operation-option> String 一部のアクションについては、operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。

アクションの種類の一覧

よく使用するアクションの種類をいくつか示します。

組み込みアクション

アクションの種類 説明
作成 さまざまな種類を持つ可能性がある複数の入力から、単一の出力を作成します。
JavaScript コードの実行 特定の条件に適合する JavaScript コード スニペットを実行します。 コードの要件と詳細については、「Add and run code snippets with inline code」(インライン コードを使用してコード スニペットを追加および実行する) を参照してください。
Function Azure 関数を呼び出します。
HTTP HTTP エンドポイントを呼び出します。
結合 配列内のすべての項目から 1 個の文字列を作成します。それらの項目は指定した区切り文字を使って区切ります。
Parse JSON JSON のコンテンツ内にあるプロパティから、ユーザー フレンドリなトークンを作成します。 その後はロジック アプリ内にトークンを含めることで、それらのプロパティを参照できます。
Query 条件またはフィルターに基づいて別の配列内の項目から配列を作成します。
Response 受信する呼び出しまたは要求に対する応答を作成します。
選択 指定したマップに基づいて別の配列の項目を変換することによって、JSON オブジェクトの配列を作成します。
Table 配列から CSV または HTML のテーブルを作成します。
Terminate アクティブに実行中のワークフローを停止します。
Wait 指定した期間、または指定した日付と時刻まで、ワークフローを一時停止します。
Workflow ワークフローを別のワークフローの中に入れ子にします。

マネージド API アクション

アクションの種類 説明
ApiConnection Microsoft マネージド APIを使用して HTTP エンドポイントを呼び出します。
ApiConnectionWebhook HTTP Webhook と同様に動作しますが、Microsoft マネージド API を使用します。

ワークフローを制御するアクション

これらのアクションでは、ワークフローの実行を制御し、他のアクションを含めることができます。 ワークフローを制御するアクションの外側から、そのワークフロー制御アクションの内部にあるアクションを直接参照できます。 たとえば、スコープの内部で Http アクションを使用している場合、ワークフロー内のどこからでも @body('Http') 式を参照できます。 ただし、ワークフロー制御アクションの内部に存在するアクションは、同じワークフロー制御構造体の中にある他のアクションの "後に実行" することしかできません。

アクションの種類 説明
ForEach 配列内のすべての項目に対して同じアクションをループ実行します。
If 指定した条件が true であるか false であるかに基づいて、アクションを実行します。
Scope 一連のアクションから得られるグループの状態に基づいて、アクションを実行します。
Switch 式、オブジェクト、またはトークンの値が、各ケースによって指定された値と一致する場合、ケース別に構成されたアクションを実行します。
Until 指定した条件が true になるまで、アクションをループ実行します。

アクション - 詳細なリファレンス

APIConnection アクション

HTTP 要求を Microsoft マネージド API に送信するアクションです。このアクションには、API およびパラメーターに関する情報と、有効な接続への参照が必要です。

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

必須

種類 説明
<action-name> String コネクタによって指定されるアクションの名前
<api-name> String 接続に使用される Microsoft マネージド API の名前
<method-type> String API を呼び出すための HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
<api-operation> String 呼び出す対象の API 操作

省略可能

種類 説明
<other-action-specific-input-properties> JSON オブジェクト この特定のアクションに適用するその他の入力プロパティ
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<query-parameters> JSON オブジェクト API 呼び出しに含める任意のクエリ パラメーター。

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。

<other-action-specific-properties> JSON オブジェクト この特定のアクションに適用するその他のプロパティ

この定義は、Office 365 Outlook コネクタのメールの送信アクションを記述しています。このアクションは、Microsoft マネージド API です。

"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 アクション

このアクションは、Microsoft マネージド API を使用して HTTP 経由でエンドポイントにサブスクリプション要求を送信し、エンドポイントからの応答の送信先となるコールバック URL を指定して、エンドポイントの応答を待機します。 詳細については、エンドポイントのサブスクリプションに関する説明を参照してください。

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

<method-type> などの一部の値は、"subscribe" オブジェクトと "unsubscribe" オブジェクトの両方に使用できます。

必須

種類 説明
<action-name> String コネクタによって指定されるアクションの名前
<method-type> String エンドポイントの登録または登録解除に使用する HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
<api-subscribe-URL> String API への登録に使用する URI

省略可能

種類 説明
<api-unsubscribe-URL> String API からの登録解除に使用する URI
<header-content> JSON オブジェクト 要求で送信するヘッダー

たとえば、言語と種類を要求に設定するには、次のようにします。

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }

<body-content> JSON オブジェクト 要求で送信するメッセージの内容
<authentication-type> JSON オブジェクト 送信要求の認証のために要求で使用される認証モデル。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。
<retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<query-parameters> JSON オブジェクト API 呼び出しに含めるクエリ パラメーター

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。

<other-action-specific-input-properties> JSON オブジェクト この特定のアクションに適用するその他の入力プロパティ
<other-action-specific-properties> JSON オブジェクト この特定のアクションに適用するその他のプロパティ

ApiConnectionWebhook アクションに対する制限も、HTTP 非同期制限と同じ方法で指定できます。

作成アクション

このアクションでは、複数の入力から単一の出力を作成します。入力には式も含みます。 出力と入力の両方に、Azure Logic Apps でネイティブにサポートされている任意の型 (配列、JSON オブジェクト、XML、バイナリなど) を使用できます。 このアクションの出力を他のアクションで使用できます。

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

必須

種類 説明
<inputs-to-compose> Any 単一の出力を作成するための入力

例 1

このアクション定義では、abcdefg に後続のスペースと値 1234 を結合します。

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

このアクションで作成される出力は次のようになります。

abcdefg 1234

例 2

このアクション定義では、abcdefg が格納された文字列型の変数と、1234 が格納された整数型の変数を結合します。

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

このアクションで作成される出力は次のようになります。

"abcdefg1234"

JavaScript コードの実行アクション

このアクションは、JavaScript コード スニペットを実行し、ワークフロー内の後続のアクションが参照できるトークンを使用して結果を返します。

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

必須

種類 説明
<JavaScript-code-snippet> 場合により異なる 実行する JavaScript コード。 コードの要件と詳細については、「ワークフローでコード スニペットを実行する」を参照してください。

コード スニペットは、code 属性で、読み取り専用の workflowContext オブジェクトを入力として使用できます。 このオブジェクト内のサブプロパティにより、コードからワークフロー内のトリガーや以前のアクションの出力結果にアクセスできます。 workflowContext オブジェクトの詳細についは、「workflowContext オブジェクトを使用してトリガーとアクションの出力を参照する」をご覧ください。

場合により必須

explicitDependencies 属性は、トリガー、前のアクション、またはその両方からの結果を依存関係としてコード スニペットに明示的に含めることを指定します。 これらの依存関係の追加の詳細については、「インライン コード アクションに依存関係をパラメーターとして追加する」を参照してください。

includeTrigger 属性には、true または false を指定できます。

種類 説明
<preceding-actions> 文字列配列 JSON 形式のアクション名を依存関係として持つ配列。 必ず、ワークフロー定義に示されるアクション名を使用してください。アクション名ではスペース (" ") ではなく、アンダースコア (_) を使用してください。

例 1

このアクションは、ロジック アプリ ワークフローの名前を取得して、結果として "Hello world from <logic-app-name>" というテキストを返すコードを実行します。 この例では、コードは読み取り専用の workflowContext オブジェクトを介して workflowContext.workflow.name プロパティにアクセスすることで、ワークフローの名前を参照します。 workflowContext オブジェクトの使用方法の詳細については、「Reference trigger and action results in your code」(コード内でトリガーとアクションの結果を参照する) を参照してください。

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

例 2

このアクションは、Outlook アカウントに新しい電子メールが届くとトリガーされるロジック アプリ ワークフローでコードを実行します。 このワークフローでは、受信した電子メールの内容と承認要求を転送する、Office 365 Outlook の承認メールの送信アクションも使用します。

このコードは、電子メール メッセージの Body プロパティから電子メール アドレスを抽出し、そのアドレスと承認アクションの SelectedOption プロパティ値を返します。 このアクションは、承認メールの送信アクションを explicitDependencies オブジェクト内の actions オブジェクトに依存関係として明示的に含めます。

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

Function アクション

あらかじめ作成した Azure 関数を呼び出すアクションです。

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

必須

種類 説明
<Azure-function-ID> String 呼び出す対象である Azure 関数を表すリソース ID。 この値の形式は次のとおりです。

"/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Web/sites/<Azure-function-app-name>/functions/<Azure-function-name>"

<method-type> String 関数の呼び出しに使用する HTTP メソッド: "GET"、"PUT"、"POST"、"PATCH"、または "DELETE"

指定しない場合、既定のメソッドは "POST" です。

省略可能

種類 説明
<header-content> JSON オブジェクト 呼び出しで送信するヘッダー

たとえば、言語と種類を要求に設定するには、次のようにします。

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }

<body-content> JSON オブジェクト 要求で送信するメッセージの内容
<query-parameters> JSON オブジェクト API 呼び出しに含めるクエリ パラメーター

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。

<other-action-specific-input-properties> JSON オブジェクト この特定のアクションに適用するその他の入力プロパティ
<other-action-specific-properties> JSON オブジェクト この特定のアクションに適用するその他のプロパティ

ロジック アプリを保存すると、参照される関数に対する以下のチェックが Logic Apps エンジンによって実行されます。

  • 使用するワークフローからその関数にアクセスできる必要があります。

  • ワークフローでは、標準 HTTP トリガーまたは汎用 JSON webhook トリガーだけを使用できます。

    トリガーの URL が Logic Apps エンジンによって取得され、キャッシュされます。その URL が実行時に使用されます。 ただし、キャッシュされた URL がいずれかの操作によって無効化された場合、Function アクションは実行時に失敗します。 この問題を解決するには、ロジック アプリをもう一度保存して、ロジック アプリによってトリガーの URL の取得とキャッシュが再度行われるようにします。

  • 関数にルートを定義することはできません。

  • 使用できる承認レベルは、"function" と "anonymous" だけです。

このアクション定義では、あらかじめ作成した "GetProductID" 関数を呼び出します。

"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 アクション

指定の HTTP または HTTPS エンドポイントに要求を送信し、応答を調べてワークフローの実行状況を判断するアクションです。 詳細については、「Azure Logic Apps から HTTP または HTTPS でサービス エンドポイントを呼び出す」を参照してください。

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

必須

プロパティ 種類 説明
method <method-type> String 外向き要求を送信するために使用するメソッド:"GET"、"PUT"、"POST"、"PATCH"、または "DELETE"
uri <HTTP-or-HTTPS-endpoint-URL> String 外向き要求を送信する HTTP または HTTPS エンドポイント URL。 最大文字列サイズ: 2 KB (キロバイト)

Azure のサービスまたはリソースの場合、この URI 構文には、アクセスするリソース ID とパスが含まれます。

省略可能

プロパティ 種類 説明
headers <header-content> JSON オブジェクト 要求に含める必要があるヘッダー

たとえば、言語と型を設定するには、次のようにします。

"headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }

queries <query-parameters> JSON オブジェクト 要求で使用する必要があるクエリ パラメーター

たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。

body <body-content> JSON オブジェクト ペイロードとして要求で送信するメッセージの内容
authentication <authentication-type-and-property-values> JSON オブジェクト 送信要求の認証のために要求で使用される認証モデル。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。 Scheduler 以外に、authority プロパティがサポートされています。 指定しない場合の既定値は https://management.azure.com/ ですが、別の値を使用できます。
retryPolicy > type <retry-behavior> JSON オブジェクト 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。
<other-action-specific-input-properties> <input-property> JSON オブジェクト この特定のアクションに適用するその他の入力プロパティ
<other-action-specific-properties> <property-value> JSON オブジェクト この特定のアクションに適用するその他のプロパティ

このアクション定義では、指定したエンドポイントに要求を送信して、最新のニュースを取得します。

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

結合アクション

配列内のすべての項目から 1 個の文字列を作成するアクションです。それらの項目は指定した区切り文字を使って区切ります。

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

必須

種類 説明
<array> Array ソース項目を渡す配列または式。 式を指定する場合は、その式を二重引用符で囲みます。
<delimiter> 1 文字の文字列 文字列内の各項目を区切る文字

あらかじめ作成した "myIntegerArray" という変数があり、次の整数型配列が格納されているとします。

[1,2,3,4]

このアクション定義では、式の中で variables() 関数を使用してこの変数から値を取得し、コンマで区切ったそれらの値を含む "1,2,3,4" という文字列を作成します。

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

JSON の解析アクション

JSON コンテンツのプロパティからユーザー フレンドリなフィールドまたはトークンを作成するアクションです。 作成したトークンをロジック アプリ内でプロパティの代わりに使用して、それらのプロパティにアクセスできます。 たとえば、Azure Service Bus や Azure Cosmos DB といったサービスからの JSON 出力を使用する場合、このアクションをロジック アプリに追加することで、その出力に含まれるデータをより簡単に参照できます。

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

必須

種類 説明
<JSON-source> JSON オブジェクト 解析する対象の JSON コンテンツ
<JSON-schema> JSON オブジェクト 基になる JSON コンテンツを記述する JSON スキーマ。ソースの JSON コンテンツを解析するために、アクションによって使用されます。

ヒント:Logic Apps デザイナーで、スキーマを指定するかサンプル ペイロードを入力すると、アクションによるスキーマの作成が可能になります。

このアクション定義により、ワークフローで使用できる以下のトークンが作成されますが、これらを使用できるのは、Parse JSON アクションに続いて実行されるアクション内に限ります。

FirstNameLastNameEmail

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

この例では、アクションによる解析の対象である JSON コンテンツを "content" プロパティで指定しています。 スキーマを生成するためのサンプル ペイロードとして、次の JSON コンテンツを指定することもできます。

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

"schema" プロパティでは、JSON コンテンツを記述するために使用される JSON スキーマを指定します。

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

クエリ アクション

指定された条件またはフィルターに基づいて、別の配列内の項目から配列を作成するアクションです。

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

必須

種類 説明
<array> Array ソース項目を渡す配列または式。 式を指定する場合は、その式を二重引用符で囲みます。
<condition-or-filter> String ソース配列内の項目のフィルター処理に使用される条件

:条件を満たす値がない場合は、アクションによって空の配列が作成されます。

このアクション定義では、指定した値 2 より大きい値を持つ配列を作成します。

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

応答アクション

HTTP 要求に対する応答のペイロードを作成するアクションです。

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

必須

種類 説明
<response-status-code> Integer 受信要求に送信される HTTP 状態コード。 既定のコードは "200 OK" ですが、2xx、4xx、または 5xx で始まる任意の有効な状態コードを使用できます。3xxx で始まるコードは使用できません。

省略可能

種類 説明
<response-headers> JSON オブジェクト 応答に含める 1 つまたは複数のヘッダー
<response-body> 各種 応答本文。文字列、JSON オブジェクト、または先行アクションからのバイナリ コンテンツとすることができます。

このアクション定義では、指定した状態コード、メッセージ本文、メッセージ ヘッダーを使用して、HTTP 要求への応答を作成します。

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

制限事項

他のアクションとは異なり、Response アクションには特別な制限があります。

  • ワークフローで Response アクションを使用できるのは、ワークフローが HTTP 要求トリガーで始まる場合だけです。つまり、ワークフローは HTTP 要求によってトリガーされる必要があります。

  • Response アクションはワークフロー内のどの位置でも使用できます。例外は、Foreach ループ、Until ループ、順次ループ、並列分岐です。

  • 元の要求でワークフローの応答が取得されるのは、Response アクションに必要なすべてのアクションが、HTTP のタイムアウト期限内に終了した場合だけです。

    ただし、ワークフローが、入れ子になったワークフローとして別のロジック アプリを呼び出す場合、親ワークフローは、入れ子になったワークフローが終了するまで時間がどれだけ経過しても関係なく、入れ子になったワークフローが終了するまで待機します。

  • ワークフローで Response アクションと同期応答パターンを使用している場合は、同時にトリガー定義で splitOn コマンドを使用することはできません。理由は、そのコマンドによって複数の実行が作成されるからです。 PUT メソッドを使用する場合は、これに該当しているかどうかを確認し、該当している場合は、"bad request (無効な要求)" 応答を返します。

    そうでない場合、ワークフローで splitOn コマンドと Response アクションを使用すると、ワークフローは非同期で実行され、"202 ACCEPTED" 応答が直ちに返されます。

  • ワークフローの実行が Response アクションに達したとき、受信要求が既に応答を受信している場合は、Response アクションは競合を理由に "Failed" とマークされます。 その結果、ロジック アプリの実行も "Failed" 状態にマークされます。

選択アクション

指定したマップに基づいて別の配列の項目を変換することによって、JSON オブジェクトの配列を作成するアクションです。 主力配列とソース配列は常に同じ数の項目を持ちます。 出力配列内のオブジェクトの数は変更できませんが、それらのオブジェクト全体にプロパティとプロパティの値を追加または削除できます。 select プロパティには、ソース配列内の項目を変換するためのマップを定義する、キーと値のペアを少なくとも 1 つ指定します。 キーと値のペアは、出力配列内のすべてのオブジェクトのプロパティとその値を表します。

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

必須

種類 説明
<array> Array ソース項目を渡す配列または式。 式は必ず二重引用符で囲みます。

:ソース配列が空の場合、アクションによって空の配列が作成されます。

<key-name> String <expression> の結果に割り当てられたプロパティ名

出力配列内のすべてのオブジェクトに新しいプロパティを追加するには、そのプロパティの <key-name> と、プロパティ値を表す <expression> を指定します。

あるプロパティを配列内のすべてのオブジェクトから削除するには、そのプロパティの <key-name> を省略します。

<expression> String ソース配列の項目を変換し、結果を <key-name> に代入する式

Select アクションでは、出力として配列が作成されます。この出力を使用するアクションは、配列を受け入れるか、配列をコンシューマー アクションで受け入れられる型に変換する必要があります。 たとえば、出力配列を文字列に変換する場合は、その配列を Compose アクションに渡し、Compose アクションからの出力を他のアクション内で参照することができます。

このアクション定義では、整数の配列から JSON オブジェクトの配列を作成します。 アクションはソース配列を反復処理し、式 @item() を使用して各整数値を取得すると、各値を各 JSON オブジェクトの "number" プロパティに割り当てます。

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

このアクションで作成される配列は次のようになります。

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

この配列出力を他のアクション内で使用するには、この出力を Compose アクションに渡します。

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

Compose アクションからの出力を他のアクション内で使用できます。たとえば、Office 365 Outlook - メールの送信アクションで次のように使用します。

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

テーブル アクション

配列から CSV または HTML のテーブルを作成します。 JSON オブジェクトを含む配列の場合、このアクションによって、オブジェクトのプロパティ名から列ヘッダーが自動的に作成されます。 他のデータ型を含む配列の場合、列ヘッダーと値をユーザーが指定する必要があります。 たとえば、この配列には "ID" と "Product_Name" というプロパティが含まれます。これらのプロパティを、このアクションで列ヘッダーと名前として使用できます。

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

必須

種類 説明
<CSV または HTML> String 作成するテーブルの形式
<array> Array テーブルのソース項目を提供する配列または式

:ソース配列が空の場合、アクションによって空のテーブルが作成されます。

省略可能

列ヘッダーと値を指定またはカスタマイズするには、columns 配列を使用します。 ヘッダー名が同じ header-value のペアが複数ある場合、それらのペアの値は、そのヘッダー名の下の同じ列に表示されます。 そうでない場合、一意のヘッダーごとに一意の列が定義されます。

種類 説明
<column-name> String 列のヘッダー名
<column-value> Any その列に含まれる値

例 1

あらかじめ作成した "myItemArray" という変数があり、現在は次の配列が格納されているとします。

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

このアクション定義では、"myItemArray" 変数から CSV テーブルを作成します。 from プロパティで使用している式によって、variables() 関数を使用して "myItemArray" から配列が取得されます。

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

このアクションで作成される CSV テーブルは次のようになります。

ID,Product_Name 
0,Apples 
1,Oranges 

例 2

このアクション定義では、"myItemArray" 変数から HTML テーブルを作成します。 from プロパティで使用している式によって、variables() 関数を使用して "myItemArray" から配列が取得されます。

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

このアクションで作成される HTML テーブルは次のようになります。

idProduct_Name
0Apples
1Oranges

例 3

このアクション定義では、"myItemArray" 変数から HTML テーブルを作成します。 ただし、この例では、既定の列ヘッダー名を "Stock_ID" と "Description" でオーバーライドし、"Description" 列の値に "Organic" という単語を追加します。

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

このアクションで作成される HTML テーブルは次のようになります。

Stock_ID説明
0Organic Apples
1Organic Oranges

終了アクション

このアクションは、ワークフロー インスタンスの実行を停止し、進行中のすべてのアクションをキャンセルし、残りのアクションをすべてスキップして、指定された状態を返します。 たとえば、エラー状態のロジック アプリを完全に終了する必要があるときに、Terminate アクションを使用できます。 このアクションは、既に完了しているアクションには影響しません。また、順次ループを含めて、Foreach ループと Until ループの内部には指定できません。

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

必須

種類 Description
<status> String 実行に関して返す状態: "Failed"、"Cancelled"、または "Succeeded"

省略可能

"runStatus" オブジェクトのプロパティは、"runStatus" プロパティが "Failed" 状態に設定されている場合にのみ適用されます。

種類 説明
<error-code-or-name> String コード、またはエラーの名前
<error-message> String エラーとアプリ ユーザーが実行できる対処について説明したメッセージまたはテキスト

このアクション定義では、ワークフローの実行を停止し、実行の状態を "Failed" に設定して、状態、エラー コード、およびエラー メッセージを返します。

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

待機アクション

指定の期間または指定の時刻まで (両方は不可)、ワークフローの実行を一時停止するアクションです。

指定の期間

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

指定の時刻

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

必須

種類 説明
<number-of-units> Integer Delay アクションで待機する単位数
<interval> String Delay アクションで待機する期間: "Second"、"Minute"、"Hour"、"Day"、"Week"、"Month"
<date-time-stamp> String Delay Until アクションで実行を再開する日時。 この値には UTC の日付と時刻の形式を指定する必要があります。

例 1

このアクション定義では、ワークフローを 15 分間一時停止します。

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

例 2

このアクション定義では、ワークフローを指定時刻まで一時停止します。

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

ワークフロー アクション

あらかじめ作成した別のロジック アプリを呼び出すアクションです。つまり、他のロジック アプリのワークフローを挿入して再利用することができます。 子または入れ子になったロジック アプリからの出力を、入れ子になったロジック アプリに続くアクション内で使用することもできます (ただし、子ロジック アプリから応答が返される場合に限る)。

呼び出そうとしているトリガーへのアクセスが Logic Apps エンジンによってチェックされます。そのトリガーにアクセスできることを確認してください。 また、入れ子になったロジック アプリは、以下の条件を満たす必要があります。

  • 入れ子になったロジック アプリをトリガー (RequestHTTP トリガーなど) によって呼び出し可能にします

  • 親ロジック アプリと同じ Azure サブスクリプション

  • 入れ子になったロジック アプリからの出力を親ロジック アプリ内で使用するには、入れ子になったロジック アプリに Response アクションが必要です

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

必須

種類 説明
<nested-logic-app-name> String 呼び出す対象のロジック アプリの前
<trigger-name> String 入れ子になったロジック アプリ内の、呼び出す対象のトリガーの名前
<Azure-subscription-ID> String 入れ子になったロジック アプリの Azure サブスクリプション ID
<Azure-resource-group> String 入れ子になったロジック アプリの Azure リソース グループ名

省略可能

種類 説明
<header-content> JSON オブジェクト 呼び出しで送信するヘッダー
<body-content> JSON オブジェクト 呼び出しで送信するメッセージの内容

出力

このアクションの出力は、入れ子になったロジック アプリの Response アクションに応じて異なります。 入れ子になったロジック アプリに Response アクションが含まれていない場合、出力は空です。

このワークフロー アクション定義では、"Start_search" アクションが正常に完了した後、"Get_product_information" という名前の別のロジック アプリを呼び出して、指定した入力を渡します。

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

ワークフローを制御するアクションの詳細

Foreach アクション

このループ アクションでは、配列を反復処理し、配列の各項目に対してアクションを実行します。 既定では、"for each" ループはループの最大数まで並行して実行されます。 この最大値については、制限と構成に関するセクションを参照してください。"for each" ループを作成する方法については、こちらを参照してください

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

必須

種類 説明
<action-1...n> String 配列の各項目に対して実行するアクションの名前
<action-definition-1...n> JSON オブジェクト 実行するアクションの定義
<for-each-expression> String 指定した配列内の各項目を参照する式

省略可能

種類 説明
<count> Integer 既定では、"for each" ループの反復処理は、既定の制限に達するまでは (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「"for each" のコンカレンシーを変更する」を参照してください。
<operation-option> String "for each" ループを並行してではなく順次実行するには、<operation-option> を Sequential に設定するか、<count> を 1 に設定します。両方を設定することはできません。 詳細については、「"for each" ループを順次実行する」を参照してください。

この "for each" ループでは、配列の項目ごとに、受信メールに付いていた添付ファイルを含む電子メールを送信します。 このループでは、添付ファイルのレビュー担当者に、添付ファイルを含む電子メールを送信します。

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

トリガーからの出力として渡される配列のみを指定するには、この式でトリガー本文から <array-name> 配列を取得します。 配列が存在しない場合のエラーを回避するために、式では ? 演算子を使用しています。

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

If アクション

このアクションは条件付きステートメントです。条件を表す式を評価し、条件が true であるか false であるかに基づいて、異なる分岐を実行します。 条件が true の場合、条件は "Succeeded" 状態とマークされます。 条件付きステートメントを作成する方法については、こちらを参照してください

"Condition": {
   "type": "If",
   "expression": { "<condition>" },
   "actions": {
      "<action-1>": { "<action-definition>" }
   },
   "else": {
      "actions": {
        "<action-2>": { "<action-definition" }
      }
   },
   "runAfter": {}
}
種類 説明
<condition> JSON オブジェクト 評価する条件 (式にすることもできます)
<action-1> JSON オブジェクト <condition> が true と評価された場合に実行するアクション
<action-definition> JSON オブジェクト アクションの定義
<action-2> JSON オブジェクト <condition> が false と評価された場合に実行するアクション

actions オブジェクトまたは else オブジェクト内のアクションで取得される状態は、次のとおりです。

  • "Succeeded": 実行して成功した場合
  • "Failed": 実行して失敗した場合
  • "Skipped": それぞれの分岐が実行されない場合

この条件では、整数型の変数が 0 より大きい値を持つときに、ワークフローが Web サイトをチェックすることを指定しています。 変数が 0 以下の場合、ワークフローは別の Web サイトをチェックします。

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

条件で式を使用する方法

条件で式を使用する方法の例を次に示します。

JSON 結果
"expression": "@parameters('<hasSpecialAction>')" ブール式の場合に限り、値が true と評価されれば条件が満たされます。

他の型をブール値に変換するには、empty() または equals() 関数を使用します。

"expression": "@greater(actions('<action>').output.value, parameters('<threshold>'))" 比較関数の場合、<action> からの出力が <threshold> の値よりも大きい場合にのみ、アクションが実行されます。
"expression": "@or(greater(actions('<action>').output.value, parameters('<threshold>')), less(actions('<same-action>').output.value, 100))" ロジック関数の場合、入れ子になったブール式を作成すると、<action> からの出力が <threshold> の値より大きいか 100 を下回る場合にのみ、アクションが実行されます。
"expression": "@equals(length(actions('<action>').outputs.errors), 0))" 配列に項目が存在するかどうかを確認するには、配列関数を使用できます。 アクションは errors 配列が空のときに実行されます。

スコープ アクション

アクションをスコープとして論理的にグループ化するアクションです。スコープ内のアクションの実行が終了すると、スコープ独自の状態が取得されます。 その後はスコープの状態を使用して、他のアクションを実行するかどうかを判断できます。 スコープを作成する方法については、こちらを参照してください

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

必須

種類 説明
<inner-action-1...n> JSON オブジェクト スコープ内部で実行される 1 つ以上のアクション
<action-inputs> JSON オブジェクト 各アクションの入力

switch アクション

このアクションは switch ステートメントとも呼ばれます。他のアクションをケースとして整理し、既定のケース (存在する場合) を除く各ケースに値を割り当てるアクションです。 ワークフローを実行すると、Switch アクションによって、式、オブジェクト、またはトークンの値が、各ケースに指定した値と比較されます。 一致するケースが Switch アクションによって見つかった場合、ワークフローはそのケースに対してのみ実行されます。 Switch アクションが実行されるたびに、一致するケースが 1 つだけ存在するか、一致が存在しないかのどちらかになります。 一致が存在しない場合、Switch アクションの既定のアクションが実行されます。 switch ステートメントを作成する方法については、こちらを参照してください

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

必須

種類 説明
<expression-object-or-token> 場合により異なる 評価する対象の式、JSON オブジェクト、またはトークン
<action-name> String 一致するケースがある場合に実行するアクションの名前
<action-definition> JSON オブジェクト 一致するケースがある場合に実行するアクションの定義
<matching-value> 場合により異なる 評価された結果と比較する値

省略可能

種類 説明
<default-action-name> String 一致するケースが存在しないときに実行する既定のアクションの名前
<default-action-definition> JSON オブジェクト 一致するケースが存在しないときに実行するアクションの定義

このアクション定義では、承認要求の電子メールに応答した担当者が、"承認" オプションを選択したか、それとも "拒否" オプションを選択したかを評価します。 この選択に基づいて、Switch アクションとして、一致するケースのアクションが実行されます。つまり、異なる文章を使用した別の電子メールを応答者に送信します。

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

Until アクション

このループ アクションには、指定した条件が true になるまで実行されるアクションが含まれています。 ループでは、他のすべてのアクションが実行された後に、最後のステップとして条件をチェックします。 "actions" オブジェクトには複数のアクションを含めることができます。アクションには、少なくとも 1 つの制限を定義する必要があります。 "until" ループを作成する方法については、こちらを参照してください

 "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": {}
}
種類 説明
<action-name> String ループ内で実行するアクションの名前
<action-type> String 実行するアクションの種類
<action-inputs> 各種 アクションを実行するための入力
<condition> String ループ内のすべてのアクションの実行が終了した後に評価する条件または式
<loop-count> Integer アクションで実行できる最大ループ回数に対する制限。 既定の制限と上限の詳細については、Azure Logic Apps の制限と構成に関する記事を参照してください。
<loop-timeout> String ループを実行できる最長時間に対する制限。 timeout の既定値は PT1H です。これは、必須の ISO 8601 フォーマットです。

注意

式が Until ループ内の任意のアクションからの出力に依存している場合は、そのアクションから発生するすべてのエラーを必ず考慮に入れてください。

このループ アクション定義では、以下のいずれかの条件が満たされるまで、指定した URL に HTTP 要求を送信します。

  • 要求に対して状態コード "200 OK" の応答が返される。
  • ループの実行回数が 60 回に達する。
  • ループの実行時間が 1 時間に達する。
 "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": {}
}

Webhook とサブスクリプション

Webhook ベースのトリガーとアクションでは、エンドポイントの定期的なチェックは行わず、代わりに特定のイベントやエンドポイントのデータを待機します。 それらのトリガーとアクションでは、エンドポイントからの応答の送信先となるコールバック URL を指定することで、エンドポイントを登録します。

subscribe 呼び出しは、ワークフローに何らかの変更があったとき (たとえば、資格情報が更新されたときや、トリガーまたはアクションの入力パラメーターが変更されたとき) に行われます。 この呼び出しでは、標準の HTTP アクションと同じパラメーターを使用します。

unsubscribe 呼び出しは、以下のような操作によってトリガーまたはアクションが無効になると、自動的に行われます。

  • トリガーを削除または無効にする。
  • ワークフローを削除または無効にする。
  • サブスクリプションを削除または無効にする。

これらの呼び出しをサポートするために、@listCallbackUrl() 式により、トリガーまたはアクション用の一意の "コールバック URL" が返されます。 この URL は、サービスの REST API を使用するエンドポイントの一意識別子を表します。 この関数のパラメーターは、webhook トリガーまたはアクションと同じです。

非同期の継続時間を変更する

トリガーとアクションの両方について、limit.timeout プロパティを追加することにより、非同期パターンの継続時間を特定の期間に制限できます。 そうすれば、特定の期間が経過した時点でアクションが終了していない場合、アクションの状態は ActionTimedOut コードを使って Cancelled としてマークされます。 timeout プロパティには ISO 8601 形式を使用します。

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

実行時の構成設定

トリガーまたはアクションの定義にこれらの runtimeConfiguration プロパティを追加することによって、トリガーとアクションの既定の実行時ビヘイビアーを変更できます。

プロパティ タイプ 説明 トリガーまたはアクション
runtimeConfiguration.concurrency.runs Integer (同時にまたは並行して) 実行できるワークフロー インスタンスの数に対する既定の制限を変更します。 この値を調整することで、バックエンド システムが受信する要求の数を制限できます。

runs プロパティを 1 に設定すると、operationOptions プロパティを SingleInstance に設定したのと同じように機能します。 いずれか一方のプロパティを設定できます。両方を設定することはできません。

既定の制限を変更するには、「トリガーのコンカレンシーを変更する」または「インスタンスを順次トリガーする」を参照してください。

すべてのトリガー
runtimeConfiguration.concurrency.maximumWaitingRuns Integer ロジック アプリが最大数の同時実行インスタンスを既に実行している場合に実行を待機する必要があるワークフロー インスタンスの数に対する既定の制限を変更します。

既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。

すべてのトリガー
runtimeConfiguration.concurrency.repetitions Integer (同時にまたは並行して) 実行できる "for each" ループ繰り返し回数に対する既定の制限を変更します。

repetitions プロパティを 1 に設定すると、operationOptions プロパティを SingleInstance に設定したのと同じように機能します。 いずれか一方のプロパティを設定できます。両方を設定することはできません。

既定の制限を変更するには、「"for each" のコンカレンシーを変更する」、または「"for each" ループを順次実行する」を参照してください。

アクション:

Foreach

runtimeConfiguration.paginationPolicy.minimumItemCount Integer 改ページ位置の自動修正をサポートし、これが有効になっている特定のアクションの場合、この値により、取得する結果の最小数を指定します。

改ページ位置の自動修正を有効にするには、改ページ位置の自動修正によるデータ、アイテム、または結果の一括取得に関する記事を参照してください

アクション:多様
runtimeConfiguration.secureData.properties Array 多くのトリガーおよびアクションでは、これらの設定により、ロジック アプリの実行履歴から入力と出力のどちらかまたは両方が非表示になります。

このデータの保護の詳細については、実行履歴からの入力と出力の非表示に関するページを参照してください。

ほとんどのトリガーとアクション
runtimeConfiguration.staticResult JSON オブジェクト 静的な結果設定をサポートし、有効にするアクションの場合、staticResultオブジェクトには次の属性があります。

- name。現在のアクションの静的結果の定義名を参照します。この名前は、ロジック アプリ ワークフローの definition 属性の staticResults 属性内に表示されます。 詳細については、静的結果 - ワークフロー定義言語のスキーマ参照に関するページを参照してください。

- staticResultOptions。現在のアクションに対して静的結果が Enabled であるかどうかを指定します。

静的結果を有効にするには、「静的な結果を設定してモック データでロジック アプリをテストする」を参照してください。

アクション:多様

操作オプション

トリガーまたはアクションの定義で operationOptions プロパティを使用して、トリガーとアクションの既定のビヘイビアーを変更できます。

操作オプション Type 説明 トリガーまたはアクション
DisableAsyncPattern String HTTP ベースのアクションを非同期に実行するのではなく、同期的に実行します。

このオプションを設定するには、「アクションを同期的に実行する」を参照してください。

アクション:

ApiConnection
HTTP
回答

IncludeAuthorizationHeadersInOutputs String Microsoft Entra ID を使用して OAuth が要求ベースのトリガー エンドポイントへの受信呼び出しのアクセスを承認できるようにするロジック アプリの場合は、OAuth アクセス トークンからのヘッダーをトリガー出力に含Authorizationめます。 詳細については、「要求トリガーの出力に "Authorization" ヘッダーを含める」を参照してください。 トリガー:

要求
HTTP Webhook

Sequential String "for each" ループの反復処理を、すべて同時に並行して実行するのではなく、一度に 1 つずつ実行します。

このオプションは、runtimeConfiguration.concurrency.repetitions プロパティを 1 に設定したのと同じように機能します。 いずれか一方のプロパティを設定できます。両方を設定することはできません。

このオプションを設定するには、「"for each" ループを順次実行する」を参照してください。

アクション:

Foreach

SingleInstance String 各ロジック アプリ インスタンスのトリガーを順次実行し、直前のアクティブな実行が終了するまで待機してから、次のロジック アプリ インスタンスをトリガーします。

このオプションは、runtimeConfiguration.concurrency.runs プロパティを 1 に設定したのと同じように機能します。 いずれか一方のプロパティを設定できます。両方を設定することはできません。

このオプションを設定するには、「インスタンスを順次トリガーする」を参照してください。

すべてのトリガー
SuppressWorkflowHeaders String 送信要求内で x-ms-* メタデータ ヘッダーを送信しません。 既定では、Azure Logic Apps サービスには、送信要求の一部としてヘッダー名に x-ms- プレフィックスを含む追加のメタデータ ヘッダーが含まれます。 ただし、一部のレガシ サービスでは、追加の不明なヘッダーを含む要求は受け入れられず、要求が失敗します。 アクション:

HTTP
関数
APIManagement

SuppressWorkflowHeadersOnResponse String 受信トリガー要求への応答では、x-ms-* メタデータ ヘッダーを送信しません。 既定では、Azure Logic Apps サービスにより、ヘッダー名に x-ms- プレフィックスを含む追加のメタデータ ヘッダーを含む受信要求への応答が送信されます。 ただし、一部のレガシ サービスでは、追加の不明なヘッダーを含む要求または応答は受け入れられず、要求が失敗します。 トリガー:

要求
HTTP Webhook

トリガーのコンカレンシーを変更する

既定では、ロジック アプリ ワークフロー インスタンスはすべて (同時にまたは並行して) 実行されます。 この動作は、直前のアクティブなワークフロー インスタンスが実行を終了する前に各トリガー インスタンスが起動することを意味します。 ただし、同時に実行されるインスタンスの数には既定の制限があります。 同時に実行されるワークフロー インスタンスの数がこの制限に達すると、その他の新しいインスタンスは実行を待機する必要があります。 この制限を使用して、バックエンド システムが受信する要求の数を制限できます。

トリガーのコンカレンシー制御を有効にすると、トリガー インスタンスは既定の制限まで並列実行されます。 既定のコンカレンシー制限を変更するには、コード ビュー エディターまたは Logic Apps デザイナーのどちらを使用してもかまいません。コンカレンシーの設定をデザイナーから変更すると、基になるトリガー定義において runtimeConfiguration.concurrency.runs プロパティの追加または更新が行われるからです (または、その逆も行われます)。 このプロパティを使用すると、並行して実行できる新しいワークフロー インスタンスの最大数が制御されます。

トリガーでコンカレンシーを有効にする前に、次の考慮事項を確認してください。

  • コンカレンシー制御を有効にした後にコンカレンシーを無効にすることはできません。

  • 同時トリガー実行の最大数が並列処理の最大度に達すると、後続のトリガー実行で調整または "429 - 要求が多すぎます" エラーが発生する可能性があります。 429 エラーを処理する再試行ポリシーを設定した場合、トリガーで再試行と調整の動作のサイクルが発生し、新しいトリガー要求の処理に長い遅延が発生する可能性があります。

  • コンカレンシーが有効になっていると、配列のバッチ解除のために SplitOn 上限が大幅に下がります。 項目数がこの上限を超えると、SplitOn 機能は無効になります。

  • コンカレンシーを有効にすると、実行時間の長いロジック アプリ インスタンスによって、新しいロジック アプリ インスタンスが待機状態になることがあります。 この状態により、Azure Logic Apps で新しいインスタンスが作成されなくなります。この状態は、同時実行の数が、指定された同時実行の最大数よりも少ない場合でも発生します。

    • この状態を中断するには、"まだ実行されている" インスタンスのうち最も古いものを取り消します。

      1. ロジック アプリのメニューで、 [概要] を選択します。

      2. [実行履歴] セクションで、次の例のように、まだ実行されているインスタンスのうち最も古いものを選択します。

        Select earliest running instance

        ヒント

        まだ実行されているインスタンスだけを表示するには、 [すべて] の一覧を開き、 [実行中] を選択します。

      3. [ロジック アプリの実行] で、 [実行の取り消し] を選択します。

        Find earliest running instance

    • この可能性を回避するには、これらの実行を保持する可能性のある任意のアクションにタイムアウトを追加します。 コード エディターで作業している場合は、「非同期の継続時間を変更する」を参照してください。 それ以外の場合で、デザイナーを使用している場合は、次の手順に従います。

      1. ロジック アプリ ワークフローで、タイムアウトを追加するアクションを選択します。 アクションの右上隅の省略記号 (...) ボタンを選択し、次に [設定] を選択します。

        Open action settings

      2. [タイムアウト] の下で、タイムアウト期間を ISO 8601 形式で指定します。

        Specify timeout duration

  • ロジック アプリを順番に実行するには、コード ビュー エディターまたはデザイナーを使用して、トリガーのコンカレンシーを 1 に設定します。 コード ビュー エディターで、トリガーの operationOptions プロパティを SingleInstance に設定しないようにしてください。 これに従わないと、検証エラーになります。 詳細については、「インスタンスを順次トリガーする」を参照してください。

コード ビューで編集する

基になるトリガーの定義で、runtimeConfiguration.concurrency.runs プロパティを追加し、トリガーのコンカレンシーの制限に基づいて値を設定します。 ワークフローを順番に実行するには、プロパティの値を 1 に設定します。

この例では、同時実行の数を 10 インスタンスに制限しています。

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

詳細については、「ランタイム構成の設定」を参照してください。

Logic Apps デザイナーで編集する

  1. トリガーの右上隅の省略記号ボタン ( ... ) を選択し、 [設定] を選択します。

  2. [コンカレンシー制御] で、 [Limit](限度)[オン] に設定します。

  3. [並列処理の次数] スライダーをドラッグして必要な値に設定します。 ロジック アプリを順番に実行するには、スライダーの値を 1 にドラッグします。

"for each" のコンカレンシーを変更する

既定では、"for each" ループの反復処理はすべて (同時にまたは並行して) 実行されます。 この動作は、前の反復処理の実行が完了する前に各反復処理の実行が開始されることを意味します。 ただし、同時に実行される反復処理の数には既定の制限があります。 同時に実行される反復処理の数がこの制限に達すると、その他の反復処理は実行を待機する必要があります。

既定の制限を変更するには、コード ビュー エディターまたは Logic Apps デザイナーのどちらを使用してもかまいません。コンカレンシーの設定をデザイナーから変更すると、基になる "for each" アクション定義において runtimeConfiguration.concurrency.repetitions プロパティの追加または更新が行われるからです (または、その逆も行われます)。 このプロパティでは、並行して実行できる反復処理の最大数を制御します。

注意

デザイナーまたはコード ビュー エディターを使用して "for each" アクションの順次実行を設定する場合、コード ビュー エディターでアクションの operationOptions プロパティを Sequential に設定しないでください。 これに従わないと、検証エラーになります。 詳細については、「"for each" ループを順次実行する」を参照してください。

コード ビューで編集する

基になる "for each" 定義で、1 から 50 までの範囲の値を持つことができる runtimeConfiguration.concurrency.repetitions プロパティを追加または更新します。

同時実行を 10 個の反復処理に制限する例を次に示します。

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

詳細については、「ランタイム構成の設定」を参照してください。

Logic Apps デザイナーで編集する

  1. For each アクションの右上隅で省略記号 ( ... ) ボタンを選択し、 [設定] を選択します。

  2. [コンカレンシー制御] で、 [コンカレンシー制御][オン] に設定します。

  3. [並列処理の次数] スライダーをドラッグして必要な値に設定します。 ロジック アプリを順番に実行するには、スライダーの値を 1 にドラッグします。

実行待機の制限を変更する

既定では、ロジック アプリ ワークフロー インスタンスはすべて (同時にまたは並行して) 実行されます。 この動作は、直前のアクティブなワークフロー インスタンスが実行を終了する前に各トリガー インスタンスが起動することを意味します。 ただし、 同時に実行されるワークフロー インスタンスの数には既定の制限 があります。 同時実行の数がこの制限に達した場合、他の新しいワークフロー インスタンスは実行を待機する必要があります。 既定の 制限 は、待機中のワークフロー インスタンスの数にも存在します。 待機中のインスタンスの数がこの制限に達すると、Azure Logic Apps エンジンは実行する新しいワークフロー インスタンスを受け入れなくなります。 要求トリガーと webhook トリガーは 429 を返します 。要求 エラーが多すぎると、定期的なトリガーがポーリングの試行をスキップし始めます。

トリガーコンカレンシーの既定の制限と、実行待機の既定の制限を変更できます。 ただし、この変更により、主にトリガーが遅くなり、コンカレンシーによる負荷が軽減されます。 たとえば、ポーリング トリガーがあり、実行中の実行が原因で待機中の実行キューがいっぱいになった場合、Azure Logic Apps はポーリングを停止します。 ワークフローで要求ベースのトリガーが使用されていて、待機中の実行キューがいっぱいである場合、Azure Logic Apps は 429 エラーの返しを開始します。 Azure Logic Apps で失敗を発生させずにトリガーのポーリングを停止できず、呼び出し元の実行に失敗することなく、待機中の実行キューにこのような実行を追加することを選択できないシナリオもあります。

基になるトリガー定義で、1 から 100 までの範囲の値を持つことができる runtimeConfiguration.concurrency.maximumWaitingRuns プロパティを追加します。

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

詳細については、「ランタイム構成の設定」を参照してください。

インスタンスを順次トリガーする

各ロジック アプリ ワークフロー インスタンスを、必ず直前のインスタンスの実行が終了してから実行するには、トリガーの順次実行を設定します。 コード ビュー エディターまたは Logic Apps デザイナーのどちらを使用してもかまいません。コンカレンシーの設定をデザイナーから変更すると、基になるトリガー定義において runtimeConfiguration.concurrency.runs プロパティの追加または更新が行われるからです (または、その逆も行われます)。

注意

デザイナーまたはコード ビュー エディターを使用してトリガーの順次実行を設定する場合、コード ビュー エディターでトリガーの operationOptions プロパティを Sequential に設定しないでください。 これに従わないと、検証エラーになります。

コード ビューで編集する

トリガー定義において、以下のプロパティのどちらか一方を設定します。両方を設定することはできません。

runtimeConfiguration.concurrency.runs プロパティを 1 に設定します。

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

- または -

operationOptions プロパティを SingleInstance に設定します。

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

詳細については、「ランタイム構成の設定」および「操作オプション」を参照してください。

Logic Apps デザイナーで編集する

  1. トリガーの右上隅の省略記号ボタン ( ... ) を選択し、 [設定] を選択します。

  2. [コンカレンシー制御] で、 [Limit](限度)[オン] に設定します。

  3. [並列処理の次数] スライダーをドラッグして数値 1 に設定します。

"for each" ループを順次実行する

"for each" ループを、必ず直前の反復処理の実行が終了してから実行するには、"for each" アクションの順次実行を設定します。 コード ビュー エディターまたは Logic Apps デザイナーのどちらを使用してもかまいません。アクションのコンカレンシーの設定をデザイナーから変更すると、基になるアクション定義において runtimeConfiguration.concurrency.repetitions プロパティの追加または更新が行われるからです (または、その逆も行われます)。

注意

デザイナーまたはコード ビュー エディターを使用して "for each" アクションの順次実行を設定する場合、コード ビュー エディターでアクションの operationOptions プロパティを Sequential に設定しないでください。 これに従わないと、検証エラーになります。

コード ビューで編集する

アクション定義において、以下のプロパティのどちらか一方を設定します。両方を設定することはできません。

runtimeConfiguration.concurrency.repetitions プロパティを 1 に設定します。

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

- または -

operationOptions プロパティを Sequential に設定します。

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

詳細については、「ランタイム構成の設定」および「操作オプション」を参照してください。

Logic Apps デザイナーで編集する

  1. For each アクションの右上隅で省略記号 ( ... ) ボタンを選択し、 [設定] を選択します。

  2. [コンカレンシー制御] で、 [コンカレンシー制御][オン] に設定します。

  3. [並列処理の次数] スライダーをドラッグして数値 1 に設定します。

同期操作パターンでアクションを実行する

既定では、Azure Logic Apps の HTTP アクションと APIConnection アクションは、標準的な非同期操作パターンに従いますが、Response アクションは同期操作パターンに従います。 非同期パターンは、アクションによって指定されたエンドポイント、サービス、システム、または API へ要求が呼び出される、または送信された後、受信側が直ちに "202 ACCEPTED" 応答を返すことを指定します。 このコードは、受信側が要求を受け入れたが、処理が完了していないことを確認します。 応答には、受信側が処理を停止し、"200 OK" の成功応答またはその他の非 202 応答が返されるまで、呼び出し元が非同期要求の状態を継続的にポーリングまたは確認するために使用できる URL および更新 ID を指定する location ヘッダーを含めることができます。 詳細については、「マイクロサービスの非同期統合によるマイクロサービスの自律性の強制」を参照してください。

  • ロジック アプリ デザイナーでは、HTTP アクション、APIConnection アクション、および Response アクションの非同期パターン設定があります。 この設定を有効にした場合、呼び出し元は処理が終了するのを待たず、次のアクションに進むことができますが、処理が停止するまで状態のチェックは続行されます。 無効にした場合、この設定は次のアクションに進む前に、呼び出し元が処理の終了を待機することを指定します。 この設定を見つけるには、次の手順を実行します。

    1. HTTP アクションのタイトル バーで、省略記号 ( ... ) ボタンを選択します。これにより、アクションの設定が開きます。

    2. [非同期パターン] 設定を探します。

  • アクションの基になる JavaScript Object Notation (JSON) 定義では、HTTP アクションと APIConnection アクションは暗黙的に非同期操作パターンに従います。

シナリオによっては、代わりに同期パターンに従うアクションが必要になることがあります。 たとえば、HTTP アクションを使用する際に、以下を行いたい場合があるとします。

このような場合は、以下のオプションを使用してアクションを同期的に実行することができます。

[非同期パターン] 設定をオフにします

  1. ロジック アプリ デザイナーのアクションのタイトル バーで、省略記号 ( ... ) ボタンを選択します。これにより、アクションの設定が開きます。

  2. [非同期パターン] 設定を探し、有効にした場合は設定を [オフ] にし、 [完了] を選択します。

    Turn off

アクションの JSON 定義で非同期パターンを無効にする

アクションの基になる JSON 定義で、アクションの "inputs" セクションの "DisableAsyncPattern""operationOptions" プロパティを追加して設定します。次に例を示します。

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

トリガーとアクションを認証する

HTTP および HTTPS エンドポイントでは、さまざまな種類の認証がサポートされています。 これらのエンドポイントにアクセスする送信呼び出しまたは送信要求を行うために使用するトリガーまたはアクションに基づいて、さまざまな認証の種類から選択できます。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。

次のステップ