2017年7月7日金曜日

LogicFlow の HTTP トリガの挙動

LogicFlow には HTTP アクセスした結果をトリガとして、LogicFlow を動作させるコネクタが提供されています。基本的には ステータス 200(正常終了)した場合に、処理が動作するのですが、その他のステータスやその際のヘッダー値によって、挙動が色々変わる点があるのでまとめてみました。

まずは現在 MSDN に記載されている内容を転載します。

image

まとめてみると、

  • ステータス 200 の時に限り LogicFlow が実行される
  • ステータス 202 の場合は RetryAfter ヘッダ値で指定された時間の後、再度アクセスを行う
  • ステータス 200 で RetryAfter ヘッダ値が指定されていると、LogicFlow を実行し指定秒数後に再びアクセスを行う

となっています。ということでそれを検証するために、簡単な LogicFlow を一つ用意してみます。

image

HTTP でのリクエストを受けたら、好みのステータスで RetryAfter 値付きで返却する LogicFlow です。今回は返却する値をそのまま記載していますが、呼び出す際に戻してほしいステータスやRetryAfter の値を一緒に受け渡せるようにすることも簡単です。まぁ、その場合 HTTP GET で試すことができませんが(LogicFlow で HTTP GET しようとした際に Body 値を指定するとエラーとして保存できません)

image

呼び出す側はこのような形で、作成した確認用の LogicFlow を直接呼び出します。ここでは、確認する頻度(デフォルトでの実行感覚)を 3 分としています。

まずはステータス 201 、RetryAfter 30 とした場合の挙動です。

image

これが一度目の呼出し時で、結果としてステータス 201 であり、RetryAfter 値が 30 と戻されているのが確認できます。

image

そして 2 度目の実行がこちらです。19:24:16 に実行されている事より、RetryAfter の値に指定されている秒数後に、再度 HTTP 呼出しが行われ、LogicFlow が実行されているのが確認できます。この場合は、HTTP トリガに設定してある実行間隔の設定よりも、RetryAfter 値が優先されているのがわかります。

image

続いてはステータス 202 の場合です。こちらも RetryAfter 値を同様に 30 と設定しています。

image

実際の結果はこのようになりました。ステータス 202 なので、LogicFlow 自体は実行されていないのですが、再試行されている間隔が RetryAfter 値で指定した 30 秒ではなく、HTTP トリガで指定した 3 分となっています。これはドキュメントの記載と異なる挙動です。

image

最後に正常動作となるステータス 200 の挙動を確認します。初回実行時に、このようにステータス 200 と RetryAfter 30 として返却された状態です。

image

結果としてはこのようになりました。ステータス 201 の時と同様で、RetryAfter の値に従って再試行が行われているのが確認できます。HTTP ステータスとしては 200 は正常終了(OK)、201 は完了(Created)ということもあり、現在の LogicFlow では正常終了扱いとして動作しているのがわかります。ですが 202 の受理(Accepted)については、ドキュメントしても非同期パターンで利用すると明記されているのですが、そのようには動作していないようです。

0 件のコメント:

コメントを投稿