Текущая версия на 11:36, 26 декабря 2020

RunaWFE. Практикум. Введение.

Версия 4.6.0

Введение

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

Теории процессного подхода (как реинжиниринга бизнес-процессов, так и постепенного эволюционного изменения бизнес-процессов) являются достаточно зрелыми, им посвящено большое число работ как российских, так и иностранных авторов (например, - [1] - [5]). Однако до недавнего времени выполнение бизнес-процессов в организациях производилось косвенным образом - через изменение должностных инструкций, организационной структуры предприятия, прямые указания руководителей.

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

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

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

Для автоматизации процессного управления предприятием разработан специальный класс компьютерных систем – системы управления бизнес-процессами и административными регламентами (далее СУБПиАР). Основная задача таких систем - раздавать задания исполнителям и контролировать их выполнение. Последовательность заданий определяется схемой бизнес-процесса, которую можно разработать и в дальнейшем быстро модифицировать при помощи среды разработки. Эта схема похожа на блок-схему алгоритма. По схеме перемещаются точки управления. В узлах схемы генерируются задания исполнителям.

Внедрение СУБПиАР на предприятии приводит к появлению единого для всех менеджеров предприятия или сотрудников ведомства языка описания бизнес-процессов, основанного на графических диаграммах. После освоения этого языка сотрудниками организации они могут быстро читать существующие бизнес-процессы, разбираться в состояниях выполняющихся бизнес-процессов и административных регламентов, а также производить быструю сборку из разнородных элементов (труда сотрудников и работы компьютерных систем предприятия) новых качественных бизнес-процессов.

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

В последние годы происходит активное внедрение СУБПиАР как в бизнесе, так и в государственных организациях. Поэтому возникла задача обучения студентов как экономических специальностей, так и специальностей, связанных с информационными технологиями, процессному подходу и работе с СУБПиАР.

В лабораторном практикуме дано описание основных элементов систем управления бизнес-процессами. Описание дано на примере свободной системы с открытым кодом – RunaWFE. RunaWFE свободно распространяется вместе со своими исходными кодами на условиях открытой лицензии LGPL. Система бесплатная, ее можно свободно установить на любое количество компьютеров без каких-либо ограничений. Скачать дистрибутивы и исходный код ее можно через интернет с портала разработчиков свободного программного обеспечения sourceforge.net по адресу: http://sourceforge.net/projects/runawfe.

Адрес сайта проекта RunaWFE - https://runawfe.ru/rus.

Исполнимые бизнес-процессы и административные регламенты

В данном методическом пособии мы будем рассматривать термины бизнес-процесс и административный регламент как синонимы. Традиционно термин бизнес-процесс используется в случае промышленного предприятия, а административный регламент – государственной организации.

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

Дадим определение исполнимого бизнес-процесса, основу которого составляют идеи С. Яблонского и С. Бусcлера [6].

Исполнимый бизнес-процесс определяется при помощи задания следующих перспектив (точек зрения или слоев/уровней рассмотрения):

перспектива потока управления (control-flow perspective)
перспектива данных (data perspective)
перспектива ресурсов (resource perspective)
перспектива операций (operational perspective)

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

Рассмотрим более подробно уровни определения исполнимого бизнес-процесса.

Перспектива потока управления

Перспектива потока управления соответствует схеме бизнес-процесса. Изначально схема определялась как математическое понятие — направленный граф: множество узлов, соединенных между собой дугами (возможными переходами). Узлы бизнес-процесса могли быть двух типов — узлы, соответствующие шагам процесса, и маршрутные узлы. По переходам перемещается точка управления (указатель на активный узел процесса), руководствуясь правилами в маршрутных узлах.

В узле, соответствующем шагу процесса, находится узел-действие (Activity). Если точка управления пришла в узел-действие, то СУБПиАР дает задание исполнителю (сотруднику или информационной системе) и ждет ответа (сообщения, что работа выполнена). После ответа исполнителя точка управления движется по переходу к следующему узлу процесса. К узлу, соответствующему узлу-действию, может примыкать только один входящий и один исходящий переход.

Маршрутный узел соответствует появлению, удалению, разветвлению-слиянию точек управления или выбору перехода, по которому точка управления будет перемещена дальше. В таких узлах СУБПиАР выбирает на основании содержащихся в маршрутных узлах правил следующий узел (узлы), в который будет передано управление. Часто с этими узлами связано более одного входящего или исходящего перехода.

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

Позже в различных спецификациях данное определение было расширено:

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

2. Были добавлены дополнительные конструкции, элементы которых не являются элементами графа (далее – дополнительные конструкции), однако к этим элементам могут быть присоединены переходы и маршрутные узлы или же переходы могут пересекать эти элементы. Например, были введены события и области с прерыванием, объемлющие шаги бизнес-процесса. При нахождении точки управления внутри области с прерыванием может произойти событие (клиент может передумать делать заказ, в процессе выполнения договора могут возникнуть форс-мажорные обстоятельства и т.п.). В этом случае точка управления может из любого находящегося внутри области узла сразу переместиться в присоединенный к области маршрутный узел и уже из него продолжить движение по присоединенному к нему переходу.

3. Были добавлены узлы, соответствующие шагу процесса, но не являющиеся узлами-действиями. Например, узлы-ожидания, в которых не дается заданий исполнителям процесса, СУБПиАР просто ожидает в этих узлах наступления определенного события, после которого точка управления идет дальше. Или узлы-подпроцессы. Для этих узлов не определен конкретный исполнитель, в этих узлах СУБПиАР запускает другой бизнес-процесс в качестве подпроцесса текущего процесса и передает ему соответствующие данные.

С учетом дополнений перспективу потока управления можно определить следующим образом:

Перспектива потока управления представляет собой схему бизнес-процесса. Схема бизнес-процесса состоит из направленного графа и, возможно, дополнительных конструкций. Узлы бизнес-процесса могут быть трех типов — узлы, соответствующие шагам процесса, маршрутные узлы и комбинированные узлы, представляющие собой слияние шага процесса с одним или несколькими маршрутными узлами.

Шаги процессов являются узлами-действиями или дополнительными узлами. По переходам перемещаются точки управления. В момент прихода точки управления в узел-действие СУБПиАР дает задание исполнителю. После выполнения задания исполнителем точка управления движется по переходу к следующему узлу процесса. К узлу, соответствующему узлу-действию, может примыкать только один входящий и один исходящий переход.

Маршрутный узел соответствует появлению, удалению, разделению, слиянию точек управления или выбору перехода. В этих узлах СУБПиАР выбирает на основании содержащихся в маршрутных узлах правил следующий узел (узлы), в который будет передано управление.

Принципиальное отличие шага процесса от маршрутного узла состоит в том, что в маршрутном узле надо только принять решение о дальнейшем пути (путях) движения точки управления на основании уже существующих данных, поэтому точка управления не должна находиться в маршрутном узле долго. На шаге процесса точка управления может находиться длительное время. Исключение из этого правила составляют узлы-слияния, в которых пришедшие точки управления «ждут» прихода точек управления по остальным входящим переходам, после чего все пришедшие точки управления уничтожаются и генерируются точки управления по исходящим переходам. Однако, если считать, что пришедшая в узел-слияние точка управления удаляется сразу, при этом в узле хранится информация, что по этому переходу точка управления уже приходила, то данное исключение исчезает.

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

Узел «начало» соответствует точке начала исполнения бизнес-процесса. У него нет входящих ребер и есть только одно исходящее ребро. В момент запуска экземпляра бизнес-процесса в узел помещается точка управления, которая тут же выходит из него по исходящему ребру. В бизнес-процессе должен существовать единственный узел «начало». Обозначается «тонкой» окружностью (Рис. 2.1 а)

Рисунок 2.1 Обозначения узлов: а – начало; б – завершение потока; в – окончание; г – действие

Узел «завершение потока» должен иметь одно или более входящих ребер и ни одного исходящего. При попадании какой-либо точки управления в этот узел она удаляется. Экземпляр бизнес-процесса, в котором не осталось ни одной точки управления, считается завершившимся. Может существовать несколько узлов «завершение потока», но обязательно должен быть хотя бы один такой узел. Обозначается «жирной» окружностью (Рис. 2.1, б).

Узел «окончание» соответствует точке окончания исполнения бизнес-процесса. Узел «Окончание» должен иметь один или более входящих Переходов и ни одного исходящего Перехода. При попадании управления в Окончание останавливаются все потоки этого процесса, а также все его синхронные подпроцессы. В бизнес-процессе может существовать несколько узлов «Окончание». Однако этот узел не обязателен в бизнес-процессе, если в бизнес-процессе существует хотя бы одна точка завершения потока. Обозначается черной окружностью внутри окружности (Рис. 2.1, в).

Узел «действие» генерирует задание исполнителю, обозначается прямоугольником со скругленными углами, в центре которого пишется имя узла (Рис. 2.1, г) и имеет одно входящее и одно исходящее ребро.

Узел «исключающий шлюз» может иметь несколько входящих и несколько исходящих ребер. Для каждой пришедшей в него точки управления выбирается, по какому из исходящих ребер она будет перемещена далее. Обозначается ромбом, в котором изображен «крестик» (Рис. 2.2, а).

Рисунок 2.2 Обозначения узлов: а – исключающий шлюз; б – параллельный шлюз

Узел «параллельный шлюз» обозначается ромбом, в котором изображен «плюс» (Рис. 2.2, б). Может иметь несколько входящих и несколько исходящих ребер. Для каждого входящего ребра пришедшая по нему в параллельный шлюз точка управления ставится в очередь. Если для всех входящих ребер их очереди заполнены хотя бы одной точкой управления, то все точки управления, находящиеся на первой позиции очереди каждого входящего ребра, удаляются, а на каждом исходящем ребре генерируется точка управления.

Перспектива данных

Перспектива данных соответствует набору внутренних переменных бизнес-процесса. Переменные бизнес-процесса могут являться входящими и исходящими параметрами при взаимодействии СУБПиАР с информационными системами предприятия. При помощи переменных происходит обмен информацией между шагами процесса и, как следствие, между внешними информационными системами, т. е. бизнес-процесс может переносить информацию в корпоративной информационной среде между разнородными информационными системами. Переменные бизнес-процесса также используются при выборе конкретного внутреннего перемещения точки управления между узлами по какому-либо из возможных переходов.

Перспектива ресурсов

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

В бизнес-процессе производится связывание узлов-действий с исполнителями заданий при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам-действиям. Во время выполнения бизнес-процесса ролям назначаются конкретные исполнители. Здесь можно провести аналогию с театральным спектаклем: в процессе написании сценария определяются используемые в спектакле роли. Потом, при постановке в конкретном театре, на роли назначаются актеры – исполнители ролей. Например, роль может называться «Эдмон Дантес», а исполнителем быть – заслуженный артист Петров. В узле-действии бизнес-процесса может быть сразу несколько возможных исполнителей роли.

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

Перспектива операций

Перспективе операций бизнес-процесса соответствует список элементарных действий, совершаемых исполнителями в рамках узла-действия.

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

Системы управления бизнес-процессами и административными регламентами (на примере свободного ПО RunaWFE)

Принято считать, что современная система управления бизнес-процессами и административными регламентами (далее СУБПиАР) должна обеспечивать разработку бизнес-процесса в графической среде, исполнение бизнес-процесса, мониторинг состояния бизнес-процесса, ведение истории событий бизнес-процесса, интеграцию приложений при помощи используемых бизнес-процессами коннекторов, администрирование пользователей, а также возможность замещения исполнителей заданий.

Для выполнения этих функций в СУБПиАР служат следующие графические интерфейсы:

интерфейсы для работы с заданиями исполнителей
интерфейсы для работы с загруженными в СУБПиАР определениями бизнес-процессов
интерфейсы для работы с выполняющимися в СУБПиАР экземплярами процессов
интерфейсы для администрирования пользователей и групп пользователей
интерфейсы для настройки замещений исполнителей заданий

Для разработки бизнес-процессов обычно применяются графические дизайнеры бизнес-процессов, которые являются отдельными приложениями.

В системе RunaWFE для интеграции приложений реализованы специальные сущности – боты и бот-станции.

В данной части методического пособия на примере системы RunaWFE продемонстрирована вся перечисленная функциональность и пользовательские интерфейсы.

Основные компоненты системы

RunaWFE состоит из следующих основных компонентов:

RunaWFE–сервер
Внешняя бот-станция (необязательный компонент)
Среда разработки
Web-интерфейс системы
Клиент-оповещатель о поступивших заданиях (необязательный компонент)

RunaWFE–сервер – это основной компонент системы. RunaWFE–сервер реализует среду исполнения экземпляра процесса в соответствии с его определением. Этот компонент содержит определения загруженных в него бизнес-процессов и выполняющиеся экземпляры бизнес-процессов. Позволяет создавать и изменять свойства пользователей. Генерирует списки заданий и визуальные формы, соответствующие заданиям. Позволяет устанавливать различные права на объекты системы.

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

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

