Как стать автором
Обновить

Написание высоконагруженных корпоративных решений на SharePoint

ECM/СЭД *
Tutorial
Доброго времени суток, уважаемые хабровчане!

В этой статье хочу описать, что делать, если решили написать высоконагруженное корпоративное решение на SharePoint, и показать реализацию вышесказанного на примере решения EOS for Sharepoint 3.7.

Для тех, кто не любит много читать, кратко по ссылке:

  • данные всех списков (кроме библиотек документов) семейства сайтов в Sharepoint хранятся в одной таблице контентной базы;
  • индексы списков обслуживаются не СУБД, а встроенными механизмами Sharepoint;
  • неразумное использование индексов в списках может снизить быстродействие системы.


У подхода, принятого в Sharepoint, есть свои плюсы – для хранения неструктурированных данных схемы БД Sharepoint подходят неплохо, и, при использовании дополнительных средств Sharepoint Server создать мощный кор. портал для большой организации не представляется чем-то очень сложным.

Но если решение должно работать на SP Foundation и обрабатывать большие объемы структурированных данных (например, карточки документов и связанные с ними поручения, журналы, файлы) – так или иначе придется использовать внешние источники данных.

Наиболее подходящие и «родные» для Sharepoint варианты хранения данных во внешних базах – это использование BCS и ServiceApplications. От использования BCS разработчики ЭОС (и не только они) по многим причинам отказываются, поэтому в этой статье речь будет идти о создании базы данных в приложении-службе.

Разработку части решения, отвечающую за работу во внешней БД можно разделить на несколько больших этапов, каждый из которых я кратко опишу.

Этап 1. Создание приложения-службы.

Как пишут на MSDN «Создание собственных приложений-служб SharePoint 2010 является нетривиальной задачей» и требует хорошего понимания архитектуры Sharepoint, зато в награду – решение в стиле Sharepoint, масштабируемость и прозрачность для администратора.

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

Чтобы создать свое приложение-службу, нужно создать класс, унаследованный от SPServiceApplication. Например, в EOS4SP 3.5 этот класс выглядит так:


После этого нужно создать свой класс базы данных, унаследованный от SPDatabase, и это как раз то место, где можно определить структуру создаваемой БД (или, точнее, вставить ссылки на свои скрипты для создания базы). Для этого нужно переопределить метод Provision (пример реализации в EOS4SP на рисунке ниже) и запустить в нем встроенный SPDatabase.Provision с нужными параметрами:


Этап 2. Синхронизация данных в БД со списками Sharepoint.

Синхронизацию можно разделить на первичную и постоянную. С первичной, думаю, все понятно (можно, например добавить страницу с обработчиком в центр администрирования), а вот с постоянной – все зависит от потребностей – можно поместить в TimerJob, но оперативнее будет обновлять запись в БД одновременно с элементом списка, в EventReceiver или в переопределенных кнопках FormTemplates.

В EOS4SP 3.5, например, задействовано оба механизма:
  1. Переопределение кнопки SaveButton в форме типа контента вызывает метод SaveItem класса EServiceAccess (класс для обработки данных в базе).
  2. Для удаления элемента используется EventReceiver, вызывающий метод DeleteItem класса EServiceAccess:


Таким образом, в ходе постоянной синхронизации, данные в списках Sharepoint могут быть продублированы во внешней таблице и могут быть получены быстро или очень быстро.

Шаг 3. Получение и отображение данных из внешней БД

Когда данные загружены в базу, нужно продумать механизм их отображения. Здесь четких инструкций нет, разработчик на ASP .NET может выбрать любой удобный для себя механизм (GridView, например), но все же предпочтительнее использовать контролы в стиле Sharepoint и помещать их в связываемые веб-части. Например, веб-часть для отображения данных и веб-часть фильтра могут быть расположены на одной странице и соединяться друг с другом, именно так как сделано в EOS for SharePoint. Если сделать контрол похожим на XSLTViewWebPart, то будет совсем хорошо, но сделать это непросто, и не всегда оправданно.

Вот, собственно, и все, что нужно для успешной работы решения с внешней БД. В результате получаем:
  • прирост в быстродействии (при небольшом количестве элементов в среднем в 1.5 раза, при большом — в 2 раза);
  • масштабируемость (приложение-службу можно размещать на нескольких серверах);
  • возможность администрирования и настройки баз средствами СУБД.
Теги:
Хабы:
Всего голосов 18: ↑7 и ↓11 -4
Просмотры 6.8K
Комментарии Комментарии 37