SharePoint Onlineで大量データを管理する方法

SharePoint Onlineでは、昔から「5000件問題」がネックになってきました。本稿執筆時点で、モダンビューではこの制限が撤廃されています。(新しい上限値の情報を探しているのですが見当たりません。。。)

SharePoint Onlineのモダン表示では5000件問題が解消されている - 鍋綿ブログ

但しクラシック表では相変わらず問題になっているため、フォルダ分けで対応している状況です。

というわけで、クラシック表示の機能を使って5000件問題に対処する構築を考えてみたいと思います。

なお先に断っておきますが、どう構築しても5000件超えると面倒です。
1フォルダを5000件以内に抑える設計と運用ができるならば、それに越したことはありません。
絶対にシステム側で対処するという強い決意がある方はこの先へお進みくださいませ。。。

5000件問題のおさらい
今回想定する要件
要件を満たすための構築例
結論

5000件問題のおさらい

はじめに、SharePoint Onlineの5000件問題についておさらいしておきます。

SharePointのリスト/ライブラリは、公式サイトによると3,000万件までのアイテムを格納できるようです。

SharePoint Online の制限 - SharePoint

但し、アイテムを表示する機能である「ビュー」の制限により、「1度に表示できる件数は5,000件まで」となっています。(クラシック表示のみ)

SharePoint で大規模なリストとライブラリを管理する - SharePoint

ビューは既定の設定ではフォルダ1つ分を見せるものですから、実際にビューを運用できるのは「1フォルダ当たり5,000件まで」と考えるのが簡単です。

[詳しい方向けのTIPS]

　APIやCSOMでアイテムを取得する際も同様の制限があります。
　より正確に表現するならば、5000件問題はビューの制限というよりも
　APIの制限と言うべきかもしれません。
　開発によって逃れようとしても結局はフォルダ分けが必要になります。

以下に挙動の一例を紹介します。

PowerBIでカスタマイズしたビューでも制限は同様。
フィルタによって5,000件以内に抑えてもダメ。（インデックス付きの列を使ったフィルタは例外）
ページングによって1ページを5,000件以内に抑えてもダメ。
ページング無しで件数を絞る設定をすれば全件で5,000を超えていても表示可能。(30件しか見せない、とか)
但しフォルダを跨って表示する設定を行うと問答無用でNG。

今回想定する要件

ありがちな要件を想定しました。

1リスト当たりのアイテム件数がウン十万件になる
Flowなんかを使いたいのでビューの機能は要る
アイテムはユーザーが手動登録する
アイテム登録の際、フォルダ分けはしてくれない（というかしてくれたとしても1フォルダ5000件を超えない保証が無い）

っつか制限値が上がって、例えば5000が2万になったとしても問題の根っこは変わらないですよね。。。今後ずっと付きまとう問題なんでしょうか。めんどくせえ。

要件を満たすための構築例

まず大前提として、リスト内のアイテムは1フォルダ5000件を超えないようにフォルダ分けして管理します。ユーザーはフォルダを意識せず登録することを要件にしているので、フォルダ分けはシステム側で行います。

また、フォルダ分けしてしまうとユーザーはアイテムを探すためにひたすらフォルダを潜ることが必要になり、アイテムが見つからなくなります。ユーザーはフォルダを意識せずにフィルタや検索でアイテムを見つけられなければなりません。

色々考えると、以下のような設計だと拡張性が高いのではないかと。

f:id:micknabewata:20180921142043j:plain — 設計例

・ユーザーは、データ登録用画面でデータを登録する。特別な要件が無い限り、SharePoint標準のビューと登録機能で賄えるはず。
・ユーザーは、検索画面で登録済データを発見する。発見したデータを選択してアイテム表示画面に遷移し、データ編集など必要な操作を実行する。
・ユーザーが登録したデータは、自動でアーカイブ用リストに移動される。アーカイブ用リスト内は1フォルダ5000件を超えないようにフォルダ分けされている。

自動アーカイブの構築例

例１：Flowで自動フォルダ振分

アイテムが登録された時に自動で実行されるFlowを構築し、登録されたアイテムをアーカイブに移動します。アイテムの移動は、Flowの標準アクションだとうまく行かなかったので、REST API実行をお勧めします。要求するURIは以下の形になります。

_api/web/getFileByServerRelativeUrl('/sites/{サイトURL}/Lists/{リストURL}/{アイテムID}_.000')/moveto(newurl='/sites/{サイトURL}/Lists/{リストURL}/{アイテムID}_.000',flags=1)

例２：SharePoint Designerのワークフローで自動フォルダ振分

Flowの代わりにSharePoint Designerのワークフローも利用できます。標準アクションでアイテム移動ができないので、Flowと同じくREST APIを利用します。

SharePoint Designer のワークフローで REST API を呼び出す - 鍋綿ブログ

例３：情報管理ポリシーで自動フォルダ振分

例１と例２はアイテム新規登録時にすぐフォルダ振分をしていましたが、情報管理ポリシーを利用して一定期間後に振り分けることも可能です。

検索画面の構築例

例１：Webパーツを開発する(ﾟдﾟ )

アーカイブ用リストからデータを探して一覧表示するWebパーツを開発すればビューは要りません！ヤッター！
が、手間がかかりますね。標準ビューと同じだけの機能を開発するのはコストがかかりすぎるでしょうから、必要な機能だけ盛り込むことをお勧めします。
前述したとおり、たとえ開発したところでいっぺんに5000件以上は取れません。
ページングやフィルタ機能も開発対象に盛り込み、1度に1フォルダに対して問い合わせながら必要なデータを集めるという面倒な作りが必要になります。

例２：SharePointの検索機能を利用する(´ﾟдﾟ｀)

エンタープライズ検索センターなどを利用して検索機能を構築すればビューは要りません・・要件次第ですが。
が、標準機能では検索結果画面からアイテムに対する操作(編集とかFlow実行とか)ができません。表示テンプレートのカスタマイズを行って検索結果画面から実施できるアクションを追加するか、一度アイテム表示画面に遷移させてそこから実行させるかの2択です。