はじめに
複数あるLogic Appsを一つにまとめる案件にあたり、「 共通処理 の部分を 複数のトリガー(Logic App呼び出し処理) から叩かせればいいじゃん！」と思い立った。
そこまではよかったのだが、「せや！ トリガーもわざわざ分けんで並列処理にしたらもっとまとめられるやん!! 天才か！ 」と思い立ちまとめてみたら、予想通りにはまとまらなかった。
反省も兼ねて本記事にナレッジを残しておくものとする。
目次
状況詳細
下図のように、複数のLogic Appsがあった。
それぞれのLogic Appsは取り扱うパラメータのみ異なる、共通化可能な処理を有していた。
これを、Logic Appsを入れ子にする方法を参考に、下図のように共通部分をまとめるものとした。
ここまでは文句なく良かった。別の開発現場に入っても応用可能な使える設計パターンだったと自負している。
何がしたかったのか？
問題は、この後、 トリガー に当たる部分を共通化した時、一長一短のトレードオフが発生してしまうことだった。
この複数のトリガーは、同一の種類のトリガー(例えばスケジューラなど)を利用していた。
よって、下図のようにトリガー部分も共通化してしまい、Logic Appsの呼び出し部分を並列処理にしようと考えた。
何がダメだったというのか？
一見、下記のようなメリットがあり、良さそうに見える。
- Logic Apps 呼び出し処理ごとにLogic Appsを作成しなくてよくなる
- 一か所に呼び出し処理がまとまるため、パラメータ管理が楽になる
正常に動くパターンのみを考えれば悪くないかもしれないが、 並列処理のどれか一つが実行に失敗して再実行する場合、単純にデザイナーから実行するともう処理が成功している処理まで実行されてしまうのである！！
一定期間に重複して実行しても構わない処理ならばこれでも問題ないが、例えばどのLogic Appsの呼び出し処理も、1日1回だけにしたいなどという要件があった場合、脆くもこの企てはまほろばの夢に朽ちることとなるのである。
解決策（暫定）
案1：共通処理のLogic Appsを直接叩く
結局のところ、呼び出し側に設定してあるトリガーは、HTTPリクエストトリガーである。
そのため、リクエストツールで直接叩いてしまえば、ピンポイントで再実行できんこともない。
案2：実行時にトリガーファイルを出力
共通処理で実行時に「実行済み」を示すトリガーファイルを出力しておく。
このトリガーファイルを、共通処理の最初のアクションで確認し、出力されていたら実行を中断する。
案3：あきらめてLogic Apps呼び出し処理を分ける
あくまでデザイナーから手軽にたたきたければ、トリガーまでまとめるのはあきらめて、別個に呼び出し処理を作ってしまえばいい。
別案求む
あくまで、解決策は暫定案である。
さらにベターな解決方法を発見されている先達がいらっしゃれば、コメントなどでご指摘いただけると大変助かります。