Web-интерфейс системы предоставляет возможность доступа пользователей к функциональности RunaWFE–сервера. Web-интерфейс - это графический интерфейс пользователя, который отображается в окне браузера. Web-интерфейс системы RunaWFE: Отображает списки заданий и визуальные формы заданий. Позволяет пользователям выполнять задания. Позволяет администратору системы устанавливать права на объекты системы. Дает возможность осуществлять мониторинг исполнения экземпляров бизнес процессов, а также выполняет большое количество других функций.

Клиент-оповещатель о поступивших заданиях представляет собой среду доступа пользователей к функциональности RunaWFE–сервера. Он запускается на компьютере пользователя как самостоятельное приложение, при этом содержит внутри себя Web-интерфейс системы RunaWFE, а также реализует оповещение пользователя о поступивших задачах.

Замечание. Если оповещение о поступивших задачах не требуется или достаточно оповещения по электронной почте, то для получения остальной описанной выше функциональности можно клиент-оповещатель не устанавливать. Эта функциональность доступна при помощи Web-интерфейса системы через обычный браузер.

Краткое описание функциональности компонентов системы

Web-интерфейс системы

При помощи web-интерфейса системы пользователь может:

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

При помощи web-интерфейса системы администратор может:

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

Среда разработки

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

Симулятор бизнес-процессов

Симулятор бизнес-процессов является адаптированной для клиентского компьютера версией RunaWFE – сервера. При помощи симулятора бизнес-процессов можно тестировать разработанные бизнес-процессы на условной конфигурации на клиентском компьютере аналитика, не загружая их в промышленную систему.

Где скачать исходные файлы системы RunaWFE

RunaWFE распространяется в следующих вариантах:

В виде специализированных дистрибутивов для конкретных операционных систем
В виде исполнимых файлов java-машины.
В исходных кодах.

Проще всего установить RunaWFE при помощи специализированного дистрибутива для конкретной операционной системы. Например, в случае операционной системы Windows скачайте файл-дистрибутив «RunaWFE-*-Wildfly-java8_64u.exe» для 64-разрядной версии Windows или «RunaWFE-*-Wildfly-java8_32u.exe» для 32-разрядной. Запуск на выполнение этого файла запустит на компьютере с ОС Windows диалог установки системы RunaWFE. Если вам удобнее устанавливать систему с CD-диска, то из той же папки надо скачать файл «installer-wildfly-java8_64.iso» для 64-разрядной версии Windows или «installer-wildfly-java8_32.iso» для 32-разрядной и скопировать его на CD-диск. При вставке этого диска в CD-дисковод компьютера запустится диалог установки системы RunaWFE для ОС Windows.

Вариант распространения в виде исполняемых файлов java-машины используется, если в проекте RunaWFE нет специализированного дистрибутива для ОС, которую вы используете на своем компьютере. В этом случае надо обратиться к документации проекта RunaWFE (например, на сайте runawfe.ru/rus) и установить на компьютер непосредственно исполняемые файлы java. Вариант распространения в виде исходных кодов предназначен для разработчиков программного обеспечения. Используя исходные коды, они могут модифицировать систему или встраивать ее в какое-то другое программное обеспечение.

Установка системы RunaWFE при помощи специализированного дистрибутива для операционной системы Windows

Перечислим компоненты дистрибутива системы, которые можно установить при помощи дистрибутива.

Компоненты дистрибутива, относящиеся к клиентской части системы:

Клиент (web-интерфейс)
Среда разработки
Симулятор бизнес-процессов
Клиент-оповещатель о поступивших заданиях

Компоненты дистрибутива, относящиеся к серверной части системы:

RunaWFE – сервер
Бот-станция

В данном лабораторном практикуме рекомендуется установить на компьютер только клиентские компоненты. Клиентский компонент «симулятор» является адаптированной для компьютера пользователя версией RunaWFE сервера, этот компонент содержит в себе локальную бот-станцию. Поэтому клиентских компонентов достаточно для того, чтобы познакомиться со всей функциональностью RunaWFE.

Замечание. В следующем разделе описан порядок установки системы в случае ОС Windows, но для системного администратора, устанавливающего систему в компьютерном классе, есть более подробная инструкция Универсальная инструкция по установке дистрибутивов RunaWFE в ОС Windows (Файл:Admin instruction ver2.doc)

Порядок установки системы в случае ОС Windows

Вставьте диск в дисковод (в случае дистрибутива на CD-диске) или запустите на выполнение файл RunaWFE-Installer.exe (в случае дистрибутива в виде исполняемого файла). Появится экран мастера установки системы:

Рисунок 3.1 Экран мастера установки системы

Нажмите «Установить». В следующем мастере установки появится текст свободной лицензии LGPL (Лицензия LGPL разрешает свободное использование, изменение кода и распространение программного продукта. На использование кода программы под LGPL лицензией разработчиками программного обеспечения в других коммерческих проприетарных программах налагаются некоторые ограничения), под которой распространяется система RunaWFE. В настоящее время не существует официального перевода лицензии LGPL на русский язык, поэтому текст лицензии представлен в оригинале - на английском языке.

Рисунок 3.2 Лицензионное соглашение

После утвердительного ответа на вопрос о принятии условий лицензии появится выбор – установить на компьютер клиентские или серверные компоненты RunaWFE

Рисунок 3.3 Выбор вариантов установочного пакета системы

Выберите клиентские приложения и нажмите «Далее»

Появится страница выбора конкретных клиентских компонентов.

Рисунок 3.4 Выбор компонентов системы

Отметьте все компоненты кроме компонента «Интернет ссылка» и нажмите «Далее».

Рисунок 3.5 Выбор папки для установки

Выберите папку для установки RunaWFE и нажмите «Далее».

В появившемся окне мастера установите самую верхнюю галочку:

Рисунок 3.6 Дополнительные параметры мастера установки

Нажмите «Далее».

Рисунок 3.7 Мастер настройки точек доступа

В следующем окне мастера оставьте настройки, появившиеся по умолчанию, и нажмите «Далее». – Начнется процесс копирования файлов системы. После того, как система будет установлена, появится следующее окно мастера:

Рисунок 3.8 Завершение установки

Нажмите «Готово». Процесс установки будет завершен.

Замечание. В случае отсутствия в системе java 8, инсталлятор предложит установить, кроме того будет предложено установить переменную среды JAVA_HOME.

Начало работы с системой RunaWFE

Работать с системой можно через системное меню ( Пуск / Программы / RunaWFE)

Рисунок 3.9 Запуск программы

или через расположенные на рабочем столе иконки.

Для начала работы с системой RunaWFE:

1. Запустите RunaWFE симулятор. Это можно сделать, например, командой меню Пуск / Программы / RunaWFE / Start Simulation.

