Немного о Sharepoint и DynamicsAX: Sharepoint – частный случай решения “проблемы больших списков”

Пользователи Sharepoint очень любят наполнять списки данными. Часто это приводит вот к такой картине:

Пороговое значение списка 20 тыс. установлено в Администраторской консоли, обычно оно ещё меньше – всего 5 тыс. элементов.

После того как значение элементов списка превысило допустимый порог, в списке отключаются возможности фильтрации по полям, становится очень сложно им пользоваться, найти что-либо в таком списке можно только встроенным в SharePoint поиском.

В целом такое ограничение вполне оправдано. Список – это не таблица в БД, из него не выбрать данные select’ом, и необходимо осознанно подходить к наполнению списка данными, настройке представлений на списке. При бесконтрольном добавлении данных список становится неуправляемым, пользователям становится сложно искать в нём необходимые данные.

Однако бывают ситуации, когда большой список просто необходим. Ниже я опишу, что можно сделать для комфортной работы с таким списком.

Первое: необходимо отключить для отдельно взятого списка ограничение по порогу. Для всех остальных списков это ограничение продолжит работать, и администратору не придётся волноваться, что вышедшие из-под контроля пользователя за неделю заполнят всё имеющееся дисковое пространство на SQL-сервере Sharepoint.
Отключить ограничение можно установкой свойства isThrottled в “false”. Для этого нужно под учёткой Администратора фермы зайти на сервер, запустить командную консоль SharePoint и выполнить:
$list.EnableThrottling = $false
$list.Update()

После этого для списка будут доступны все возможности фильтрации, как если бы превышения порога не было. Впрочем, предупреждение о превышении порога в меню “Параметры списка” останется.

Второе: нужно настроить представления для комфортной работы пользователей. Если нам известно, что в основном определённые группы пользователей работают с определёнными группами записей, нужно создать для них фильтрованные представления. Например, если в нашем списке есть поле
“Регион”, можно создать представления под названием “Все записи – Магадан”, “Все записи – Колыма” и т.д., отфильтрованные по полю “Регион”.

Переключение между представлениями для начинающего пользователя Sharepoint не так очевидно, поэтому хорошо бы вывести ссылки на эти представления на отдельную страницу, или на меню быстрого запуска, или отдельной веб-частью в представление “по умолчанию”. Ни рисунке показан пример того, как ссылки на представления перечислены в веб-части “Редактор контента”

Третье и самое главное: штатный поиск Sharepoint не умеет искать элементы по части слова или маске. Так, например, если у нас есть элементы с названиями “первый”, “второй”, “третий”, то поиск “перв” или “перв*” ничего не даст. Однако, как показывает практика, это самый необходимый тип поиска с точки зрения пользователя, “затерявшегося” в большом списке. Такой поиск по одному полю достаточно просто реализуется с использованием пары веб-частей и Sharepoint Designer.

Создадим представление. Например, на основе существующего “Все записи – Магадан”. Назовём его “Магадан – фильтр записей”, и разместим в верхней части страницы веб-часть под названием “Фильтр текста”

Далее выделяем веб-часть с данными списка и добавляем параметр для веб-части с произвольным именем: