Введение в рабочие процессы SharePoint 2010

На мой взгляд, Workflow - это как раз та самая "магическая" субстанция, которая позволяет превратить безжизненную свалку данных в живую, рабочую систему - систему, которая рассылает письма, следит за сроками выполнения задач, и главное - всегда знает ответ на вопрос: "что с этим документом делать дальше?".

Я считаю, что без понимания концепции рабочих процессов и их возможностей, - ваше знание SharePoint'а нельзя считать полным! И на мой взгляд, их действительно стоит изучать: они классные, и могут вам сэкономить немало дней, если их использовать с умом и по-назначению.

Впрочем, как это всегда бывает в SharePoint, существует множество тонкостей, нюансов и особенностей, которые нужно знать и иметь в виду, прежде чем говорить клиенту/начальнику о том, что вот мол на решение этой задачи уйдет полдня :)

Итак, давайте рассмотрим вкратце, что представляют собой рабочие процессы в SharePoint. Эта статья является стартовой в новой серии статей про рабочие процессы.


Практическое применение

Рабочие процессы (Workflow) в SharePoint 2010 - это очень мощный и гибкий инструмент для организации совместной работы над документами и данными. Если говорить упрощенно, Workflows представляют собой алгоритм, т.е. набор правил и шагов, определяющих, какие действия будут предприняты над документом или элементом списка, после его добавления или обновления (плюс, можно запускать Workflow вручную или программно).

С точки зрения программистов, рабочие процессы могут поначалу очень напоминать Event Receiver. Поэтому важно понимать - на самом деле они гораздо сложнее, чем Event Receiver, устроены совершенно иначе, и подразумевают, прежде всего:

1. Возможность длительного исполнения
2. Возможность дополнительного взаимодействия с пользователями

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

Наконец, практический пример использования рабочих процессов: в компании Softline, где я работаю, у нас есть огромный внутрикорпоративный портал на SharePoint, где на основе Workflow работают, как минимум: заявки, системы единого окна и система разрешения внутренних проблем HelpDesk. Не раз пользовался - весьма удобно. А ведь этот портал создан администраторами, т.е. с минимумом программирования или вообще без него! И я видел специализированные системы - поверьте, некоторые и похуже с такими задачами справляются...

Когда стоит, и когда не стоит использовать рабочие процессы?

Ответ на самом деле очень прост, и частично содержится в самом вопросе: если речь идет о бизнес-требованиях и моделировании бизнес-процессов - нужно использовать Workflow. Для более низкоуровневого функционала, с бизнесом непосредственно не связанного - лучше подойдут Event Receivers и Timer Jobs.

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

Три типа рабочих процессов SharePoint 2010

Рабочие процессы в SharePoint 2010 значительно обновились по сравнению с 2007 версией, и на текущий момент могут быть трех типов: Site Workflow, Reusable Workflow и List Workflow. Как нетрудно догадаться, эти типы отличаются друг от друга объектами, в контексте которых работает рабочий процесс.

Первый тип - Site Workflows - пригождается довольно редко, и рассматривать его в сегодняшнем посте я не буду. List Workflows мы тоже рассматривать не будем, это устаревший тип, пришедший из 2007го SharePoint'а. Вкратце, рабочие процессы этого вида присоединяются обязательно к уже созданному экземпляру списка. Таким образом, применение этих рабочих процессов очень ограничено, они не могут быть перенесены или использованы повторно и т.д.

Итак, остаются только Reusable Workflows. При их создании вы должны выбрать тип содержимого, к которому прицеплять этот рабочий процесс. От этого выбора зависит, какие поля можно будет использовать при построении процесса в дизайнере (т.е. какими вообще данными можно будет в основном оперировать).

Поскольку типы содержимого могут наследоваться друг от друга, можно выбрать базовый тип содержимого "All" - в этом случае ваш рабочий процесс можно будет использовать вообще в любом списке, но тогда он сможет оперировать только самыми простейшими колонками - Title, Created, Created By, Modified, Modified By...

