※この記事は プログラマがPower Automate for Desktopを使う シリーズの一つです。
環境の変化に強いフローを作るには
サイトや拡張機能といった環境が変化した際に、素早く追従できるようにするために、フローの呼び出しとサブフローの呼び出し構造で配慮すべきことを述べます。
共通処理のモジュール化
共通フロー
2つのフローに同じ処理がある場合、同じ処理を共通フローに納め、2つの処理では共通フローを呼び出す形に改善できます。
この改善については、トレードオフがあるので、考慮が必要です。
- フロー数が増えるとPower Automate for Desktopの動きが遅くなる
- 同じ処理が2箇所に書いてあると維持しにくい
共通サブフロー
1つのフロー内の2つのサブフローに同じ処理がある場合、同じ処理を共通サブフローに納め、2つの処理では共通サブフローを呼び出す形に改善できます。
この改善については、トレードオフはないので、共通化を進めるべきです。
変化しやすい箇所の局所化
フローは、操作の対象が変化すると、動かなくなります。私が体験した変化の例を挙げます。
- Webサイトが模様替えをし、htmlが変わった。
- パスワード管理ソフトにシナリオに関係が無いアカウントを追加したら、拡張機能のポップアップ画面の中身が変わった。
- ブラウザの拡張機能の増減で、ブラウザから見た拡張機能番号が変わった。
フローを使い続ける場合には、操作対象の変化はいずれは起きる事なので、変化する箇所を要因ごとに分離し、1フローまたは1サブフローに収めておくべきです。箇所の例を挙げます。
- Webサイトのトップページが変わったときに影響を受ける箇所
- Webサイトの注目するページが変わったときに影響を受ける箇所
- 利用している拡張機能が変わったときに影響を受ける箇所
- Chromeの拡張機能の出入りが変わったときに影響を受ける箇所
これらの箇所を1つのフローまたはサブフローにしておけば、変化があった際にはそのフローまたはサブフローだけを改造すれば済みます。
サブフローの文脈独立性
1つの大シナリオに2つの小シナリオがあり、大シナリオをフロー化し小シナリオをサブフロー化する際の話しです。小シナリオが独立な（つまり相互に結果を使わない）場合には、サブフローは先行するものの副作用に依存しないように作るべきです。
例えば、フローが次の形だったとします。
前処理
サブフローAを呼ぶ …この中で小シナリオAを行う
サブフローBを呼ぶ …この中で小シナリオBを行う
後処理
サブフローBのデバッグに際して
- 「サブフローAを呼ぶ」ステップを一時的に無効化してフローを流す
- 「前処理」後にフローを停め、サブフローBを「ここから実行」で動かす
という手段を使う場合があります。その時、サブフローBがサブフローAの副作用に依存しないことが必要です。
このため、私は今回のシナリオについては次の作法を使いました。
- サブフローは起点になるページがフォアグラウンドになっている前提で始める
- サブフローは起点になるページがフォアグラウンドになるように終了する