При запуске симулятора появится консольное окно:

Рисунок 3.10 Запуск сервера JBoss

Строка WFLYSRV0010: Deployed "runawfe.ear" (runtime-name : "runawfe.ear") означает, что симулятор запущен.

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

2. Запустите web-интерфейс системы RunaWFE. Для этого надо выполнить команду Пуск / Программы / RunaWFE / Simulation Web Interface. Появится окно ввода логина и пароля пользователя.

Рисунок 3.11 Окно ввода учётной записи

В этом окне введите логин администратора «Administrator» (существенно, что с большой буквы) и пароль администратора – «wf».

Главное меню системы RunaWFE

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

Рисунок 3.12 Функциональное меню Simulation web interface

Дадим краткое описание пунктов меню системы RunaWFE. Меню «Список заданий». При выполнении команды меню «Список заданий» открывается форма списка заданий для данного пользователя. Здесь пользователь может, кликнув на задание, открыть форму задания, ввести в нее данные, а также отметить выполнение задания. Также в списке заданий пользователь может искать, фильтровать задания, выводить в строках задания значения переменных бизнес-процессов.

Меню «Запустить процесс». На странице, соответствующей пункту меню «Запустить процесс» находится список определений бизнес-процессов. Здесь пользователь может запустить бизнес-процесс, посмотреть схему и другие свойства бизнес-процесса, посмотреть описание бизнес-процесса. Если у пользователя есть соответствующие права, он может загрузить новый бизнес-процесс в систему или загрузить новую версию уже существующего процесса.

Меню «Запущенные процессы». На странице, соответствующей пункту меню «Запущенные процессы», находится список экземпляров бизнес-процессов, доступных для чтения данному пользователю. Здесь пользователь может посмотреть состояния выполняющихся экземпляров бизнес-процессов, в частности – положение текущих точек управления на схеме бизнес-процесса, текущие значения переменных и ролей экземпляра бизнес-процесса, а также историю событий экземпляра бизнес-процесса. Если у пользователя есть соответствующие права, он может остановить выполнение экземпляра бизнес-процесса. Также в списке экземпляров бизнес-процессов пользователь может искать, группировать, фильтровать экземпляры бизнес-процессов, выводить в строках значения переменных бизнес-процессов.

Меню «Исполнители». На странице, соответствующей пункту меню «Исполнители», находится список потенциальных исполнителей заданий (пользователей и групп пользователей), доступных для чтения данному пользователю. На этой странице можно завести или удалить исполнителя, завести или удалить группу исполнителей, включить (исключить) исполнителя или группу исполнителей в другую группу. Для исполнителя можно установить статус (Активен / Не активен) настроить список замещений. Также здесь задается список полномочий исполнителей на действия с системой, которые настраивает администратор.

Меню «Отношения». Отношения используются в системе RunaWFE при инициализации ролей бизнес-процесса. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Инициализация роли – это назначение на роль конкретного исполнителя. Отношения соответствуют одному из используемых в системе RunaWFE способов инициализации ролей.

Меню «Бот станции». Боты в системе RunaWFE – это специальные компьютерные приложения, которые также как и люди могут быть исполнителями заданий. Бот-станция – это компьютерная среда, в которой функционируют боты. Находящиеся в бот-станции боты периодически опрашивают RunaWFE - сервер. Если выполняющиеся на сервере экземпляры бизнес-процессов содержат задачи для исполнителей - ботов, то боты выполняют эти задачи и возвращают результаты работы на RunaWFE - сервер. На странице, соответствующей пункту меню «Бот станции», находится список зарегистрированных бот-станций. Здесь пользователь может посмотреть свойства бот-станций состояния бот-станций, свойства входящих в бот-станцию ботов, а также задач, которые они могут выполнять. Также в меню «Бот станции» можно завести новую бот-станцию, изменить параметры бот-станции, запустить/остановить периодическую активацию бот-станции, а также изменять свойства входящих в бот-станцию ботов. В частности можно добавить новое задание боту, или изменить/удалить уже существующее задание.

Меню «Источники данных». В качестве источника может выступать база данных или Excel таблица. Источники данных могут быть использованы в обработчиках: "Внешнее хранилище данных" и "Выполнить запросы SQL". На этой странице можно загрузить новый источник, изменить пароль, или проверить возможность подключения к источнику.

Меню «Ошибки». Здесь отображаются ошибки, возникшие в процессах при выполнении.

Меню «Критерии замещения». Здесь можно создать критерии замещения исполнителей задача.

Меню «Системные данные». Необходимо для загрузки или выгрузки файла с данными.

Меню «Логи сервера». Данное меню ведет на страницу отображающую лог работы системы. Здесь реализован удобный просмотрщик, с такими функциями как разделение на страницы, поиск, автоматическое обновление информации и т.д.

Стандарты и концепции, связанные с СУБПиАР

Графические нотации BPMN и UML Activity Diagram.

На схеме бизнес-процесса узлы процесса можно изображать по-разному. Способ изображения узлов и переходов важен, потому что от этого зависит легкость (или сложность) понимания бизнес-процесса людьми

Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов.

Наиболее известными графическими нотациями изображения бизнес-процессов являются:

UML Activity Diagram (далее UML AD)
BPMN

В работе Stephen A. White Process Modeling Notations and Workflow Patterns, посвященной сравнению выразительной мощи UML AD и BPMN нотаций, основанной на реализациях с помощью этих нотаций типичных конструкций бизнес-процессов содержится вывод, что выразительная мощь основных конструкций обеих нотаций примерно одинакова. Позже этот результат был подтвержден в более полном исследовании: Lauri Eloranta, Eero Kallio, Ilkka Terho A Notation Evaluation of BPMN and UML Activity Diagrams.

Рассмотрим базовые элементы обеих нотаций, относящиеся к перспективе потока управления.

Базовые элементы нотации UML AD, относящиеся к перспективе потока управления:

Узел-Действие:

Рисунок 4.1 Узел-Действие

Маршрутные узлы.

Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рисунок 4.2 Ветвление

Разделение - Разделение точки управления на несколько точек управления:

Рисунок 4.3 Разделение

Слияние - Слияние точек управления в одну точку управления:

Рисунок 4.4 Слияние

Базовые элементы нотации BPMN, относящиеся к перспективе потока управления:

Узел-Действие:

Рисунок 4.5 Узел-действие

Маршрутные узлы.

В BPMN существует единая форма для маршрутного узла, представляющая собой ромбик:

Рисунок 4.6 Маршрутный узел

Конкретные маршрутные узлы отличаются изображенными внутри этой формы иконками.

Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рисунок 4.7 Ветвление

