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

必須

省略可能

トリガーの種類の一覧

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

組み込みのトリガー

マネージド 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>"
}

必須

省略可能

出力

例

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

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

必須

省略可能

例

このトリガー定義は、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>"
}

必須

省略可能

出力

着信要求についての要件

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

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

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" の両方のオブジェクトに使用できるものがあります。

必須

省略可能

出力

例

このトリガーは、指定されたエンドポイントへのサブスクリプションを作成し、一意のコールバック 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>"
}

必須

省略可能

例 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 分、午後 0 時 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 を使用する必要があります。これについては、ワークフロー サービス 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>"
}

必須

省略可能

例

このトリガーでは、着信要求がこのトリガーを呼び出すために 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 回のワークフロー実行で処理できる配列項目の最大数については、「制限と構成」を参照してください。

例

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

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

これで、このワークフロー定義では、@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>"
},

必須

省略可能

アクションの種類の一覧

よく使用されるアクションの種類を次に示します。

• 組み込みアクションの種類。主な例は次のとおりです。

  • HTTP: HTTP または HTTPS 経由でエンドポイントを呼び出すため

  • Response: 要求に応答するため

  • JavaScript コードの実行: JavaScript コード スニペットを実行するため

  • Function: Azure Functions を呼び出すため

  • さまざまな入力からデータを作成または変換するデータ操作アクション (Join、Compose、Table、Select など)

  • Workflow: 別のロジック アプリ ワークフローを呼び出すため

• マネージド API アクションの種類 (ApiConnection や ApiConnectionWebHook など) は、Microsoft が管理するさまざまなコネクタと API を呼び出します (たとえば、Azure Service Bus、Office 365 Outlook、Power BI、Azure Blob Storage、OneDrive、GitHub など)。

• ワークフロー制御アクションの種類 (If、Foreach、Switch、Scope、Until など) は、その中で他のアクションが指定され、ワークフローの実行を調整するために使用できます。

組み込みアクション

マネージド API アクション

ワークフロー制御アクション

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

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

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

必須

省略可能

例

この定義は、Microsoft マネージド API である Office 365 Outlook コネクタに対するメールの送信アクションを記述するものです。

"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" の両方のオブジェクトに使用できるものがあります。

必須

省略可能

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

Compose アクション

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

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

必須

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

必須

場合により必須

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

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

例 1

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

"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 プロパティ値を返します。 このアクションは、承認メールの送信アクションを actions オブジェクト内の explicitDependencies オブジェクトに依存関係として明示的に含めます。

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

必須

省略可能

例

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

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

結合アクション

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

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

必須

例

あらかじめ作成した "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 の解析アクションに続いて実行されるアクション内に限ります。

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

必須

例

このアクション定義は、指定された値 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": {}
},

必須

省略可能

例

このアクション定義は、指定された状態コード、メッセージ本文、メッセージ ヘッダーを使用して 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": {}
},

必須

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

必須

省略可能

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

例 1

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

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

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

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

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

ID,Product_Name 
0,Apples 
1,Oranges 

例 2

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

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

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

例 3

このアクション定義は、HTML テーブルを "myItemArray" 変数から作成します。 ただし、この例では、既定の列ヘッダー名を "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 テーブルは次のようになります。

終了アクション

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

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

必須

省略可能

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

例

このアクション定義は、ワークフローの実行を停止し、実行の状態を "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": {}
},

必須

例 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 によってチェックされるため、自分がそのトリガーにアクセスできることを確認してください。 また、入れ子になったロジック アプリは、以下の条件を満たす必要があります。

• トリガーによって、その入れ子になったロジック アプリが呼び出し可能になる (たとえば Request または HTTP トリガー)

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

必須

省略可能

出力

このアクションの出力は、入れ子になったロジック アプリの 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>"
}

必須

省略可能

例

この "for each" ループは、配列の項目ごとに 1 通の電子メールを、受信メールからの添付ファイルを付けて送信します。 このループから送信される電子メール (添付ファイルも含まれます) の送信先は、その添付ファイルのレビュー担当者です。

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

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

条件で式を使用する方法

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

スコープ アクション

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

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

必須

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

必須

省略可能

例

このアクション定義は、承認要求の電子メールに応答した担当者が "承認" オプションと "拒否" オプションのどちらを選択したかを評価します。 この選択に基づいて、一致するケースのアクションが 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": {}
}

例

このループ アクション定義は、以下のいずれかの条件が満たされるまで、指定された 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 プロパティを追加します。 このようにすると、その時間が経過した時点でアクションが終了していない場合に、アクションの状態は Cancelled となり、ActionTimedOut コードが指定されます。 timeout プロパティには ISO 8601 形式を使用します。

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

実行時の構成設定

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

操作オプション

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

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

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

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

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

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

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

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

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

  • この状態を解消するには、"まだ実行されている" インスタンスのうち最も開始日時が早いものを取り消します。

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

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

       

       ヒント

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

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

       

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

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

       

    2. [タイムアウト]の下で、タイムアウト期間を 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
      }
   }
}

詳細については、「実行時の構成設定」を参照してください。

ワークフロー デザイナーで編集する

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

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

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

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

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

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

コード ビューで編集する

基になる "for each" 定義内で、runtimeConfiguration.concurrency.repetitions プロパティを追加または更新します。この値は 1 以上 50 以下の範囲内で指定できます。

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

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

詳細については、「実行時の構成設定」を参照してください。

ワークフロー デザイナーで編集する

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

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

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

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

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

トリガー コンカレンシーの既定の制限を変更し、実行待機の既定の制限を変更することもできます。 ただし、この変更は主に同時実行によるプレッシャーを和らげるためにトリガーをスローダウンするものです。 たとえば、ポーリング トリガーがある場合、進行中の実行によって実行待機キューがいっぱいになると、Azure Logic Apps でポーリングが停止されます。 ワークフローが要求ベースのトリガーを使用し、実行待機キューがいっぱいになると、Azure Logic Apps で 429 エラーが返されます。 一部のシナリオでは、Azure Logic Apps がエラーを発生させることなくトリガーによるポーリングを停止させることができない場合がありますが、そのような実行は実行待機キューに追加することが選択され、呼び出し元の実行が失敗となることはありません。

基になるトリガー定義内で、runtimeConfiguration.concurrency.maximumWaitingRuns プロパティを追加します。この値は 1 以上 100 以下の範囲内で指定できます。

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

詳細については、「実行時の構成設定」を参照してください。

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

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

コード ビューで編集する

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

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

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

ワークフロー デザイナーで編集する

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

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

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

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

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

コード ビューで編集する

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

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

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

ワークフロー デザイナーで編集する

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

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

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

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

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

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

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

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

     

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

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

• 長時間実行されるタスクで HTTP タイムアウトを回避
• 場所ヘッダーの確認の無効化

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

• 使用可能な場合は、そのアクションのポーリングバージョンを Webhook バージョンに置き換えます。

• 次のいずれかのオプションを使用して、アクションの非同期動作を無効にします。

  • ロジック アプリ デザイナーで、非同期パターン設定をオフにします。

  • アクションの基になる JSON 定義で、"DisableAsyncPattern" 操作オプションを追加します。

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

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

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

   

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

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

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

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

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

次のステップ

• ワークフロー定義言語についてさらに学習します。