SharePoint обладает всеми свойствами распределенной БД. Разные семейства сайтов могут находиться в разных контентных базах данных. Разные контентные БД могут находиться на разных серверах. Запросы к структурированным данным работают небыстро и самый эффективный способ – обращение по ключу. Часто используется поиск для нахождения нужных данных во всей базе.
Для того чтобы обрабатывать много данных в базах SharePoint используются задачи таймера, которые выполняют запросы к БД и обрабатывают полученные данные. Но не для всех случаев запросы можно выполнить эффективно.
Например попробуем спроектировать фичу уведомлений о наступлении некоторой даты. Например предупреждать за несколько дней заинтересованных лиц о наступлении события из календаря с возможностью выбора поля даты, для которого будет приходить уведомление.
Нам обязательно понадобится задача таймера, которая будет бегать по всем спискам всех коллекций сайтов всех баз данных в пределах одного приложения с целью найти нужные элементы для уведомлений. Такой подход отметаем сразу как не масштабируемый.
Другой подход – создавать процесс с ожиданием до заданного времени. Но процессы тяжеловесны и их использование отражается на интерфейсе пользователя. Кроме того есть ограничения на количество работающих процессов в SharePoint. Тоже плохо масштабируется
Нам нужен способ позволяющий передать данные из фронтэнда (веб-приложения) в бекэнд (службу таймера). В распределенных приложениях для этого используются очереди. Но беглый просмотр API шарепоинта говорит нам что очередей нет, а в SharePoint 2010 нельзя из контекста веб-приложения изменить свойства объектов, унаследованных от SPPersitedObject (подробнее тут), и мы не можем записать что-либо в сам объект задачи таймера или в любой дочерний.
Более детальный просмотр Server OM показал одну маленькую функцию SPSite.AddWorkItem, которая добавляет куда-то workitem, и класс SPWorkItemJobDefinition наследуясь от которого можно определить задачу таймера, разгребающую эти workitem. Вот где прятались очереди в sharepoint.
Таким образом мы можем в обработчике события на изменение элемента ставить задачу в очередь, указывая дату и время когда она должна быть обработана, а обо всем остальном позаботятся внутренние механизмы.
Удивляет отсутствие толковой документации и примеров использования этого метода. Похоже что это внутренний механизм, который частично торчит наружу, но далеко не до всех деталей, которые используют процессы и алерты (да-да, они именно такой метод используют) можно добраться. Тем не менее то что доступно вполне можно использовать для своих целей.
