1. システムとオフィスの融合
  2. media
  3. マイクロソフトソリューション Power Apps Power Platform Power Automate
  4. Power Apps キャンバスアプリテンプレートを作る⑤ データロード

QESブログ

Power Apps キャンバスアプリテンプレートを作る⑤ データロード

  • LINEで送る
  • このエントリーをはてなブックマークに追加



こんにちは。システムソリューション営業本部の吾妻です。

この記事は、私たちが今までに Power Platform サポート&アプリカタログサービス をはじめとする Power Apps アプリ開発で得てきた経験をもとに、「アプリテンプレート」を作りながら、構成要素と考え方についてご紹介している連載の第5回目のものになります。

アプリテンプレートに含めたい事柄としては、

  1. マスタデータ
  2. 設定情報
  3. ログ・デバッグ
  4. 初期化処理(前回)
  5. データロード
  6. UIパーツ
を考えていますが、今回は5つ目の、データ読込み処理を実装する際の考え方についてご紹介していきます。


データ読込み処理の種類

キャンバスアプリが外部のデータソースに対して行う「データロード処理」として、タイミング別に以下のようなものが挙げられます。タイミングごとに、読込むデータの特徴も異なることが多いので、実装方法を検討する前に、対象とするデータソースをどのタイミングで読込むか整理しておくと良いです。読み込み元となるデータソースは原則Dataverseですが、SharePointをはじめとする「データベースのようなもの」や、コネクタ経由でのAPI呼び出しも含めます。
 タイミング   内容 
 ①バックグラウンド(バッチ処理)   保有ライセンス等の制約により、DataverseテーブルとSharePointリストの双方をデータソースとして利用する場合に、双方のデータの同期を取るための読み書きを行う
 ②アプリ起動時   マスタデータや設定情報といった、比較的データ量が小さく、アプリ起動中にあまり変更されない情報を読込む 
 ③遅延読込み   マスタデータ・トランザクションデータのうち、ある程度容量が大きいデータをバックグラウンドで読込む 
 ④検索   ユーザーの指定した値に基づいてデータソースに検索を行ったり、APIを呼び出したりして、結果を読込む  
 ⑤更新処理直後   フォームを送信したり、Patch関数でデータを書き込んだ直後に、UIに反映するためにデータソースから情報を読込む 
 

データ読込み処理のポイント

データ読込み処理の実装に当たって、考慮しないといけない一番重要なポイントは「データ量の削減」です。
アプリを実装、利用する側にとっては、データを際限なく扱えることが理想ですが、パフォーマンスの面で制約があります。最近私が相談を受けたデータ読込み周りのトラブルとして、以下のようなものがありました。
  • 従業員マスタと1対1関係にある「拡張ユーザーテーブル」を利用するアプリを展開したところ、データの読込みに10分以上掛かるようになってしまった
  • 店舗マスタを各店舗ごとに管理してもらうアプリを展開したところ、データを更新した後に画面がフリーズしてしまう
  • リレーション先のレコードを選択するコントロールを実装したが、必要なレコードが表示されず、選択できない
いずれの事例も、一定以上の規模(ユーザー、店舗、取引情報、…)の会社であればどこでも発生し得るものだと思います。
そこで、どのようにテーブル、アプリを実装すれば、こうした問題を回避できるのか、考えていきたいと思います。


テーブル設計

まず、テーブルを設計する時点で、取り扱うデータの行や列をなるべく抑えます。

列に関しては、①テーブルを正規化して重複して存在する情報を削減したり、②業務上必要がなくなった列を削除したり、③列のデータ型・サイズを格納される情報に適したものに変更したりといった方法を検討します。

行に関しては、④アーカイブデータ(業務上は利用し終わったが、保存しておかないといけない情報)をAzure SQL Database等の外部のデータベースにオフロードさせたり、⑤単一テーブルに格納していた情報を水平分割して複数のテーブルに分散させたりといった方法を検討します。

また、データソースに対して直接アクセスするだけでなく、クライアント側(アプリ側)の変数をキャッシュ的に扱うことで、ネットワークを経由することによるパフォーマンス低下を抑える方法も検討する必要があります。


UI設計

次に、UI上の工夫によって、アプリに持ってくるデータを絞り込む必要があります。

まず、「一覧形式で全てのレコードを表示する」ようなUIは排除して、検索を前提としたUIを実装することが望ましいです。キャンバスアプリには「データ行の制限」という仕様があり、2000件(デフォルトは500件)を超えるデータは原則扱えないため、検索キーワードや日付といった検索条件で予め絞り込んでからユーザーに提示する必要があります。ギャラリーコントロール等の一部例外はあり、2000件超の一覧を表示させることもできなくはないですが、原則一覧形式はモデル駆動型アプリに任せるという役割分担を前提にした方が良いです。

次に、リレーションが張られたテーブルがある場合に、子テーブルの情報を親テーブルの一覧に混ぜ込んで表示するのは避けた方が良いです。例えば、従業員に紐付いたコメントを蓄積するテーブルがあるとします。アプリ側で従業員を一覧表示するギャラリーに直近のコメントも含めるUIを実装する場合、リレーションを辿るのではなく、予め親テーブル側に子テーブルのデータを複製しておき、親テーブルのみからデータを取得するような方法を検討します。この複製処理には、Power Automateクラウドフローを利用したりDataverseの集計列を利用したりすることが可能です。

また、初期化処理のときと同様に、プログレスサークルを表示することで、アプリ利用者の「体感速度」をなるべく落とさないUIとすることも有用です。ただし、あくまでもユーザーの体感速度のみに関わるもので、データ読込み処理そのものを高速化したり最適化したりするわけではないので、最終手段と考えた方が良いです。
baseapp20.png


まとめ

今回は、Power Appsでデータ読込み処理を実装する際の考慮事項についてご説明しました。データ読込みも初期化処理と同様に、慎重に実装方法を検討しないと、アプリのパフォーマンス、操作性が低下してしまうことが考えられます。

QESの Power Platform サポート&アプリカタログサービス は、アプリを開発するだけのサービスではなく、トラブルシューティング、パフォーマンス改善のような、運用を始めてから重要になってくる技術サポートについても含まれるものになっています。まずはお気軽にお問い合わせください。







このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。

  • LINEで送る
  • このエントリーをはてなブックマークに追加

お気軽にお問い合わせください。

ページのトップへ