Внутри ромбика содержится иконка – «крестик».

Разделение - Разделение точки управления на несколько точек управления:

Рисунок 4.8 Разделение

Внутри ромбика содержится иконка – «плюсик».

Слияние - Слияние точек управления в одну точку управления:

Рисунок 4.9 Слияние

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

Сравнение графических нотаций

В BPMN нотации – более универсальные элементы. Элементы BPMN нотации определяются парой графических объектов – формой элемента и изображенной внутри нее иконкой. Например, форма для всех маршрутных узлов BPMN одинакова, а поведение определяется иконкой: «крестик» соответствует выбору одного из нескольких направлений, а «плюсик» - разделению точки управления на несколько одновременно перемещающихся точек. Это позволяет использовать различные комбинации форм и иконок вместо того, чтобы вводить новые графические элементы и таким образом можно уменьшить общее число используемых в нотации объектов.

Однако UML AD нотация проще для изучения неподготовленным пользователем, она интуитивно понятна. UML AD нотация использует хотя и не универсальные, но широко известные графические элементы. Например, в ней для выбора одного из нескольких направлений используется «ромбик». А параллельно выполняющиеся узлы-действия в UML AD нотации как правило соединены с элементами – разделениями-слияниями параллельными линиями, что интуитивно соответствует одновременно выполняющимся действиям.

В UML AD нотации изображение процессов очень похоже на блок-схемы, которые изучаются в российских технических ВУЗах и техникумах. В начальной школе при изучении математики в некоторых учебниках также активно используются те же блок-схемы (Петерсон Л. Г. Математика. Учебники для 1-4 класса. Ювента. 2009). То есть многим российским пользователям изображения в UML AD нотации сразу будут интуитивно понятны, а для понимания изображений в BPMN нотации придется потратить время и усилия на ее изучение.

У BPMN-нотации есть свои сильные стороны, например, очень велика маркетинговая мощь международных софтверных компаний, продвигающих эту нотацию. Есть элементы, пользоваться которыми в BPMN нотации удобнее, чем в UML нотации.

Пример процесса «заявка на платеж» в UML-нотации:

Рисунок 4.10 Пример процесса «заявка на платеж» в UML-нотации

Пример процесса «заявка на платеж» в BPMN-нотации:

Рисунок 4.11 Пример процесса «заявка на платеж» в BPMN-нотации

Для того чтобы объяснять схемы несложных бизнес-процессов, нарисованные в UML AD нотации не требуется много усилий. В случае же BPMN нотации требуются учебные курсы и различные консультации.

Кратко преимущества нотаций можно сформулировать так:

Преимущества UML нотации относительно BPMN для российских пользователей.

UML нотация проще. Ее легче изучать.
Значительному числу пользователей графы процессов, нарисованные в UML нотации (с движением точек управления бизнес-процесса преимущественно сверху-вниз) более понятны, чем процессы, нарисованные в BPMN нотации.

Преимущества BPMN нотации.

Более понятные изображения некоторых элементов (например – таймеров)
Более удобно работать с бизнес-исключениями

Использование бинарных отношений для упрощения инициализации ролей

Роли и их инициализация

Исполнителями заданий бизнес-процесса могут быть как сотрудники предприятия, так и информационные системы. Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Инициализация роли – это назначение на роль конкретного исполнителя. Для построения простого механизма инициализации ролей удобно использовать концепцию бинарных отношений (см. А. Н. Колмогоров, С. В. Фомин, Элементы теории функций и функционального анализа. 4 изд. М. Наука, 1976).

Понятие «бинарное отношение»

Бинарное отношение можно рассматривать как расширение понятия функция.

Определение. Бинарным отношением между множествами A и B называется любое подмножество P декартова произведения множества A на множество B. Часто, чтобы обозначить принадлежность упорядоченной пары (a,b) к бинарному отношению P вместо записи (a,b) P используют обозначения P(a,b) или aPb. При этом говорят, что a находится в отношении P к b.

Замечание1. Для множеств A и B, состоящих из конечного числа элементов, любое отношение можно задать, определив набор упорядоченных пар (a,b)для этого отношения.

Замечание2. Некоторые (но не все) бинарные отношения соответствуют функциям. То есть некоторые бинарные отношения являются функциями. Можно определить функцию как такое бинарное отношение R, в котором каждому значению b отношения aPb соответствует лишь одно единственное значение a (но не наоборот). В этом случае a=f(b), где f - функция, соответствующая бинарному отношению R.

Применение понятия «бинарное отношение» к инициализации ролей

Кроме традиционных способов инициализации ролей удобно иметь возможность инициализации ролей при помощи бинарных отношений.

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

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

Отношение над исполнителями заданий можно построить при помощи задания набора пар (Исполнитель1, Исполнитель2). При этом не требуется проверять каких-либо ограничений (как, например, для функции – что она возвращает только одно значение для одного исполнителя).

Использование групп пользователей при задании отношений

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

Группы пользователей служат для объединения пользователей по какому-либо признаку. Обычно группа «наследует» свойства всех групп, в которые она входит.

Зададим отношение как множество пар (Исполнитель1, Исполнитель2), в которых Исполнитель является пользователем или группой пользователей.

Инициализация роли при помощи отношения производится следующим образом:

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

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

Реализация бинарных отношений в системе RunaWFE.

Концепция отношений реализована в интерфейсе RunaWFE следующим образом

1. В главном меню системы содержится пункт меню - Отношения (в английской локализации - Relations).

Рисунок 4.12 Вкладка «Отношения» в Simulation web interface

В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.

2. Для каждого исполнителя в его свойствах добавлены два раздела:

Отношения, в которых он может находиться в левой части
Отношения, в которых он может находиться в правой части

Рисунок 4.13 Вкладка исполнители в Simulation web interface

Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения.

Рисунок 4.14 Редактирование отношений в Simulation web interface

Доступ к созданию новых и изменению существующих отношений имеет только пользователь, обладающий соответствующим полномочием.

Рисунок 4.15 Редактирование прав на отношение в Simulation web interface

Работа с отношениями в среде разработки

В среде разработки при редактировании инициализатора роли можно выбрать закладку «задать роль с помощью отношения». В этом случае можно задать настройки соединения с сервером и импортировать отношения в среду.

Рисунок 4.16 Среда разработки. Импорт процессов

Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения, а в качестве параметра может быть задана переменная формата "Пользователь", "Исполнитель", "Группа", или "Роль-дорожка".

Рисунок 4.17 Редактор инициализатора роли

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

Концепция ботов и бот-станций.

Исполнителями заданий в современных СУБПиАР могут быть как люди, так и компьютерные приложения.

