このシリーズについて
フローとつながったキャンバスアプリを別環境へ移すときの管理方法を、全5部で整理しています。1部ごとに1つの判断を扱い、読み進めると推奨構成にたどり着く形です。本記事は第3部です。
- 第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション
- 第2部 ソリューションを1本にするか、2本に分けるか
- 第3部 移行先の SharePoint との差は環境変数で吸収する（この記事）
- 第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない
- 第5部 結局どう運ぶのがよかったか
この記事は学習メモです。実際に検証できた範囲と、まだ推測にとどまる範囲を分けて書いています。間違いや不足に気づいたら随時更新します。
最終的なゴールは、アプリとフローを別テナント（先方環境）へ移すことです。現在は自分たちのテナント内にある開発環境と既定環境を使って検証している段階で、未検証の部分も残っています。ある程度方向性が定まってきたので、いったん整理しました。
この記事では、キャンバスアプリの「パッケージのエクスポート」で出力するものを「アプリのパッケージ」、Dataverse のソリューションとしてエクスポートするものを「ソリューション」と呼び分けています。
背景
第2部で、アプリ用とフロー用にソリューションを2本に分けると決めました。次に出てくるのが、移行先では参照する SharePoint のサイトやリストが変わるという問題です。参照先を直接書いていると、環境ごとに直して回ることになります。
課題
これを吸収するのが環境変数（環境ごとに中身を差し替えられる設定値）です。フロー側の使い方は分かっていました。ソリューション内に環境変数を作っておくと、SharePoint のアクション設定でサイトやリストを指定するときに、動的なコンテンツの一覧にその環境変数が出てきます。それを選んでおけば、移行先では値を差し替えるだけで済む。
実際、サイトとリストを環境変数で参照する形にしたフローとアプリを一式そろえて別環境へ新規でインポートし、アプリを操作してフローが正常に動くところまでは確認済みでした。自分たちのテナント内の既定環境と、先方テナントの環境の両方で試して、どちらも問題なく使えています。移行先のリストは、表示名と内部名を移行元と同じにして用意しました。なお、このときの運び方はフローがソリューション、アプリがアプリのパッケージという構成で、第1部の結論を出す前のものです。ここで見ているのは環境変数が効くかどうかだけになります。
分からなかったのはアプリ側です。アプリの編集画面で環境変数を選べる条件がはっきりしていませんでした。
調べたこと
検証用のテストアプリと新しいソリューションを作って試しました。ソリューションにアプリを入れてから編集画面を開き、データソースの追加ダイアログを出すと「詳細」タブが現れ、環境変数のリストを選んでデータソースとして追加できます。一方、ソリューションに属していないアプリではこのタブ自体が出ません。出てくるのは URL の入力欄と、最近使ったサイトの一覧だけでした。
結果
環境変数を使うなら、アプリはソリューションに入っている必要がある。第2部で2本に分けると決めた時点で、この条件は満たせていました。
ただ、確認できたのはデータソースとして追加できるところまでです。本当ならその環境変数を経由してリストへ読み書きできるかまで見ないと、フロー側と同じ水準で確かめたことにはなりません。そこはまだ試せていないので、今後の宿題ですね。
なお、移行先のリストは表示名と内部名を揃えておくのが前提になります。公式にも、列の名前が一致している必要があると書かれていました。
まとめ
移行先の SharePoint サイトやリストの違いは、環境変数で吸収します。編集画面で環境変数を選べるのはソリューション内のアプリだけなので、ソリューションで運ぶという第2部の判断が、そのまま環境変数を使うための条件にもなっています。
参考
- キャンバス アプリでデータ ソース環境変数を使用する
https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/environmentvariables-data-source-canvas-apps - Power Platform ソリューションで環境変数を使用する
https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/environmentvariables
前の記事：第2部 ソリューションを1本にするか、2本に分けるか
次の記事：第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない