アプリからフローを呼ぶ参照は、環境変数では吸収できない

このシリーズについて

フローとつながったキャンバスアプリを別環境へ移すときの管理方法を、全5部で整理しています。1部ごとに1つの判断を扱い、読み進めると推奨構成にたどり着く形です。本記事は第4部です。

1. 第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション
2. 第2部 ソリューションを1本にするか、2本に分けるか
3. 第3部 移行先の SharePoint との差は環境変数で吸収する
4. 第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない（この記事）
5. 第5部 結局どう運ぶのがよかったか

この記事は学習メモです。実際に検証できた範囲と、まだ推測にとどまる範囲を分けて書いています。間違いや不足に気づいたら随時更新します。

最終的なゴールは、アプリとフローを別テナント（先方環境）へ移すことです。現在は自分たちのテナント内にある開発環境と既定環境を使って検証している段階で、未検証の部分も残っています。ある程度方向性が定まってきたので、いったん整理しました。

この記事では、キャンバスアプリの「パッケージのエクスポート」で出力するものを「アプリのパッケージ」、Dataverse のソリューションとしてエクスポートするものを「ソリューション」と呼び分けています。

背景

第3部で、移行先の SharePoint サイトやリストの違いは環境変数で吸収できると分かりました。そうなると気になってくるのが、環境をまたいで変わるものは他にもあるという点です。アプリからフローを呼ぶ参照がそれにあたります。移行先にあるのは、開発環境とは別のフローだからです。

課題

これも環境変数で吸収できるなら話は早い。ただ、環境変数を作るときに選べるデータ型は、10進数・テキスト・JSON・2つのオプション・データソース・シークレットの6つで、フローという型はありません。つまり「このフローを呼ぶ」という参照を環境変数に持たせる方法はない、ということになります。

調べたこと

では何が参照を支えているのか。Claude に依存関係まわりの記述を当たってもらったところ、ソリューションの依存関係に行き着きました。アプリはフローを識別子で参照していて、移行先にその参照先が存在していれば解決される。逆に言えば、アプリ用ソリューションを入れる時点で、参照先のフローが移行先にいなければ成立しません。

同じ理屈が環境変数にも当てはまります。公式には、別のソリューションにある環境変数を選んだ場合、その環境変数を含むソリューションへの依存関係が生じると書かれています。そのため、エクスポート前に自分のソリューションへ環境変数を追加しておくか、自分のソリューションをインポートする前に環境変数を含むソリューションを移行先へ入れておく必要がある、と。

結果

第2部でソリューションを2本に分けたので、ここから初回のインポート順序が決まります。フロー用を先に、アプリ用を後に。この順で入れれば、アプリ用を入れる時点で参照先のフローも環境変数も移行先にそろっている状態になります。

環境変数は環境ごとに変わる値を差し替える仕組みであって、コンポーネント同士のつながりを運ぶ仕組みではない。フロー参照はソリューションの依存関係が引き受ける。第3部で環境変数の守備範囲を確かめた流れで言うと、その外側にあるものがここで見えてきた形です。

まとめ

アプリからフローを呼ぶ参照は、環境変数では吸収できません。ソリューションの依存関係で維持されるので、初回のインポートはフロー用を先、アプリ用を後の順で行います。

参考

• Power Platform ソリューションで環境変数を使用する
  https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/environmentvariables
• キャンバス アプリでデータ ソース環境変数を使用する
  https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/environmentvariables-data-source-canvas-apps

---

前の記事：第3部 移行先の SharePoint との差は環境変数で吸収する
次の記事：第5部 結局どう運ぶのがよかったか