Во многих СУБПиАР узлы, в которых задание выполняет компьютерное приложение, отмечаются на схеме процесса специальным образом (отличным от узлов, в которых задание выполняет человек), а роль в таких узлах всегда задается одинаково, например - "система".

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

Логика управленцев при этом следующая: Управленец традиционно мыслит в понятиях должностей специалистов и их компетенций. Он говорит: в компании есть должность "уборщица", я знаю, что сотрудник на этой должности умеет выполнять ограниченный набор действий (например "подметать" и "убирать") и исходя из этих возможностей я планирую участие уборщицы в соответствующих бизнес-процессах. Для компьютерных приложений мне тоже было бы удобно видеть "что они умеют делать" при планировании их использования в бизнес-процессах. Для самих приложений тоже удобна была бы логическая группировка по видам деятельности (например, - работа с электронной почтой, работа с отчетами и т.п.)

Поэтому было введено понятие бота для СУБПиАР. Для заданий, выполняемых компьютерными системами была сделана их логическая группировка по ботам, чтобы при работе с бизнес-процессами управленец мог мыслить в терминах автоматических исполнителей и их областях компетенции.

Кроме того, для ботов было введено понятие прав на выполняемые действия (аналогичные правам людей-пользователей). Поэтому боты, также как люди, во время своей работы аутентифицируются в СУБПиАР, после чего СУБПиАР проводит их авторизацию при совершении операций.

Для работы ботов была разработана специальная среда - бот-станция, которая организует их взаимодействие с СУБПиАР. Как правило, бот-станция соответствует серверу, на котором размещены боты. Находящиеся в бот-станции боты обращаются к СУБПиАР. Если выполняющиеся на сервере экземпляры бизнес-процессов содержат задачи для ботов, то боты выполняют эти задачи и возвращают результаты работы на сервер.

Реализация концепции

Настройка всех бот-станций и ботов производится через меню «Бот станции».

Рисунок 4.18 Меню редактора Бот-станции

Пользователь имеет доступ к меню «Бот станции», если у него есть права на чтение бот-станций. Если прав на чтение бот-станций у пользователя нет, то пункт меню «Бот станции» интерфейсе пользователя будет отсутствовать. Для изменения настроек бот-станций необходимо иметь права «Конфигурировать бот-станцию». Для изменения полномочий необходимо иметь права "Изменять полномочия".

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

Рисунок 4.19 Работа с Бот-станциями

Параметрами бота являются: имя бота (соответствует логину пользователя), пароль бота, опция включения последовательного выполнения заданий в одном потоке в рамках бота, список заданий, выполняемых ботом. Список заданий состоит из имени задания, ссылки на обработчик, конфигурации задания и режима выполнения. Опция “Последовательное выполнение” позволяет установить особый режим, при котором данная задача будет выполняться последовательно в одном потоке в рамках данной задачи.

Рисунок 4.20 Параметры бота

Кроме того, разработку бот станции, ботов и их задач можно вести и в среде разработки.

Рисунок 4.21 Бот станция в среде разработки

Замещение исполнителей заданий

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

Часто в СУБПиАР решают эту проблему при помощи импорта организационной структуры предприятия в СУБПиАР и задания в ней функций замещения, основанных на положении сотрудников в административной системе управления предприятием. В некоторых системах эта проблема решается при помощи вставки программного кода, реализующего перенаправление заданий, непосредственно в бизнес-процессы.

Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в СУБПиАР нежелательно, т. к. она также используется в других системах предприятия (ERP, CRM и т.п.). В случае использования программного кода бизнес-процесс становится неудобным для модификации, т.к. для изменения замещения как правило требуется привлекать программиста.

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

Поэтому в системе RunaWFE правила замещения "привязаны" к исполнителям задач, а не к бизнес-процессам. Для каждого замещаемого сотрудника правила замещения просматриваются в некотором порядке до тех пор, пока либо не будет найдено подходящее правило замещения, либо будет выяснено, что ни одного подходящего правила нет.

Описание правила назначения заместителя.

Правило содержит функцию над организационной структурой предприятия, которая возвращает заместителя.

Список параметров правила:

Замещаемый Пользователь (Пользователь)
Заместитель (Функция над орг-структурой, возвращающая Пользователя)
Применимо ли правило (формула)

Пример правила назначения заместителя:

Иванов
Петров
(Роль = «инспектор_Кадровой_Службы») & (Бизнес-процесс= «больничный»)

Реализация в системе RunaWFE

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

Заместитель (Функция над организационной структурой предприятия, возвращающая пользователя-заместителя)
Условие применения правила (Критерий)

Выбираемый критерий замещения либо соответствует бизнес-процессу и роли-дорожке (варианты критериев создаются отдельно, на странице “Система”), в которых будет происходить замещение, либо является критерием «замещать всегда»

Правила замещения могут быть двух видов:

“Правило” – определяет кем надо замещать Исполнителя в определенном случае
“Терминатор” – определяет, что в определенном случае Исполнителя замещать не надо

Рисунок 4.22 Корректировка правил замещения сотрудников

У пользователя может быть одно из двух состояний:

Активен
Не активен

Механизм замещения применяется только к пользователям, имеющим статус «не активен».

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

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

В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.

Замечание. Возможны ситуации, в которых у Пользователя не будет заместителя.

Замечание. Чтобы пользователь мог выполнить задачу по замещению необходимо, чтобы у него были права на чтение пользователя, которого он замещает.

Вводное занятие. Изучение интерфейса системы RunaWFE.

Цель занятия

Целью занятия является ознакомление с Web-интерфейсом системы RunaWFE и средой разработки.

Порядок выполнения работы

Запустите RunaWFE симулятор, для этого дважды кликните по ярлыку «Start Simulation» на рабочем столе, или выполните команду меню Пуск / Программы / RunaWFE / Start Simulation. Появится консольное окно (рис 5.1).

Рисунок 5.1 Окно RunaWFE симулятора

Строка … Deployed "runawfe.ear" означают, что симулятор запущен.

После того, как RunaWFE симулятор запустится, кликните на ярлыке «Simulation Web Interface» (Или выполните команду Пуск / Программы / RunaWFE / Simulation Web Interface). Откроется окно браузера (рис 5.2).

Рисунок 5.2 Форма аутентификации пользователя

В поле «Пользователь» введите Administrator, а в поле «Пароль» - wf и нажмите кнопку «Войти». Появится web-интерфейс системы RunaWFE (рис 5.3).

Замечание.

Рис 5.3 Web-интерфейс системы RunaWFE

Перейдите к списку исполнителей кликнув по ссылке «Исполнители» в левой части экрана. Откроется список исполнителей (рис 5.4)

