Итоги вебинара: Рабочие процессы в SharePoint 2010

  • Article

В четверг мы провели технический вебинар (L300), в котором рассказывали о подходах к созданию рабочих процессов в SharePoint 2010 . Далее собираюсь рассказать о тех темах, которые вызвали наибольший интерес и являются наиболее важными.

Архитектура

Рабочие процессы в SharePoint 2010 основаны на .Net Workflow Foundation 3.5. Фактически SharePoint 2010 содержит (host) среду Workflow Runtime 3.5 внутри себя и предоставляется собственную закрытую реализацию сервисов этой среды (persistence, tracking и т.п.). Но у нас есть возможность взаимодействовать с инфраструктурой Workflow Runtime в SharePoint 2010 с помощью класса SPWorkflowManager, например, программно запускать рабочие процессы. SPWorkflowManager является для нас основной точкой взаимодействия и расширения.

Взаимодействие с внешними системами

imageВзаимодействие рабочих процессов SharePoint с внешними системами основано на механизме External Data Exchange (EDE). Ранее (SharePoint 2007) данный механизм был только внутренним, в SharePoint 2010 – это внешний модуль (класс SPWorkflowExternalDataExchangeService), который позволяет разработчикам создавать собственную логику взаимодействия с внешними системами (например, CRM\ERP).

Частным случаем взаимодействия может быть работа с событиями самого портала (OnTaskChanged, OnTaskCreated и т.п.), вся инфраструктура для этого уже есть по умолчанию и не требует дополнительной разработки. Разработка потребуется, если например, Вы вызываете из своего рабочего процесса сторонний веб-сервис, который возвращает ответ клиенту приходит по каналу обратного вызова, а не мгновенно. И в SharePoint 2010 данная логика может быть реализована за счет External Data Exchange.

Как мне кажется, EDE может быть очень полезен при написании системы документооборота на основе платформы SharePoint.

Оптимизация производительности

В отличие от привычных показателей производительности (например, transaction per second) для рабочих процессов (т.к. длительные и срок их жизни может измеряться неделями\месяцами) более актуальны другое:

  • длительность процесса инициализации (запуска), т.е. продолжительность синхронной стадии;
  • логика (и параметры, от которых она зависит), по которой Workflow Runtime принимает решение о сохранении состояния рабочего процессы и возобновление его выполнения.

Для нас здесь важны следующие показатели: Throttle, Batch size, Timeout, Workflow Timer Interval и AutoCleanUpDays. Именно эти показатели позволяют контролировать нагрузку, которую оказывают рабочие процессы, на ресурсы серверов фермы SharePoint, т.к. в отличие от других служб (Query\Index\Excel\BCS) для службы рабочих процессов нет возможности выделить аффилированный сервер. И обычно значения вышеуказанных параметров подбираются индивидуально для каждой промышленной среды.

Диагностика

Необходимость в диагностике возникает в случае неожиданного возникновения проблем\ошибок\сбоев в промышленной среде. В этом случае Вы можете включить детальную трассировку событий Workflow Runtime через конфигурационный файл web.config приложения (например, c:\inetpub\wwwroot\80\intranet.contoso.com\web.config). Мне это часто помогает бороться с ошибками “Error Occurred”. Не забудьте выключить трассировку, когда в ней отпадет необходимость!

image

Полезные ресурсы: