Power Apps キャンバスアプリテンプレートを作る② 設定情報の管理
こんにちは。システムソリューション営業本部の吾妻です。
この記事は、私たちが今までに Power Platform サポート＆アプリカタログサービス をはじめとする Power Apps アプリ開発で得てきた経験をもとに、「アプリテンプレート」を作りながら、構成要素と考え方についてご紹介している連載の第2回目のものになります。
| Microsoft Japan Partner of the Yearについてはこちら➡ |
アプリテンプレートに含めたい事柄としては、
- マスタデータ（前回）
- 設定情報
- ログ・デバッグ
- 初期化処理
- データロード
- UIパーツ
設定情報の粒度
前回のマスタデータの管理では更新頻度に着目してみましたが、今回の設定情報の管理では、設定の粒度に着目して、Power Platformの中でどのように管理すべきか考えていきたいと思います。次の表は、よくある設定項目の例と、設定の粒度を示したものです。システムによって想定は異なるとは思いますが、大まかに、①アプリ全体に関する設定、②グループ毎に設定するもの、③ユーザー毎に設定するもの、の3つに分類してみました。
| 設定項目 | 粒度 | 内容 |
| アプリの バージョン情報 |
アプリ毎 / 固定 | アプリをデプロイする度にインクリメント※1 |
| 設定ファイルの バージョン情報 |
設定ファイルの フォーマット毎 / 固定 |
設定ファイルのフォーマットが変更された際にインクリメント※2 |
| デバッグ／ メンテナンスモード フラグ |
アプリ毎 / 管理者が(一時的に)変更 |
デバッグモード※3やメンテナンスモード※4へ切り替えるためのフラグ※5 |
| バリデーションに利用する値 | アプリ毎 / 固定 | 条件分岐の際の境界値を格納 |
| 配色 | ユーザー毎 / ユーザーが選択 |
UIのパーツの別の色情報を格納※6 |
| 初回起動フラグ | ユーザー毎 / ユーザーが変更 |
・初回起動時にフラグを切り替える ・初回起動時のみ案内を表示したり、設定画面に遷移させたりするために利用 |
| 言語設定 | グループorユーザー毎 / ユーザーが変更 |
・UIの表示言語やDBに格納する通貨型のフォーマットを、ブラウザのロケール設定等に依らずに独自管理する場合、言語タグや通貨コードを格納 ・他の設定値（翻訳ファイル等）を読み出す際のキーの一部として利用 |
※1 ... キャンバスアプリ内とDataverseテーブル内にそれぞれ定数を格納し、差異がある場合にアップデートを促すために使用する
※2 ... アプリ単位よりは広くなる可能性もある
※3 ... エラー表示を抑制しないモード
※4 ... どの画面にアクセスしても一律でメンテナンス画面を表示するモード
※5 ... アプリ内で定義してしまうとアプリを編集しないと切り替えられなくなってしまうため外部に配置する必要がある
※6 ... ライト／ダークテーマ等予め決められた選択肢から選択、または、カラーコード等を格納
設定情報の管理方法
マスタデータの場合とほぼ同じように、設定情報を格納する場合は以下のようなデータソースに格納・変更を行うことになります。| 機能 | 長所 | 短所 |
| ①Dataverse テーブル | RDB のテーブルと同様にリレーションを張ったりリレーションをたどったりして自由に利用できる | ソリューションをエクスポート／インポートする際に、テーブル構造はエクスポート／インポートできるが、データは保持されないため、別途データのエクスポート／インポートを行う必要がある |
| ②ローカル ・SaveData ・LoadData |
ローカルに保管するため、デバイスがオフラインの時にもデータを利用できる | ・データサイズの制約 ・突然データが削除される可能性がある |
マスタデータと異なり、ユーザー自身によって値が変更され得るので、読み出し専用のデータソースは利用せず、Dataverseテーブルまたはローカルに格納することになります。
一方で、設定の既定値を用意しておく場合、Dataverseテーブルに格納してしまうと、ソリューションパッケージをインポートした後に、データのインポートも独立して行う必要があるので、アプリ内の初期処理として設定の既定値を定義するか、初回起動時（Dataverseテーブルが空の状態の場合）に起動して、イニシャルデータをDataverseテーブルに書き込むクラウドフローをキャンバスアプリに仕込んでおくと便利です。
デモアプリ
ユーザー（クライアント）側の情報をキーとして、Dataverseのテーブルに格納されている設定情報を読み出す例を考えてみます。設定を管理するためのSettingテーブルと、設定種別を管理するためのSettingTypeテーブルの2つを、Dataverseに用意します。2テーブルの間には多対一のリレーションを張っておきます。
（画像をクリックすると別窓で開きます）
 |
 |
Settingテーブルの「Key」列は、設定の粒度に応じて階層をどんどん深くできるように、文字列型でファイルパスのような "/" 区切りで記述することにしました。設定種別を管理するためのSettingTypesテーブルを用意することで、設定値（「Value」列）ごとのバリデーションを行ったり、フォームのUIを変更したりする必要がある場合に対応できるようにしました。これにより、例えば、string型の列の場合は、TextInputに入力された値をそのままDataverseへ格納し、Color型の列の場合は、「形式が妥当か？」「RGBAのそれぞれの値が0～255の範囲内か？」「TextInputの代わりにカラーピッカーを表示する」といった追加の処理を行うことができるようになります。
また、今回は単一参照テーブルに設定キー・値を格納するようにしていますが、設定の種別ごとにテーブルを分割したり、ユーザー毎にレコードができるような横持ちのテーブルにデータを格納することも可能です。
単一参照テーブルの場合は後から設定項目を増やすことが容易という利点はある一方で、値を格納する時にデータベース側（Dataverse側）での制約チェックを利用できません。そのため、上のテーブルの場合、例えば、int型の整数文字列（整数型ではない）を想定した列に対して、整数でない文字列が格納される場合、データベース側ではなくアプリケーション側での制約チェックを用意しなければならないため、アプリを実装する際に注意しなければいけないポイントが増えることになります。
その一方で、設定種別・設定項目ごとにテーブルを分割した場合、当然後から設定項目の仕様変更があればDataverseのテーブルを変更しなければならなくなり、柔軟性が低下します。通常のWebアプリケーションなどでは柔軟性を重視する機会は多くないかと思いますが、Power Appsの場合は、PoC的に使い捨てたり、まずはMVP（Minimum Viable Product）を作るということも多いので、柔軟にテーブルを変更できたほうがいい場合も少なくありません。また、テーブルの数が増えるとJOINの数も増えるため、パフォーマンス上不利になるかもしれません（厳密に計測したことはありませんが、SQLクエリでJOINするときほど素早く取れることはないと思います）。どちらを選ぶかはトレードオフですが、今回は柔軟性の方を優先して、単一参照テーブルの方を選びました。
次に、キーとして利用する情報を取得するためのクラウドフローを作成します。今回は、 Office365ユーザー コネクタを利用して取得したユーザープリンシパル名・ドメイン（UPNから切り出す）・優先する言語と、 PowerApps (V2) コネクタを利用して取得したUser Agentを、キャンバスアプリに返すようにしました。User Agentについては、PCとAndroid、iOSを区別するために、 okhttp (Android) または Darwin (iOS) の文字列が含まれるかをキャンバスアプリ側で判定しようと思います。
ちなみに、UPN、言語設定を取得する方法としては、Office365ユーザーコネクタを利用する代わりに、キャンバスアプリのUser関数・Language関数を使ったり、 PowerApps (V2) コネクタで取得したヘッダのうち 'x-ms-user-email' 、 'Accept-Language' を利用することも可能です。
キャンバスアプリを作り、作成したクラウドフローをキャンバスアプリの App.OnStart で呼び出して、取得したデータを変数に格納しておきます。
アプリの初期化処理に、設定を読み込むための条件やLookUp関数を記述します。設定値をキャンバスアプリ側で格納するのにはコレクションを使いました（単一参照テーブルなので接頭辞はcolではなくgblにしています）。Upsert（キーがぶつかる既存レコードがあれば上書き）のような関数がないため、少しコードが長くなっています。コレクションではなくグローバル変数を使うと容易に値を上書きできますが、変数の数が膨大になってしまうので避けました。
このように実装することで、クラウドフロー側で用意しておいた言語コードやUPNのような設定値のキーとなる情報を利用して、階層的に徐々に絞り込みながら、該当するキーの設定値を上書きしつつ、読み込むことができます。そのため、冒頭で定義した設定の粒度（①アプリ全体に関する設定、②グループ毎に設定するもの、③ユーザー毎に設定するもの）毎に、柔軟に対応することができます。
まとめ
今回は、Power Platformで設定情報を管理する方法についてご紹介しました。マスタデータの管理の際は更新頻度に着目していましたが、今回の設定情報の管理では、設定の粒度、階層的な管理に着目しつつ、実装しました。
マスタデータの設計と同様に、実際にアプリを開発して運用してみて使いづらさに気づくことになりがちな箇所だと思います。
QESの Power Platform サポート＆アプリカタログサービス は、ただアプリを開発し提供するのみのサービスではなく、こうした壁にぶつかりそうなときにご利用いただける、ノウハウ提供、トラブル調査や解決策提示なども含まれているものになっています。まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
