Доброго времени суток, уважаемые хабровчане!
Довольно большое количество организаций, государственных и коммерческих, если не поставили у себя Sharepoint, то хотя бы слышали и представляют себе что с помощью него можно делать (спасибо маркетологам Microsoft).
В этой статье хочу кратко описать основные известные мне способы создания рабочих процессов в Sharepoint, и, в качестве дополнительной темы – то, как это можно сделать в одном из прикладных решений — EOS for Sharepoint. Тематика рабочих процессов – документооборот.
Представим себе бизнес-процесс согласования документа, заявки или другой сущности, который схематично можно изобразить так, как на рисунке 1 (последовательное согласование по линейному маршруту) и по очереди рассмотрим подходы:
1. Использование встроенного в Sharepoint бизнес-процесса утверждения (три этапа)
2. Моделирование процесса в Sharepoint Designer
3. Создание рабочего процесса в Visual Studio
4. Создание рабочего процесса в решении EOS for Sharepoint
Сознательно опущу здесь такие методы как написание Custom Activities + Sharepoint Designer, создания конструктора рабочих процессов в Visual Studio, использование логики в Infopath формах. Первый несущественно повышает логическую гибкость по сравнению с Sharepoint Designer, второй сложен в разработке, которая будет обоснована разве что при разработке собственных коробочных решений. Ну а формы InfoPath есть только в Enterprise-версии, желание покупать Enterprise есть не у всех.
Рисунок 1 — Схема линейного согласования
Очевидно, если автоматизируемый бизнес-процесс выглядит так, как на рисунке 1, то, с некоторыми оговорками, подойдет любой способ – дело только в целесообразности. Я бы использовал встроенный рабочий процесс + удобное оформление страниц и представлений списков.
Но что делать, если процесс согласования выглядит так, как на рисунке 2? Здесь процесс согласования нелинейный, и маршрут зависит от нескольких условий.
Рисунок 2 – Схема нелинейного согласования
В отделе документационного обеспечения (2-й шаг), получив проект документа, могут решить, что в процесс требуется добавить дополнительных согласующих. Кроме того, на согласование к финансовому директору проект должен направляться только при условии, что сумма договора по проекту составляет более 900 000 рублей.
По поводу возможных средств здесь ситуация выглядит иначе:
Встроенный процесс не поддерживает ветвления, а значит для решения задачи не подойдет
Если бы передо мной поставили условие смоделировать процесс в Sharepoint Designer, я бы, несколько ругаясь, написал что-то подобное тому, что изображено на рисунке 3.
Рисунок 3 – Рабочий процесс в Sharepoint Designer
Cовокупностью условных операторов, и настраиваемых форм задач, вроде отображенной на рисунке 4, процесс реализовать можно.
Рисунок 4 – Настраиваемая задача в Sharepoint Designer
Плюсы подхода:
1. При некоторой подготовке, упорстве и наличии свободного времени, с этой задачей справится и грамотный менеджер или адекватный админ.
2. Процесс можно перенастраивать.
3. Возможность ограничения прав пользователя, создающего рабочий процесс.
Минусы подхода:
1. выглядит громоздко и непрозрачно.
2. При большем количестве ветвлений придется рисовать схему рабочего процесса на листочке отдельно – по тому, как это выглядит в Sharepoint Designer, понять что-то сложно.
3. В Sharepoint Designer 2010 циклы в рабочих процессах еще не придумали, поэтому перезапускать процесс в случае отказа не получится, по крайней мере очевидными методами.
4. Большое количество дополнительных действий, которые не относятся к логике процесса.
Visual Studio позволяет создавать сколь угодно гибкие и сложные бизнес-процессы. Например, часть описанного выше процесса может выглядеть примерно так (Рисунок 5):
Рисунок 5 – Фрагмент рабочего процесса Visual Studio
Логикой можно управлять, используя циклы While, ветвления If-Else и ConditionalActivity (подробнее можно здесь http://msdn.microsoft.com/ru-ru/library/hh824675(v=office.14).aspx).
Плюсы подхода:
1. Высокая логическая гибкость
2. Возможности .NET
Минусы подхода:
1. сложность реализации, внесения изменений.
2. требуется программирование и права администратора фермы.
3. Прозрачность только во время написания процесса и при серьезном документировании.
Eos for Sharepoint – полноценная система электронного документооборота. Визуального редактора процессов здесь нет, но есть встроенный конструктор, который при ближайшем рассмотрении оказывается довольно мощным и простым в использовании. Так, процесс, описанный выше, состоит из последовательной настройки всех этапов (рисунки 6,7,8).
Рисунок 6 – Выбор участников этапа
Рисунок 7 – Условия запуска рабочего процесса
Для каждого этапа можно выбрать участников, автоматически настроить права, определить способ ведения истории рабочего процесса (рисунок 6), настроить условия запуска и запросить поля значение полей у пользователя (Рисунок 7). Для этапа, на котором требуются дополнительные согласующие, можно запустить отдельный настроенный рабочий процесс согласования.
После окончания настройки каждого этапа можно настроить параметры рабочего процесса в целом: например, перезапуск рабочего процесса в случае отказа одного из согласующих (в этом рабочий процесс начнется с первого этапа, Рисунок 8).
Рисунок 8 – Настройка параметров рабочего процесса
Используя последовательную настройку каждого этапа в EOS for Sharepoint можно смоделировать бизнес-процесс согласования любой сложности за довольно короткое время. Никаких дополнительных действий, проверок и валидаций – с созданием процесса справится любой более или менее грамотный айтишник.
Выбор способа автоматизации бизнес-процессов Sharepoint зависит, по большей части, от его сложности. Если процесс очень простой – достаточно использовать стандартные средства. Если процесс сложный и разветвленный, реализация его логики в SPD или Visual Studio может оказаться длительной и сложной, в этом случае эффективнее будет применять сторонние средства, которые позволяют сосредоточиться на логике процесса, не вдаваясь в тонкости реализации.
Довольно большое количество организаций, государственных и коммерческих, если не поставили у себя Sharepoint, то хотя бы слышали и представляют себе что с помощью него можно делать (спасибо маркетологам Microsoft).
В этой статье хочу кратко описать основные известные мне способы создания рабочих процессов в Sharepoint, и, в качестве дополнительной темы – то, как это можно сделать в одном из прикладных решений — EOS for Sharepoint. Тематика рабочих процессов – документооборот.
Представим себе бизнес-процесс согласования документа, заявки или другой сущности, который схематично можно изобразить так, как на рисунке 1 (последовательное согласование по линейному маршруту) и по очереди рассмотрим подходы:
1. Использование встроенного в Sharepoint бизнес-процесса утверждения (три этапа)
2. Моделирование процесса в Sharepoint Designer
3. Создание рабочего процесса в Visual Studio
4. Создание рабочего процесса в решении EOS for Sharepoint
Сознательно опущу здесь такие методы как написание Custom Activities + Sharepoint Designer, создания конструктора рабочих процессов в Visual Studio, использование логики в Infopath формах. Первый несущественно повышает логическую гибкость по сравнению с Sharepoint Designer, второй сложен в разработке, которая будет обоснована разве что при разработке собственных коробочных решений. Ну а формы InfoPath есть только в Enterprise-версии, желание покупать Enterprise есть не у всех.
Рисунок 1 — Схема линейного согласования
Очевидно, если автоматизируемый бизнес-процесс выглядит так, как на рисунке 1, то, с некоторыми оговорками, подойдет любой способ – дело только в целесообразности. Я бы использовал встроенный рабочий процесс + удобное оформление страниц и представлений списков.
Но что делать, если процесс согласования выглядит так, как на рисунке 2? Здесь процесс согласования нелинейный, и маршрут зависит от нескольких условий.
Рисунок 2 – Схема нелинейного согласования
В отделе документационного обеспечения (2-й шаг), получив проект документа, могут решить, что в процесс требуется добавить дополнительных согласующих. Кроме того, на согласование к финансовому директору проект должен направляться только при условии, что сумма договора по проекту составляет более 900 000 рублей.
По поводу возможных средств здесь ситуация выглядит иначе:
1. Использование встроенного в Sharepoint бизнес-процесса утверждения
Встроенный процесс не поддерживает ветвления, а значит для решения задачи не подойдет
2. Моделирование процесса в Sharepoint Designer
Если бы передо мной поставили условие смоделировать процесс в Sharepoint Designer, я бы, несколько ругаясь, написал что-то подобное тому, что изображено на рисунке 3.
Рисунок 3 – Рабочий процесс в Sharepoint Designer
Cовокупностью условных операторов, и настраиваемых форм задач, вроде отображенной на рисунке 4, процесс реализовать можно.
Рисунок 4 – Настраиваемая задача в Sharepoint Designer
Плюсы подхода:
1. При некоторой подготовке, упорстве и наличии свободного времени, с этой задачей справится и грамотный менеджер или адекватный админ.
2. Процесс можно перенастраивать.
3. Возможность ограничения прав пользователя, создающего рабочий процесс.
Минусы подхода:
1. выглядит громоздко и непрозрачно.
2. При большем количестве ветвлений придется рисовать схему рабочего процесса на листочке отдельно – по тому, как это выглядит в Sharepoint Designer, понять что-то сложно.
3. В Sharepoint Designer 2010 циклы в рабочих процессах еще не придумали, поэтому перезапускать процесс в случае отказа не получится, по крайней мере очевидными методами.
4. Большое количество дополнительных действий, которые не относятся к логике процесса.
3. Создание рабочего процесса в Visual Studio
Visual Studio позволяет создавать сколь угодно гибкие и сложные бизнес-процессы. Например, часть описанного выше процесса может выглядеть примерно так (Рисунок 5):
Рисунок 5 – Фрагмент рабочего процесса Visual Studio
Логикой можно управлять, используя циклы While, ветвления If-Else и ConditionalActivity (подробнее можно здесь http://msdn.microsoft.com/ru-ru/library/hh824675(v=office.14).aspx).
Плюсы подхода:
1. Высокая логическая гибкость
2. Возможности .NET
Минусы подхода:
1. сложность реализации, внесения изменений.
2. требуется программирование и права администратора фермы.
3. Прозрачность только во время написания процесса и при серьезном документировании.
4. EOS for Sharepoint
Eos for Sharepoint – полноценная система электронного документооборота. Визуального редактора процессов здесь нет, но есть встроенный конструктор, который при ближайшем рассмотрении оказывается довольно мощным и простым в использовании. Так, процесс, описанный выше, состоит из последовательной настройки всех этапов (рисунки 6,7,8).
Рисунок 6 – Выбор участников этапа
Рисунок 7 – Условия запуска рабочего процесса
Для каждого этапа можно выбрать участников, автоматически настроить права, определить способ ведения истории рабочего процесса (рисунок 6), настроить условия запуска и запросить поля значение полей у пользователя (Рисунок 7). Для этапа, на котором требуются дополнительные согласующие, можно запустить отдельный настроенный рабочий процесс согласования.
После окончания настройки каждого этапа можно настроить параметры рабочего процесса в целом: например, перезапуск рабочего процесса в случае отказа одного из согласующих (в этом рабочий процесс начнется с первого этапа, Рисунок 8).
Рисунок 8 – Настройка параметров рабочего процесса
Используя последовательную настройку каждого этапа в EOS for Sharepoint можно смоделировать бизнес-процесс согласования любой сложности за довольно короткое время. Никаких дополнительных действий, проверок и валидаций – с созданием процесса справится любой более или менее грамотный айтишник.
Вывод
Выбор способа автоматизации бизнес-процессов Sharepoint зависит, по большей части, от его сложности. Если процесс очень простой – достаточно использовать стандартные средства. Если процесс сложный и разветвленный, реализация его логики в SPD или Visual Studio может оказаться длительной и сложной, в этом случае эффективнее будет применять сторонние средства, которые позволяют сосредоточиться на логике процесса, не вдаваясь в тонкости реализации.
