このエントリは2019/07/26現在の情報に基づきます。今後の機能追加・廃止に伴い、記載内容との齟齬が発生する可能性があります（以前作成したものを手違いで削除したため、新たに書き起こしました）。
関連エントリ
- Part 1: 基本
- Part 2: EDI/B2B
- Part 3: オンプレミスとの接続
- Part 4: Cosmos DBとの接続
- Part 5: 長時間実行タスクの待機（このエントリ）
HTTP応答タイムアウト
ロジックアプリのHTTP同期応答タイムアウトは120秒（ISEは240秒）で、この間に応答がなければタイムアウトし、次のアクションに進む。
タイムアウト / Timeout
https://docs.microsoft.com/azure/logic-apps/logic-apps-limits-and-config#timeout
同期応答のタイムアウトを超えて待機する必要がある場合、非同期ポーリング、非同期webhook、もしくはUntilループを使うことが推奨されている。それぞれに関するドキュメントは以下の通り。
ポーリング アクション パターンで長時間タスクを実行する / Perform long-running tasks with the polling action pattern
https://docs.microsoft.com/azure/logic-apps/logic-apps-create-api-app#async-pattern
webhook アクション パターンで長時間タスクを実行する / Perform long-running tasks with the webhook action pattern
https://docs.microsoft.com/azure/logic-apps/logic-apps-create-api-app#perform-long-running-tasks-with-the-webhook-action-pattern
Until アクション / Until action
https://docs.microsoft.com/azure/logic-apps/logic-apps-workflow-actions-triggers#until-action
まず、何も考えずにHTTP同期レスポンスタイムアウトの挙動を確認する
単純にタイムアウト時間を超えるようなロジックアプリを作成し、実行する。子ロジックアプリは以下のような感じ。
これを親ロジックアプリから実行すると、タイムアウト制限時間内にHTTP同期レスポンスがないために再試行し、結果として失敗してしまう。以下はPostmanから呼び出した例。2分過ぎでタイムアウト発生、504を返していることがわかる。
こちらは。Logic Appsの実行履歴。
子ロジックアプリ側は、親ロジックアプリにレスポンスを返そうとしたけれど、親ロジックアプリはすでにタイムアウトしているので送信できない、という状況。
非同期ポーリング アクション パターン
非同期ポーリング アクション パターンの場合、Untilループを使って結果を確認する。以下はその例。
- 子ロジックアプリを起動
- 子ロジックアプリが即座に202などを親ロジックアプリに返す
- 親ロジックアプリは後続の処理を続行
- 子ロジックアプリの処理終了後、何らかの記憶域に結果を書き出す
- 親ロジックアプリは、子ロジックアプリの処理状況（つまり子ロジックアプリの結果を書き出す記憶域）をループで確認して、その結果によって次のアクションに移るかどうか判断する。
この非同期ポーリングでは、親ロジックアプリで並列分岐のアクションを使えば、結果を待つ処理と、後続処理を並行させることができる。
この例はイメージしやすいので詳細は省略する。HTTP応答のタイムアウト設定などは、HTTP送信アクションの設定から構成できる。
Webhook アクション パターン
非同期ポーリングパターンとは異なり、親ロジックアプリがコールバックURLを子ロジックアプリに渡し、親ロジックアプリではコールバックを待機する。以下はその例。
- 子ロジックアプリを起動する際に、コールバックURLを登録する
- 親ロジックアプリはコールバックを待機
- 子ロジックアプリは処理終了後、コールバックURLに対して結果を返す
- 親ロジックアプリは、子ロジックアプリからのコールバックを受け取り、その結果によって次のアクションに移るかどうか判断する。
WS-BPELなどにおける非同期コールバックと似ているが、WS-BPELの場合、 （非同期ポーリングの場合と同様に） リクエストから非同期コールバックまでの間に処理を含めることができるのに対し、Wehookアクションの場合、子ロジックアプリ呼び出しのタイミングでコールバック待機するため、並行処理できないという点に大きな違いがある。
親ロジックアプリに少々手をいれ、着信と同時に202を返した後、子ロジックアプリを呼び出しつつコールバックを登録している。以下はその例。
子ロジックアプリも少々変更し、コールバックURLに対して応答を返すようにした。以下はその例。
実際に動作確認してみた。まずは先ほどと同様、Postmanで呼び出したところ、設定通り202を返すことがわかる。
実行履歴を見ると、2分以上経過しても待機しつづけ、完了まで待っている。
実行履歴の詳細を比較すると、相関IDである関連付けIDが一致していることもわかる。
Logico Inside 