Многие разработчики уже привыкли к проектированию с использованием SharePoint 2013. Но функции платформы SharePoint чрезвычайно разнообразны, поэтому неудивительно, что многие пока используют далеко не все фантастические возможности новейшей версии. Одно из таких замечательных новшеств — рабочие процессы SharePoint.

Рабочий процесс подвергся значительным изменениям между выходом версий SharePoint 2007 и 2010, но в версии 2013 произошел полный пересмотр рабочего процесса, и моя задача в данной статье — рассказать об этих революционных изменениях.

Обратная совместимость

Прежде всего, надо развеять сомнения, которые могут возникнуть у многих читателей: что будет с прежними рабочими процессами? Нужно ли перепроектировать свои решения для новой платформы? На этот вопрос ответить просто. В SharePoint 2010 рабочий процесс основывался на Windows Workflow Foundation 3.5, и многих пользователей обрадует, что версия SharePoint 2013 обратно совместима с решениями, построенными в традиционном стиле. Как известно, нередко переход на новую платформу связан с глобальной переработкой существующих решений (такое часто происходило с пользовательскими решениями).

Переходим к Workflow 2013

Убедившись, что наш труд не пропал даром, мы можем приступать к проектированию новых рабочих процессов в SharePoint 2013.

Рабочий процесс не стал исключением на фоне преобладающей тенденции переноса возможностей платформы Azure в другие компоненты. Новый обработчик рабочего процесса, известный как Workflow Manager, основан на Windows Azure Workflow (WAW). Во-первых, следует отметить, что новый обработчик основан на Workflow Foundation 4.5. Это заметно расширяет функциональность и изначально рассчитано на создание рабочих процессов корпоративного класса. Во-вторых, Workflow Manager выполняется отдельно от SharePoint, так что рабочие процессы также можно размещать извне. Это может быть собственно Azure или локальный экземпляр Workflow Manage, как в случае со многими службами Microsoft Azure. Возможность размещать рабочие процессы извне приносит разработчикам SharePoint ряд важных преимуществ:

  • Нагрузка рабочего процесса больше не возлагается непосредственно на SharePoint. У SharePoint есть много задач по управлению другими нагрузками, поэтому хорошо, что с него снята задача исполнения рабочих процессов. При локальном использовании Workflow Manager устанавливается отдельно от SharePoint и может размещаться на одном сервере с SharePoint или в собственной среде.
  • Рабочие процессы, построенные на Windows Azure Workflow, изначально межплатформенные, то есть можно строить рабочие процессы, интегрированные со многими системами. Рассмотрим пример рабочего процесса для отслеживания квитанций и обработки заказов на всем протяжении их жизненного цикла. Конечно, можно построить мощную систему, которая позволит использовать SharePoint для обработки заказа на всех этапах его исполнения, но благодаря WAW можно создать клиентское приложение. NET, взаимодействующее с рабочим процессом, например чтобы техники на объекте могли изменять статус заказа. Кроме того, мы можем разместить все свои рабочие процессы, независимо от их платформы, в одном месте.
  • Возможность создавать и размещать рабочие процессы вовне означает, что сценарии перехода на будущие версии SharePoint упрощаются по сравнению со специализированными решениями, построенными на основе самого SharePoint.

Размещение рабочих процессов

Неудивительно, что такое изменение в базовой платформе рабочих процессов заметно влияет на процесс при создании и разработке решений для него. Теперь рабочие процессы полностью декларативные, то есть их определение и пути исполнения описаны в наборе XAML-файлов. Одно из основных следствий нового декларативного подхода в том, что традиционный кодовый подход к проектированию рабочих процессов остался в прошлом. Не беспокойтесь, это не означает, что нельзя создать пользовательскую логику при проектировании рабочих процессов, но теперь вы инкапсулируете логику в веб-службах и взаимодействуете с ними с помощью операций (activities). Операции представляют собой объекты, которые обрабатывают обращения к API-интерфейсам, управляющим выполнением и поведением рабочих процессов, в том числе вызовами веб-служб (подробнее об операциях будет рассказано ниже).

В SharePoint Designer 2013 кардинально переработан инструментарий для реализации нового декларативного подхода, в соответствии с которым рабочий процесс, по словам представителей Microsoft, становится предпочтительной средой для разработки рабочих процессов SharePoint. Среди изменений в средствах проектирования рабочих процессов в SharePoint Designer — появление циклов (Loops), которых до сих пор не хватало в рабочих процессах. Эти циклы очень похожи на хорошо знакомые нам циклы, позволяющие повторять процесс определенное число раз или пока не будет выполнено заданное условие.

SharePoint Designer, несомненно, хороший инструмент для проектирования рабочих процессов, но я наблюдаю нежелание многих разработчиков SharePoint, предпочитающих среду Visual Studio, работать с этим инструментом. К счастью, компания Microsoft реализовала эти функции разработки и в Visual Studio в форме шаблонов проекта Workflow, а именно Sequential Workflow (последовательный рабочий процесс) и State Machine Workflow (рабочий процесс конечного автомата), что позволяет создавать рабочие процессы с использованием конструктора и окна свойств в среде разработки.

Действия и операции

Как уже отмечалось, операции — это объекты, которые обрабатывают вызовы к API-интерфейсам, определяющим поведение рабочих процессов, тогда как действия представляют собой объекты, инкапсулирующие эти операции и позволяющие включать их в рабочие процессы. Действия можно сделать частью рабочего процесса с помощью упомянутого выше конструкторского инструментария.

Компания приложила большие усилия, чтобы предугадать типы действий, которые потребуются для построения рабочих бизнес-процессов для пользователей как SharePoint Designer, так и Visual Studio. Список доступных действий в Workflow 2013 должен соответствовать самым строгим требованиям. Среди многочисленных новых действий есть обеспечивающие возможность запуска рабочего процесса списка или сайта, взаимодействие с Microsoft Project и возможность вызывать веб-службу HTTP. Действий слишком много, чтобы подробно описать в этой статье, но полезный справочный материал опубликован по адресу msdn.microsoft.com/en-us/library/office/jj163867(v=office.15).aspx. В нем вы найдете список доступных действий и классов операций.

Что делать, если этого недостаточно, и вам требуется нечто совершенно особое? В Workflow 2013 появилась поддержка настраиваемых действий. Требования бизнеса часто оказываются весьма специфическими, и настраиваемые действия можно создать с использованием шаблона Visual Studio. Однажды созданные настраиваемые действия можно упаковать и разместить в SharePoint, после чего они становятся доступными другим участникам рабочего процесса в таких инструментах, как SharePoint Designer, как будто были частью готовой библиотеки доступных действий. Хороший обзор настраиваемых действий можно найти на сайте MSDN по адресу msdn.microsoft.com/en-us/library/office/jj163911(v=office.15).aspx.

Таким образом, в SharePoint 2013 произошли важные изменения рабочего процесса, и хотя некоторые из них свидетельствуют о смене парадигмы проектирования (в частности, декларативная основа XAML), у нового подхода есть множество преимуществ. Благодаря тому обстоятельству, что рабочий процесс в сущности отделен от SharePoint и обеспечивает кроссплатформенную разработку, перед нами открывается новый захватывающий мир рабочих процессов.