Рис 5.4 Список исполнителей

Создайте группу пользователей «Сотрудники». Для этого кликните «Создать группу», Откроется интерфейс создания группы (рис 5.5).

Рис 5.5 Интерфейс создания группы пользователей

Введите в поле «Имя» слово «Сотрудники», также добавьте описание этой группы, после чего нажмите кнопку «Применить»
Далее откройте пункт «Исполнители», и перейдите к настройкам полномочий, кликнув по ссылке «Обладатели полномочий» над списком пользователей (рис 5.6).

Рис 5.6 Форма распределения полномочий

Добавьте созданную Вами группу в этот список. Для этого кликните по ссылке «Добавить». Откроется список (рис 5.7), в котором найдите группу «Сотрудники». Установите напротив этой группы галочку и нажмите «Добавить».

Рис 5.7 Форма добавления пользователей в список для установления полномочий

Теперь необходимо выдать группе полномочие на вход. Для этого поставьте галочку в столбце: «Вход в систему», как показано на рисунке 5.8, после чего нажмите кнопку «Применить».

Рис 5.8 Выдача полномочий на вход в систему группе «Сотрудники»

Далее создайте учетные записи пользователей «Сверчков» и «Паучков». Для создания учетной записи «Сверчков» откройте интерфейс «Исполнители» и кликните по надписи «Создать пользователя». Откроется форма для ввода данных пользователя. В поле «Имя» введите «Сверчков», в поле «Полное имя» введите «Сверчков Иван Иванович», остальные поля заполнять необязательно (рис 5.9).

Рис 5.9 Форма создания учетной записи пользователя

По окончании заполнения полей формы нажмите кнопку «Применить». Для правки учетной записи откройте меню «Исполнители». Найдите исполнителя «Сверчков» и кликните по нему. Откроется интерфейс редактирования учетной записи (рис 5.10).

Рис 5.10 Расширенная форма правки учетной записи пользователя

В разделе «Свойства исполнителя» содержится базовое описание пользователя.

В графе «Статус» устанавливается статус пользователя («Активен» или «Не активен»). Его изменяют в случае, если сотрудник должен быть на рабочем месте, либо не может на нем появиться в силу каких-либо обстоятельств.

В графе «Пароль» введите пароль для пользователя «Сверчков» (например - 123), знать старый пароль пользователя при этом не требуется. Затем нажмите «Применить». В разделе «Группы пользователя» кликните надпись «Добавить» и в открывшемся списке поставьте галочку напротив группы «Сотрудники», после чего нажмите кнопку «Добавить».

Кликните на ссылку «Обладатели полномочий» в верхней части формы (рис 5.11).

Рис 5.11 Ссылка «Обладатели полномочий»

Добавьте в список обладателей полномочий группу «Сотрудники» с правами только на чтение (рис 5.12).

Рис 5.12 Установка прав на чтение группе «Сотрудники» на пользователя «Сверчков»

Настройка учетной записи пользователя «Сверчков» завершена.

Аналогичным образом создайте и настройте учетную запись «Паучков» (Паучков Петр Петрович).
Запустите компонент системы RunaWFE - "Среда разработки". Для этого кликните на ярлык "Process Designer" на рабочем столе, или выполните команду меню Пуск / Программы / RunaWFE / Process designer. Появится окно среды разработки (Рис 5.13).

Рис 5.13 Среда разработки

Создайте новый проект - "Вводное занятие" (Рис 5.14).

Рис 5.14 Создание нового проекта

Создайте простейший бизнес-процесс (Рис 5.15).

Рис 5.15 Создание нового бизнес-процесса

Введите название процесса – Процесс1, в качестве языка выберите BPMN (Рис 5.16)

Рис 5.16 Форма создания нового процесса

Поместите на схему бизнес-процесса узел - начало бизнес-процесса, узел-действие и узел-окончание. Кликните на элемент «Выбрать» в палитре. Будет установлен режим выбора. В этом режиме каждый узел надо поместить на схему при помощи клика на элемент, расположенный в палитре и последующего клика на место в схеме, в которое требуется поместить новый элемент (Рис 5.17).

Рис 5.17 Создание схемы бизнес-процесса

Для удобства расположения объектов можно использовать «сетку» (устанавливается в меню вид - показать сетку).

Поместите на схему бизнес-процесса линии-переходы, соединяющие начало, узел - действие и окончание. Для этого надо кликнуть на элемент «Переход» в палитре. Будет установлен режим рисования переходов. В этом режиме создания каждого перехода надо сначала кликнуть в центр узла, в котором должен начаться переход, потом кликнуть в центр узла, в который должен закончиться переход (Рис 5.18).

Рис 5.18 Создание переходов

Замечание. Если требуется "изогнуть" линии-переходы, то надо в режиме «Выбрать» выделить кликом переход, найти в середине прямолинейного участка точку (на рисунке 5.19 эти точки выделены овалами) и далее "тащить" ее мышкой в нужном направлении. Линия будет "изгибаться".

Рис 5.19 Изменение формы перехода

Создайте роль (которая будет в дальнейшем связана с узлом-началом и узлом «Действие 1»). Для этого кликните на вкладку роли, в появившемся окне выполните команду «создать», далее в появившейся форме введите «Роль1». Нажмите «OK» (рис 5.20).

Рис 5.20. Создание роли без инициализатора

Свяжите роль «Роль1» с узлом-началом и с узлом «Действие 1». Для этого кликните правой кнопкой мыши на каждый узел и выберите «Роли/Роль1» (Рис 5.21).

Рис 5.21 Связывание узла с ролью исполнителя задания

Простейший бизнес-процесс готов. Экспортируйте его в файл-архив командой "Файл/Экспорт процесса" (См. Рис 5.22) и поместите в папку «рабочий стол».

Рис 5.22 Экспорт бизнес-процесса в файл-архив

Войдите в web-интерфейс системы RunaWFE под пользователем Administrator.

Загрузите разработанный бизнес-процесс на RunaWFE сервер:

Кликните на пункт меню "Запустить процесс", затем кликните на ссылку "Загрузить определение процесса" (Рис 5.23).

Рис 5.23 Команда "Загрузить определение процесса"

В появившейся форме кликните на "Загрузить файл" и выберите файл "Процесс1.par", который был сохранен на рабочий стол. В поле "создайте свой тип" введите "Занятие1" (рис 5.24).

Рис 5.24 Окно команды "Загрузить определение процесса"

Кликните на "Загрузить определение процесса". Разработанный бизнес-процесс "Процесс1" будет загружен на RunaWFE сервер (рис. 5.25).