Впрочем, здесь есть важное уточнение: существуют так называемые Association Columns - это колонки, которые будут автоматически созданы в списке при присоединенни к нему Reusable-рабочего процесса. Но тут, опять же, важно понимать: эти колонки будут созданы в любом случае, даже если аналогичные колонки с теми же именами уже в этом списке существуют.

Три инструмента для создания рабочих процессов

Для создания рабочих процессов, на текущий можно использовать аж целых три различных программных продукта, на любой вкус:

1. Microsoft Visio
2. SharePoint Designer
3. Visual Studio

При этом Microsoft Visio позволяет только нарисовать красивый "набросок" рабочего процесса, который потом нужно обязательно изменять в SharePoint Designer. Впрочем, для бизнес-пользователей такой вариант очень хорош: они могут нарисовать процесс не вдаваясь в детали, а дорабатывать его будет уже администратор, программист или IT-специалист.

Плюс к тому, с помощью Visio, рабочие процессы могут быть визуализированы через веб-интерфейс. Это очень классная "фишка", которая позволяет отобразить диаграмму процесса на сайте SharePoint, причем уже выполненные шаги будут помечены галочками. На мой взгляд, это может служить прекрасным добавлением к каким-нибудь отчетам/dashboard'ам. Функция работает только в SharePoint Server 2010, при наличии запущенных Visio Services, и включенной галочке в свойствах рабочего процесса в SPD:

В общем, Visio скорее нужно рассматривать как некое приятное дополнение к SharePoint Designer, чем как самостоятельный инструмент для создания SharePoint Workflow.

Так что давайте рассмотрим следующий инструмент - собственно SharePoint Designer. Его можно использовать и без Visio, он вполне самодостаточен. Вообще, на мой взгляд, SPD как средство для создания рабочих процессов - это лучший вариант, потому что:

1. Визуальный редактор в SPD - очень приятный и интуитивно-понятный. К слову, намного лучше, чем был в SPD 2007.
2. SPD-workflow - это единственный тип workflow, который работает в Sandbox и Office365
3. Reusable workflows можно переносить между фермами и сайтами
4. Можно разрабатывать программные расширения (собственные Actions) для SPD-редактора. Эти расширения развертываются на сайт, и потом SharePoint Designer при подгрузке списка Workflow с сайта заодно подгружает и расширения, сразу же соответствующим образом обновляя свой интерфейс. Эта фишка работает в том числе и для Sandboxed Solutions.

Внешний вид дизайнера рабочих процессов SPD 2010

Наконец, последний вариант, Visual Studio Workflows. Минусы:

1. Функционально больших отличий от SPD нет. Конечно, у SPD-workflows есть ряд ограничений, но на практике, все они обходятся через использование программных расширений, дополнительных колонок, или дополнительных workflow.
2. Если попробовать реализовать один и тот же функционал средствами Visual Studio и средствами SPD - в Visual Studio это делается значительно дольше и сложнее.
3. SharePoint Workflows в Visual Studio реализованы на основе Windows Workflow Foundation, которая сама по себе весьма глючная - а SharePoint туда еще добавляет немало "нюансов" :)
4. Visual Studio Workflows даже теоретически не работают в Sandbox. В свете выхода Office365, мне кажется это очень актуально.

Конечно, Visual Studio гораздо более гибкий и всё такое, но такая низкоуровневая гибкость на практике пригождается редко, а вот разработку и поддержку значительно усложняет.

Поэтому я стараюсь использовать SPD Workflows и писать для них Sandboxed Workflow Actions.

Заключение

Надеюсь, этот краткий обзор помог обратить ваше внимание на рабочие процессы SharePoint 2010 и обозначил некоторые общие направления для дальнейшего изучения. Конечно, полностью описать систему в рамках статьи невозможно: рабочие процессы - это действительно мощная система, и понадобилась бы целая книга, чтобы подробно её описать. Кстати, такая книга уже есть, её написал Phil Wicklund, рекомендую: SharePoint 2010 Workflows In Action (на английском языке).

В следующих постах серии мы рассмотрим создание Sandboxed Workflow Actions, примеры "боевых" рабочих процессов, способы обхода встроенных ограничений рабочих процессов SPD, и многое другое. Так что, если еще не подписались на RSS - уже пора! :)