記事公開日
最終更新日
Power Apps キャンバスアプリテンプレートを作る① マスタデータの管理
こんにちは。システムソリューション営業本部の吾妻です。
普段はテレワークで勤務しているのですが、先日開催された「Microsoft Inspire」の配信の際は、本社オフィスに出社して、ステージの大画面で視聴しました。
さて、ローコードツール「 Power Apps 」を利用したアプリケーション開発、特に業務部門ユーザーによる市民開発が会社内に浸透していくと、作成されるアプリの数がどんどん増えていきます。アプリの数が増えてくると、目的の異なるアプリ同士であっても存在するベースの部分をいかに手間をかけずに実装するかという点や、作成されたアプリの運用性・保守性をいかに高めて機能追加・トラブルシューティングしやすい環境を保つかという点が気になってくると思います。
そこで今回の記事では、私たちが今までに Power Platform サポート＆アプリカタログサービス をはじめとする Power Apps アプリ開発で得てきた、「ここはこう設計した方が良かった」「ここはこう実装して良かった」といった経験をもとに、「アプリテンプレート」を作りながら、構成要素と考え方についてご紹介できればと考えています。本当は、Django (Python)やLaravel (PHP)といったWebフレームワークのように「コマンド一発でプロジェクトのベースができあがる」ものができれば良いのですが、残念ながらPower Platformにはそのようなものはないので、「ソリューションパッケージをインポートして、アプリの編集をし始める」のに利用できるようなテンプレートを目指します。
アプリテンプレートに含めたい事柄としては、
を考えていますが、今回は1つ目のマスタデータ管理の考え方についてご紹介していきます。
事前準備
Power Apps の試用環境（テナント）をお持ちでない方は、以下の記事の手順でご用意ください。
マスタデータの更新頻度
今回は、マスタデータの更新頻度に着目して、Power Platformの中でどのように管理すべきか考えていきたいと思います。次の図は、よくあるマスタデータの種別と、想定される更新頻度を示したものです。
会社によって、またはシステムによって想定される更新頻度は変わるかと思います。例えばユーザーマスタの場合、新規ユーザーが来た時にIT部門に依頼してID・パスワードを払い出してもらわないといけないシステムと、同じ部署のユーザーがユーザー申請を行い、上長の承認を得て自動的にID・パスワードが払い出されるシステムでは更新頻度が変わります。また、図では数年～数十年毎に更新するとした国マスタの場合、世界中のすべての国を対象にする場合と、例えばJPとUSのみを対象にする場合では変更が入る可能性がだいぶ変わってくると思います。
マスタデータの管理方法
Power Platformでマスタデータを管理する場合、取り得る手段としては、以下のようなものがあります。| 機能 | 長所 | 短所 |
| ①Dataverse テーブル | RDBのテーブルと同様にリレーションを張ったりリレーションをたどったりして自由に利用できる | ソリューションをエクスポート／インポートする際に、テーブル構造はエクスポート／インポートできるが、データは保持されないため、別途データのエクスポート／インポートを行う必要がある |
| ②環境変数 | ソリューションをエクスポート／インポートする際に、対象に含めるかどうか選択できる | データ型がスカラー値なので、表形式のデータを格納しにくい（カンマ区切りで無理やり格納することは可能） |
| ③キャンバスアプリにコレクションを定義 | リモートのデータソースに読みに行かないため、結果を得るまでの時間を短縮できる | ソリューションの中に複数のキャンバスアプリが存在する場合、マスタが重複して存在することになり管理が困難 |
| ④キャンバスアプリに静的 Excel ファイルを埋め込み | 〃 | 〃 （ただし、ExcelファイルをGit等で管理していれば、③コレクション定義よりは管理が容易） |
| ⑤管理しない | 自前で管理する手間が省ける | 外部データソースに依存するため、破壊的な変更が加わったり、利用できなくなったりするリスクがある |
通常Power Platformでデータストアとして利用するのはDataverseテーブルなので、マスタデータも基本的にはDataverseテーブルに格納します。
特に、リアルタイムで変更されるようなデータや、比較的短い頻度で頻繁に更新されるようなデータは、自動化されたクラウドフローやデータフローとの相性を考えるとDataverseテーブル一択だと思います。
データフローについてはこちらの記事でご紹介しています。
その一方で、ソリューションパッケージをエクスポート／インポートする際の仕様から、一度決めたら（ほぼ）固定となるようなデータは、Dataverseテーブルではなく静的Excelファイルとしてキャンバスアプリに埋め込んでしまうのが便利です。埋め込まれたExcelファイルのデータは、Dataverseテーブルと同様にテーブル型のデータソースとしてアクセスできるので、使い勝手はほぼ変わりません。
固定のデータもDataverseテーブルに格納しても良いのですが、ソリューションパッケージをインポートした後にデータのインポートも独立して行う必要があるので、若干面倒です。初回起動時（Dataverseテーブルが空の状態の場合）に起動して、イニシャルデータをDataverseテーブルに書き込むクラウドフローをキャンバスアプリに仕込んでおく方法もありますが、1度切りの処理のためにクラウドフローを用意するのも手間です（しかも、そのクラウドフローが静的なファイルをデータソースにDataverseテーブルに書き込むのであれば2度手間です）。
静的Excelファイルをキャンバスアプリで利用するには、以下のように、「データの追加」から「Excelからインポート」を選択し、ローカルファイルを選択します。
データフローでインポートするのとは異なり、いったんOneDrive for Businessにファイルアップロードする必要がないのもメリットの1つです。
さらに、マスタデータの種類によっては、Power Platformの中でマスタデータを管理せず、外部のデータソースから読み込むのみとする方法もあります。
例えば、従業員マスタを例に挙げると、Dataverseに「従業員テーブル」を用意せず、ユーザーの管理をAzure AD上のみで行ったうえで、Power Appsでは「Office365ユーザー」コネクタを利用してユーザーデータを読み込むことができます。
（Azure ADとPower Platformのどちらかしか自由に触れない〈管理者権限的な面 ＆ 社内手続き的な面〉場合は、ユーザーマスタをPower Platform側で自前管理にしておいた方が、後々悩まずに済むかと思います）
まとめ
今回は、Power Platformでのマスタデータ管理方法についてご紹介しました。
一見、Dataverseでなんでも管理すればいいように思われますが、実際にアプリを開発して運用してみると必ずしもそうではなく、余分な開発が発生したり、代替手段を利用した方が良かったりすることもあります。こうした課題には、臨機応変な対応が求められますが、はじめにデータを検討する段階ではなかなか決めにくい面もあります。
QESの Power Platform サポート＆アプリカタログサービス は、ただアプリを開発し提供するのみのサービスではなく、こうした壁にぶつかりそうなときにご利用いただける、ノウハウ提供、トラブル調査や解決策提示なども含まれているものになっています。まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
