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

Print Friendly, PDF & Email

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

1.はじめに

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

2.委任(Delegation)という考え方

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

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

3. Common Data Serviceという選択肢

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

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

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

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

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

5.おわりに

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

※Office365については以下をご覧ください。
https://www.si-jirei.jp/office365/

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

Related post

更新情報

最新コラム

  1. はじめに 先日、マイナビにて新連載 「5分で理解するITセキュリティ最新動向コラム」 を始め…
  2. こんにちは!クラウドビジネス担当の三島です。今回のOffice365コラムでは、社員の労働時間を把…
  3. こんにちは。吉政創成の吉政でございます。 今日は「クラウドを購入する際は技術の顔が見えるシェ…

ログインステータス

Return Top