三島正裕のOffice 365コラム「Common Data Serviceは如何でしょう？そろそろリストも限界ではないですか？」

この記事のURLとタイトルをコピーする

1 はじめに
2 委任（Delegation）という考え方
3 Common Data Serviceという選択肢
4 Common Data Serviceでアプリケーション開発をするには
5 おわりに
6 三島正裕が登壇！オンデマンドウェビナー
7 DX教育サービス、「Microsoft Power Apps」見本アプリ
8 「Microsoft Power Apps」導入事例
9 Microsoft Power Apps ハッカソン、イベント登壇レポート

はじめに

こんにちは！クラウドビジネス担当の三島です。Office 365徹底活用コラム9回目ということで、今回はOffice 365のCommon Data Serviceについて少し触れてみたいと思います。

皆さんはOffice 365で業務アプリケーションを作成するとき、データソースは何を使われますか？方法は色々とありますよね。比較的簡単な方法をあげると、OneDriveやExcelがあります。Excelはテーブル化すれば簡単なデータベースとして利用出来ますし、メディアコンテンツ(画像や動画)をOneDriveに置けば、これらを組み合わせたアプリケーションを作成することも出来ます。SharePoint Onlineを使う方法もありますよね。最近ではリストを作成すると、ボタン1つでPower Appsアプリケーションを作成することも出来ます。Dynamics365やSalesforceをお使いであれば、これらをそのままデータソースとして利用されることもあるとか思います。
Office365にはたくさんのコネクタが用意されていて、ありとあらゆるデータに接続してアプリケーションを開発することが出来ますが、仕様の段階で気を付けなくてはならないことがあります。それがデータソースのレコード件数です。一般的にデータベースに接続されているアプリケーションは、処理の度に全レコードをアプリケーション側とやり取りしているわけではなく、一部のデータのみをやり取りしています。アプリケーション側からの命令で、データベース側は対象レコードを絞り込み、集計した結果や対象レコードの情報のみをアプリケーション側に返します。これは、アプリケーション本体や、メモリ、ネットワークの負荷を軽減する目的で行われます。Office 365のアプリケーション開発ツールPower Appsは、モバイルで利用されるケースも想定されています。そのため、Power Appsでは大量のデータ通信を行わないよう、レコード件数も初期設定で500件、最大で2000件迄と制限されています。最も古いデータから500～2000件までのデータのみが処理の対象となりますので、制限を超えているデータは、古いデータが削除されない限り処理の対象とはなりません。

委任（Delegation）という考え方

データの検索や集計をアプリケーション側で行うのではなく、データソース側で処理させることを、Power Appsでは委任という呼び方をします。データソース側に大量のデータが存在していたとしても、委任をすることで必要最低限のレコード件数でやりとりをすることが出来ます。しかし、委任も利用出来るデータソースが決まっており、現時点では、SQL Server、SharePoint、Common Data Service、Dynamics365、Salesforceのみが対象となっています（2018年12月現在）。委任がサポートされる関数もデータソース毎に決まっています。例えばフィルター関数は概ねどのデータソースでも利用出来ますが、集計関数（SumやMaxなど）は使用出来るデータソースは限定されています。また、関数の述語単位（等号・不等号など）でサポートが異なるものもあります。

使用出来る関数や述語の一覧がメーカー公式サイトのドキュメントにありますので、確認をしてみて下さいね。
https://docs.microsoft.com/ja-jp/powerapps/maker/canvas-apps/delegation-list

Common Data Serviceという選択肢

これまでのコラムでは業務改善というテーマでPowerAppsアプリケーションの作り方を紹介しておりましたが、学習ということで、短時間で開発出来ることや開発工程が少ないことから、SharePoint Onlineのリストをデータソースとして主に取り扱ってきました。レコード件数の少ない小規模のアプリケーションであれば、これでも長期間の使用に耐えうるのですが、ユーザー数が増えたり、利用期間が数年にも渡ったりすることを想定した場合、リストのみの設計では非常に厳しくなってきます。

そこで「Common Data Service（以下CDS）」です。CDSはマイクロソフトが提供するビジネスアプリケーションプラットフォームの1つで、エンティティと呼ばれるデータ構造でデータを格納しています。位置付けとしてはPower AppsやPowerBIと同じ製品グループに属してはいますが、あらゆるアプリケーションデータを統合的に管理することを目的に設計されているため、規模にとらわれない柔軟なデータプラットフォームとして構築することが出来ます。
CDSはアプリケーションの利用者側にもメリットがあります。1つはレスポンスです。どのようなデータソースを使用していても、データ量が増えてくると必ずアプリケーションの動作は鈍くなります。それはSharePoint Onlineのリストも同様で、リストのレコード件数が増えてくると、データの読み書きが関わる動作は鈍くなってきます。では実際のところ、CDSとリストではどの程度レスポンスに差があるのか、当社環境で確認したところ、このような結果が出てきました。

レコードの追加削除についてはCDSがリストに対して平均60％、更新については平均40％程度の速度で処理が完了しています。この結果を見るだけでもCDSを利用するメリットはありそうですよね。前述した委任については如何でしょう。CDSとリストでは委任出来る関数にも差があります。データの検索や絞込みに使用するSearch関数はCDS側では委任出来るのに対し、リスト側ではサポート対象外となっています。更にリストではFilter関数やLookUp関数（数式を満たす最初のレコードを検索）で使用する不等号（<，<=）も委任することが出来ません。データソースに置くレコード件数が多くなる程、委任の重要度は増し、処理出来るレコード件数もソース毎に差が出てきます。それは開発が可能なアプリケーションにもダイレクトに影響しますので、将来性を考えると、より多くのアプリケーションを開発提供出来るCDSの方が、利用者にとっては便利だと言えるはずです。

Common Data Serviceでアプリケーション開発をするには

CDSを利用してアプリケーション開発をするにはPowerAppsが必要ですが、Office365プランに含まれるいわゆる「PowerApps for Office 365」では利用することが出来ません。PowerApps単体の有償プランである「プラン1」、「プラン2」の購入が必要となります。詳細については下記リンクをご参考下さい。
https://powerapps.microsoft.com/ja-jp/pricing/
CDSには無料で試せる「Community Plan」も用意されています。1ユーザーでの使用に限定されていますが、全ての機能を無料で試すことが出来ます。

おわりに

Offcie365アプリケーションのデータソースはCDSが良いのか、それともSharePoint Onlineのリストが良いのか。その判断はユーザー数やレコード件数にもよりますが、業務として本格的に運用する予定であれば、最初からCDSを利用することをお勧めします。実際にPowerAppsアプリケーションを運用していると実感すると思いますが、十数名程度のユーザー数で毎日リストにデータを登録すれば、1年も経たずしてレコード制限を超えてしまいます。また、運用途中で他のデータソースに切り替えるのは非常に大きな労力やコストを要します。データの移行作業も発生します。それならば最初から多機能、高性能なデータソースをベースに構築する方が結果的には負担が少ないですよね。
CDSを使ったアプリケーションについては、コラムでも少しずつ紹介させて頂きたいと思いますので、皆様もぜひトライしてみて下さいね。それでは次回もお楽しみに。Office 365につきましてはお気軽にディーアイエスサービス＆ソリューションまでお問い合わせください。