вторник, 8 ноября 2011 г.

Введение в рабочие процессы 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 - уже пора! :)

24 комментария:

  1. Здравствуйте. Судя по тексту вы как-то очень негативно относитесь к разработке workflows в vs. Особенно бросается но фоне всего оставльного "минусы" - обычно пишут и минусы и плюсы. Да и пишут их у всех рассматриваемых вариантов. А то получается, что SPD только плюсы, vs - одни минусы. Но это не взаимозаменяемые инструменты. Студия мощный инструмент разработки процессов и активностей. SPD - это больше планировщик и дизайнер РП, нежели средство их создания.

    ОтветитьУдалить
  2. unxc3113d, вы не согласны с перечисленными минусами Visual Studio? :) Или вы знаете какие-то не упомянутые плюсы? А может быть, вам известны какие-то страшные минусы SPD? :)

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

    ОтветитьУдалить
  3. Добрый день!
    У меня следующая проблема: есть простой workflow

    codeActivity1
    delayActivity1
    codeActivity2

    у codeActivity1, codeActivity2 имеются обработчики событий, где я поставил точки останова. у delayActivity1 свойство TimeoutDuration стоит 00:06:00.

    Так вот, если дебажить этот workflow, то событие для codeActivity1 возникает, а для codeActivity2 никогда. В чем проблема? Читал на форумах, delay вообще не рекомендуют использовать, вроде как он с багом. А есть тогда какие-то альтернативные варианты?

    ОтветитьУдалить
  4. Аргументация? А вы действительно считаете, что ваше сравнение SPD vs VS корректно? В первый пункт минусов VS вы записали минус SPD! (да-да это именно в SPD толком не изменить РП, они достаточно скудны и покрывают лишь базовые потребности, но никак не в VS - там вы ограниченны только своей фантазией и навыками). Второй пункт - достаточно плохой пример. Зачем реализовывать в VS то, что есть в SPD. Т.е. тут-то конечно не поспорить - ведь с нуля (в vs) делать то же простое согласование (которое уже есть в SPD) конечно дольше. Но вы, видимо, так и не поняли, мой первый комментарий, а именно: нельзя вот так вот просто говорить "можно делать в SPD, можно делать в vs, но в vs сложнее и дольше". Надо писать, что если вам не хватает базовых возможностей SPD, то придется разрабатывать в VS (где, разумеется, сложнее и дольше). Основной минус SPD (повторюсь) - это покрытие лишь базовых потребностей.

    ОтветитьУдалить
  5. 3-ий пункт: да и в SPD тот же "глючный" WWF. По 4 пункту: How to: Create a Sandboxed Workflow Action: http://msdn.microsoft.com/en-us/library/ff798499.aspx

    ОтветитьУдалить
  6. unxc3113d, спасибо за ответ :)

    1) Я согласен, в Visual Studio действительно возможностей больше, - к примеру, можно создавать State Machine Workflow и т.д. - но считаю, SPD уже достаточно гибок для большинства реальных задач.

    2) Даже если представить, что у нас нет OOTB рабочих процессов, просто в SPD создавать рабочие процессы быстрее.

    3) SPD обрабатывает косяки WWF, и напрямую с ними не сталкиваешься.

    4) Я имел в виду проекты и Project Items типа "Sequential Workflow" и "State Machine Workflow". Их деплоить в Sandbox не получится. А Sandboxed Workflow Action - это расширение для SPD-workflow :) Т.е. создается программное действие, которое затем нужно добавить в конкретный рабочий процесс, используя SPD. Я тремя руками "за" Sandboxed Workflow Actions, и использую их с большим удовольствием.

    В общем, как я понял, если представить, что SPD workflow позволяют решить бизнес-задачу, то вы согласны, что использовать их вместо Visual Studio workflows будет хорошей идеей. Верно? :)

    Дак вот, 90% "ограничений" SPD, о которых пишут в интернете (циклы, работа с внешними данными, вызов одного WF из другого и т.п.) на самом деле очень легко обходятся. Для большинства реальных задач SPD workflow + их расширений с помощью Custom Activity/Custom WF Action хватает за глаза.

    Поэтому, предлагаю вместо беспредметного спора, дождаться следующих статей - там будут примеры, и можно будет обсудить более предметно, какие ограничения SPD workflow вам не нравятся :)

    ОтветитьУдалить
  7. 2) Да, составить базовый РП в SPD быстрее, я не оспаривал это.
    3) Ну я бы не сказал, что уже прямо так уж и обрабатывает. Но тут каждый при своем мнении.
    4) Я понимаю, что это расширения для SPD (но они-то делаются в VS). Т.е. по вашему последнему комментарию как раз и получается, что чтобы нормально использовать SPD без VS никак не обойтись. А в статье не совсем так написано.
    5) Да, если перефразировать "...что если вам не хватает базовых возможностей SPD, то придется разрабатывать в VS...", то и получится, что если хватает, то и используйте SPD.
    6) Все эти обходы и есть работа в VS

    Мы начали спорить ни о чем. Я к чему все это: по тексту получается противопоставление SPD и VS (вывод из статьи такой получается). Но мы оба знаем, что это два разных инструмента, дополняющих друг друга.

    ОтветитьУдалить
  8. unxc3113d, ненене, я с самого начала писал про создание программных расширений. Цитата из статьи, например:

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

    Плюс в списке достоинств SPD 4й пункт и т.п.

    Понятное дело, что программные расширения пишутся в Visual Studio :) Но одно дело программные расширения для SPD Workflows, и совсем другое дело - Visual Studio Workflows. Именно "SPD WF vs VS WF" мне хотелось противопоставить.

    Сейчас перечитал статью, действительно, наверное это моя ошибка - немного неверно сформулировал :( Вечером попробую подправить текст статьи, чтобы не вводить в заблуждение будущих читателей.

    В любом случае, большое вам спасибо за feedback! Любые комментарии всегда приветствуются, мне кажется, идеальных специалистов не бывает - и я не претендую на абсолютное знание WF. И наверное это даже хорошо, когда такие статьи порождают дискуссии и обмен опытом :)

    ОтветитьУдалить
  9. Vladimir, прошу прощения, пропустил ваш комментарий :(

    К сожалению, я небольшой любитель Visual Studio Workflows, и с ошибкой с DelayActivity не сталкивался, поэтому конкретного ничего подсказать не могу.

    Могу только порекомендовать не пользоваться Visual Studio Workflows вообще :) (почему - описано в статье как раз)

    ОтветитьУдалить
  10. Vladimir, наткнулся только что на пост Bug using delay activity on SharePoint 2010 Workflow, описывается такая же проблема - неработоспособность Delay activity, и приводится решение с помощью stsadm.

    Надеюсь, поможет :)

    ОтветитьУдалить
  11. Мы разрабатываем решение по расширению фунцкионала рабочих процессов: HarePoint Workflow Extensions (http://www.harepoint.com/Products/HarePointWorkflowExtensions/)

    По этому будет очень интересно следить за статьями по рабочим процессам и их обсуждением.

    ОтветитьУдалить
  12. Доброго времени суток! Андрей, большое спасибо за статью.
    Сейчас начал изучать workflow и читаю как раз рекомендованную книгу (Workflows in Action). Вы ее вероятно читали, и возможно сможете помочь с вопросом. У меня появилось некоторое непонимание в разделе Task Processing in SharePoint Designer Workflows. Там в примере создается Custom Task Process, и в "Change the behavior of the over task process" производятся некоторые действия в момент "When the task process completes", в частности "set workflow status to Deferred". Но у меня нету такого статуса, все что доступно это только Approved, Rejected & Canceled. А автор испоьзует еще и Deferred. Как этот статус добавить, или где его найти?
    Заранее спасибо.

    ОтветитьУдалить
  13. Kai, в SharePoint Designer можно просто любой собственный Workflow Status вписать в то поле, где он выбирается. Т.е. там можно не только выбрать, но и вписать вручную. После этого новый статус появится в списке вариантов статуса.

    ОтветитьУдалить
    Ответы
    1. Все гениальное как всегда просто :). Спасибо!

      Удалить
  14. Все замечательно только Дизенджер ИМХО калеченый инструмент и вот почему: все операции с правами доступа в шагах ассоциации. И все пиши пропало. Сразу в версионности светится не нужный пользователь.

    Второе коменты в "код" процесса не вставишь только бить по шагам и называть шаги.

    Третье это работа команды "назад" в редакте процесса просто отвратительная. В визуал студии написал что то не то назад назад откати или стер что то лишнее то же самое. Тут же это просто ужас....

    ОтветитьУдалить
    Ответы
    1. Виктор, я согласен, сам редактор WF в SPD не очень удобный. Нет массовых операций, нет drag-n-drop, некоторые вещи глючат, некоторые вещи голову сломаешь пока разберешься куда нужно нажать. Но на текущий момент, я считаю, это все равно лучшее, из того что есть. Будем надеятся, в следующей версии редактор сделают более вменяемым.

      P.S. Комментарии вообще-то там есть. Это активность такая :) Не очень логично и не очень красиво - согласен, но сама возможность всё-таки существует.

      Удалить
  15. Коллега, доброго дня.
    вам случайно не встречалась следующая проблема: при завершении пользователем порожденной процессом задачи, задача переходит в состояние "В процессе выполнения", а значение состояния процесса становится "Ошибка". При этом в логах не удается как-то идентифицировать ошибку.

    ОтветитьУдалить
  16. Наконец-то дошёл до этой заключительной части изучения SP! :)
    Хороше начало (тут), даже зачитался...

    А где обещаное продолжение??

    ОтветитьУдалить
    Ответы
    1. Пост с продолжением был написан и даже переписан как минимум два раза, но всё равно он вышел какой-то неудачный, и поэтому я так его и не опубликовал :( Возможно, в ближайшее время опубликую что-нибудь про Workflow в SP2013, но пока не уверен.

      Удалить
  17. Андрей, здравствуйте! Спасибо вам за все ваши статьи! Для меня это целый курс для продвинутых =).
    Скажите, пожалуйста, правильно ли я понял, что workflow в SPD 2010 как ни крути не сможет мне присылать по понедельникам перечень элементов созданный в этот самый понедельник в одном конкретном списке Sharepoint?

    Каким путем вы посоветуете решать эту задачу?

    ОтветитьУдалить
    Ответы
    1. Добрый день!
      Вариант 1: Писать TimerJob
      Вариант 2: Написать PS-скрипт и настроить его выполнение по расписанию

      Удалить
  18. Здравствуйте! Подскажите, пожалуйста. Я представляю себе как я могу создать решение в VisualStudio со списками, обработчиками событий и рабочими процессами. И, да, я бы тоже хотел создавать простые рабочие процессы в Disigner, но у меня вопрос, как я могу воспользоваться Designer`ом для создания рабочего процесса и развернуть созданный процесс с помощью wsp файла? Или вы предлагаете создавать решение в Studio, разворачивать у заказчика, а потом подключаться Designer`ом и допиливать процесс?

    ОтветитьУдалить
  19. Андрей спасибо большое за книгу! Также вообще за пост и блог, не знал что он есть. А так давно видел ваши посты на stackexchange, они содержат много know-how :-)

    Best regards,
    Gennady

    ОтветитьУдалить

Внимание! Реклама и прочий спам будут беспощадно удаляться.

Примечание. Отправлять комментарии могут только участники этого блога.