Роли и задания. Замещение исполнителей. Эскалация заданий

# Роли и задания

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

Роль (или роль-дорожка) – специальный тип переменной бизнес-процесса.

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

Роль инициализируется значением в случае:

  • выполнения стартовой задачи (при условии настройки Доинициализация роли = да)
  • прихода точки управления в задачу с этой ролью (при условии что значение роли не определено либо настройка Переинициализация роли = да
  • при первом использовании в БП, например в обработчике (при использовании настройки ServerConfigurationGuide#process.swimlane.auto.initialization.enabled)
  • при назначении ей значения как переменной

Значением роли может быть:

  • 1 пользователь
  • 1 группа
  • 1 временная группа, состоящая из нескольких пользователей (которые определились инициализатором)
  • 1 группа делегирования
  • 1 группа эскалации

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

Роль можно использовать как переменную:

  • присваивать ей значение другой роли или переменной типа Исполнитель, Пользователь или Группа
  • присваивать ей значение переменной типа Список(Исполнитель), Список(Пользователь), Список(Группа)
  • получить текущее значение

Начиная с версии 4.2 в узле действии для роли может быть выбрана доинициализация (по умолчанию) и переинициализация:

Если настройка Переинициализация роли установлена в да — то выполняется переинициализация роли на основании инициализатора, безусловно от текущего значения роли.

Если настройка Переинициализация роли установлена в нет — то принудительная переинициализация роли при создании задания не выполняется, используется текущее значение роли. И только если оно не определено — выполняется инициализация роли.

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

Если настройка Доинициализация роли установлена в нет — то значение роли при выполнении задания не меняется.

Значения настроек по умолчанию задаются в настройках редактора.

значение настройки Переинициализация роли значение настройки Доинициализация роли типичная ситуация использования
да да После выполнения задания можно получить информацию о выполнившем её пользователе. Но при этом закрепления дальнейших заданий за ним не происходит, в каждой задаче — переинициализация роли.
да нет В длинных БП актуализация пользователей в роли. Например если роль инициализируется по отделу — то таким образом учитываются уволенные и вновь взятые сотрудники в старых БП.
нет да Закрепление пула задач за одним пользователем.
нет нет Роль инициализируется 1 раз в БП и далее не меняется. Затрудняюсь привести практичную ситуацию.

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

Для каждого исполнителя в системе есть возможность снять статус “Активен”, например по причине отъезда в командировку или болезни. Для этого необходимо перейти в свойства исполнителя и снять галочку в строке “Активен”, затем нажать “применить”.

Замечание. Если пользователю не видно заголовка «Статус» значит, он не обладает достаточными правами и нужно обратиться к администратору.

Substitution ru1.png

Задачи “неактивного” пользователя могут быть перенаправлены его заместителям.
Для этого используется механизм правил замещения.

Добавление правил замещения выполняется на странице свойств исполнителя.

Substitution ru2.png

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

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

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

 

# Добавление правила

Для добавления правила замещения необходимо нажать на “Добавить правило”

Substitution ru3.png

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

Substitution ru4.png

В настоящее время доступны следующие оргфункции:

Substitution ru5.png

ru.runa.wfe.extension.orgfunction.GetActorsByCodesFunction – “Исполнитель по коду”, функция предусматривает один параметр (исполнитель или код пользователя). Возвращает исполнителя.

ru.runa.wfe.extension.orgfunction.ExecutorByNameFunction – “Исполнитель по имени”, функция предусматривает один параметр (исполнитель или имя исполнителя). Возвращает исполнителя.

ru.runa.wfe.extension.orgfunction.DemoChiefFunction – “Руководитель (демо)”, функция предусматривает один параметр (пользователь или код пользователя). Возвращает непосредственного руководителя пользователя, определённого в demo.chief.properties.

ru.runa.wfe.extension.orgfunction.SQLChiefFunction — “Руководитель”, функция предусматривает один параметр (пользователь или код пользователя). Возвращает непосредственного руководителя пользователя, определяемого с помощью запроса к БД в sql.orgfunction.properties.

ru.runa.wfe.extension.orgfunction.SQLDirectorFunction – “Директор”, функция предусматривает один параметр (пользователь или код пользователя). Возвращает директора пользователя, определяемого с помощью запроса к БД в sql.orgfunction.properties.

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

Опция “Применить” – включение/выключения текущего правила.

# Добавление терминатора

В свойствах пользователя, в разделе “Заместители”, имеется пункт “Добавить терминатор”

Substitution ru6.png

При задании терминатора необходимо выбрать из списка критерий замещения.

Substitution ru7.png

В списке доступен вариант “Замещать всегда”, а также критерии созданные на странице “Система”

# Критерий замещения руководителя

Кроме варианта “Замещать всегда” существует возможность добавления других критериев.
Для этого необходимо перейти на страницу “Система”, где в разделе “Критерии замещения” нажать на “Добавить”

Substitution ru8.png

Здесь задается “Название” критерия, его тип и параметр

Substitution ru9.png

Возможные типы критериев:

ru.runa.wfe.ss.SubstitutionCriteriaSwimlane

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

ru.runa.wfe.ss.SubstitutionCriteriaNotEquals
Данный критерий замещения работает следующим образом: в качестве конфигурации указывается название переменной типа (Исполнитель, Пользователь, Группа) либо название роли (с префиксом swimlane:), значение которой используется для определения “будет ли применено правило замещения или нет”.

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

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

Критерии доступны как в правилах замещения так и в терминаторах.

 

# Принцип работы механизма

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

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

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

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

Substitution ru10.png

Замечание.
Если Роль инициализирована группой (или временной группой), то задание для заместителя/заместителей по замещению будет генерироваться только в том случае если все пользователи данной группы неактивны. Например, если в группе только один пользователь неактивен, то его заместитель задание не получит, если же все пользователи группы неактивны, то задания по замещению получат все заместители.

# Игнорирование правил замещения.

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

Для этого при редактировании графа процесса в Среде разработки необходимо выделить нужную задачу, вызвать меню правой кнопкой мышки и далее выбрать “Роли” > “Игнорировать механизм замещения”. При включенном игнорировании напротив этой опции меню будет стоять галочка, а в свойствах узла графа процесса будет значится «Игнорировать механизм замещения — Да».

WF-system User guide gpd ru1.png

# Пример выполнения механизма замещения исполнителей.

Для пользователя julius, который “неактивен” определены заместители: nero, marcus, octavia, выбираемые в зависимости от правил замещения.

Substitution ru12.png

В данном случае приведены три правила и один терминатор. При чем терминатор отключен, т.к. не установлена опция “Применить”

Используемые критерии для правил замещения:

Substitution ru13.png

Рассмотрим работу механизма замещения на следующем примере:

Пользователь julius в командировке, его статус “неактивен”, получает задание из бизнес-процесса “sub2”, при этом роль-дорожка в данном задании – “Роль1”. Срабатывает механизм, который просматривает сверху-вниз правила замещения, в данном примере для определения заместителя будет выбрано второе правило в списке, т.к. сработает критерий замещения “командировка”, у которого в качестве типа указан SubstitutionCriteriaSwimlane, а параметр “sub2.Роль1” совпал со значением бизнес-процесса и роли-дорожки у полученного задания.

Таким образом заместителем будет пользователь “nero”.

Substitution ru14.png

Задача попала к “nero” по замещению

# Эскалация заданий

# Срок выполнения заданий

# Общее описание

Для каждого задания в системе RunaWFE имеется возможность установить срок выполнения.
Задача считается почти просроченной, если прошла уже определенная часть времени от срока выполнения, по истечению же полного времени — задача считается просроченной.
В списках задач и на графе процесса, почти просроченная задача выделяется розовым цветом, а полностью просроченная – красным:

Timer ru pic1.png

Timer ru pic2.png

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

 

# Настройка параметров в файле конфигурации

Согласно Основные настройки (system.properties) параметры отвечающие за сроки выполнения задач:

  • task.default.deadline — время исполнения задания по умолчанию (если не установлено явно в Среде разработки), по истечению данного времени задача считается просроченной. По умолчанию установлено в значение 2 hours;
  • task.almostDeadlinePercents – процент истечения времени исполнения задачи, задается в процентах (от срока выполнения). По умолчанию установлено в значение 90;

Для переопределения значений по умолчанию данных параметров, согласно Правило переопределения настроек, определенных в properties файлах,
необходимо создать файл с названием wfe.custom.system.properties в каталоге wfe.custom

# Настройка параметров в Среде разработки

Имеется возможность задать время выполнения для каждого задания в отдельности, для этого необходимо выделить узел, перейти в его свойства и вызвать форму установки параметра “Время выполнения”

Timer ru pic3.png

Timer ru pic4.png

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

Timer ru pic5.png

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

Timer ru pic6.png

Timer ru pic7.png

Приоритет использования настроек для параметра «Срок выполнения» следующий:

В Среде разработки срок выполнения задается в свойствах задания (параметр «Время выполнения»).

Если для задания, время выполнения не задано, то для него будет взят параметр «Срок выполнения каждого задания по умолчанию» из свойств процесса.

В случае, если в свойствах процесса этот параметр тоже не задан, то используется настройка RUNA WFE сервера «task.default.deadline» из system.properties (wfe.custom.system.properties).

# Механизм эскалации заданий

# Общее описание

Эскалация — механизм, который по истечению некоторого времени расширяет круг исполнителей задачи. Предусмотрено время первого расширения круга исполнителей, а также периодического последующего расширения.

Для настройки эскалации используются:

  1. параметры по умолчанию, заданные в конфигурационном файле system.properties или через web интерфейс;
  2. настройки в свойствах Среды разработки (из меню Настройка эскалации); Замечание. Эта настройка не распространяется на уже существующую эскалацию, а действует только на добавление новой.
  3. настройки непосредственно в свойствах задания при включенной эскалации;

# Настройка параметров по умолчанию

В system.properties имеются два параметра, отвечающие за работу эскалации:

  • escalation.enabled – принимает значения true/false, используется для глобального разрешения/запрета эскалации, т.е. если установлено значение false, то эскалация не сработает, даже если она настроена в Среде разработки. По умолчанию эскалация включена;
  • escalation.default.hierarchy.loader (до версии 4.1.1 — escalation.default.orgFunction) — орг. функция или отношение 4.1.1+, для определения иерархии эскалации заданий, которая будет использоваться по умолчанию (т.е. в случае если не задано в Среде разработки). По умолчанию используется ru.runa.wfe.extension.orgfunction.TestOrgFunction (фиктивная орг. функция). Значением может быть либо полное название класса орг. функции, либо отношение в формате @relationName. Обратное отношение задаётся в формате @!relationName.

Данные параметры могут быть изменены в web интерфейсе или с помощью переопределения в файле wfe.custom.system.properties

Замечание. Значения заданные через web интерфейс имеют приоритет перед значениями в custom файле.

Для определения значений через web интерфейс необходимо открыть страницу с основными настройками (меню «Настройки»->»Основные настройки»)

и ввести данные в соответствующие поля

Также для изменения параметров по умолчанию можно воспользоваться правилом переопределения настроек, согласно которому следует использовать wfe.custom.system.properties, в который внести параметры с необходимыми значениями.

# Настройка и включение эскалации в Среде разработки

В Среде разработки используются следующие параметры эскалации:

  • “время до срабатывания эскалации” – необязательный параметр, определяет время, по истечении которого срабатывает механизм эскалации; Замечание. В случае если данный параметр не задан – будет использовано время, определенное как “срок выполнения задания”;
  • “орг. функция” (или отношение 4.1.1+) – функция, вызываемая после срабатывания механизма эскалации, расширяет круг исполнителей задания;
  • “задержка между повторениями” – предоставляет возможность установить время, по истечении которого будет выполнено повторное срабатывание эскалации;

Данные параметры в Среде разработки необходимы для настройки эскалации в заданиях процесса.

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

Для включения эскалации в задании необходимо вызвать контекстное меню задания и выбрать пункт “Опции > Эскалация”

Escalation ru pic1.png

Выключение эскалации выполняется аналогично

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

Escalation ru pic3.png

При включении эскалации (не важно, для всего процесса или для отдельного задания) начальные значения параметров берутся из настроек Среды разработки и заносятся в параметры эскалации в свойствах задания (или заданий). Если же они не заданы, то берутся параметры по умолчанию из файлов system.properties/wfe.custom.system.properties.

Для установки параметров эскалации по умолчанию в Среде разработки, необходимо выбрать в главном меню пункт “Свойства/настройки, Эскалация/настройки по умолчанию”

Escalation ru pic4.png

Escalation ru pic5.png

Напротив каждого параметра имеется кнопка “Изменить”, позволяющая изменить значение по умолчанию.

Задается задержка таймера до срабатывания эскалации, которая считается от даты прихода управления в задание:

Escalation ru pic6.png

единица измерения выбирается из предлагаемого списка:

Escalation ru pic7.png

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

Escalation ru pic8.png

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

Орг. функция «Функция SQL» также не используется для эскалации.

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

Параметры по умолчанию для орг. функций Руководитель (SQLChiefFuntion) и Директор (SQLDirectorFunction) заданы в конфигурационном файле sql.orgfunction.properties (подробнее о параметрах). Для переопределения значений параметров необходимо использовать wfe.custom.sql.orgfunction.properties (см. «Правило переопределения настроек, определенных в properties файлах«). Параметр datasource — название источника данных БД (это может быть как текущая БД Runa так и внешняя БД, например содержащая орг. структуры компании). В случае использования внешней БД, источник должен быть зарегистрирован в standalone.xml, но без привязки и установки соответствующего диалекта (подробнее о добавлении нового источника).

Также возможно использование и «своих» обработчиков (написанных по аналогии с существующими).

 

TODO: пример выбора отношения.

 

Замечание. Начиная с версии 4.1.1 для эскалации также имеется возможность использовать Отношения.

Форма ввода значения для “Задержка между повторениями” имеет такой же вид, как и у параметра “Время до срабатывания эскалации”:

Escalation ru pic9.png

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

Escalation ru pic10.png

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

# Связь эскалации и замещения

Эскалация расширяет временную группу исполнителей и к этой группе применяется стандартный механизм замещения для группы (см. Замещения. Принцип работы механизма. Замечание по работе замещения для группы).

Замечание.
Однако механизм замещения к группе в случае связи с эскалацией имеет недостаток.

Рассмотрим пример.

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

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

# Пример процесса с эскалацией и сроком выполнения

# Описание процесса

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

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

Для начала настроим параметры эскалации по умолчанию в Среде разработки:

Escalation ru pic11.png

Рассматриваемый пример бизнес процесса состоит из нескольких заданий и одного ветвления.

Escalation ru pic12.png

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

Escalation ru pic13.png

Время до срабатывания эскалации – 2 минуты

Орг. функция – DemoChiefFunction — руководитель (через файл)

Механизм повторного срабатывания не задан

“Задание 2” – эскалация включена, время до срабатывания эскалации задано непосредственно в свойствах задания (отличное от значения по умолчанию), орг. функция DemoChiefFunction:

Escalation ru pic14.png

Время до срабатывания эскалации – 1 минута

Орг. функция – руководитель (через файл)

“Задание 3” – эскалация включена, время до срабатывания эскалации не задано, но при этом задано “Время выполнения” , т.е. эскалация должна сработать по истечении “Времени выполнения” задания:

Escalation ru pic15.png

Время выполнения задания – 3 минуты

Орг. функция – руководитель (через файл)

# Выполнение процесса

Запустим данный процесс под пользователем “attila”

В списке задач получаем “Задание 1”:

Escalation ru pic16.png

Не выполняем данный процесс в течении 2 минут:

Escalation ru pic17.png

Как видно из истории выполнения, сработал механизм эскалации, в результате чего была создана временная группа с исполнителями attila, nero

Nero является руководителем пользователя Attila

Escalation ru pic18.png

Таким образом круг исполнителей данной задачи был расширен.

У пользователя nero, который является руководителем attila в списке активных заданий появилось “Задание1”

Escalation ru pic19.png

Выполним данную задачу под пользователем nero.
В истории процесса фиксируется, что данную задачу выполнил пользователь nero но при этом было использовано замещение:

Escalation ru pic20.png

перейдем к “Задание 2”:

Escalation ru pic21.png

Спустя 1 минуту, срабатывает механизм эскалации:

Escalation ru pic22.png

Снова расширен круг исполнителей, задача попадает к руководителю пользователя attila

Escalation ru pic23.png

Переходим к следующей задачи.

В “Задание 3” эскалация должна сработать по истечении времени заданного в параметре “Время выполнения”, которое составляет 3 минуты

Escalation ru pic24.png

Escalation ru pic25.png

Спустя 3 минуты сработал механизм эскалации:

Escalation ru pic26.png

Задание также отправлено пользователю nero

Escalation ru pic27.png