Рис 5.25 Бизнес-процесс загружен на RunaWFE сервер

Дайте пользователю "Паучков" права на чтение, запуск и чтение экземпляра, а группе "Сотрудники" только права на чтение на разработанный бизнес-процесс:

Кликните на поле "Свойства" в строке бизнес-процесса. В появившемся окне кликните на ссылку "Обладатели полномочий" (рис. 5.26).

Рис 5.26 Форма свойств бизнес-процесса

Кликните на ссылку "Добавить", в появившемся окне обладателей полномочий на определение разработанного бизнес-процесса (рис. 5.27).

Рис 5.27 Окно обладателей полномочий на определение бизнес-процесса

В появившейся форме поставьте в списке исполнителей галочки рядом с пользователем "Паучков" и группой "Сотрудники" и кликните на кнопке "Добавить" (рис. 5.28).

Рис 5.28 Окно добавления полномочий на определение бизнес-процесса

Расставьте галочки в появившемся окне обладателей полномочий в соответствии с рисунком рис 5.29

Рис 5.29 Окно обладателей полномочий на определение бизнес-процесса

Кликните на кнопке "Применить".

Войдите на RunaWFE сервер под разными пользователями и исполните бизнес-процесс:

Кликните на ссылке выход в правой верхней части экрана (рис 5.30).

Рис 5.30 Ссылка "Выход"

Войдите в систему как пользователь "Сверчков" (рис 5.31).

Рис 5.31 Вход в систему

Кликните на пункт меню "Запустить процесс" (рис 5.32).

Рис 5.32 Окно для работы с определениями процессов и запуска экземпляров процессов

Проверьте, что в появившейся форме содержится разработанный бизнес-процесс "Процесс1", который нельзя запустить (его иконка и ссылка в поле "Имя" неактивны), но можно посмотреть его свойства, кликнув по ссылке в поле "Свойства". Так происходит потому, что мы установили права на процесс "Процесс1" для группы "Сотрудники", в которую входит пользователь "Сверчков" только на чтение. Для самого пользователя "Сверчков" или для каких-то других содержащих его групп права на "Процесс1" не установлены.
Кликните на ссылке выход. Войдите в систему под пользователем "Паучков" (рис 5.33).

Рис 5.33 Вход в систему

Проверьте, что у пользователя "Паучков" есть права на запуск бизнес-процеса "Процесс1". (иконка процесса и ссылка в поле "Имя" активны).
Кликните на иконке бизнес-процесса. - В верхней части экрана появится надпись "Экземпляр процесса запущен, рядом с которой будет находиться номер запущенного бизнес-процесса (рис 5.34).

Рис 5.34 Запуск бизнес-процесса на исполнение

Кликните на пункт меню "Запущенные процессы". Найдите в появившемся окне строку, соответствующую запущенному экземпляру бизнес-процесса - в ней число в поле номер должно совпадать с тем, которое было отображено в сообщении о запуске экземпляра процесса (рис. 5.35).

Рис 5.35 Незавершенный экземпляр бизнес-процесса (нет даты завершения)

Кликните в этой строке на номер бизнес-процесса. - Откроется форма экземпляра бизнес-процесса. В этой форме будет показано, что в процессе есть единственная точка управления, которая находится в узле "Действие 1", задание этого узла назначено пользователю "Паучков". Пользователь Паучков является исполнителем роли "Роль1". Также в форме находится схема экземпляра бизнес-процесса с отмеченными на ней маршрутами точек управления. Переходы и узлы, по которым прошли точки управления выделены зеленым, узлы-Действия, в которых находятся текущие точки управления, выделены жирной рамкой (рис 5.36).

Рис 5.36 Форма экземпляра бизнес-процесса

Кликните на строку меню "Список заданий". В появившейся форме найдите задание "Действие 1" (рис. 5.37)

Рис 5.37 Список заданий

Кликните на задание "Действие 1" в поле "Имя". Появится форма, содержащая сообщение "Форма задания не определена" (что означает - "для узла Действие 1 не была определена графическая форма") (рис 5.38).

Рис 5.38 Форма задания (в случае отсутствия формы, подготовленной в среде разработки)

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

Рис 5.39 Завершенный экземпляр бизнес-процесса (есть дата завершения)

Требования к содержанию и оформлению отчета

В результате выполнения лабораторной работы должны быть представлены преподавателю отчет, файл с данными archive.datafile (как получить файл данных), содержащие разработанные на занятии бизнес-процессы и DOCX файл созданного журнала.

В отчете должны содержаться следующие выходные данные:

1) Скриншоты основных действий, совершенных на занятии, с пояснениями

2) Описание возникших при выполнении задания проблем и найденных путей их решения (не обязательно, только если возникли проблемы при выполнении задания)

Контрольные вопросы

Из каких компонентов состоит система RunaWFE?
Что такое Web-интерфейс? Обладает ли компонент "Среда разработки" системы RunaWFE Web-интерфейсом?
Какие права нужны пользователю, чтобы он
А) Мог запускать экземпляры данного бизнес-процесса

Б) Мог выполнять задания данного бизнес-процесса

Список литературы

Абдикеев Н.М., Данько Т.П., Ильдеменов С.В., Киселев А.Д. Реинжиниринг бизнес-процессов. М.: Эксмо, 2005
Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. – М.: Финансы и статистика, 2006
Тельнов Ю.Ф. Реинжиниринг бизнес-процессов: Компонентная методология. – М.: Финансы и статистика, 2004
Кловпулос Т. Необходимость Workflow. – М. Весть-МетаТехнология 2000
Хаммер M., Чампи Д. Реинжиниринг корпорации: манифест революции в бизнесе. – СПб.: Изд-во СПбУ, 1997
S. Jablonski and C. Bussler. Workfow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, London, UK, 1996
Михеев А. Г. Системы управления бизнес-процессами и административными регламентами на примере свободной программы RunaWFE – М.: ALT Linux, 2011
Куликов Г. Г., Михеев А. Г., Орлов М. В., Габбасов Р. К., Антонов Д. В. Изучение методологии BPMN на примере программного продукта RunaWFE. Лабораторный практикум по дисциплине «Автоматизированные информационные системы в производстве» и «Автоматизированные информационные системы в экономике». - Уфа. УГАТУ. 2010
Куликов Г. Г., Михеев А. Г. Особенности реализации процессного подхода и обучения управлению бизнес-процессами при помощи свободного ПО с открытым кодом. / Открытое образование, № 4 2011 с. 47 – 57
Документация Runa WFE [официальный сайт проекта]. URL: https://runawfe.ru/rus/doc/Документация

TrainingMaterials 4 4 Introduction: различия между версиями