このシリーズについて
フローとつながったキャンバスアプリを別環境へ移すときの管理方法を、全5部で整理しています。1部ごとに1つの判断を扱い、読み進めると推奨構成にたどり着く形です。本記事は第5部です。
- 第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション
- 第2部 ソリューションを1本にするか、2本に分けるか
- 第3部 移行先の SharePoint との差は環境変数で吸収する
- 第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない
- 第5部 結局どう運ぶのがよかったか（この記事）
※各記事へのリンクは公開後に追加します。
この記事は学習メモです。実際に検証できた範囲と、まだ推測にとどまる範囲を分けて書いています。間違いや不足に気づいたら随時更新します。
最終的なゴールは、アプリとフローを別テナント（先方環境）へ移すことです。現在は自分たちのテナント内にある開発環境と既定環境を使って検証している段階で、未検証の部分も残っています。ある程度方向性が定まってきたので、いったん整理しました。
この記事では、キャンバスアプリの「パッケージのエクスポート」で出力するものを「アプリのパッケージ」、Dataverse のソリューションとしてエクスポートするものを「ソリューション」と呼び分けています。
背景
ここまでで4つの判断をしてきました。アプリのパッケージではなくソリューションで運ぶ、アプリ用とフロー用に2本へ分ける、SharePoint の差は環境変数で吸収する、フロー参照は依存関係に任せる。これらを1つの構成としてまとめます。
課題
最後まで分からなかったことがあります。アプリのパッケージで「更新」を選んだとき、フローの表示名や所有者、有効・無効の状態がどうなるのか。公式に記載を見つけられず、推測のままです。
対応方法
分からない部分には触らない構成を選びました。整理すると次のようになります。
- ソリューションはアプリ用とフロー用の2本に分ける
- 環境変数はどちらか一方に置く
- 初回のインポートはフロー用を先、アプリ用を後の順で行う
- 以降、アプリだけの更新はアプリ用ソリューションの入れ替えで完結させ、フローには触らない
インポートのときに指定を求められるのは、接続参照と環境変数の値だと考えています。アプリはフローを識別子で参照しているので、先にフロー用を入れておけば移行先に参照先が存在する状態になり、インポート画面で選び直す操作は出てこないはず。ただしこれは仕組みからの推測で、実際にこの順でインポートするところまでは確認できていません。
インポートが通ったら、そこで終わりにしないほうがいいと思っています。インポートの成功は構造が揃ったことを示すだけで、実際に動くかは別の話です。一般ユーザーのテストアカウントで1件通すところまで確認すると、依存関係の問題と実行時の権限の問題を切り分けられます。
結果
第3部の時点では、環境変数についての当初の心配は解消していました。それでもアプリのパッケージは選ばないという結論になっています。理由は2つで、エクスポートした時点のフロー定義まで運んでしまうことと、アプリからフローへの参照が環境をまたいで維持されないことです。
公式には、フローや接続参照など Dataverse への依存があるキャンバスアプリはアプリのパッケージではサポートされていない、とも書かれています。エラーで止まるとは限らないので、動いてしまったときに判断を誤りやすいところですね。動いたかどうかと、その方法が想定されているかどうかは別に考えたほうがよさそうです。
1本にまとめない理由は第2部のとおりで、触っていないフローを上書き対象に入れたくないからです。
まとめ
アプリ用とフロー用にソリューションを2本用意し、環境変数はどちらか一方に置き、初回はフロー用から順にインポートする。この形にしておくと、以降はアプリ用ソリューションの入れ替えだけで更新が完結するはずです。ここも含めて未検証の項目がいくつか残っているので、実測しながら埋めていくつもりです。
参考
- キャンバス アプリのエクスポートとインポートの概要
https://learn.microsoft.com/ja-jp/power-apps/maker/canvas-apps/export-import-app - ソリューションのインポート
https://learn.microsoft.com/ja-jp/power-automate/import-flow-solution
前の記事：第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない
これでシリーズは完結です。未検証の項目を確かめたら、各記事を更新していきます。