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> | Integer | 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。 間隔の最小値と最大値は次のとおりです。 -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 | トリガーの名前 |
host.connection.name | <connection-name> | String | ワークフローに使用するマネージド API への接続の名前 |
method | <method-type> | String | マネージド API と通信するための HTTP メソッド: GET、PUT、POST、PATCH、DELETE |
path | <api-operation> | String | 呼び出す対象の API 操作 |
recurrence.frequency | <time-unit> | String | トリガーが起動する頻度を表す時間の単位: Second、Minute、Hour、Day、Week、Month |
recurrence.interval | <number-of-time-units> | Integer | 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。 間隔の最小値と最大値は次のとおりです。 - month: 1 ~ 16 か月 - day: 1 ~ 500 日 - hour: 1 ~ 12,000 時間 - minute: 1 ~ 72,000 分 - second: 1 ~ 9,999,999 秒 たとえば、間隔が 6 で頻度が Month の場合、繰り返しは 6 か月ごとに行われます。 |
オプション
プロパティ | 値 | 種類 | 説明 |
---|---|---|---|
retryPolicy | <retry-behavior> | JSON オブジェクト | 状態コード 408、429、5XX の断続的なエラーと接続の例外に対する再試行ビヘイビアーをカスタマイズします。 詳細については、「Retry policies (再試行ポリシー)」をご覧ください。 |
クエリ | <query-parameters> | JSON オブジェクト | API 呼び出しに含める任意のクエリ パラメーター。 たとえば、"queries": { "api-version": "2018-01-01" } オブジェクトでは ?api-version=2018-01-01 を呼び出しに追加します。 |
runtimeConfiguration.concurrency.runs | <max-runs> | Integer | 既定では、ワークフロー インスタンスは、既定の制限に達するまでは (同時にまたは並行して) 実行されます。 この制限を変更するには、新しい <count> 値を設定します。「トリガーのコンカレンシーを変更する」を参照してください。 |
runtimeConfiguration.maximumWaitingRuns | <max-runs-queue> | Integer | ワークフローで既に最大数のインスタンスが実行されている場合、新しい実行はすべて既定の制限までこのキューに配置されます。 既定の制限を変更するには、「実行待機の制限を変更する」を参照してください。 インスタンスの最大数を変更するには、runtimeConfiguration.concurrency.runs プロパティの値を指定します。 注: |
splitOn | <splitOn-expression> | String | 配列を返すトリガーの場合、使用する配列をこの式で参照すると、"for each" ループを使わずに、配列の項目ごとにワークフローを作成して実行することができます。 たとえば、 @triggerbody()?['value'] という式は、トリガー本文の内容の中に返される配列の項目を表します。 |
operationOptions | <operation-option> | String | operationOptions プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。 |
出力
要素 | Type | 説明 |
---|---|---|
headers | JSON オブジェクト | 応答のヘッダー |
body | JSON オブジェクト | 応答の本文 |
状態コード | 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> | Integer | 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。 間隔の最小値と最大値は次のとおりです。 -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> | Integer | 頻度に基づいてトリガーが起動する頻度を指定する値。これは、トリガーが再び起動するまで待機する時間単位の数です。 間隔の最小値と最大値は次のとおりです。 -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 プロパティを設定して既定のビヘイビアーを変更できます。 詳細については、「操作のオプション」を参照してください。 |
アクションの種類の一覧
よく使用するアクションの種類をいくつか示します。
次の例のような組み込みアクションの種類。
マネージド API アクションの種類 (ApiConnection や ApiConnectionWebHook など) は、Microsoft が管理するさまざまなコネクタと API を呼び出します (たとえば、Azure Service Bus、Office 365 Outlook、Power BI、Azure Blob Storage、OneDrive、GitHub など)
ワークフローを制御するアクションの種類 (If、Foreach、Switch、Scope、Until など) は、他のアクションを含み、ワークフローの実行を調整するために使用できます
組み込みアクション
アクションの種類 | 説明 |
---|---|
作成 | さまざまな種類を持つ可能性がある複数の入力から、単一の出力を作成します。 |
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 オブジェクト | この特定のアクションに適用するその他のプロパティ |
ロジック アプリを保存すると、Azure Logic Apps は参照先の関数に対して次のチェックを実行します。
使用するワークフローからその関数にアクセスできる必要があります。
ワークフローでは、標準 HTTP トリガーまたは汎用 JSON webhook トリガーだけを使用できます。
Azure 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 コンテンツを解析するために、アクションによって使用されます。 ヒント: ワークフロー デザイナーでは、スキーマを指定するか、アクションでスキーマを生成できるようにサンプル ペイロードを指定できます。 |
例
このアクション定義により、ワークフローで使用できる以下のトークンが作成されますが、これらを使用できるのは、Parse JSON アクションに続いて実行されるアクション内に限ります。
FirstName
、LastName
、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": { }
},
この例では、アクションによる解析の対象である 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 テーブルは次のようになります。
id | Product_Name |
---|---|
0 | Apples |
1 | Oranges |
例 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 | 説明 |
---|---|
0 | Organic Apples |
1 | Organic 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": {}
},
ワークフロー アクション
あらかじめ作成した別のロジック アプリを呼び出すアクションです。つまり、他のロジック アプリのワークフローを挿入して再利用することができます。 子または入れ子になったロジック アプリからの出力を、入れ子になったロジック アプリに続くアクション内で使用することもできます (ただし、子ロジック アプリから応答が返される場合に限る)。
Azure Logic Apps では、呼び出すトリガーへのアクセスがチェックされるため、そのトリガーにアクセスできることを確認してください。 また、入れ子になったロジック アプリは、以下の条件を満たす必要があります。
親ロジック アプリと同じ 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 |
トリガーのコンカレンシーを変更する
既定では、ロジック アプリ ワークフロー インスタンスはすべて (同時にまたは並行して) 実行されます。 この動作は、直前のアクティブなワークフロー インスタンスが実行を終了する前に各トリガー インスタンスが起動することを意味します。 ただし、同時に実行されるインスタンスの数には既定の制限があります。 同時に実行されるワークフロー インスタンスの数がこの制限に達すると、その他の新しいインスタンスは実行を待機する必要があります。 この制限を使用して、バックエンド システムが受信する要求の数を制限できます。
トリガーのコンカレンシー制御を有効にすると、トリガー インスタンスは既定の制限まで並列実行されます。 この既定のコンカレンシー制限を変更するには、コード ビュー エディターまたはワークフロー デザイナーのいずれかを使用できます。デザイナーを使用してコンカレンシー設定を変更すると、基になるトリガー定義のプロパティが追加または更新 runtimeConfiguration.concurrency.runs
されます。その逆も同様です。 このプロパティを使用すると、並行して実行できる新しいワークフロー インスタンスの最大数が制御されます。
トリガーでコンカレンシーを有効にする前に、次の考慮事項を確認してください。
コンカレンシー制御を有効にした後にコンカレンシーを無効にすることはできません。
同時トリガー実行の最大数が並列処理の最大度に達すると、後続のトリガー実行で調整または "429 - 要求が多すぎます" エラーが発生する可能性があります。 429 エラーを処理する再試行ポリシーを設定した場合、トリガーで再試行と調整の動作のサイクルが発生し、新しいトリガー要求の処理に長い遅延が発生する可能性があります。
コンカレンシーが有効になっていると、配列のバッチ解除のために SplitOn 上限が大幅に下がります。 項目数がこの上限を超えると、SplitOn 機能は無効になります。
コンカレンシーを有効にすると、実行時間の長いロジック アプリ インスタンスによって、新しいロジック アプリ インスタンスが待機状態になることがあります。 この状態により、Azure Logic Apps で新しいインスタンスが作成されなくなります。この状態は、同時実行の数が、指定された同時実行の最大数よりも少ない場合でも発生します。
この状態を中断するには、"まだ実行されている" インスタンスのうち最も古いものを取り消します。
ロジック アプリのメニューで、 [概要] を選択します。
[実行履歴] セクションで、次の例のように、まだ実行されているインスタンスのうち最も古いものを選択します。
ヒント
まだ実行されているインスタンスだけを表示するには、 [すべて] の一覧を開き、 [実行中] を選択します。
[ロジック アプリの実行] で、 [実行の取り消し] を選択します。
この可能性を回避するには、これらの実行を保持する可能性のある任意のアクションにタイムアウトを追加します。 コード エディターで作業している場合は、「非同期の継続時間を変更する」を参照してください。 それ以外の場合で、デザイナーを使用している場合は、次の手順に従います。
ロジック アプリ ワークフローで、タイムアウトを追加するアクションを選択します。 アクションの右上隅の省略記号 (...) ボタンを選択し、次に [設定] を選択します。
[タイムアウト] の下で、タイムアウト期間を ISO 8601 形式で指定します。
ロジック アプリを順番に実行するには、コード ビュー エディターまたはデザイナーを使用して、トリガーのコンカレンシーを
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
}
}
}
詳細については、「ランタイム構成の設定」を参照してください。
ワークフロー デザイナーで編集する
トリガーの右上隅の省略記号ボタン ( ... ) を選択し、 [設定] を選択します。
[コンカレンシー制御] で、 [Limit](限度) を [オン] に設定します。
[並列処理の次数] スライダーをドラッグして必要な値に設定します。 ロジック アプリを順番に実行するには、スライダーの値を 1 にドラッグします。
"for each" のコンカレンシーを変更する
既定では、"for each" ループの反復処理はすべて (同時にまたは並行して) 実行されます。 この動作は、前の反復処理の実行が完了する前に各反復処理の実行が開始されることを意味します。 ただし、同時に実行される反復処理の数には既定の制限があります。 同時に実行される反復処理の数がこの制限に達すると、その他の反復処理は実行を待機する必要があります。
既定の制限を変更するには、コード ビュー エディターまたはワークフロー デザイナーのいずれかを使用できます。デザイナーを使用してコンカレンシー設定を変更すると、基になる "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
}
}
}
詳細については、「ランタイム構成の設定」を参照してください。
ワークフロー デザイナーで編集する
For each アクションの右上隅で省略記号 ( ... ) ボタンを選択し、 [設定] を選択します。
[コンカレンシー制御] で、 [コンカレンシー制御] を [オン] に設定します。
[並列処理の次数] スライダーをドラッグして必要な値に設定します。 ロジック アプリを順番に実行するには、スライダーの値を 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
}
}
}
詳細については、「ランタイム構成の設定」を参照してください。
インスタンスを順次トリガーする
各ロジック アプリ ワークフロー インスタンスを、必ず直前のインスタンスの実行が終了してから実行するには、トリガーの順次実行を設定します。 デザイナーを使用してコンカレンシー設定を変更すると、基になるトリガー定義のプロパティも追加または更新 runtimeConfiguration.concurrency.runs
されるため、コード ビュー エディターまたはワークフロー デザイナーを使用できます。
Note
デザイナーまたはコード ビュー エディターを使用してトリガーの順次実行を設定する場合、コード ビュー エディターでトリガーの 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"
}
詳細については、「ランタイム構成の設定」および「操作オプション」を参照してください。
ワークフロー デザイナーで編集する
トリガーの右上隅の省略記号ボタン ( ... ) を選択し、 [設定] を選択します。
[コンカレンシー制御] で、 [Limit](限度) を [オン] に設定します。
[並列処理の次数] スライダーをドラッグして数値
1
に設定します。
"for each" ループを順次実行する
"for each" ループを、必ず直前の反復処理の実行が終了してから実行するには、"for each" アクションの順次実行を設定します。 コード ビュー エディターまたはワークフロー デザイナーを使用できます。デザイナーを使用してアクションのコンカレンシーを変更すると、基になるアクション定義のプロパティも追加または更新 runtimeConfiguration.concurrency.repetitions
されます。その逆も可能です。
Note
デザイナーまたはコード ビュー エディターを使用して "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"
}
詳細については、「ランタイム構成の設定」および「操作オプション」を参照してください。
ワークフロー デザイナーで編集する
For each アクションの右上隅で省略記号 ( ... ) ボタンを選択し、 [設定] を選択します。
[コンカレンシー制御] で、 [コンカレンシー制御] を [オン] に設定します。
[並列処理の次数] スライダーをドラッグして数値
1
に設定します。
同期操作パターンでアクションを実行する
既定では、Azure Logic Apps の HTTP アクションと APIConnection アクションは、標準的な非同期操作パターンに従いますが、Response アクションは同期操作パターンに従います。 非同期パターンは、アクションによって指定されたエンドポイント、サービス、システム、または API へ要求が呼び出される、または送信された後、受信側が直ちに "202 ACCEPTED" 応答を返すことを指定します。 このコードは、受信側が要求を受け入れたが、処理が完了していないことを確認します。 応答には、受信側が処理を停止し、"200 OK" の成功応答またはその他の非 202 応答が返されるまで、呼び出し元が非同期要求の状態を継続的にポーリングまたは確認するために使用できる URL および更新 ID を指定する location
ヘッダーを含めることができます。 詳細については、「マイクロサービスの非同期統合によるマイクロサービスの自律性の強制」を参照してください。
ロジック アプリ デザイナーでは、HTTP アクション、APIConnection アクション、および Response アクションの非同期パターン設定があります。 この設定を有効にした場合、呼び出し元は処理が終了するのを待たず、次のアクションに進むことができますが、処理が停止するまで状態のチェックは続行されます。 無効にした場合、この設定は次のアクションに進む前に、呼び出し元が処理の終了を待機することを指定します。 この設定を見つけるには、次の手順を実行します。
HTTP アクションのタイトル バーで、省略記号 ( ... ) ボタンを選択します。これにより、アクションの設定が開きます。
[非同期パターン] 設定を探します。
アクションの基になる JavaScript Object Notation (JSON) 定義では、HTTP アクションと APIConnection アクションは暗黙的に非同期操作パターンに従います。
シナリオによっては、代わりに同期パターンに従うアクションが必要になることがあります。 たとえば、HTTP アクションを使用する際に、以下を行いたい場合があるとします。
このような場合は、以下のオプションを使用してアクションを同期的に実行することができます。
使用可能な場合は、そのアクションのポーリングバージョンを Webhook バージョンに置き換えます。
次のいずれかのオプションを使用して、アクションの非同期動作を無効にします。
ロジック アプリ デザイナーで、非同期パターン設定をオフにします。
アクションの基になる JSON 定義で、
"DisableAsyncPattern"
操作オプションを追加します。
[非同期パターン] 設定をオフにします
ロジック アプリ デザイナーのアクションのタイトル バーで、省略記号 ( ... ) ボタンを選択します。これにより、アクションの設定が開きます。
[非同期パターン] 設定を探し、有効にした場合は設定を [オフ] にし、 [完了] を選択します。
アクションの JSON 定義で非同期パターンを無効にする
アクションの基になる JSON 定義で、アクションの "inputs"
セクションの "DisableAsyncPattern"
に "operationOptions" プロパティを追加して設定します。次に例を示します。
"<some-long-running-action>": {
"type": "Http",
"inputs": { "<action-inputs>" },
"operationOptions": "DisableAsyncPattern",
"runAfter": {}
}
トリガーとアクションを認証する
HTTP および HTTPS エンドポイントでは、さまざまな種類の認証がサポートされています。 これらのエンドポイントにアクセスする送信呼び出しまたは送信要求を行うために使用するトリガーまたはアクションに基づいて、さまざまな認証の種類から選択できます。 詳しくは、「送信呼び出しに認証を追加する」をご覧ください。