image001

© Syntellect 2020


1. Введение в конструктор бизнес-процессов

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

1.1. Основные компоненты

Узел (Node)

workflowEditor2

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

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

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

Действие (Action)

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

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

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

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

Сигнал

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

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

Событие

Событие – внешнее событие, обработчик которого инициирует отправку какого-либо сигнала в процесс. Например, нажатие кнопки в задании, кнопки процесса на боковой панели и т.д.

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

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

В связи определяется поведение создания экземпляров узла при переходе на новый узел. Оно может иметь одно из трех значений:

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

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

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

В связи определяется, должен ли данный сигнал выполняться синхронно, асинхронно или после загрузки файлов. Если установлен режим обработки сигнала Асинхронный, то при переходе сигнала по данной связи, его обработка будет выполнена асинхронно плагином Chronos, а если установлен режим После сохранения файлов, то обработка сигнала будет выполнена не в основном сохранении, а в отдельном уже после сохранения всех файлов карточки. Так же присутствует настройка Блокировать процесс при асинхронном вызове, которая определяет, может ли производиться обработка сигнала в данном процессе (синхронная или асинхронная) при выполнении данной асинхронной операции.

Шаблон процесса

workflowEditor7

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

Шаблон процесса поддерживает настройку и использование параметров. Параметры процесса копируются в каждый созданный по данному шаблону экземпляр и доступны в контексте обработки в любой момент обработки процесса. Редактор процесса описан в разделе Редактор процесса.

Экземпляр процесса

workflowEditor8

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

Экземпляр узла

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

Подписка

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

Есть несколько различных видов подписок:

  • Подписка на задание - данная подписка срабатывает при выполнении действия над заданием (взятие в работу, откладывание, завершение и т.д.), на которое подписан узел. Тип отправляемого сигнала зависит от произведенного над заданием действия.

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

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

  • Подписка на таймер - данная подписка срабатывает при каждом тике таймера, в зависимости от переданных в нее настроек (период, флаг "Выполнять один раз" и т.д.). При обработке данной подписки на узел отправляется сигнал "TimerTick".

1.2. Стандартные типы сигналов

  • Default – сигнал по умолчанию. Отправляется при создании процесса или если не указан иной тип сигнала при переходе.

  • Exit – сигнал, отправляемый при обработке выхода из узла.

  • CompleteTask – сигнал, отправляемый при завершении задания или для завершения задания. В параметрах имеет список заданий (если не задан, обрабатываются все задания) и вариант завершения задания.

  • DeleteTask – сигнал, отправляемый для удаления задания. В параметрах имеет список заданий (если не задан, обрабатываются все задания).

  • ReinstateTask – сигнал, отправляемый при возвращении задания на роль.

  • ProgressTask – сигнал, отправляемый при взятии задания в работу.

  • PostponeTask – сигнал, отправляемый при откладывании задания.

  • ReturnFromPostponeTask – сигнал, отправляемый при возврате задания из отложенного.

  • UpdateTask – сигнал, отправляемый для обновления параметров задания. В параметрах имеет список заданий (если не задан, обрабатываются все задания) и новые параметры для задания (дата завершения, исполнитель, описание задания)

  • SubprocessCompleted – сигнал, отправляемый подпроцессом в родительский процесс при завершении. Содержит тип сигнала, который фактически отправляет подпроцесс для обработки в родительский процесс.

  • SubprocessControl – сигнал, отправляемый для отправки сигнала в подпроцесс. В параметрах имеет тип отправляемого в подпроцесс сигнала.

  • Start – сигнал, используемый по умолчанию для запуска процесса.

  • UpdateTimer – сигнал, отправляемый для обновления параметров таймера. В параметрах имеет список идентификаторов обновляемых таймеров (или пустой список, если обновляются все таймеры) и новые параметры таймера (период и/или cron-выражение)

  • StopTimer – сигнал, отправляемый для остановки таймера. В параметрах имеет список идентификаторов обновляемых таймеров (или null, если ожидается остановка всех таймеров).

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

  • TimerTick – сигнал, отправляемый при обработке завершения таймера.

1.3. Обработка сигналов

В данном разделе концепция работы бизнес-процессов, созданных в редакторе.

Запуск процесса

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

workflowEditor72

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

При запуске процесса по данным из текущей версии шаблона бизнес-процесса создается новый экземпляр. И на все узлы с действием Старт процесса с нужным типом сигнала производится отправка сигнала с типом Default.

Обработка события

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

Например, узел, в котором есть действие с типом Задание, ожидает завершение отправленного им задания. При завершении задания в узел отправляется сигнал с типом CompleteTask и дополнительными параметрами, которые определяют задание и вариант завершения.

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

Также есть особый вид подписок на сигнал - подписки по умолчанию.

workflowEditor73

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

Обработка сигнала в узлах

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

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

Обработку сигнала в узле происходит в следующей последовательности:

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

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

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

    2. Выполняется предобработка действия. Если в предобработке задать свойству Cancel значение true, то дальнейшая обработка текущего действия пропускается.

    3. Выполняется само действие. Как каждый тип действия обрабатывает сигналы, смотрите в разделе в разделе Описание действий.

    4. Выполняется постобработка действия. Если в постобработке задать свойству Cancel значение true, то дальнейшая обработка всех действий узлов пропускается.

  3. После того, как все действия обработаны, происходит проверка списка связей для дальнейшей обработки. Если список пустой, то сигнал завершает свою обработку. Если список не пустой, то происходит дальнейшая обработка.

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

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

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

Обработка сигнала в связи

Обработка сигнала по связи производится по следующему алгоритму:

  1. Выполняется условие выхода из узла (если оно задано для конкретной связи). Если условие выполнено, то происходит дальнейшая обработка, иначе обработка сигнала прерывается. Условие выхода из узла выполняется в контексте узла, из которого происходит переход.

  2. Далее выполняется условие перехода в узел (если оно задано для конкретной связи). Если условие выполнено, то дальше происходит обработка сигнала в узле, куда выполняется переход, иначе обработка сигнала прерывается. Условие выхода из узла выполняется в контексте узла, из которого происходит переход.

Завершение процесса

Процесс завершается при выполнении действия Конец процесса при наличии у него настройки Завершить процесс. При завершении процесса, экземпляр процесса и все оставшиеся (если такие есть) экземпляры узлов удаляются. При завершении процесса, если это подпроцесс, то в родительский процесс отправляется сигнал с типом SubprocessCompleted с сигналом для обработки, который указан в действии Конец процесса. Обработкой данного типа сигнала занимается действие типа Подпроцесс.

Пример

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

workflowEditor71

При нажатии на кнопку запуска процесса происходит следующая последовательность событий:

  1. В первую очередь сигнал с типом Default придет в узел Старт процесса с действием типа Старт процесса в нем. Данное действие не выполняет никакой дополнительной обработки над список связей для дальнейшей обработки или над самим сигналом (если это не задано в пред- или постобработке).

  2. Дальше произойдет обработка списка связей для дальнейшей обработки. Т.к. он не был изменен действием Старт процесса, то дальше проверятся условия связи между узлами Старт процесса и сценарий, и если они выполнены, дальше вызовется обработка сигнала в узла Сценарий.

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

  4. В каждый узел Задание придет своя копия сигнала с типом Default (т.к. ни одно из действий до этого не изменило тип сигнала). Действия типа Задание при получении данного сигнала отправляет задание и очищает список связей для дальнейшей обработки. Поэтому дальнейшая обработка процесса после нажатия кнопки завершится.

В результате в карточке, в которой был запущен данный процесс, появится 2 задания.

При завершении первого из заданий сформируется сигнал завершения задания (тип сигнала CompleteTask) и отправится в тот узел, действие которого отправило данное задание. Дальше обработка перейдет в узел И с соответствующим типом действия, которое будет ожидать сигнала от второго узла Задание. Т.е. при завершении первого задания его узел завершит свое существование, но узел И остановит дальнейшую обработку.

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

1.4. Неперсистентный режим хранения процесса

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

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

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

Важно понимать, что неперсистентный процесс может перейти в персистентный, но персистентный в неперсистентный - не может.

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

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

2. Введение в настройку шаблона бизнес-процесса

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

2.1. Карточка шаблона бизнес-процесса

Чтобы создать карточку шаблона бизнес-процесса нужно на левой панели выбрать меню Создать карточку→Справочники→Шаблон бизнес-процесса.

workflowCard1

У данного типа карточек следующий набор полей:

  • Название - определяет название бизнес-процесса.

  • Группа - определяет группу, к которой относится бизнес-процесс.

  • Запуск из карточки - определяет, запускается ли данный процесс из карточки.

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

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

  • Сообщение при блокировке - сообщение, которое увидит пользователь при нажатии на кнопку процесса или завершении задания процесса, если версия этого процесса заблокирована на редактирование.

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

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

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

  • Версии бизнес-процесса - таблица со всеми версиями данного шаблона бизнес-процесса. Более подробное описание данной таблицы расположено в подразделе данной главы.

  • Кнопки бизнес-процесса - таблица со всеми кнопками данного шаблона бизнес-процесса. Более подробное описание данной таблицы расположено в подразделе данной главы.

2.1.1. Версии бизнес-процесса

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

workflowCard2

Таблица имеет следующие колонки:

  • Версия - номер версии шаблона процесса.

  • Родительская версия - номер родительской версии шаблона процесса.

  • Дата создания - дата и время создания версии бизнес-процесса.

  • Создано - создатель версии шаблона бизнес-процесса.

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

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

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

  • Заблокирован - определяет, заблокирована ли данная версия процесса на изменения. Если версия процесса заблокирована, то никакой процесс не может быть запущен или продолжен по данной версии процесса.

  • Заблокирован сотрудником - сотрудник, который заблокировал данную версию процесса на редактирование.

  • Число активных процессов - определяет число активных процессов по данной версии процесса.

Таблица имеет следующие кнопки:

  • Открыть - открывает редактор для выбранной версии шаблона бизнес-процесса. Открытие также можно производить по двойному нажатию на строку таблицы.

  • Заблокировать для редактирования - производит блокировку выбранной версии шаблона бизнес-процесса.

  • Разблокировать - производит снятие блокировки с выбранной версии шаблона бизнес-процесса (кнопка доступна при выборе заблокированной строки процесса).

  • Копировать в новую версию - копирует выбранную версию процесса в новую версию.

  • Сделать версией по умолчанию - делает выбранную версию версией по умолчанию, при этом снимает флаг По умолчанию с предыдущей версии.

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

2.1.2. Кнопки бизнес-процесса

В данной таблице содержится список всех кнопок для шаблона бизнес-процесса со всеми настройками отображения и доступа к ним. В колонку *Настройки" выводится информация о настройках расширений проверки доступа для тайлов (см. раздел Расширения проверки доступа для тайлов).

workflowCard3

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

По двойному нажатию производится открытие формы настройки кнопки.

workflowCard4

Форма настроек кнопок имеет следующие поля:

  • Название - определяет отображаемое значение на панели у пользователя на кнопке.

  • Иконка - определяет иконку кнопки.

  • Группа - определяет имя группирующего тайла, к которому будет принадлежать данная кнопка.

  • Размер плитки - определяет размер кнопки на панели пользователя.

  • Описание - текстовое описание кнопки. Пользователю нигде не отображается.

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

  • Текст подтверждения - текст сообщения, которое отображается пользователю при нажатии на кнопку, если стоит флаг Спрашивать подтверждение.

  • Спрашивать подтверждение - определяет, нужно ли выводить сообщение с текстом из поля Текст подтверждения для подтверждения нажатия на кнопку.

  • Группировать в действия - определяет, нужно ли данную кнопку группировать в панель Действия на левой боковой панели пользователя.

  • Отправляемый сигнал - определяет тип сигнала, отправляемый при нажатии на кнопку.

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

  • Доступна ролям - определяет список ролей, которым данная кнопка доступна. Допускает добавление любых ролей, кроме контекстных.

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

  • Условие - определяет дополнительное условие, написанное на языке C#, которое выполняется для проверки доступа к тайлу. API для подобных условий можно посмотреть в разделе API скриптов в условиях для тайлов.

2.1.3. Расширения проверки доступа для тайлов

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

Типы расширений проверки доступа для тайлов могут быть разработаны в рамках проектов. О том, как сделать свое расширение смотрите в разделе Создание расширений на проверку доступа к тайлам.

По умолчанию в платформе присутствуют следующие виды расширений:

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

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

2.2. Карточка настроек конструктора процессов

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

workflowCard5

У данного типа карточек следующий набор полей:

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

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

  • Настройки типов - таблица с настройками типов для редактора параметров.
    Настройки каждого типа имеют следуюшие поля:

    • Название - уникальная строка, обозначающая имя типа.

    • Заголовок - отображаемое для пользователя имя типа. Поддерживает строки локализации.

    • Секция - определяет секцию, из которой берутся данные для данного типа.

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

    • RefSection - определяет RefSection для выбора значений из представлений. Если не задан, то используется имя секции.

2.3. Доступ к шаблону бизнес-процесса

При создании новой карточки шаблона бизнес-процесса по умолчанию в поле Доступ на редактирование и Доступ на чтение экземпляров записывается создавший процесс сотрудник.
Доступ к шаблону процесса определяется следующим образом:

  • Если сотрудник входит в список ролей из поля Администраторы шаблонов процессов карточки настроек конструктора процессов, он имеет доступ на просмотр и редактирование шаблона процесса.

  • Если сотрудник входит в список ролей из поля Доступ на редактирование, он имеет доступ на просмотр и редактирование шаблона процесса.

  • Администраторы системы могут открыть карточку шаблона и выдать права на редактирование себе или другому сотруднику.

2.4. Доступ к экземпляру бизнес-процесса

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

  • Если сотрудник входит в список ролей из поля Администраторы шаблонов процессов карточки настроек конструктора процессов, он имеет доступ на просмотр и редактирование экземпляра процесса (подробнее о редактировании экземпляра в разделе Введение в отладку экземпляров процесса).

  • Если сотрудник входит в список ролей из поля Доступ на редактирование, он имеет доступ на просмотр и редактирование экземпляра процесса (подробнее о редактировании экземпляра в разделе Введение в отладку экземпляров процесса).

  • Если сотрудник входит в список ролей из поля Доступ на чтение экземпляров, он имеет доступ только на просмотр экземпляра процесса. Для просмотра экземпляров процесса на левой боковой панели карточки есть тайл Процессы со всеми доступными для просмотра экземплярами процесса. workflowCard1.1

3. Введение в визуальный редактор процессов

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

Редактор процесса можно разделить на 4 основных элемента:

workflowEditor1
  1. Панель с кнопками редактора - на данной панели отображаются все доступные кнопки редактора (например, "Сохранить", "Обновить", "Заблокировать на редактирование" и т.д.).

  2. Панель с действиями - на данной панели отображаются все доступные действия.

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

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

3.1. Панель с кнопками редактора

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

Кнопки панели:

  • Сохранить процесс - осуществляет сохранение версии процесса. Кнопка доступна только, если процесс заблокирован на редактирование или еще не был сохранен на сервере. Горячая клавиша [Ctrl+s].

  • Обновить процесс - производит обновление версии процесса и редактора. Кнопка доступна только если процесс уже был сохранен на сервере. Горячая клавиша [F5].

  • Заблокировать процесс - производит блокировку версии процесса на редактирование.

  • Разблокировать процесс - производит снятие блокировки на редактирование с версии процесса.

  • Настройки процесса - производит открытие на панели Редактор объекта формы для редактирования настроек процесса (см. Редактор процесса).

  • Отменить - производит отмену последнего изменения, производимого над макетом редактора. Горячая клавиша [Ctrl+z].

  • Вернуть - производит возврат последнего отмененного изменения над макетом редактора. Горячая клавиша [Ctrl+y].

  • Открыть руководство - производит открытие руководства разработчика бизнес-процесса. По умолчанию открывается ссылка на руководство на сайте. Ее можно переопределить путем переопределения строки локализации WorkflowEngine_ManualLink в библиотеке локализации проекта. Горячая клавиша [F1].

  • Открыть окно поиска - производит открытие окна поиска по шаблону бизнес-процесса. Описание и функциональность данного окна можно посмотрать в разделе Окно поиска. Горячая клавиша [Ctrl+f].

3.2. Панель с действиями

На данной панели отображаются все доступные действия.

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

В рамках решения можно разрабатывать свои типы действий. Пример того как сделать можно посмотреть в разделе Создание собственных действий.

3.3. Окно поиска

workflowEditor79

Окно поиска представляет из себя механизм, позволяющий производить поиск и замену строк среди объектов шаблона процесса.

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

  • Строка фильтра - здесь вводится искомая строка. Дополнительные кнопки позволяют перезапустить поиск и открыть строку замены.

  • Строка замены - в данное поле вводится строка, на которую должна заменится искаомая строка. Замена производится путем нажатия на кнопку Заменить для замены строк только в выделенных в таблице результатов объектах, или путем нажатия кнопки Заменить все для замены всех вхождений строки.

  • Совпадение слова целиком - при наличии установленного флага производит поиск только совпадений слова целиком.

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

3.4. Макет процесса

workflowEditor7

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

Макет процесса поддерживает работу с историей изменений, производимых в макете процесса. С помощью сочетания клавиш Ctrl+Z можно отменить последнее изменение, а Ctrl+Y вернуть последнее отмененное изменение.

Важно, что отменять можно только изменения, произведенные непосредственно на макете (добавление узла/связи/подписи, перемещение элемента на макете, изменение размера узла и т.д.).

У макета процесса есть контекстное меню, которое разрешает производить следующие действия:

  • Масштаб по умолчанию - устанавливает масштаб макета процесса на значение по умолчанию.

  • Размер сетки - группа действий, которая позволяет изменить размер сетки или отключить ее.

    • Без сетки - отключает сетку.

    • Маленький - изменяет размер сетки на маленький.

    • Средний - изменяет размер сетки на средний. Установлен по умолчанию.

    • Большой - изменяет размер сетки на большой.

  • Сохранить картинку…​ - позволяет сохранить текущий макет процесса как картинку в формате .png. При формировании картинки учитываются также все изменения, связанные с выбором элементов, размером сетки.

  • Вставить - производит вставки скопированного узла на макет.

На макете можно выделить следующие элементы:

3.4.1. Узел

workflowEditor2

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

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

workflowEditor3
  • Если для узла настроены подписки по умолчанию, то цвет данного узла в редакторе шаблона становится зеленым.

Действия над узлами
  • Добавление узла

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

    • Добавить новый узел можно путем перетаскивания в область макета действия из панели с действиями. Узел добавится в выбранную область непосредственно на макет. Если действие добавляется к существующем узлу, новый узел создан не будет.

    • Любой узел можно скопировать. Для этого нужно открыть контекстное меню узла и выбрать пункт Копировать или выбрать узел и нажать на сочетание клавиш Ctrl+C (важно, одновременно можно скопировать только один узел). Для добавления узла необходимо нажать правой кнопкой мыши на макете или стрелке и в контекстном меню выбрать пункт Вставить (горячая клавиша Ctrl+V) или Вставить в связь соответственно. Узел будет добавлен в позицию нажатой правой кнопки мыши.

  • Выбор узла

    • Выбрать узел можно простым нажатием на него. При этом откроется редактор узла (смотри раздел Редактор узла).

    • С помощью зажатой клавиши Ctrl или Shift можно выбирать несколько узлов одновременно. При выборе нескольких объектов сразу редактор узла не отображается.

    • С помощью зажатой клавиши Shift при нажатии по пустому месту на макете можно осуществить массовый выбор узлов в области.

    • Путем нажатия сочетания клавиш Ctrl+A можно выделить все узлы процесса. workflowEditor4

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

  • Изменение узла

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

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

    • Иконку и подпись узла можно изменить через редактор узла (смотри раздел Редактор узла).

    • К узлам могут быть добавлены подписи. Для добавления подписи откройте контекстное меню узла и выберите пункт Добавить подпись.
      workflowEditor6

  • Добавление связи

    • Чтобы добавить связь нужно выбрать узел, на появившейся боковой панели зажать Добавить связь и потянуть ее к другому узлу.

    • Также можно создать новую связь, просто зажав клавишу Ctrl, нажать на узел левой кнопкой мыши и не отпуская ее потянуть появившуюся новую стрелку к другому узлу.

  • Удаление узла

    • Чтобы удалить узел нужно выбрать узел и на появившейся боковой панели нажать кнопку Удалить.

    • Можно выбрать один или несколько узлов и нажать на кнопку Delete на клавиатуре.

Более подробно о настройках узла можно посмотреть в разделе Редактор узла.

3.4.2. Связь

workflowEditor25

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

Визуальные особенности

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

workflowEditor26

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

workflowEditor27

Если в настройках связи указано, что при переходе по ней никогда не создаются новые экземпляры, то стрелка имеет полоску возле ее окончания.

workflowEditor28

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

workflowEditor30

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

workflowEditor29
Действия над связью
  • Добавление связи

    • Чтобы добавить связь нужно выбрать узел, на появившейся боковой панели зажать Добавить связь и потянуть ее к другому узлу.

    • Также можно создать новую связь, просто зажав клавишу Ctrl, нажать на узел левой кнопкой мыши и не отпуская ее потянуть появившуюся новую стрелку к другому узлу.

  • Выбор связи

    • Выбрать связь можно простым нажатием на нее. При этом откроется редактор связи (смотри раздел Редактор связи).

    • С помощью зажатой клавиши Ctrl или Shift можно выбирать несколько связей одновременно. При выборе нескольких объектов сразу редактор связи не отображается.

  • Изменение связи

    • Чтобы изменить позицию начала стрелки или окончания стрелки, нужно выбрать ее и потянуть за кружок, примыкающий к соответствующему узлу.

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

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

  • Изменение позиции подписи - есть два режима расчета позиции подписи: автоматический и относительно "якоря" на стрелке. Если "якорь" активен, то он отображается как зеленый кружок на стрелке, иначе как серый. По умолчанию позиция подписи определяется автоматически. Сменить режим можно одним из следующих способов:

    • Открыть контекстное меню стрелки и выбрать пункт Автоматический расчет позиции подписи. Этот пункт переключает режим с одного на другой.

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

    • Переместить вручную якорь. Это отключит режим автоматического расчета позиции подписи.

  • Изменение текста подписи - текст подписи изменяется через редактор связи (смотри раздел Редактор связи).

  • Удаление связи

    • Чтобы удалить связь нужно выбрать одну или несколько связей и нажать на кнопку Delete на клавиатуре.

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

3.4.3. Подпись

workflowEditor39

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

Подписи могут иметь в качестве текста одну или несколько констант локализации. Для добавления нескольких констант локализации следует каждую константу обрамлять в фигурные скобки. Например:
{$Text1} текст без локализации {$Text2}.

Редактирование текста подписи производится прямо на макете. Для этого дважды нажмите на подпись и на ней откроется редактор текста.

workflowEditor40

3.5. Редактор объекта

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

workflowEditor50
  • Назад - открывает форму предыдущего объекта. Актуально для редактора действий.

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

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

  • Закрепить редактор - производит закрелпение редактора на одной стороне, чтобы его положение не изменялось в зависимости от положения выбранного объекта на макете.

  • Посмотреть содержимое - открывать окно с содержимым объекта в виде хеша.

  • Свернуть - сворачивает панель до минимизированного состояния. Панель будет минимизирована, пока не нажмут кнопку Развернуть.

    Внешний вид свернутого редактора объекта: workflowEditor51

  • Закрыть - закрывает панель.

3.5.1. Редактор процесса

Редактор процесса открывается по нажатию кнопки Настройки процесса на панели с кнопками редактора.

workflowEditor52

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

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

  • Описание - текстовое описание процесса.

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

  • Редактировать параметры процесса - кнопка, открывает редактор параметров для процесса. Про редактор параметров можно посмотреть в разделе Редактор параметров.

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

  • Открыть файл в проекте - кнопка, производит открытие файла с основным скриптом процесса после выгрузки скриптов в проект .csproj.

  • Выбрать проект - кнопка, позволяет выбрать проект .csproj для выгрузки скриптов процесса в проект в виде структуры файлов в формате .cs. Более подробно смотрите в разделе Выгрузка скриптов процесса.

  • Обновить проект - кнопка, производит повторную выгрузку скриптов процесса в проект.

  • Обновить процесс по проекту - кнопка, производит загрузку скриптов из проекта обратно в процесс.

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

  • Базовый класс процесса - определяет класс, который будет являться базовым для всех компилируемых объектов процесса. Его свойства и методы могут использоваться во всех скриптах и условиях процесса. Подробнее смотрите в разделе Создание кастомного базового класса процесса.

  • Основной скрипт процесса - скрипт на языке C#, который может быть использован в любом месте процесса.

3.5.2. Редактор узла

Редактор узла открывается при выборе узла.

workflowEditor53

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

  • Имя - уникальное в рамках процесса имя узла.

  • Заголовок - отображаемый на самом узле заголовок. Поддерживает строки локализации.

  • Описание - текстовое описание узла.

  • Иконка - иконка, которая отображается на узле.

  • Редактировать параметры узла - кнопка, открывает редактор параметров для узла. Про редактор параметров можно посмотреть в разделе Редактор параметров.

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

  • Подписки узла по умолчанию - определяет список типов сигналов, на которые подписывается данный узел при запуске процесса.

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

  • Входящие связи - список связей, входящих в данный узел. При двойном клике по строке таблицы откроется форма для редактирования параметров связи, относящихся к переходу в данный узел. Более подробно о параметрах можно посмотреть в разделе Редактор связи.

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

3.5.3. Редактор связи

Редактор связи открывается при выборе связи.

workflowEditor54

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

  • Имя - уникальное в рамках процесса имя связи.

  • Заголовок - текст отображаемой на стрелке подписи. Поддерживает локализацию.

  • Режим перехода - определяет режим создания экземпляра узла при переходе по данной связи.
    Может иметь одно из трех значений:

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

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

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

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

    • По умолчанию - обработка сигнала будет производиться в текущем контексте обработки процесса.

    • Асинхронный - обработка сигнала будет производиться асинхронно на Chronos.

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

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

  • Условие выхода из узла

    • Условие - условие на языке C#. Условие выполняется в контексте узла, из которого происходит переход. Если условие не выполнено, то переход по данной связи не осуществляется.

    • Описание условия - текстовое описание условия.

  • Условие входа в узел

    • Условие - условие на языке C#. Условие выполняется в контексте узла, в который происходит переход. Если условие не выполнено, то переход по данной связи не осуществляется.

    • Описание условия - текстовое описание условия.

По умолчанию условия пишутся в упрощенном режиме, в котором нужно написать просто результат.
Например:

SignalObject.Type == "SomeType"

С помощью директивы #script можно переключить режим написания условия в режим скрипта. Тогда в условие пишется как обычный метод C#, который должен возвращать значение типа bool.
Например:

#script
var signalType = SignalObject.Type;

return signalType == "SomeType";

3.5.4. Редактор действия

Редактор действия открывается из редактора узла. В редакторе действия доступна кнопка Назад, при нажатии которой открывается редактор узла.

workflowEditor55

Редактор действия имеет различный набор параметров, в зависимости от редактируемого действия.
Пример редактора действия Задание:

workflowAction6

В общий для всех редакторов действий входит следующий набор параметров и кнопок:

  • Имя - уникальное в рамках узла имя действия.

  • Редактировать параметры действия - кнопка, открывает редактор параметров для действия. Все настройки, которые доступны для определенных типов действий, записываются в параметры действия. Про редактор параметров можно посмотреть в разделе Редактор параметров.

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

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

  • Предобработка - скрипт на языке C#, который выполняется перед самим действием. Допускает отмену выполнения конкретного действия путем задания свойства Cancel.

  • Постобработка - скрипт на языке C#, который выполняется после выполнения действия. Допускает отмену дальнейшей обработки последующих действий узла путем задания свойства Cancel.

3.5.5. Редактор параметров

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

workflowEditor56

Редактор параметров служит для ручного создания и изменения параметров процесса, узла или действия.

Типы параметров

Параметры редактора поддерживают следующие типы данных:

  • Да/Нет - значение типа boolean.

  • Строка - значение типа string.

  • Вещественное число - значение типа double.

  • Десятичное число - значение типа decimal.

  • Целое число - значение типа int.

  • Идентификатор - значение типа Guid. Редактор имеет кнопку для генерации случайного идентификатора.

  • Дата/Время - значение типа DateTime. Редактор поддерживает возможность настройки типа хранения значения в UTC или в локальном часовом поясе.

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

  • Список - сложный объект, хранящий другие параметры внутри себя в виде списка.
    Может использовать типы объектов, описанные в настройках конструктора процесса, а также имеет Режим секции, при включении которого в каждую строку будет добавлено поле RowID.
    После выбора типа список можно наполнить значениями с помощью кнопки кнопки Выбрать значения. После выбора типа значения и наполнением его значениями, тип списка поменять нельзя.

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

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

Каждый параметр имеет следующие варианты в контекстном меню:

  • Изменить значение - открывает редактор выделенного объекта.

  • Копировать - копирует значение выбранного объекта.

  • Удалить имя ключа/из списка - производит удаление выбранного объекта из родительской хеш-таблицы или из родительского списка.

Параметры типа Объект (хеш-таблица) имеют дополнительно следующие варианты в контекстном меню:

  • Добавить элемент - позволяет добавить новый параметр в выделенный объект. При этом откроется редактор параметра с возможностью выбора типа и значения параметра, а также ключа, по которому будет хранится данный параметр.

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

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

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

  • Добавить элемент в начало - позволяет добавить новый параметр в выделенный объект в начало списка. При этом откроется редактор параметра с возможностью выбора типа и значения параметра.

  • Добавить элемент в конец - позволяет добавить новый параметр в выделенный объект в конец списка. При этом откроется редактор параметра с возможностью выбора типа и значения параметра.

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

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

  • Очистить список - удаляет все параметры из списка.

При открытии контекстного меню для элемента списка также доступны варианты:

  • Добавить элемент в список до - позволяет добавить новый параметр в список перед выделенным объектом. При этом откроется редактор параметра с возможностью выбора типа и значения параметра.

  • Добавить элемент в список после - позволяет добавить новый параметр в список после выделенного объекта. При этом откроется редактор параметра с возможностью выбора типа и значения параметра.

  • Вставить в список до - позволяет добавить скопированный параметр из буфера обмена в список перед выделенным объектом.

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

3.5.6. Форма для создания привязки

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

Поддерживаются следующие источники данных для параметров действия:

  • Параметры процесса

  • Параметры узла, к которому относится действие

  • Параметры самого действия

  • Параметры сигнала

  • Поле/секция карточки

  • Поле/секция задания (или заданий)

  • SQL-запрос

  • Представление

Например, можно указать роль Руководитель в параметре процесса ManagerRole, и использовать во всех действиях типа Задание, где необходимо отправить задание на роль Руководитель.

Параметры действия, которые допускают привязку, имеют справа специальную кнопку настройки привязки. workflowEditor57

Для контролов с уже настроенной привязкой в форме добавляются дополнительные кнопки. workflowEditor57.1

  • Кнопка со стрелками переключает вид контрола из режима отображения привязки на отображение значения.

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

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

При нажатии на кнопку настройки привязки открывается форма:

workflowEditor58

В форме отображаются следующие настройки:

  • Выбранный параметр - показывает текущий выбранный параметр.

  • Тип привязки - определяет текущий тип привязки. Для каждого типа используется свой редактор для создания привязки. При смене типа привязки текущая привязка очищается.

  • Редактор привязки - редактор, соответствующий текущему выбранному типу привязки.

  • Кнопка "Ок" - при нажатии сохраняет настроенную привязку в качестве значения.

  • Кнопка "Отмена" - производит отмену изменений, внесенных в привязку.

В зависимости от выбранного типа привязки отображается тот или иной редактор.

Параметры процесса, узла, действия и сигнала

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

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

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

workflowEditor74

Редактор имеет следующие настройки:

  • Новый параметр - используется для создания нового параметра для параметров Действия, Узла и Процесса, или полем для ввода параметра для параметров Сигнала.

    Значение поля Новый параметр должно содержать полный путь к создаваемому в дереве параметров элементу. Если необходимо создать параметр как вложенный в хеш-таблицу (или в дерево хеш-таблиц), то полный путь должен состоять из списка имен всей посследовательности хеш-таблиц, в которую добавляется элемент, с именем параметра, где каждое имя отделено от другого символом . (точка). Например, указанный путь Variables.ParameterHash.Parameter создаст структуру вида:

    Variables: {
      ParameterHash: {
        Parameter: ...
      }
    }
  • Создать - создает параметр, по пути, указанному в поле Новый параметр, и делает его выбранным. Если параметр уже создан, то делает его выбранным, если тип данных параметра подходит для настраиваемого поля.

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

  • Редактор параметров - редактор параметров, из которого можно выбрать нужный параметр. Недоступен для типа привязки Параметры сигнала.

Карточка

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

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

workflowEditor75

Редактор имеет следующие настройки:

  • Тип карточки - позволяет выбрать тип карточки, структуру которой мы хотим увидеть в редакторе параметров для выбора значения.

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

  • Колонка для сортировки - определяет колонку, по которой будут сортироваться значения. Доступно только при выборе списка значений.

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

Задание

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

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

workflowEditor76

Редактор имеет следующие настройки:

  • Тип задания - позволяет выбрать тип карточки задания, структуру которой мы хотим увидеть в редакторе параметров для выбора значения.

  • Фильтры - блок определяет фильтры для определения задания из контекста обработки процесса.

    • Новые задания - для получения значения могут использоваться новые задания. Задания считается новым, если его State соответствует CardRowState.Inserted.

    • Завершенные задания - для получения значения могут использоваться завершенные задания. Задания считается завершенным, если его State соответствует CardRowState.Deleted или CardRowState.Modified, а Action соответствует CardTaskAction.Complete.

    • Измененные задания - для получения значения могут использоваться измененные задания. Задания считается измененным, если его State соответствует CardRowState.Deleted или CardRowState.Modified, или в задании происходит изменение хотя бы одного из его аттрибутов (Digest, Author и т.д.), а Action отличен от CardTaskAction.Complete.

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

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

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

  • Колонка для сортировки - определяет колонку, по которой будут сортироваться значения. Доступно только при выборе списка значений.

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

    • Role - роль, на которую отправлено задание.

    • Author - автор задания.

    • User - сотрудник, завершивший заданий.

    • CreatedBy - сотрудник, являющийся создателем задания.

    • Digest - описание задания.

    • Planned - плановая дата завершения задания.

    • InProgress - дата взятия задания в работу.

    • Created - дата создания задания.

SQL-значение

Привязка к SQL-значению подразумевает, что значение привязки будет взято из результата заданного SQL-запроса.

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

workflowEditor77

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

В редакторе заполняется SQL-запрос, который используется для получения значения привязки.

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

Привязка к представлению подразумевает, что значение привязки будет взято из данных, полученных из представления.

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

workflowEditor78

Редактор имеет следующие настройки:

  • Представление - представление, которое используется для получения данных.

  • Колонка/Ссылочное значение - колонка из списка колонок при создании привязки для получения значения простого типа (строка, число, дата и т.д.) или ссылочное значение (reference в представлении) из списка всех ссылочных значений при создании привязки для получения значения сложного типа или списка.

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

3.5.7. Редактирование экземпляра процесса

Редактор экземпляра процесса внешне практически не отличается от редактора шаблона процесса, однако сильно отличается его возможностями.

Окно редактора экземпляра процесса можно разделить на 3 основных элемента:

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

    • Сохранить - сохраняет изменения экземпляра процесса. Доступно только при наличии доступа на редактирование экземпляра процесса.

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

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

    • Открыть карточку - открывает карточку, к которой относится текущий процесс.

    • Обновить - производит обновление экземпляра процесса. Не обновляет расположение узлов и связей на макете в случае изменения шаблона. Для полного обновления необходимо нажать на кнопку с зажатой клавишей Shift.

    • Показать логи процесса - открывает представление со всеми логами процесса. Доступно только при наличии доступа на редактирование экземпляра процесса.

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

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

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

Отличия макета экземпляра от шаблона

При редактировании экземпляра узла макет имеет два основных отличия:

  • Макет нельзя редактировать

  • Для узлов добавляется подсветка. Активные узлы подсвечиваются желтым цветом, узлы, которые исполнялись, подсвечиваются серым цветом, узлы с ошибкой отображаются красным цветом (про узлы с ошибками смотри в разделе Отладка экземпляра процесса).

Изменение редактора узла

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

Если у узла всего один экземпляр, то при выборе узла сразу откроется редактор этого экземпляра узла.

Редактор экземпляра процесса

Редактор экземпляра процесса открывается по кнопке Настройки процесса из панели с кнопками редактора.

workflowEditor60

В редакторе экземпляра процесса присутствует следующие настройки:

  • Имя - имя экземпляра процесса.

  • Уровень логирования - уровень логирования для текущего экземпляра процесса.

  • Редактировать параметры процесса - кнопка, открывает редактор параметров для экземпляра процесса. Про редактор параметров можно посмотреть в разделе Редактор параметров.

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

    • Открыть карточку ошибки - открывает карточку выбранной ошибки в клиенте. Можно также открыть двойным щелчком (мыши) по строке таблицы.

    • Повторить отправку сигнала - производит открытие редактора сигнала (см. …​) для возможности повторной отправки сигнала, который обрабатывался при возникновении ошибки. Более подробно смотри в разделе Отладка экземпляра процесса.

    • Сбросить отображение ошибки - сбрасывает отображение ошибки на макете.

Редактор экземпляра узла

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

workflowEditor62
workflowEditor63

Редактор экземпляра узла имеет следующие параметры, кнопки и таблицы:

  • Имя - показывает имя узла, по которому создан экземпляр.

  • Заголовок - показывает заголовок узла, по которому создан экземпляр.

  • Редактировать параметры узла - кнопка, открывает редактор параметров для экземпляра узла. Про редактор параметров можно посмотреть в разделе Редактор параметров.

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

  • Задания - таблица, в которой отображаются все активные задания, созданные действиями из данного экземпляра узла. При двойном щелчке (мыши) по строке таблицы открывается форма с более подробной информацией о задании.
    Таблица имеет кнопки для управления выбранными заданиями. Более подробно о данном функционале смотрите в разделе Отладка экземпляра процесса.

  • Подпроцессы - таблица, в которой отображаются все активные подпроцессы, созданные действиями из данного экземпляра узла. При двойном щелчке (мыши) по строке таблицы открывается редактор подпроцесса.
    Таблица имеет кнопки для управления выбранными подпроцессами. Более подробно о данном функционале смотрите в разделе Отладка экземпляра процесса.

Редактор экземпляра действия

Редактор действия открывается из редактора экземпляра узла. В редакторе экземпляра действия доступна кнопка Назад, при нажатии которой открывается редактор экземпляра узла.

workflowEditor64

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

В общий для всех редакторов экземпляров действий входит следующий набор параметров и кнопок:

  • Имя - уникальное в рамках узла имя действия.

  • Редактировать параметры действия - кнопка, открывает редактор параметров для экземпляра действия. Про редактор параметров можно посмотреть в разделе Редактор параметров.

3.6. Выгрузка скриптов процесса

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

При нажатии на кнопку Выбрать проект в редакторе процесса, система откроет окно для выбора файла с форматом .csproj.

Для корректной работы выгрузки в выбранном проекте должна быть ссылка на Tessa.Extensions.Server.dll, а также на все зависимости, указанные в скриптах процесса.
Можно создать отдельный проект в Tessa.Extensions.sln, и использовать его для выгрузки разрабатываемых процессов, или использовать сам проект Tessa.Extensions.Server.csproj.

После выбора файла .csproj система создаст папку Processes в папке с выбранынм файлом проекта, и в нее выгрузит все скрипты процесса в виде следующей структуры:

workflowEditor81

В файле MainClass.cs хранится скрипт основного процесса. В папке Links хранятся скрипты всех связей процесса, в каждом отдельном файле хранятся все скрипты соответствующей связи. В папке Nodes хранятся папки со всеми узлами процесса. В каждой папке лежат файлы со всеми скриптами действий процесса, в каждом отдельном файла хранятся все скрипты соответствющего действия.

При нажатии на кнопку Обновить проект система пересоздаст всю структуру файлов в выбранном ранее проекте.

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

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

При изменении файла .cs соответствующие изменения скриптов объекта, к которому относится данный файл, автоматически переносятся и в скрипты процесса. Также можно принудительно обновить процесс по нажатию на кнопку Обновить процесс по проекту.

Система определяет тело скрипта действия, связи или процесса в .cs файле по меткам регионов в формате #region MethodName Body …​ #endregion MethodName Body End. Эти не рекомендуется менять, т.к. это приведет к некорректной работе обратной загрузки скриптов в процесс.

При закрытии редактора процесса, система автоматически удалит выгруженные папки из проекта.

4. Введение в отладку экземпляров бизнес-процесса

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

Текущие механизмы отладки позволяют производить следующие операции над экземпляром процесса:

4.1. Отправка произвольного сигнала

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

Чтобы отправить сигнал нужно открыть контекстное меню любого узла и выбрать опцию Отправить сигнал.

workflowEditor65

Появится окно с редактором отправляемого сигнала (более подробно о редакторе сигнала см. в разделе <<signalEditor, Редактор сигнала). Для отправки сигнала необходимо нажать на кнопку Отправить сигнал.

workflowEditor66

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

4.2. Управление заданием

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

Есть два способа формирования подобного сигнала:

  1. Открыть контекстное меню активного узла с отправленными заданиями и выбрать одну из опций: Отправить сигнал завершения заданий, Отправить сигнал обновления заданий или Отправить сигнал удаления заданий.

  2. Открыть редактор экземпляра узла, в таблице Задания выбрать одну или несколько строк с заданиями и нажать одну из кнопок: Отправить сигнал завершения заданий, Отправить сигнал обновления заданий или Отправить сигнал удаления заданий.

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

Есть три типа воздействия на задание, каждое из которых вызывается соответствующей кнопкой или вариантом контекстного меню:

  • Завершение заданий - завершает выбранные задания с указанным в сигнале вариантом завершения. При выборе данного варианта завершения система предложит сразу выбрать вариант завершения заданий и по нему сформирует сигнал и откроет редактор сигнала.
    workflowEditor67

  • Обновление заданий - производит обновление данных (исполнитель, срок завершения, текст задания) для выбранных заданий. После нажатия на кнопку система сформирует макет сигнала и откроет редактор сигнала, в котором есть дополнительная кнопка Выбрать роль для выбора новой роли исполнителя из представления системы.
    workflowEditor68 У заданий обновятся только те поля, которые были заполнены в сигнале (Date - для даты завершения, Digest - для текста задания, Role - для роли исполнителя).

  • Удаление заданий - удаляет выбранные задания. После нажатия на кнопку система сформирует макет сигнала и откроет редактор сигнала.
    workflowEditor69

4.3. Управление подпроцессом

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

Есть два способа формирования подобного сигнала:

  1. Открыть контекстное меню активного узла с отправленными подпроцессами и выбрать опцию Отправить сигнал управления подпроцессом.

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

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

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

workflowEditor70

4.4. Повторная отправка сигналов после ошибки

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

workflowEditor60

С помощью кнопки Повторить отправку сигнала можно отправить тот же сигнал на экземпляр узла, при отправке которого произошла ошибка. Отправка производится из-под сессии текущего сотрудника.

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

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

4.5. Возобновление процесса

При возникновении ошибки при асинхронной обработке процесса, помимо повторной отправки сигнала, в системе есть возможность возобновления асинхронной обработки процесса.

Возобновить работу процесса после ошибки при асинхронной обработке можно двумя способами:

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

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

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

4.6. Редактор сигнала

Редактор сигнала представляет из себя редактор параметров с возможностью указания типа сигнала при отправке.

workflowEditor66

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

При нажатии на кнопку Отправить сигнал производится отправка сигнала с типом и параметрами, указанными в редакторе.

5. Описание действий

В данном разделе представлена информация о стандартных действиях.

5.1. Особенности действий

  • Некоторые действия могут находиться в узле только как единственное действие. Узлы таких действий не могут иметь больше чем один экземпляр узла. Данные действия принято называть одиночные.

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

  • Некоторые виды действий могут обрабатывать особый системный Exit-сигнал, который вызывается перед осуществлением выхода из узла.

  • Некоторые виды действий не могут работать в неперсистентном режиме обработки процесса. Такие действия выводят обрабатываемый процесс из неперсистентного режима.

5.2. Старт процесса

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

Настраиваемые параметры

workflowAction1
  • Запускающий сигнал (значение из справочника сигналов или строка, обязательный) - тип сигнала, при получении которого процесс начинает свое выполнение, начиная от данного действия.

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

Типы обрабатываемых сигналов

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

5.3. Конец процесса

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

Настраиваемые параметры

workflowAction2
  • Сигнал окончания (значение из справочника сигналов или строка) - тип сигнала, который отправляется на все процессы, подписанные на данный процесс.

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

Типы обрабатываемых сигналов

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

5.4. Сценарий

Данное действие выполняет заданный в настройках действия скрипт. Скрипт может быть написан языке C#. Подробнее о написании скриптов можно посмотреть в разделе API скриптов и Примеры.

Настраиваемые параметры

workflowAction3
  • Сценарий (значение типа string) - текст выполняемого скрипта.

  • Выполнять на любой сигнал (значение типа boolean) - флаг определяет, должен ли данный скрипт выполняться при получении любого сигнала, или только при получении сигнала типа Default.

Типы обрабатываемых сигналов

Данное действие выполняется при получении сигнала типа Default, или при получении любого сигнала, если установлен флаг Выполнять на любой сигнал.

5.5. Группа заданий

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

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction4
  • Тип задания (значение из справочника типов заданий, обязательный) - определяет тип отправляемых заданий.

    Не используйте типы заданий, которые также задействованы в других типах процессов, не связанных с конструктором бизнес-процессов. Это относится к заданиям процесса маршрутов (KrApprove, KrEdit и др.), процесса задач (WfResolution и др.), и процессов Workflow API, написанных кодом (TestTask1 и др.). При необходимости использовать похожее задание создайте копию типа задания в контекстном меню в списке типов TessaAdmin.
  • Роли (список значений из справочника ролей, может быть привязан к параметрам процесса) - определяет список ролей, на которые должны отправляться задания.

  • Параллельная отправка заданий (значение типа boolean) - флажок определяет, должны ли задания отправляться в параллельном режиме (т.е. одновременно). Если флаг установлен, все задания отправляются одновременно. Если нет, то задания отправляются последовательно, одно за другим после завершения предыдущего, по списку ролей.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

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

  • Сценарий инициализации заданий (значение типа string) - скрипт, который выполняется при создании каждого задания.
    Имеет дополнительные параметры:

    • task - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

    • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

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

  • Не отправлять заместителям (значение типа boolean, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

    • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Варианты завершения (таблица) - содержит настройки обработки заданий при их завершении по вариантам завершения.
    workflowAction21

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

    • Результат (значение типа string, может быть привязано к параметрам процесса) - определяет результат, который будет записан в историю заданий при завершении заданий с данным вариантом завершения. Поддерживает использование плейсхолдеров. Если данный результат не задан, то будет использоваться результат из основных настроек.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении задания с данным вариантом завершения.
      Имеет дополнительные параметры:

      • task - объект задания, которое завершается.

      • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

      • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

    • Переходы (список связей, исходящих из текущего узла) - определяет список связей, по которым должен быть отправлен сигнал после завершения обработки узла.

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

      • Каждое задание - обработка должна производиться сразу после завершения задания с данным вариантом завершения.

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

      • Все задания, после завершения всех заданий - обработка должна производиться после завершения всех заданий, если каждое задание было завершено с данным вариантом завершения.

      • Всегда, после завершения всех заданий - обработка должна производится после завершения всех заданий вне зависимости от вариантов завершения. При данной настройке Вариант завершения ни на что не влияет.

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

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

    • Приостановить выполнение группы (значение типа boolean) - установка данного флага приостанавливает выполнение группы заданий. Если группа заданий приостановлена, то новые задания группы не будут создаваться.

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

    • Вариант завершения отмены (значение из справочника вариантов завершений) - определяет вариант завершения, с которым будут отменены другие задания данной группы. Если не задан, задания при отмене группы будут удалены.

    • Уведомление (значение из справочника уведомлений) - карточка уведомления, по которой должна производиться отправка уведомления при завершении задания с указанным вариантом завершения.

    • Получатели (список ролей) - список получателей уведомления.

    • Отправить исполнителю (значение типа boolean) - определяет, нужно ли к списку получателей добавить исполнителя задания. Если задание взято в работу, то к получателям добавится сотрудник, взявший задание в работу. Если задание не взято в работу, то добавится роль, на которую отправлено задание.

    • Отправить автору (значение типа boolean) - определяет, нужно ли к списку получателей добавить автора задания.

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

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

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

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

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

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

      • Взять в работу - выполняется при взятии задания в работу.

      • Вернуть на роль - выполняется при возвращении задания на роль.

      • Отложить - выполняется при откладывании задания.

      • Вернуть из отложенного - выполняется при возвращении задания из отложенного.

      • Выполнить задание - выполняется при выполнении задания.

    • Сценарий (значение типа string) - скрипт, который выполняется при получении от любого задания группы заданий указанного события.
      Имеет дополнительные параметры:

      • task - объект задания, которое вызвало данное событие.

      • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

      • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

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

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

    • Тип карточки (обязательное, елси не задан Шаблон карточки, значение из справочника Типы для диалогов) - определяет тип карточки, который будет использован в качестве типа карточки диалога. Тип карточки определяет структуры данных и UI полей диалога.

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

    • Отображаемое имя диалога (значение типа string) - имя диалога, которое видет пользователь при его открытии.

    • Имя диалога (для расширений) (значение типа string) - имя диалога, которое используется для идентификации диалога в расширениях.

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

    • Время жизни диалога (значение из выпадающего списка) - определяет время жизни диалога. Может иметь одно из значений:

      • Запрос - диалог хранится на уровне запроса. При каждом новом открытии диалога он формируется заново.

      • Задание - диалог хранится в настройках задания. Состояние диалога будет сохраняться и изменяться, пока существует задание. Диалог перестает существовать, когда завершается (с удалением) задание, к которому он относится.

      • Карточка - диалог хранится как отдельная карточка в системе. Может быть использован в различных диалогах этого процесса при использовании настройки Алиас диалога. Если карточка диалога является карточкой сателлита, то она удалится вместе с основной карточкой.

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

    • Настройки кнопок (таблица) - таблица с натройками кнопок диалога. Каждая кнопка имеет следующие настройки:

      workflowAction24

      • Алиас кнопки (значение типа string) - определяет уникальное (в рамках диалога) имя кнопки, которое может быть использовано в расширениях для ее идентификации.

      • Тип (значение из справочника типов кнопок) - определяет тип кнопки. Это влияет на то, где данная кнопка будет отображаться (в тулбаре, в нижнем тулбаре или в кнопках диалога).

      • Текст кнопки (значение типа string) - отобраамео имя кнопки, которое видит пользователь.

      • Иконка (значение типа string) - икнопка кнопки на верхнем или нижнем тулбаре. Не используется при отображении кнопки в нижней панели.

      • Отмена (флаг) - определяет, является ли данная кнопка - кнопкой отмены. При нажатии на такую кнопку, диалог просто закрывается, настройки переходов и сценарий кнопки не применяются.

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

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

      • Сценарий (значение типа string) - скрипт на языке C#, который выполняется при нажатии данной кнопки диалога.
        Имеет дополнительные параметры:

        • dialog - контекст обработки диалога, который имеет тип Tessa.Workflow.Actions.WorkflowDialogContext. Более подробно о данном объекте написано в описании действия Диалог.

    • Сценарий инициализации диалога (значение типа string) - скрипт на языке C#, который выполняется при инициализации диалога. Инициализация диалога происходит вместе с созданием задания.

    • Сценарий сохранения (значение типа string) - скрипт на языке C#, который выполняется при сохранении диалога. Сохранение диалога происходит как при обычном сохранении карточки диалога, так и по кнопке диалога (кроме кнопки с флагом Отмена).

    • Сценарий валидации (значение типа string) - скрипт на языке C#, который выполняется при валидации диалога. Происходит только при непосредственном завершении диалога по кнопке, у которой не стоят флаги Не завершает диалог и Отмена.
      Этот и описанные выше сценарии имеют дополнительные параметры:

      • dialog - контекст обработки диалога, который имеет тип Tessa.Workflow.Actions.WorkflowDialogContext. Более подробно о данном объекте написано в описании действия Диалог.

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку заданий с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активные задания группы, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление активных заданий. При последовательной отправке данный сигнал прерывает обработку всей группы.

  • UpdateTask - производит обновление заданий по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активные задания, то данное действие помечает узел как Активный.

5.6. Добавить файл по шаблону

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

Настраиваемые параметры

workflowAction5
  • Шаблон файла (значение из справочника шаблонов файла) - шаблон файла, по которому будет сгенерирован новый файл.

  • Имя файла (значение типа string) - имя нового файла. Допускает использование плейсхолдеров. Если имя не задано, то будет использоваться стандартное имя файла, указанное в шаблоне файла.

Типы обрабатываемых сигналов

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

5.7. Задание

Данное действие отправляет задание по настройкам, указанным в данном действии, а также обрабатывает завершение и другие события, отправленные из задания. Данное действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction6
  • Тип задания (значение из справочника типов заданий, обязательный) - определяет тип отправляемых заданий.

    Не используйте типы заданий, которые также задействованы в других типах процессов, не связанных с конструктором бизнес-процессов. Это относится к заданиям процесса маршрутов (KrApprove, KrEdit и др.), процесса задач (WfResolution и др.), и процессов Workflow API, написанных кодом (TestTask1 и др.). При необходимости использовать похожее задание создайте копию типа задания в контекстном меню в списке типов TessaAdmin.
  • Роль (значений из справочника ролей, может быть привязано к параметрам процесса) - определяет роль, на которую будет отравлено задание.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

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

  • Сценарий инициализации заданий (значение типа string) - скрипт, который выполняется при создании каждого задания.
    Имеет дополнительные параметры:

    • task - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

    • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

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

  • Не отправлять заместителям (значение типа boolean, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

    • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Варианты завершения (таблица) - содержит настройки обработки заданий при их завершении по вариантам завершения.
    workflowAction20

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

    • Результат (значение типа string, может быть привязано к параметрам процесса) - определяет результат, который будет записан в историю заданий при завершении заданий с данным вариантом завершения. Поддерживает использование плейсхолдеров. Если данный результат не задан, то будет использоваться результат из основных настроек.

    • Переходы (список связей, исходящих из текущего узла) - определяет список связей, по которым должен быть отправлен сигнал после завершения обработки узла.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении задания с данным вариантом завершения.
      Имеет дополнительные параметры:

      • task - объект задания, которое завершается.

      • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

      • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

    • Уведомление (значение из справочника уведомлений) - карточка уведомления, по которой должна производиться отправка уведомления при завершении задания с указанным вариантом завершения.

    • Получатели (список ролей) - список получателей уведомления.

    • Отправить исполнителю (значение типа boolean) - определяет, нужно ли к списку получателей добавить исполнителя задания. Если задание взято в работу, то к получателям добавится сотрудник, взявший задание в работу. Если задание не взято в работу, то добавится роль, на которую отправлено задание.

    • Отправить автору (значение типа boolean) - определяет, нужно ли к списку получателей добавить автора задания.

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

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

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

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

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

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

      • Взять в работу - выполняется при взятии задания в работу.

      • Вернуть на роль - выполняется при возвращении задания на роль.

      • Отложить - выполняется при откладывании задания.

      • Вернуть из отложенного - выполняется при возвращении задания из отложенного.

      • Выполнить задание - выполняется при выполнении задания.

    • Сценарий (значение типа string) - скрипт, который выполняется при получении от любого задания группы заданий указанного события.
      Имеет дополнительные параметры:

      • task - объект задания, которое вызвало данное событие.

      • taskCard - представление строковых секций карточки задания посредством dynamic-полей.

      • taskCardTables - представление табличных секций карточки задания посредством dynamic-полей.

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

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

    • Тип карточки (обязательное, елси не задан Шаблон карточки, значение из справочника Типы для диалогов) - определяет тип карточки, который будет использован в качестве типа карточки диалога. Тип карточки определяет структуры данных и UI полей диалога.

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

    • Отображаемое имя диалога (значение типа string) - имя диалога, которое видет пользователь при его открытии.

    • Имя диалога (для расширений) (значение типа string) - имя диалога, которое используется для идентификации диалога в расширениях.

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

    • Время жизни диалога (значение из выпадающего списка) - определяет время жизни диалога. Может иметь одно из значений:

      • Запрос - диалог хранится на уровне запроса. При каждом новом открытии диалога он формируется заново.

      • Задание - диалог хранится в настройках задания. Состояние диалога будет сохраняться и изменяться, пока существует задание. Диалог перестает существовать, когда завершается (с удалением) задание, к которому он относится.

      • Карточка - диалог хранится как отдельная карточка в системе. Может быть использован в различных диалогах этого процесса при использовании настройки Алиас диалога. Если карточка диалога является карточкой сателлита, то она удалится вместе с основной карточкой.

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

    • Настройки кнопок (таблица) - таблица с натройками кнопок диалога. Каждая кнопка имеет следующие настройки:

      workflowAction24

      • Алиас кнопки (значение типа string) - определяет уникальное (в рамках диалога) имя кнопки, которое может быть использовано в расширениях для ее идентификации.

      • Тип (значение из справочника типов кнопок) - определяет тип кнопки. Это влияет на то, где данная кнопка будет отображаться (в тулбаре, в нижнем тулбаре или в кнопках диалога).

      • Текст кнопки (значение типа string) - отобраамео имя кнопки, которое видит пользователь.

      • Иконка (значение типа string) - икнопка кнопки на верхнем или нижнем тулбаре. Не используется при отображении кнопки в нижней панели.

      • Отмена (флаг) - определяет, является ли данная кнопка - кнопкой отмены. При нажатии на такую кнопку, диалог просто закрывается, настройки переходов и сценарий кнопки не применяются.

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

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

      • Сценарий (значение типа string) - скрипт на языке C#, который выполняется при нажатии данной кнопки диалога.
        Имеет дополнительные параметры:

        • dialog - контекст обработки диалога, который имеет тип Tessa.Workflow.Actions.WorkflowDialogContext. Более подробно о данном объекте написано в описании действия Диалог.

    • Сценарий инициализации диалога (значение типа string) - скрипт на языке C#, который выполняется при инициализации диалога. Инициализация диалога происходит вместе с созданием задания.

    • Сценарий сохранения (значение типа string) - скрипт на языке C#, который выполняется при сохранении диалога. Сохранение диалога происходит как при обычном сохранении карточки диалога, так и по кнопке диалога (кроме кнопки с флагом Отмена).

    • Сценарий валидации (значение типа string) - скрипт на языке C#, который выполняется при валидации диалога. Происходит только при непосредственном завершении диалога по кнопке, у которой не стоят флаги Не завершает диалог и Отмена.
      Этот и описанные выше сценарии имеют дополнительные параметры:

      • dialog - контекст обработки диалога, который имеет тип Tessa.Workflow.Actions.WorkflowDialogContext. Более подробно о данном объекте написано в описании действия Диалог.

Типы обрабатываемых сигналов

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

Если задания нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление активного задания.

  • UpdateTask - производит обновление задания по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

5.8. Ожидание сигнала

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

Настраиваемые параметры

workflowAction7
  • Ожидаемый сигнал (значение из справочника типов сигналов или строка) - тип сигнала, при получении которого должен осуществляться переход по связям, указанным в Переходы, выполняемые после получения сигнала.

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

Типы обрабатываемых сигналов

Данное действие обрабатывает следующие типы сигналов:

  • Default - при получении сигнала данного типа действие создает подписку на сигнал с типом, указанным в поле Сигнал для подписки, очищает список связей для дальнейшей обработки и помечает узел как Активный.

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

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

5.9. Ознакомление

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

Настраиваемые параметры

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

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

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

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

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

  • Не отправлять заместителям (значение типа boolean, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей ознакомления учитывать замещения сотрудников.

Типы обрабатываемых сигналов

При обработке сигнала любого типа производит отправку ознакомлений по заданным в действии настройкам.

5.10. Подпроцесс

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

Настраиваемые параметры

workflowAction8
  • Подпроцесс (значение из справочника шаблонов бизнес-процессов) - шаблон процесса, по которому будет производиться отправка дочернего подпроцесса.

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

  • Настройки завершения подпроцесса (таблица) - настройки обработки сигналов, полученных от созданного подпроцесса.

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

    • Переход - (связь, исходящая из выбранного узла) - связь, по которой производится дальнейшая обработка сигнала при обработка данной строки таблицы.

    • Сценарий - (значение типа string) - скрипт, который вызывается при обработка данной строки таблицы.

Типы обрабатываемых сигналов

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

Если активного подпроцесса нет, то действие обрабатывает сигналы следующим образом:

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

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал сквозь без изменений.

Если активный подпроцесс есть, то действие обрабатывает сигналы следующим образом:

  • При получении любого сигнала - очищает список исходящих связей для дальнейшей обработки.

  • SubprocessControl - производит отправку сигнала в подпроцесс, указанный как параметр сигнала в поле SubprocessControlSignal.

  • SubprocessCompleted - производит обработку сигналов, переданных в параметре SubprocessEndSignals по таблице Настройки завершения подпроцесса. Если подпроцесс не был завершен, то действие продолжит ожидание получения сигналов от подпроцесса.

5.11. Создать карточку

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

Настраиваемые параметры

workflowAction9
  • Тип карточки (значение из справочника типов карточек или типов документов, может быть привязано к параметрам процесса) - тип карточки (или тип документа), который будет использоваться для создания новой карточки. Если для типа карточки используются типы документов, то необходимо выбрать тип документа. Нельзя заполнить одновременно с полем Шаблон карточки.

  • Шаблон карточки (значение из справочника шаблонов, может быть привязано к параметрам процесса) - шаблон процесса, который будет использоваться для создания новой карточки. Не может быть заполнено одновременно с полем Тип карточки.

  • Открыть карточку (значение типа boolean) - определяет, должна ли открыться новая карточка текущему сотруднику в клиенте. Не работает при асинхронной обработке запроса.

  • Сделать основной карточкой процесса (значение типа boolean) - определяет, нужно ли сделать новую карточку основной карточкой процесса.

  • Сценарий (значение типа string) - скрипт инициализации карточки. В нем следует производить заполнение полей новой карточки.
    Имеет дополнительные параметры:

    • newCard - представление строковых секций создаваемой карточки посредством dynamic-полей.

    • newCardTables - представление коллекционных секций создаваемой карточки посредством dynamic-полей.

    • newCardObject - объект создаваемой карточки.

    • newCardFileContainer - контейнер с файлами для новой карточки. Может использоваться для добавления файлов при создании новой карточки.

Типы обрабатываемых сигналов

При обработке сигнала типа Default производит создание карточки и обработку согласно настройкам действия. При получении любого другого сигнала не выполняет никаких действий и пропускает сигнал сквозь без изменений.

5.12. Уведомление

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

Настраиваемые параметры

workflowAction10
  • Получатели (список значений из справочника ролей, может быть привязан к параметрам процесса) - определяет список ролей, сотрудники которых должны получить уведомление. Если сотрудник принадлежит нескольким ролям, переданным в данном параметре, он получит только одно уведомление. Язык уведомления определяется в зависимости от указанного языка в карточке сотрудника. Расчет контекстных ролей осуществляется от основной карточки процесса.

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

  • Не отправлять заместителям (значение типа boolean, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

    • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

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

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

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

Типы обрабатываемых сигналов

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

5.13. Управление историей

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

Настраиваемые параметры

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

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

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

Типы обрабатываемых сигналов

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

5.14. Смена состояния

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

Настраиваемые параметры

workflowAction11
  • Состояние (значение из списка состояний) - состояние, которое устанавливается как новое состояние обрабатываемой процессом карточки.

Типы обрабатываемых сигналов

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

Важные особенности

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

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

Action.AffectMainCardVersionWhenStateChanged = false;

5.15. 'И'

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

Типы обрабатываемых сигналов

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

5.16. Условие

Данное действие выполняет переходы по связям в зависимости от настроенных в них условиях. Если условия не настроены, сигнал продолжит выполнение по всем исходящим связям. Одиночное действие.

Настраиваемые параметры

workflowAction18
  • Условия (таблица) - содержит условия для выполнения переходов по исходящим из узла связям.

    • Переход (связь, исходящая из текущего узла) - определяет связь, по которой должен осуществлятся переход, если условие выполнено.

    • Условие (значение типа string) - условие на языке C#. Если условие выполнено, то переход по данной связи осуществляется. Не может быть задано, если установлен флаг Выполнять, если другие условия не выполнены.

    • Выполнять, если другие условия не выполнены (значение типа boolean) - определяет улосвие перехода по связи в том случае, когда ни одно другое условие не выполнено.

    • Описание (значение типа string) - текстовое описание условия.

Типы обрабатываемых сигналов

Производит обработку при получении любого вида сигнала.

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

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

5.17. Таймер

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

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction12
  • Состояние (значение из списка состояний) - состояние, которое устанавливается как новое состояние обрабатываемой процессом карточки.

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

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

  • Выражение Cron (значение типа string, может быть привязано к параметрам процесса) - определяет период выполнения таймера с помощью cron-выражения.

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

  • Условие остановки таймера (значение типа string) - условие, которое проверяется при каждом выполнении таймера. Если условие возвращает true, то таймер останавливается.

Типы обрабатываемых сигналов

При получении сигнала с типом Default действие создает таймер (если он еще не был создан) и очищает список связей для дальнейшей обработки сигнала. При получении сигнала с типом TimerTick (отправляется системой при каждом завершении таймера) действие обновляет тип сигнала на Default и отправляет сигнал на дальнейшую обработку по всем исходящим связям. Если условие остановки таймера вернуло true или установлен флаг Запускать один раз, таймер останавливается. При получении сигнала с типом UpdateTimer действие обновляет время исполнения таймера в зависимости от параметров переданного сигнала. При получении сигнала с типом StopTimer действие производит остановку таймера.

5.18. Управление таймером

Данное действие позволяет управлять другими действиями типа Таймер. Управление производится путем изменения типа текущего сигнала и отправки его по исходящим связям (или следующим действия в узле). В зависимости от настроек действия, оно формирует сигнал на обновление таймера (тип сигнала UpdateTimer) или сигнал на остановку таймера (тип сигнала StopTimer).

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction13
  • Остановить таймер (значение типа boolean, может быть привязано к параметрам процесса) - флаг определяет, должно ли данное действие сформировать сигнал для остановки таймера.

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

  • Выражение Cron (значение типа string, может быть привязано к параметрам процесса) - определяет период выполнения таймера с помощью cron-выражения.

Типы обрабатываемых сигналов

При выполнении любого сигнала данное действие изменяет текущий сигнал в зависимости от настроек действия. Если требуется остановка таймера, действие меняет тип текущего сигнала на StopTimer. Если требуется обновление таймера, действие меняет тип текущего сигнала на UpdateTimer и устанавливает параметры сигнала для обновления таймера.

5.19. Управление заданием

Данное действие позволяет управлять другими действиями, отправляющими задания (действия Задание и Группа заданий). Управление производится путем изменения типа текущего сигнала и отправки его по исходящим связям (или следующим действия в узле). В зависимости от настроек действия, оно формирует сигнал на удаление заданий (тип сигнала DeleteTask), на обновление параметров задания (тип сигнала UpdateTask) или на завершение задания (тип сигнала CompleteTask). В зависимости от типа управления набор полей для действий различается.

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет новый текст задания. Доступно только при типе управления Изменить задание. При отсутствии значение изменение текста задания не производится.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет новый срок исполнения задания. Доступно только при типе управления Изменить задание. При отсутствии значение изменение срока завершения задания не производится.

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

  • Вариант завершения (значение из списка вариантов завершения, может быть привязано к параметрам процесса) - определяет вариант завершения, с которым будет завершено задание. Доступно только при типе управления Завершить задание.

Типы обрабатываемых сигналов

При выполнении любого сигнала данное действие изменяет текущий сигнал в зависимости от настроек действия. Если требуется удаление задания, действие меняет тип текущего сигнала на DeleteTask. Если требуется обновление параметров задания, действие меняет тип текущего сигнала на UpdateTask и устанавливает параметры сигнала для обновления параметров задания. Если требуется завершение задания, действие меняет тип текущего сигнала на CompleteTask и устанавливает параметры сигнала для завершения задания.

5.20. Управление группой заданий

Данное действие позволяет управлять другими действиями типа Группами заданий. Данное действие может произвести следующие манипуляции над действием Группа заданий:

  • Добавить новые роли в группу заданий

  • Приостановить или возобновить выполнение группы заданий

  • Отменить выполнение группы заданий

Данное действие меняет тип текущего сигнала на TaskGroupControl и устанавливает параметры изменения группы в сигнал.

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

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

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

  • Приостановить выполнение группы (значение типа boolean) - установка данного флага приостанавливает выполнение действия Группы заданий, в которое придет сигнал. Если группа заданий приостановлена, то новые задания группы не будут создаваться.

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

  • Вариант завершения отмены (значение из справочника вариантов завершений) - определяет вариант завершения, с которым будут отменены задания действия Группа заданий. Если не задан, задания при отмене группы будут удалены.

Типы обрабатываемых сигналов

При выполнении любого сигнала данное действие изменяет текущий сигнал на TaskGroupControl и устанавливает в параметры сигнала необходимые настройки по управлению действием Группа заданий.

5.21. Управление подпроцессом

Данное действие позволяет управлять действиями Подпроцесс. Управление производится путем изменения типа текущего сигнала и отправки его по исходящим связям (или следующим действия в узле). Данное действие формирует сигнал управление подпроцессом (тип сигнала SubprocessControl) и в параметры процесса передает отправляемый в подпроцесс сигнал.

Настраиваемые параметры

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

Типы обрабатываемых сигналов

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

5.22. Диалог

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

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

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

Настраиваемые параметры

workflowAction25
workflowAction26
  • Без отправки задания (значение типа bool) - данный флаг определяет, должно ли производиться создание диалога через задание или без задания. При указании данного флага настройки, не влияющие на отображение диалога, скрываются.

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

  • Вид (значение из справочника видов задания) - определяет вид задания диалога.

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

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

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания диалога. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

  • Отображаемое имя диалога (значение типа string) - имя диалога, которое видит пользователь при его открытии.

  • Тип карточки (обязательное, елси не задан Шаблон карточки, значение из справочника "Типы для диалогов") - определяет тип карточки, который будет использован в качестве типа карточки диалога. Тип карточки определяет структуры данных и UI полей диалога.

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

  • Текст кнопки в задании (значение типа string, может быть привязан к параметрам процесса) - текст кнопки в задании диалога, которая открывает диалог. Если не задано, используется стандартное имя кнопки "Открыть диалог".

  • Имя диалога (для расширений) (значение типа string) - имя диалога, которое используется для идентификации диалога в расширениях.

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

  • Время жизни диалога (значение из выпадающего списка) - определяет время жизни диалога. Может иметь одно из значений:

    • Запрос - диалог хранится на уровне запроса. При каждом новом открытии диалога он формируется заново.

    • Задание - диалог хранится в настройках задания. Состояние диалога будет сохраняться и изменяться, пока существует задание. Диалог перестает существовать, когда завершается (с удалением) задание, к которому он относится.

    • Карточка - диалог хранится как отдельная карточка в системе. Может быть использован в различных диалогах этого процесса при использовании настройки Алиас диалога. Если карточка диалога является карточкой сателлита, то она удалится вместе с основной карточкой.

  • Режим открытия диалога (значение из выпадающего списка) - определяет режим открытия диалога пользователю при открытии карточки. Может иметь одно из значений:

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

    • Не отображать автоматически - диалог открывается только по нажатию кнопки открытия диалога из задания диалога.

  • Сохранять файлы после завершения диалога (значение типа bool) - значение определяет, должны ли сохраняться файлы диалога после его завершения (удаления). Флаг влияет только на диалоги, для которых указано значение параметра Время жизни диалога как Задание.

  • Настройки кнопок (таблица) - таблица с натройками кнопок диалога. Каждая кнопка имеет следующие настройки:

    workflowAction24

    • Алиас кнопки (значение типа string) - определяет уникальное (в рамках диалога) имя кнопки, которое может быть использовано в расширениях для ее идентификации.

    • Тип (значение из справочника типов кнопок) - определяет тип кнопки. Это влияет на то, где данная кнопка будет отображаться (в тулбаре, в нижнем тулбаре или в кнопках диалога).

    • Текст кнопки (значение типа string) - отображаемое имя кнопки, которое видит пользователь.

    • Иконка (значение типа string) - иконка кнопки на верхнем или нижнем тулбаре. Не используется для кнопок типа "Нижняя диалоговая кнопка".

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

    • Не завершает диалог (значение типа bool) - определяет, должна ли данная кнопка завершать диалог (и задание, к которому относится данный диалог). При наличии данного флага, диалог (и его задание) не будут завершены при нажатии на данную кнопку.

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

    • Сценарий (значение типа string) - скрипт на языке C#, который выполняется при нажатии данной кнопки диалога. Имеет дополнительные параметры, аналогичные ниже описанным сценариям.

  • Сценарий инициализации диалога (значение типа string) - скрипт на языке C#, который выполняется при инициализации диалога. Инициализация диалога происходит вместе с созданием задания.

  • Сценарий сохранения (значение типа string) - скрипт на языке C#, который выполняется при сохранении диалога. Сохранение диалога происходит как при обычном сохранении карточки диалога, так и по кнопке диалога (кроме кнопки с флагом Отмена).

  • Сценарий валидации (значение типа string) - скрипт на языке C#, который выполняется при валидации диалога. Происходит только при непосредственном завершении диалога по кнопке, у которой не стоят флаги Не завершает диалог и Отмена.
    Этот и описанные выше сценарии имеют дополнительные параметры:

    • dialog - контекст обработки диалога, который имеет тип Tessa.Workflow.Actions.WorkflowDialogContext. Данный тип имеет следующие свойства и методы, который можно использовать в скриптах диалога:

      • ButtonName (значение типа string) - свойство определяет имя кнопки, которая была нажата. Имеет значение null в сценарии инициализации диалога или при закрытии диалога по кнопке закрытия окна.

      • GetCardObjectAsync (значение типа Tessa.Cards.Card) - метод возвращает объект карточки диалога.

      • GetCardAsync (значение типа dynamic) - метод возвращает представление строковых секций карточки диалога посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • GetCardTablesAsync (значение типа dynamic) - метод возвращает представление коллекционных секций карточки диалога посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

      • GetFileContentAsync (значение типа byte[]) - метод возвращает контент файла. Метод используется только для получения контента файла для диалогов, у которых параметр Время жизни диалога указан как Запрос. В качестве параметра необходимо использовать объект типа Tessa.Cards.CardFile, который получен из списка файлов карточки диалога (await GetCardObjectAsync()).Files

      • GetFileContainerAsync (значение типа Tessa.Cards.ICardFileContainer) - метод возвращает файловый контейнер для карточки диалога. Метод используется только для получения файлового контейнера для диалогов, у которых параметр Время жизни диалога указан как Задание или Карточка. Добавление новых файлов через данный файловый контейнер для диалога с временем жизни диалога указаным как Задание возможно только в сценарии инициализации диалога.

Типы обрабатываемых сигналов

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

Если диалога еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку диалога с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активный диалог, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Настройки кнопок.

Если по окончанию обработки сигнала в действии есть активный диалог, то данное действие помечает узел как Активный.

5.23. Регистрация

Данное действие предназначено для регистрации документа. При регистрации карточке выделяется постоянный номер и изменяется состояние на "Зарегистрирован". Если тип обрабатываемой карточки не указан в типовом решении, то данное действие вернет ошибку.

Настраиваемые параметры

Действие не имеет дополнительно настраиваемых параметров.

Типы обрабатываемых сигналов

При получении сигнала любого типа данное действие выполняет регистрацию документа.

5.24. Отмена регистрации

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

Настраиваемые параметры

Действие не имеет дополнительно настраиваемых параметров.

Типы обрабатываемых сигналов

При получении сигнала любого типа данное действие выполняет отмену регистрации документа.

6. Описание действий из группы "Маршруты"

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

6.1. Особенности действий

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

  • Для правильной работы действий из данной группы, в типе документа должен стоять флаг Использовать маршруты.

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

  • Для правильной инициализации параметров маршрута рекомендуется всегда включать действие "Инициализация маршрута" в процесс перед действиями из данной группы.

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

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

    Параметры действия "Управление историей" должны быть следующими:

    workflowAction39

    Для упрощения настройки, параметры однотипных действий "Управление историей" можно задавать через параметры процесса.

  • В строках элементов управления типа "Таблица", расположенных на форме редактора действия, отображается индикация при наличии параметров, значения которых отличны от значений по умолчанию. Если есть такое изменение, то в строке таблицы отображается символ "*".

    workflowAction39 1
  • Примеры процессов с использованием действий из группы "Маршруты" можно найти в разделе Примеры процессов с применением действий из группы "Маршруты".

6.2. Инициализация маршрута

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

Настраиваемые параметры

workflowAction32
  • Инициатор процесса (значение из справочника ролей, может быть привязано к параметрам процесса) - персональная роль (сотрудник) являющийся инициатором процесса. Указывается в одноимённом поле на вкладке "Маршрут" карточки документа. Если значение не задано, то инициатором процесса назначается текущий пользователь.

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

Типы обрабатываемых сигналов

  • Default - производит инициализацию маршрута с учётом всех настроек действия, после чего пропускает сигнал насквозь без изменений.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

6.3. Согласование

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

Действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

Действие создаёт и обрабатывает завершение следующих типов заданий:

  • Согласование (KrApprove);

  • Дополнительное согласование (KrAdditionalApproval);

  • Комментирование (KrRequestComment);

  • Доработка (KrEditInterject).

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

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

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

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

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

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

      Обратите внимание, что согласующий, для которого указаны дополнительные согласующие, отмечается в списке специальным символом (+) перед названием роли.
      Если при выполнении действия итоговый список исполнителей пуст, то действие завершится с вариантов завершения "Согласовано" и состояние документа изменится на "Согласовано", если выставлен флаг Изменять состояние при завершении.
  • Добавить роль "Вычисляемые исполнители" - добавляет роль "Вычисляемые исполнители" в список согласующих. На это место будут подставлены согласующие вычисленные с помощью скрипта задаваемого в поле SQL исполнители. По умолчанию вычисляемые исполнители подставляется в конец списка согласующих.

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

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

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

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

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

    • Данное поле позволяет задавать значение результата, только для заданий типа "Согласование (KrApprove)". Для задания результата других типов заданий следует использовать поле "Результат" расположенное в настройках обработки заданий при их завершении по вариантам завершения (см. Варианты завершения).

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

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания согласования. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

  • Вкладка "Основные настройки"

    • Параллельная отправка заданий (значение типа bool, может быть привязано к параметрам процесса) – флаг выставляется в случае, если текущее действие согласования должно параллельно отправлять задания согласования (актуально, если в поле "Согласующие" указано более одного согласующего).

    • Рекомендательное согласование (значение типа bool, может быть привязано к параметрам процесса) - вариант завершения задания согласования "Не согласовать" не возвращает процесс на доработку. При установке флажка проставляется специальный вид задания, однако можно указывать собственный.

  • Вкладка "Дополнительно"

    workflowAction29
    • Отключить автоматическое согласование (значение типа bool, может быть привязано к параметрам процесса) - отключить для данного действия автоматическое завершение заданий согласования (см. Автоматическое согласование).

    • Вернуть после согласования (значение типа bool, может быть привязано к параметрам процесса) – вернуть документ на доработку Инициатору при согласовании всеми текущими согласующими.

    • Ожидать решения всех согласующих (значение типа bool, может быть привязано к параметрам процесса) – при выставленном флаге процесс согласования будет продолжен, несмотря на не согласование хотя бы одним из согласующих. Данный флаг не влияет на конечный результат действия, т.е. при не согласовании, хотя бы одним из согласующих, действие завершится с вариантом завершения "Не согласовано".

    • Изменять состояние при старте (значение типа bool, может быть привязано к параметрам процесса) - если флажок установлен (по умолчанию), то при запуске действия состояние карточки устанавливается в "На согласовании".

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

    • Настройки прав доступа для исполнителей

      • Редактировать карточку – дать права доступа на редактирование карточки согласующим;

      • Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для согласующих.

  • SQL исполнители (значение типа string, может быть привязано к параметрам процесса) - скрипт на языке SQL, который используется для вычисления роли "Вычисляемые исполнители". Исполнители подставляются в том же порядке, в котором они возвращаются запросом.

    Скрипт должен возвращать два столбца:

    1. Идентификатор роли;

    2. Имя роли.

  • Сценарий инициализации задания (значение типа string) - скрипт на языке C#, который выполняется при инициализации задания согласования. Инициализация задания происходит вместе с созданием задания.

    Имеет дополнительные параметры:

    • task (значение типа Tessa.Cards.CardTask) - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

    • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

  • Уведомление о задании

    Блок настроек уведомления о задании согласования.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (значение типа Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Доработка автором

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

    • Роль (значение из справочника ролей, может быть привязано к параметрам процесса) – роль на которую будет отправлено задание доработки автором. Если не задано, то используется автор задания согласования сохранённый в параметрах действия (константа Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine.WorkflowConstants.NamesKeys.EditInterjectAuthorID). Можно указать как конкретных сотрудников, так и роли.

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

    • Вид (значение из справочника видов задания, может быть привязано к параметрам процесса) - определяет вид задания доработки автором.

    • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания доработки автором. Поддерживает использование плейсхолдеров.

    • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания доработки автором в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

    • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания доработки автором. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

    • Сценарий инициализации задания (значение типа string) - скрипт на языке C#, который выполняется при инициализации задания доработки автором. Инициализация задания происходит вместе с созданием задания.

      Имеет дополнительные параметры:

      • task (значение типа Tessa.Cards.CardTask) - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

      • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

    • Уведомление о задании

      Блок настроек уведомления о задании доработки автором.

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

      • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

        Имеет дополнительные параметры:

        • email (значение типа Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Варианты завершения (таблица) - содержит настройки обработки заданий при их завершении по вариантам завершения. Если таблица пуста, то при открытии редактора действия она заполняется вариантами завершения обрабатываемых данным действием типов заданий. Информация о составе вариантов завершения считывается из метаданных типов заданий, обрабатываемых действием.

    workflowAction30

    • Тип задания (значение из справочника типов заданий) - определяет, при завершении заданий какого типа задания должна производиться обработка из данной строки таблицы.

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

    • Результат (значение типа string, может быть привязано к параметрам процесса) - определяет результат, который будет записан в историю заданий при завершении заданий с данным вариантом завершения. Поддерживает использование плейсхолдеров. Если данный результат не задан, то будет использоваться результат из основных настроек.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении задания с данным вариантом завершения.

      Имеет дополнительные параметры:

      • task (значение типа Tessa.Cards.CardTask) - объект задания, которое завершается.

      • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

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

    • Получатели (список ролей) - список получателей уведомления.

    • Отправить исполнителю (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли к списку получателей добавить исполнителя задания. Если задание взято в работу, то к получателям добавится сотрудник, взявший задание в работу. Если задание не взято в работу, то добавится роль, на которую отправлено задание.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

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

    workflowAction31

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

    • Переходы (список связей, исходящих из текущего узла) - определяет список связей, по которым должен быть отправлен сигнал после завершения обработки действия с данным вариантом завершения.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении действия с данным вариантом завершения.

      Имеет дополнительные параметры:

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfoBase) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

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

    • Получатели (список ролей) - список получателей уведомления.

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания согласования с учётом всех настроек действия и очищает список связей для дальнейшей обработки. Если исполнителей нет, то действие завершается с вариантом завершения "Согласовано".

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление всех активных заданий.

  • UpdateTask - производит обновление задания по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

6.4. Подписание

Данное действие предназначено для отправки одного или нескольких заданий подписания. Действие аналогично по смыслу этапу "Подписание" описанному в Руководстве администратора.

Действие полностью аналогично согласованию, за исключением:

  • В заданиях кнопки называются "Подписать" и "Отказать" вместо "Согласовать" и "Не согласовать";

  • Состояние карточки при входе в этап устанавливается "На подписании";

  • При подписании устанавливается состояние "Подписано";

  • При не подписании "Отказано";

  • Варианты завершения называются "Подписано" и "Отказано" вместо "Согласовано" и "Не согласовано" соответственно;

  • Отсутствует возможность задания доп. подписантов;

  • Отсутствует возможность рекомендательного подписания.

6.5. Доработка

Данное действие предназначено для доработки документа и отправки одного задания доработки, а также обрабатывает завершение и другие события, отправленные от отправленного задания. Действие аналогично по смыслу этапу "Доработка" описанному в Руководстве администратора.

Действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

Действие создаёт и обрабатывает завершение задания типа "Доработка (KrEdit)".

После завершения задания доработки отправляется сигнал на все исходящие связи.

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction33
  • Роль (значение из справочника ролей, может быть привязано к параметрам процесса) – исполнитель задания. Обычно это роль "Инициатор согласования", но можно указывать любую роль в системе. Можно указать как конкретных сотрудников, так и роли.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Вид (значение из справочника видов задания, может быть привязано к параметрам процесса) - определяет вид задания.

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

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

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

    Текущий цикл доступен в параметрах процесса (константа Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine.WorkflowConstants.NamesKeys.ProcessCycle). Так же есть вспомогательные методы предназначенные для упрощения взаимодействия с данным значением: WorkflowHelper.GetProcessCycle, WorkflowHelper.SetProcessCycle, WorkflowHelper.ProcessCycleIncrement. Они расположены в классе Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine.WorkflowHelper.

  • Изменять состояние (значение типа bool, может быть привязано к параметрам процесса) - если флажок установлен (по умолчанию), то при входе в действе состояние карточки меняется на "На доработке".

  • Сценарий инициализации задания (значение типа string) - скрипт на языке C#, который выполняется при инициализации задания доработки. Инициализация задания происходит вместе с созданием задания.

    Имеет дополнительные параметры:

    • task (значение типа Tessa.Cards.CardTask) - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

    • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

    • Сценарий завершения задания (значение типа string) - скрипт, который выполняется при завершении задания.

      Имеет дополнительные параметры:

      • task (значение типа Tessa.Cards.CardTask) - объект задания, которое завершается.

      • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

  • Уведомление о задании

    Блок настроек уведомления о задании доработки.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (значение типа Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Уведомление о завершении задания

    Блок настроек уведомления о задании задания доработки.

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

    • Получатели (список ролей) - список получателей уведомления.

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания доработки с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление всех активных заданий.

  • UpdateTask - производит обновление задания по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

6.6. Задание регистрации

Данное действие предназначено для регистрации документа. Действие аналогично по смыслу этапу "Регистрация" описанному в Руководстве администратора.

Действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

Действие создаёт и обрабатывает завершение задания типа "Регистрация документа (KrRegistration)".

После завершения задания регистрации отправляется сигнал на все исходящие связи.

Если не требуется выполнять регистрацию документа с отправкой задания, то можно использовать действие "Регистрация".

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction34
  • Роль (значение из справочника ролей, может быть привязано к параметрам процесса) – исполнитель задания. Можно указать как конкретных сотрудников, так и роли.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Вид (значение из справочника видов задания, может быть привязано к параметрам процесса) - определяет вид задания.

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

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

  • Настройки прав доступа для исполнителей

    • Редактировать карточку – дать права доступа на редактирование карточки регистраторам;

    • Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для регистраторов.

  • Сценарий инициализации задания (значение типа string) - скрипт на языке C#, который выполняется при инициализации задания регистрации. Инициализация задания происходит вместе с созданием задания.

    Имеет дополнительные параметры:

    • task (значение типа Tessa.Cards.CardTask) - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

    • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

  • Уведомление о задании

    Блок настроек уведомления о задании регистрации.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (значение типа Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Варианты завершения (таблица) - содержит настройки обработки заданий при их завершении по вариантам завершения. Если таблица пуста, то при открытии редактора действия она заполняется вариантами завершения обрабатываемых данным действием типов заданий. Информация о составе вариантов завершения считывается из метаданных обрабатываемых действием типов заданий.

    workflowAction35

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

    • Результат (значение типа string, может быть привязано к параметрам процесса) - определяет результат, который будет записан в историю заданий при завершении заданий с данным вариантом завершения. Поддерживает использование плейсхолдеров. Если данный результат не задан, то будет использоваться результат из основных настроек.

    • Переходы (список связей, исходящих из текущего узла) - определяет список связей, по которым должен быть отправлен сигнал после завершения обработки задания с данным вариантом завершения.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении задания с данным вариантом завершения.

      Имеет дополнительные параметры:

      • task (значение типа Tessa.Cards.CardTask) - объект задания, которое завершается.

      • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

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

    • Получатели (список ролей) - список получателей уведомления.

    • Отправить исполнителю (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли к списку получателей добавить исполнителя задания. Если задание взято в работу, то к получателям добавится сотрудник, взявший задание в работу. Если задание не взято в работу, то добавится роль, на которую отправлено задание.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания регистрации с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление всех активных заданий.

  • UpdateTask - производит обновление задания по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

6.7. Исполнение задачи

Данное действие предназначено для создания типового процесса обработки задач (WfResolution). Действие аналогично по смыслу этапу "Задача" описанному в Руководстве администратора.

Действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • DeleteTask

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction36
  • Исполнители (значение из справочника ролей, может быть привязано к параметрам процесса) – исполнители задания. Можно указать как конкретных сотрудников, так и роли.

  • Добавить роль "Вычисляемые исполнители" - добавляет роль "Вычисляемые исполнители" в список согласующих. На это место будут подставлены согласующие вычисленные с помощью скрипта задаваемого в поле SQL исполнители. По умолчанию вычисляемые исполнители подставляется в конец списка согласующих.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Вид (значение из справочника видов задания, может быть привязано к параметрам процесса) - определяет вид задания.

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

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

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

  • SQL исполнители (значение типа string, может быть привязано к параметрам процесса) - скрипт на языке SQL, который используется для вычисления роли "Вычисляемые исполнители". Исполнители подставляются в том же порядке, в котором они возвращаются запросом.

    Скрипт должен возвращать два столбца:

    1. Идентификатор роли;

    2. Имя роли.

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания доработки с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет завершение задания. Сигнал должен содержать идентификатор первого задания бизнес-процесса (WfResolution) в параметрах сигнала по ключу Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine.WorkflowConstants.NamesKeys.CompletedTaskRowID.

  • DeleteTask - производит удаление всех активных заданий.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

6.8. Настраиваемое задание

Данное действие предназначено для создания и отправки настраиваемого задания. Действие аналогично по смыслу этапу "Настраиваемое задание" описанному в Руководстве администратора.

Действие создает подписку на созданное задание, а также создает подписки на сигналы:

  • Всегда:

    • CompleteTask

    • UpdateTask

    • DeleteTask

  • При наличии обработчиков соответствующих событий:

    • ProgressTask

    • ReinstateTask

    • PostponeTask

    • ReturnFromPostponeTask

Действие создаёт и обрабатывает завершение задания типа "Задание (KrUniversalTask)".

При выполнении данного действия для процесса отключается неперсистентный режим хранения.

Настраиваемые параметры

workflowAction37
  • Роль (значение из справочника ролей, может быть привязано к параметрам процесса) – исполнитель задания. Можно указать как конкретных сотрудников, так и роли.

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

  • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

  • Вид (значение из справочника видов задания, может быть привязано к параметрам процесса) - определяет вид задания.

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

  • Длительность, рабочие дни (значение типа double, может быть привязано к параметрам процесса) - определяет срок выполнения задания в рабочих днях. Не может быть заполнено одновременно с полем Срок завершения.

  • Срок завершения (значение типа DateTime, может быть привязано к параметрам процесса) - определяет срок выполнения задания. Не может быть заполнено одновременно с полем Длительность, рабочие дни.

  • Настройки прав доступа для исполнителей

    • Редактировать карточку – дать права доступа на редактирование карточки регистраторам;

    • Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для регистраторов.

  • Сценарий инициализации задания (значение типа string) - скрипт на языке C#, который выполняется при инициализации задания регистрации. Инициализация задания происходит вместе с созданием задания.

    Имеет дополнительные параметры:

    • task (значение типа Tessa.Cards.CardTask) - объект задания, которое отправляется. Уже заполнено значениями из параметров действия.

    • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

    • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

  • Уведомление о задании

    Блок настроек уведомления о задании регистрации.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (значение типа Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

  • Варианты завершения (таблица) - содержит настройки обработки заданий при их завершении по вариантам завершения.

    workflowAction38

    • Идентификатор варианта завершения (значение типа Guid, доступно только для чтения) - идентификатор варианта завершения.

    • Вариант завершения (значение типа string) - отображаемое имя настраиваемого варианта завершения задания.

    • Текст задания (значение типа string, может быть привязано к параметрам процесса) - определяет текст задания. Поддерживает использование плейсхолдеров.

    • Показывать поле комментарий - с вариантом завершения связано текстовое поле "Комментарий", которое может заполнить пользователь. Обязательность данного поля система не проверяет.

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

      if (string.IsNullOrWhiteSpace((string)taskCard.KrTask.Comment))
      {
        this.ValidationResult.AddError(this, "Пожалуйста, укажите комментарий!");
      }
    • Дополнительный вариант завершения - если флажок установлен, то вариант завершения в задании будет доступен в выпадающем списке "Еще".

    • Переходы (список связей, исходящих из текущего узла) - определяет список связей, по которым должен быть отправлен сигнал после завершения обработки задания с данным вариантом завершения.

    • Сценарий (значение типа string) - скрипт, который выполняется при завершении задания с данным вариантом завершения.

      Имеет дополнительные параметры:

      • task (значение типа Tessa.Cards.CardTask) - объект задания, которое завершается.

      • taskCard (значение типа dynamic) - представление строковых секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicEntries).

      • taskCardTables (значение типа dynamic) - представление табличных секций карточки задания посредством dynamic-полей (Tessa.Cards.CardTask.Card.DynamicTables).

      • notificationInfo (тип Tessa.Workflow.Actions.WorkflowTaskNotificationInfo) - объект с настройками уведомления, указанными в настройках данного варианта завершения. В сценарии можно переопределить данные настройки, изменив свойства данного объекта.

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

    • Получатели (список ролей) - список получателей уведомления.

    • Отправить исполнителю (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли к списку получателей добавить исполнителя задания. Если задание взято в работу, то к получателям добавится сотрудник, взявший задание в работу. Если задание не взято в работу, то добавится роль, на которую отправлено задание.

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

    • Не отправлять заместителям (значение типа bool, может быть привязано к параметрам процесса) - определяет, нужно ли при формировании списка получателей уведомления учитывать замещения сотрудников.

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

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

      Имеет дополнительные параметры:

      • email (тип Tessa.Notices.NotificationEmail) - объект уведомления, который можно изменить перед его отправкой.

Типы обрабатываемых сигналов

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

Если заданий еще нет, действие обрабатывает следующие сигналы:

  • Default - производит отправку задания регистрации с учётом всех настроек действия и очищает список связей для дальнейшей обработки.

  • Любой другой сигнал - не выполняет никаких действий и пропускает сигнал на сквозь без изменений.

Если есть активное задание, то действие обрабатывает сигналы следующий образом:

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

  • CompleteTask - выполняет обработку по таблице Варианты завершения.

  • DeleteTask - производит удаление всех активных заданий.

  • UpdateTask - производит обновление задания по указанным в сигнале параметрам.

  • ProgressTask - выполняет обработку по таблице Обрабатываемые события.

  • ReinstateTask - выполняет обработку по таблице Обрабатываемые события.

  • PostponeTask - выполняет обработку по таблице Обрабатываемые события.

  • ReturnFromPostponeTask - выполняет обработку по таблице Обрабатываемые события.

Если по окончанию обработки сигнала в действии есть активное задание, то данное действие помечает узел как Активный.

7. API скриптов

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

Доступные свойства:

  • Сontext - контекст выполнения в обработчике WorkflowEngine.

    // Меняем у экземпляра процесса имя
    Context.ProcessInstance.Name = "New name for process";
  • DbScope - объект, обеспечивающий доступ к базам данных.

    // Создаем новое подключение к базе по другому connectionString
    using (dbScope.CreateNew("SomeConnectionString))
    {
        ...
    }
  • Container - IoC-контейнер для получения любых необходимых зависимостей в рамках системы.

    // Резолвим объект из Unity-контекнера
    Container.Resolve<IRoleRepository>();
  • ValidationResult - результат валидации. В него можно записывать данные, которые будут отображены пользователю после выполнения обработки.

    // Добавляем в результат валидации ответ обработки
    ValidationResult.AddInfo(this, "Some process answer");
  • Session - сессия текущего пользователя.

    // Получаем из сессии имя текущего сотрудника
    var userName = Session.User.Name;
  • StoreCardObject - объект карточки, в контексте сохранения которой происходит обработка процесса.

    // Получаем задание из карточки, переданной из клиента, которое было завершено
    StoreCardObject.Tasks.FirstOrDefault(x => x.Action == CardTaskAction.Completed);
  • CardObject - объект карточки, в контексте которой происходит выполнение процесса. Данный объект содержит экземпляр карточки после основного сохранения и будет сохранен по окончанию обработки в случае, если в нем есть изменения. Данное свойство устарело, рекомендуется использовать метод GetCardObjectAsync.

    // Проверяем, есть ли в карточке файлы
    if (CardObject.Files.Count > 0)
    {
        ...
    }
  • CardID - идентификатор карточки, в контексте которой происходит выполнение процесса.

  • Card - представление строковых секций карточки посредством dynamic-полей. Данное свойство устарело, рекомендуется использовать метод GetCardAsync.

    // Устанавливаем в секцию DocumentCommonInfo в поле Amount значение 10000
    Card.DocumentCommonInfo.Amount = 10000;
  • Tables - представление коллекционных секций карточки посредством dynamic-полей. Данное свойство устарело, рекомендуется использовать метод GetTablesAsync.

    // Возвращает список строк в секции OutgoingRefDocs
    Tables.OutgoingRefDocs.Count
  • Tasks - список текущих активных заданий в контексте обработки. Список никогда не равен nullю Через данное свойство списком можно также управлять.

    // Устанавливаем во все новые задания значение в определенное поле
    foreach(var task in Tasks)
    {
    	if(task.State == CardRowState.Inserted)
    	{
    		task.Card.Sections["MagicSection"].RawFields["MagicNumber"] = 42;
    	}
    }
  • Task - возвращает первое задание из списка текущий активных заданий. Возвращает null, если список пустой. Может использоваться, например, для получения данных завершаемого пользователем задания, т.к. это задание добавляется в Tasks первым.

    // Записываем в сигнал комментарий завершаемого задания
    if(Task != null)
    {
    	Signal.Comment = Task.Section["KrTask"].RawFields.TryGet<string>("Comment");
    }
  • FileContainer - контейнер с файлами карточки, в контексте которой происходит работа с процессом. Данное свойство устарело, рекомендуется использовать метод GetFileContainerAsync.

    // Добавляем файл в карточку с именем Test.txt и текстом "Новый файл"
    FileContainer
        .BuildFile("Test.txt")
        .SetContentText("Новый файл", System.Text.Encoding.Default)
        .AddWithNotification();
  • Action - представление параметров текущего действия посредством dynamic-полей.

    // Устанавливаем в текущем действии в параметр SomeParam строковое значение "Value"
    Action.SomeParam = "Value";
  • ActionObject - объект текущего действия. Имеет тип WorkflowActionStateStorage.

    // записываем в переменную идетификатор текущего действия
    var actionID = ActionObject.ID;
  • ActionHash - параметры текущего действия в виде структуры IDictionary<string, object>.

    // Устанавливаем в текущем действии в параметр SomeParam строковое значение "Value"
    ActionHash["SomeParam"] = "Value";
  • Node - представление параметров текущего экземпляра узла посредством dynamic-полей.

    // Устанавливаем в текущем узле в параметр SomeParam строковое значение "Value"
    Node.SomeParam = "Value";
  • NodeObject - объект текущего экземпляра узла. Имеет тип WorkflowNodeStateStorage.

    // записываем в переменную идетификатор текущего узла
    var nodeID = NodeObject.ID;
  • NodeHash - параметры текущего экземпляра узла в виде структуры IDictionary<string, object>.

    // Устанавливаем в текущем узле в параметр SomeParam строковое значение "Value"
    NodeHash["SomeParam"] = "Value";
  • Process - представление параметров текущего экземпляра процесса посредством dynamic-полей.

    // Устанавливаем в текущем процессе в параметр SomeParam строковое значение "Value"
    Process.SomeParam = "Value";
  • ProcessObject - объект текущего экземпляра процесса. Имеет тип WorkflowProcessStateStorage.

    // записываем в переменную идетификатор текущего процесса
    var processID = ProcessObject.ID;
  • ProcessHash - параметры текущего экземпляра процесса в виде структуры IDictionary<string, object>.

    // Устанавливаем в текущем процессе в параметр SomeParam строковое значение "Value"
    ProcessHash["SomeParam"] = "Value";
  • Signal - представление параметров текущего сигнала посредством dynamic-полей.

    // Устанавливаем в текущем сигнале в параметр SomeParam строковое значение "Value"
    Signal.SomeParam = "Value";
  • SignalObject - объект сигнала, который в данный момент обрабатывается.

    // Устанавливаем в текущем сигнале тип сигнала CustomSignalType
    SignalObject.Type = "CustomSignalType";
  • SignalHash - параметры текущего сигнала в виде структуры IDictionary<string, object>.

    // Устанавливаем в текущем сигнале в параметр SomeParam строковое значение "Value"
    SignalHash["SomeParam"] = "Value";
  • Cancel - значение типа bool, которое определяет, нужно ли остановить обработку текущего сигнала.

    // Отменяет обработку сигнала
    Cancel = true;

Доступные методы:

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

    // Проверяем, есть ли в карточке файлы
    var cardObj = await this.GetCardObjectAsync();
    if (cardObj.Files.Count > 0)
    {
        ...
    }
  • GetCardAsync - метод возвращает представление строковых секций карточки посредством dynamic-полей.

    // Устанавливаем в секцию DocumentCommonInfo в поле Amount значение 10000
    (await GetCardAsync()).DocumentCommonInfo.Amount = 10000;
  • GetTablesAsync - метод возвращает представление коллекционных секций карточки посредством dynamic-полей.

    // Возвращает список строк в секции OutgoingRefDocs
    (await GetTablesAsync()).OutgoingRefDocs.Count
  • GetFileContainerAsync - метод возвращает контейнер с файлами карточки, в контексте которой происходит работа с процессом.

    // Добавляем файл в карточку с именем Test.txt и текстом "Новый файл"
    (await GetFileContainerAsync())
        .BuildFile("Test.txt")
        .SetContentText("Новый файл", System.Text.Encoding.Default)
        .AddWithNotification();
  • SetMainCard(Guid cardID) - метод для установки основной карточки процесса по ее ID.

    var amount = Card.DocumentCommonInfo.Amount; // вернет сумму из текущей карточки, к которой относится процесс
    SetMainCard(someCardID); // устанавливаем новую карточку как текущую
    var amount2 = Card.DocumentCommonInfo.Amount; // вернет сумму из другой карточки с идентификатором someCardID, к которой теперь относится процесс
  • GetTask(Guid taskID) - метод для получения объекта задания по его ID из карточки. Если задание не найдено, метод вернет null.

    // Получаем родительское задание для текущего задания в контексте обработки, если для него есть родительское задание
    if (Task?.ParentRowID.HasValue)
    {
    	var parentTask = GetTask(Task.ParentRowID);
    }
  • AddInfo(string text) - метод для добавления сообщения в ValidationResult с укровнем Info.

    // Добавляем сообщение в ValidationResult
    AddInfo("Text to user");
  • AddInfo(string format, params object[] args) - метод для добавления сообщения с форматом в ValidationResult с укровнем Info.

  • AddWarning(string text) - метод для добавления сообщения в ValidationResult с укровнем Warning.

  • AddWarning(string format, params object[] args) - метод для добавления сообщения с форматом в ValidationResult с укровнем Warning.

  • AddError(string text) - метод для добавления сообщения в ValidationResult с уровнем Error.

  • AddError(string format, params object[] args) - метод для добавления сообщения с форматом в ValidationResult с укровнем Error.

7.1. API скриптов в условиях для тайлов

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

Доступные свойства:

  • DbScope - объект, обеспечивающий доступ к базам данных.

  • Container - IoC-контейнер для получения любых необходимых зависимостей в рамках системы.

  • Session - сессия текущего пользователя.

  • CardObject - объект карточки, в контексте которой происходит выполнение нажатия кнопки. Не задан для тайлов запуска глобального процесса.

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

  • Card - представление строковых секций карточки посредством dynamic-полей. Не задан для тайлов запуска глобального процесса.

  • Tables - представление коллекционных секций карточки посредством dynamic-полей. Не задан для тайлов запуска глобального процесса.

8. Примеры

В данном разделе описаны следующие примеры:

8.1. Создание процесса

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

Реализуемый в данном примере процесс можно настроить более простым способом, используя действия из группы "Маршруты". Пример их использования см. в разделе Примеры процессов с применением действий из группы "Маршруты".

8.1.1. Этап 1. Создание отправки задания согласования с доработкой

В данном примере мы рассмотрим:

  • Создание и настройка карточки шаблона процесса

  • Создание кнопки для запуска процесса

  • Создание простого процесса

  • Настройку действий старта процесса, задания, завершения процесса

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

  • Задаем имя шаблона (например, "Согласование (пример)").

  • Задаем группу, если нужно (удобно использовать для разделения шаблонов по логике использования)

  • Флаги Запуск из карточки и Можно запускать несколько экземпляров оставляем как есть.

  • В Типы карточек добавляем тип Договорной документ.

  • В расширения проверки состояния для тайлов добавляем Проверка состояния и Проверка контекстных ролей.

  • Доступ на редактирование можно оставить как есть, доступ на чтение экземпляров можно установить Все сотрудники.

  • Добавляем новую кнопку, настраиваем ее по примеру
    workflowExample1

  • Сохраняем карточку шаблона. В итоге получаем примерно следующую картину.
    workflowExample2

Вы можете проверить наличие кнопки на боковой панели карточки договора.

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

Добавляем на наш макет следующие действия:

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

  • Конец процесса - будет использоваться для определения места конца процесса.

  • Два действия Задание - одно будет использоваться для задания Согласования, а второе для задания Доработки.

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

Располагаем созданные узлы на макете, даем им соответствующие заголовки:

workflowExample3

Следующим шагом будет создание связей между узлами. Добавим связи между:

  • Узлом запуска процесса и узлом согласования.

  • Узлом согласования и концом процесса

  • Узлом согласования и доработкой (две связи, в обоих направлениях)

  • Узлом доработки и концом процесса

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

workflowExample4

Далее переходим к настройке действий.

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

Действие Конец процесса также дополнительно настраивать не нужно.

Действие Согласование мы настроим следующим образом:

  • Тип задания "Согласование" (тип из примеров по ссылке), чтобы оно отправляло задание с данным типом.

  • Укажем роль Регистраторы, чтобы задание приходило на данную роль

  • Автора задания не будем заполнять, по умолчанию в качестве автора пропишется текущий сотрудник.

  • Укажем текст задания. В данном поле можно использовать плейсхолдеры, чтобы использовать данные карточки (например, номер договора).

  • Укажем длительность задания - 3 дня.

  • В результат записывается то, что попадает в поле Результат в истории заданий. Также поддерживает плейсхолдеры.

  • Настраиваем варианты завершения, чтобы при завершении с вариантом Согласовать мы переходили бы в узел Конец процесса, а при Не согласовать - на доработку.

В итоге мы получаем следующее настроенное действие:

workflowExample5

Дальше переходим к настройке действия Доработка:

  • Укажем в данном действии Тип задания - На доработку.

  • Роль - Автор документа. Мы хотим, чтобы задание на доработку отправлялось автору документа.

  • Укажем текст задания, результат и длительность задания.

  • Настроим варианты завершения, чтобы при завершении задания с вариантом Начать новый цикл мы возвращались на согласование, а при варианте Отозвать - мы переходили в конец процесса.

workflowExample6

В итоге получаем готовый простенький процесс.

8.1.2. Этап 2. Последовательное согласование, смена состояния, отправка уведомлений, отзыв с согласования.

В данном примере мы рассмотрим:

  • Управление версиями процесса

  • Кнопки для управления процессом

  • Действия Смена состояния, Уведомление, Управление заданием.

  • Настройка списка сигналов для обработки

  • Настройка режима перехода связи

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

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

workflowExample7

После создания новой версии, заблокируем ее на редактирование и откроем редактор.

В первую очередь мы добавим еще одно согласование после первого. Это можно сделать несколькими способами:

  1. Можно просто добавить новое действие типа Задание на связь между узлами Согласование и Конец процесса

  2. Можно копировать узел Согласование и вставить его на ту же связь, что и в первом варианте. Этот вариант позволит перенести ряд настроек действия Задание со скопированного узла.

Из нового узла добавим связь в узел Доработка. Процесс примет примерно следующий вид:

workflowExample8

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

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

workflowExample9

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

workflowExample10

Теперь добавим отправку уведомлений при получении задания на доработку. Это можно сделать двумя способами:

  1. Можно добавить новый узел с действием Уведомление перед узлом Доработка, чтобы при отправке на доработку сначала выполнялся узел с уведомлением, а за ним уже узел с заданием на доработку. workflowExample11

  2. Можно добавить новое действие непосредственно в узел Доработка. Но при таком варианте необходимо в список обрабатываемых сигналов для действия Уведомления добавить тип сигнала Default, чтобы отправка уведомления производилась только при отправке задания. workflowExample12

Настроим действие Уведомление. Укажем в качестве роли получателя роль, которая указана как исполнитель задания. В качестве уведомления можно указать из справочника уведомлений, или настроить кастомное уведомление.

workflowExample13

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

Откроем карточку шаблона и добавим новую кнопку. Настроим ее следующим образом:

workflowExample14

В качестве типа сигнала введем кастомный тип сигнала Revoke (его можно вводить вручную или добавить в перечисление WorkflowSignalTypes в схеме в рамках проекта).

Теперь доработаем сам процесс. Добавим новый узел Отзыв с действием Управление заданием, из которого мы будем отправлять сигнал с отзывом задания в узлы согласования. В настройки узла укажем в поле Подписки узла по умолчанию тип сигнала Revoke. В само действие мы настроим так, чтобы оно завершало задание с вариантом Отозвано.

workflowExample15

Из узла Отзыв создадим связи в узлы согласования. Для новых связей в настройках укажем в поле Режим перехода значение Никогда не создавать экземпляр узла. Это значит, что обработка произойдет только тогда, когда узел активен (т.е. есть задание на согласование). Также добавим действие Смена состояния в узел Отзыв или отдельный узел, и соединим связями так, чтобы из узла Отзыв мы также переходили в узел Конец процесса.

workflowExample16

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

8.1.3. Этап 3. Параллельное согласование, условие перехода, скрипты.

В данном примере мы рассмотрим:

  • Параметры процесса

  • Параллельная отправка заданий

  • Условие переходов

  • Действия Условие, И, Сценарий

  • Отмена выполнения действия

  • Написание простых скриптов

Внесем следующие изменения в процесс:

  • Добавим действие типа Сценарий в новый узел, и назовем его Инициализация.

  • Добавим новый узел согласования.

  • Добавим связь из узла Отзыв в новый узел согласования. Укажем новой связи настройку перехода Никогда не создавать экземпляр узла.

  • Все связи, что раньше переходили в первый узел согласования (кроме связи из узла Отзыв), перенесем на узел Инициализация.
    workflowExample17

  • Добавим связи из узла Инициализация в первый узел согласования и новый узел согласования.
    workflowExample18

  • Добавим узлы с типами Условие и И и настроим связи между ними и узлами согласования следующим образом:
    workflowExample19

  • Перенастраиваем переходы для узлов согласования.

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

Однако сейчас, когда завершатся обе ветви согласования и продолжится выполнение от узла И, система отправит сигнал как по связи Согласовано, так и по связи Не согласовано.

Чтобы отследить данную ситуацию можно в параметры процесса добавить новый параметр типа Да/Нет, который мы назовем NeedRework.

workflowExample20

Этот параметр будет отвечать за то, нужно ли нам будет переходить на доработку или нет.

В связи, исходящие из узла И, в условие выхода из узла, добавим условие Process.NeedRework, для связи Не согласовано, и !Process.NeedRework, для связи Согласовано.

workflowExample21

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

Добавим в скрипт для действия Сценарий из узла Инициализация Process.NeedRework = false;, а в скрипт при завершении каждого задания с вариантом Не согласовано - Process.NeedRework = true;

workflowExample22

Таким образом, если хоть одно задание завершено с вариантом Не согласовать, мы устанавливаем флаг NeedRework, и проверяем его при завершении согласования.

Далее добавим условие для перехода во вторую ветвь согласования. Будем проверять сумму договора. Допустим, если она не задана или меньше чем 50.000 (в данном примере не рассматриваем валюту), то согласование не требуется.

Эту задачу можно сделать различными способами:

  • Добавить узел с проверкой условия перед второй ветвью согласования и узел после нее, который ожидает или сигнал от первого узла с условием, или от узла с согласованием.
    workflowExample23

  • Другим вариантом будет отмена действия отправки задания на согласования в предобработке. Это позволяет пропустить выполнение действия Задание, тем самым сразу перейти по связи Завершено к узлу И.
    workflowExample24

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

Рассмотрим еще один пример. На этот раз мы будем формировать комментарий задания Доработка из комментариев при не согласовании.

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

workflowExample25

Далее в основной скрипт процесса добавим метод, который записывал бы из задания согласования комментарий в наш параметр. Также в этот метод можно вынести установку параметра NeedRework = true.
Добавим следующий метод:

protected void AddReworkComent(CardTask task)
{
    var section = task.Card.Sections.GetOrAdd("WfResolutions");
    string comment = section.RawFields.TryGet<string>("Comment");

    Process.ReworkComment = (string)Process.ReworkComment +
        (!string.IsNullOrEmpty(comment)
        ? string.Format("{0} ({1}): {2}\n", task.UserName , DateTime.Now, comment)
        : string.Format("{0} ({1})\n", task.UserName , DateTime.Now));

    Process.NeedRework = true;
}

Данный метод работает следующим образом:

  • Получаем секцию из карточки задания

  • Получаем значение из поля Комментарий из карточки задания

  • В комментарий отзыва добавляем строку вида <исполнитель> <дата завершения>: <комментарий>, если он задан, или без <комментарий>, если он не задан.

Во все места, где у нас происходит завершение задания с вариантом Не согласовано, добавляем вызов метода AddReworkComent(task).

В узел Инициализация добавляем сброс этого комментария Process.ReworkComment = null.

workflowExample26

Далее настроим параметр Описание задания для задания из узла Доработка на параметр ReworkComment.

workflowExample27

Таким образом, наш сформированный комментарий будет отображаться как текст задания для задания на доработку.

workflowExample28

8.1.4. Этап 4. Дополнительное согласования с возможностью рекурсивной отправки

  • Привязки к различным источникам данных

  • Рекурсивная отправка доп. согласований с отзывом дочерних заданий

  • Обновление родительского задания при завершении дочернего

  • Действия Группа заданий, Управление группой заданий

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

  • Добавим действие тип Группа заданий в новый узел, и назовем его Доп. согласование.

  • В новый узел добавим действие Управление заданием, переместим его в таблице действий перед группой заданий.

  • В новый узел добавим действие Управление группой заданий, переместим его в таблице действий перед группой заданий.

  • Добавим из всех узлов Согласование 1-3 связь в новый узел.

  • Добавим в новый узел связь на себя, установим ему режим перехода Никогда не создавать экземпляр узла.

  • Добавим связь в новый узел из узла Отзыв.

Получим примерно следующее:

workflowExample29

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

Добавим в узел параметр Draft и установим ему значение true. Данный параметр будет определять состояние узла. Если значение равно true, то задания создаются через Группу заданий, иначе через Управление группы заданий.

Теперь необходимо настроить действия.

В первую очередь настроим действие Группа заданий. Настроим ему поля следующим образом:

workflowExample30

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

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

  2. Выбираем тип привязки Задание;

  3. Из списка типов заданий выбираем наш тип задания;

  4. В фильтрах должны стоять флаги Завершенные задания и Только первое задание, остальные должны быть сняты;

  5. В контроле со структурой задания выбираем секцию "WfResolutionPerformers";

  6. Поле "Order" автоматически подтянется как поля для сортировки исполнителей. В данной задаче нам это не важно;

  7. Нажимаем кнопку "Ок" чтобы сохранить настройки привязки для поля Роли;

Поле Текст задания настраивается также, как и Роли, только в качестве поля для привязки выбирается поле "Comment" из секции "WfResolutions".

Далее заполним таблицу вариантов завершения. Добавим в нее строки с вариантами завершения Согласовать, Не согласовать и Запросить дополнительное согласование. Для каждого варианта завершения укажем условие выполнения перехода Одно задание, сразу, в список переходов добавим связь на себя.

Для вариантов Согласовать и Не согласовать добавим сценарий:

Signal.Revoke = true;

if (task.ParentRowID.HasValue)
{
	var parentTask = Context.GetTask(task.ParentRowID.Value);

	parentTask.Digest += "\n"
		+ task.UserName
		+ " cогласовал/не согласовал с комментарием: "
		+ task.Card.Sections["WfResolutions"].RawFields.TryGet<string>("Comment");
	parentTask.Flags |= CardTaskFlags.UpdateDigest;
	parentTask.State = CardRowState.Modified;
}

Параметр сигнала Revoke будет отвечать за отзыв дочерних заданий доп. согласования.

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

Откроем действие Управление группой заданий и заполним его следующим образом:

workflowExample31

Мы указываем список обрабатываемых сигналов, чтобы данное действие выполнялось только при получении сигнала с типом Default/

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

Поле Новые роли заполнятся аналогично тому, как было заполнено поле Роли в действии Группа заданий.

Далее откроем действие Управление заданием в узле Доп. согласование и заполним его следующим образом:

workflowExample32

Данное действие будет заниматься отзывом дерева всех дочерних заданий

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

В сценарии постобработки мы рассчитываем список ID заданий taskIDs, которые необходимо отозвать. Это необходимо делать в постобработке, т.к. действие управления заданием очищается список заданий taskIDs для обработки (по умолчанию управление применяется ко всем заданиям).

Мы используем свойство Task для получения ID завершаемого задания.

Следующим шагом будет настройка узлов действий Согласование 1-3. В настройки вариантов завершения для этих узлов в варианты завершения Согласовать и Не согласовать добавим в список переходов связь на узел Доп. согласования а в сценарий добавим следующее:

Signal.Revoke = true;

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

Таким образом при завершении задания с данным вариантов завершения будет осуществлена отправка заданий на доп. согласование на исполнителей, указанных в секции "WfResolutionPerformers", а при завершении заданий с другим вариантом завершения будет производиться отзыв отправленных, но не завершенных заданий доп. согласования.

8.2. Примеры процессов с применением действий из группы "Маршруты"

8.2.1. Согласование договора

Рассмотрим пример реализации процесса в Workflow Engine описанного в примере "Инициация нового договора" в Руководстве администратора реализованного с использованием средств подсистемы маршрутов.

Ниже представлена общая схема процесса.

workflowExample33

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

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

После успешного согласование он будет переведен в состояние "На подписании руководителем" и отправлен на подписание руководителю.

Затем договор будет переведен в состояние "На подписании контрагенту" и отправлен инициатору на организацию подписания контрагентом.

И в самом конце договор получит состояние "Подписано сторонами".

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

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

Создаёте новую карточку договора и заполните необходимые поля.

Давайте попробуем отправить договор на согласование не внося изменений в сумму. Если договор дороже 100 000, то после запуска процесса он будет отправлен на согласование, если сумма договора не указана, то она считается меньше 100 000. Она меньше 100 000 и это значит, что договор должен сразу попасть на подписание.

Нажмём в левой панели тайл "Согласование договора".

workflowExample34

Запустился процесс и нам сразу же пришло задание на подписание, минуя согласование.

workflowExample35

Обратите внимание, что состояние карточки изменилось на "На подписании руководителем". Состояние карточки можно посмотреть и на основной вкладке карточки, и на вкладке "Маршрут".

workflowExample36

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

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

Нажмите кнопку "Подписать", вы увидите поле для ввода комментария. Нажмите "Подписать" еще раз для подтверждения завершения задания.

Нам сразу же приходит следующее задание. Это задание инициатору на организацию подписания контрагентом.

workflowExample37

Обратите внимание, что состояние карточки изменилось и теперь оно "На подписании контрагентом".

Давайте откажем в подписании. Нажмите кнопку "В работу". Затем нажмите кнопку "Отказать", введите комментарий (при отказе в подписании он обязательный) и нажмите еще раз "Отказать".

Нам пришло задание доработки. Состояние карточки изменилось на "На доработке".

workflowExample38

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

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

workflowExample39

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

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

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

Процесс завершится и состояние карточки изменится на "Подписано сторонами".

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

Теперь давайте инициируем договор с большей суммой. Еще раз создаёте карточку договора и введите сумму 200 000.

И опять в левой панели нажмите тайл "Согласование договора".

И нам сразу же приходит задание на согласование договора, которого не было в прошлый раз.

Посмотрим на выполнение процесса. Для этого на левой панели необходимо выбрать тайл с именем процесса.

workflowExample40

Текущее действие "Согласование внутри компании" выполняет последовательное согласование ролями "Руководитель инициатора" и подразделением "Финансовый департамент".

workflowExample41

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

Обратите внимание, что все аспекты этого процесса реализованы при помощи механизма бизнес-процессов.

Создание процесса

Рассмотрим процесс создания описанного процесса.

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

  • Название процесса, например, "Согласование договора";

  • Группа процесса, например, "Примеры";

  • Состояние флагов Запуск из карточки и Можно запускать несколько экземпляров оставьте без изменений;

  • Укажите тип карточки "Договорной документ";

  • Задайте расширение проверки доступа для кнопок "Проверка состояния". Это позволит в кнопке бизнес-процесса указать состояние, при котором она будет доступна;

  • Добавьте кнопку бизнес-процесса и настройте её как указано на рисунке:

    workflowExample41 1

В итоге должно получиться:

workflowExample41 2

Откройте шаблон бизнес-процесса и разместите действия и связи как указано на следующем рисунке.

workflowExample33

Все узлы содержат по одному действию. Соответствие наименования узлов и действий приведено в следующей таблице.

Заголовок узла Действие

Старт процесса

Старт процесса

Инициализация маршрута

Инициализация маршрута

Управление историей

Управление историей

Сумма договора

Условие

Согласование внутри компании

Согласование

На подписании руководителем, На подписании контрагентом, Подписано сторонами

Смена состояния

Подписание руководителем, Подписание контрагентом

Подписание

Доработка после отказа в согласовании, Доработка после отказа в подписании

Доработка

Конец процесса

Конец процесса

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

Все действия "Управление историей" в данном процессе будут иметь следующие параметры:

workflowExample41 3

Параметры Группа истории заданий и Родительская группа привязаны к параметрам процесса "Process.HistoryGroup" и "Process.ParentHistoryGroup", соответственно, и имеют следующие значения: "Согласование - цикл" и "Согласование".

Обратите внимание:

  • Для правильной инициализации маршрута необходимо размещать действие "Инициализация маршрута" перед любыми действиями из группы "Маршруты".

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

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

Более подробно про особенности действий из группы "Маршруты" см. в разделе Особенности действий.

Для организации ветвления процесса, в зависимости от суммы договора, в процессе присутствует действие "Условие" имеющее два условия перехода:

  1. Сумма договора задана и больше или равна 100 000 или не задана.

    Переход в этом случает определяется по сценарию:

    #script
    
    if((await this.GetCardObjectAsync()).Sections.TryGetValue("DocumentCommonInfo", out var dCISection))
    {
    	return dCISection.Fields.TryGet<decimal?>("Amount") >= 100_000;
    }
    
    return false;

    workflowExample41 4

  2. Сумма договора меньше 100 000.

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

    workflowExample41 5

В итоге должно получиться как показано на следующем рисунке.

workflowExample41 6

Перейдём к узлу "Согласование внутри компании". Данный узел включает одно действие "Согласование", настроенное следующим образом:

workflowExample41 7

Все параметры, которые не показаны на данном рисунке, имеют значения по умолчанию.

За доработку документа инициатором в случае несогласования документа отвечает действие "Доработка", расположенное в узле "Доработка после отказа в согласовании" и настроенное следующим образом:

workflowExample41 8

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

Для реализации подписания руководителем используется действие "Подписание", настроенное как показано на рисунке.

workflowExample41 9

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

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

workflowExample41 10

После подписания состояние документа изменяется на "Подписано сторонами" в действии "Смена состояния".

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

8.2.2. Подготовка, согласование и исполнение служебной записки/заявки

Рассмотрим пример реализации процесса в Workflow Engine описанного в примере "Подготовка, согласование и исполнение служебной записки/заявки" в Руководстве администратора, реализованного с использованием средств подсистемы маршрутов.

Ниже представлена общая схема процесса.

workflowExample42

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

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

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

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

Если заявка является финансовой:

  • После отправки на согласование будет предложено предоставить финансовое обоснование или ввести комментарий.

  • Когда заявка инициирована и приложено обоснование, она отправляется на согласование. В нем участвуют роли: "Руководитель инициатора", "Финансовый департамент" и "Главный бухгалтер". С каждым циклом согласования времени на согласование система будет давать всё меньше.

Далее заявка отправляется на исполнение. Исполняют ее различные роли в зависимости от типа заявки. После исполнения система отправляет задание инициатору с просьбой подтвердить выполнение.

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

Давайте создадим новую служебную записку. Нажмите тайл "Обычная СЗ" в группе тайлов "СЗ Workflow Engine" на правой панели.

workflowExample43

Будет открыто диалоговое окно, содержащее сформированный по шаблону документ.

workflowExample44

После отправки на согласование система стартует процесс и присылает задание на исполнение заявки, отправленное на роль "ДИТ". При этом карточка автоматически открывается в клиентском рабочем месте.

workflowExample45

Посмотрим, как выглядит процесс. Для этого откроем редактор экземпляра процесса Левое меню → Действия → Процессы → Подготовка, согласование и исполнение служебной записки/заявки. В настоящий момент активно действие "Исполнение обычной СЗ".

workflowExample46

Как видите, в задании уже написано, что нам нужно сделать.

Теперь нажмите кнопку "В работу" в задании.

Теперь вам доступны все возможности работы с этим заданием. Задание можно просто завершить. Еще вы можете отправить задание другому сотруднику или сотрудникам, вы можете создать подчиненное задание, чтобы получить какие-то дополнительные материалы и данные. Возможностей очень много, и они подробно описаны в руководстве пользователя в разделе "Работа с задачами".

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

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

Система создаст карточку, но процесс дальше нельзя продолжить до тех пор, пока не будет указана допустимая категория документа.

workflowExample47

Давайте вернемся в карточку и заполним поле "Категория документа". Выберите "Прочие СЗ" из выпадающего списка и опять отправьте на согласование.

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

Состояние карточки изменилось на "На исполнении". Часто со сменой состояния также настраивают изменения прав доступа на карточку, например, чтобы инициатор имел права на изменение данных и файлов карточки, только пока она в состоянии "Проект".

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

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

Давайте не примем выполнение. Нажмите кнопку "Не принято", заполните комментарий и еще раз нажмите "Не принято" для подтверждения завершения.

workflowExample48

И мы опять переходим на этап выполнения заявки. Система вновь отправила задание исполнителю с комментарием инициатора.

workflowExample49

Давайте опять возьмём задание в работу и затем завершим его. Нажмите "В работу", затем нажмите "Завершить" и на форме завершения задания еще раз нажмите "Завершить".

Система вновь присылает нам задание на подтверждение. Возьмите его в работу, и нажмите "Выполнено".

Исполнение заявки принято, процесс завершен, карточка перешла в состояние "Исполнен".

workflowExample50

А теперь давайте инициируем финансовую заявку, чтобы посмотреть на работу согласования. Нажмите в правой панели тайл "Финансовая СЗ".

workflowExample51

Вновь система создала карточку заявки и открыла её в диалоговом окне. Система запустит процесс и отправит задание на роль "Инициатор".

workflowExample52

Задание уже взято в работу. Нажав на кнопку "Приложить обоснование" откроется диалоговое окно, где можно добавить файл или указать комментарий. Нажмите на панели инструментов кнопку "Отправить" для завершения задания.

workflowExample53

Документ отправится дальше по маршруту.

Для примера, система настроена таким образом, что приложенные в диалоге "Предоставление обоснования" файлы прикладываются в карточку документа и введённый комментарий к финансовому обоснованию записывается в поле "Комментарий к обоснованию":

workflowExample54

Согласно схеме процесса на роль "Руководитель инициатора" приходит задание на согласование заявки. Срок задания составляет 5 рабочих дней на первом цикле согласования. Он будет уменьшаться на 1 день на каждом последующем цикле согласования вплоть до 1 дня.

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

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

Система отправляет задание инициатору на доработку.

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

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

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

Если завершить и это задание, согласовав документ, мы попадем на этап согласования финансового обоснования главным бухгалтером. Укажем результат проверки и согласуем финансовое обоснование.

workflowExample55

Мы попадаем на уже знакомый нам этап исполнения заявки, только исполнителем будет другая роль, потому что категория заявки "Финансовая СЗ".

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

Скачать пример настроенного данного процесса можно по ссылке.

Создание процесса

Рассмотрим процесс создания описанного процесса.

Создайте новый шаблон бизнес процесса и настройте его следующим образом:

  • Название процесса, например, "Подготовка, согласование и исполнение служебной записки";

  • Группа процесса, например, "Примеры";

  • Снимите флаг Запуск из карточки;

  • Состояние флага Можно запускать несколько экземпляров оставьте без изменений;

  • Укажите тип карточки "Договорной документ";

  • Добавьте кнопку бизнес-процесса "Обычная СЗ" и настройте её как показано на рисунке:

    workflowExample56

  • Добавьте кнопку бизнес-процесса "Финансовая СЗ" и настройте её как показано на рисунке:

    workflowExample57

В итоге должно получиться:

workflowExample58

Откройте шаблон бизнес-процесса и разместите действия и связи как на следующем рисунке.

workflowExample42

Все узлы содержат по одному действию. Соответствие наименования узлов и действий приведено в таблице.

Заголовок узла Действие

Старт процесса по финансовой СЗ, Старт процесса по обычной СЗ

Старт процесса

Инициализация финансовой СЗ, Инициализация обычной СЗ, Предоставление обоснования, Согласование обоснования

Диалог

Инициализация маршрута

Инициализация маршрута

Управление историей

Управление историей

Категория заявки, Категория заявки

Условие

Изменение категории СЗ

Задание

Согласование с руководителем и фин. департаментом

Согласование

Доработка

Доработка

На исполнении, Исполнен

Смена состояния

Исполнение обычной СЗ, Исполнение финансовой СЗ

Выполнение задачи

Подтвердить выполнение

Настраиваемое задание

Конец процесса

Конец процесса

Для реализации возможности создания служебных записок двух разных категорий "Финансовая СЗ" и "Обычная СЗ" процесс содержит два действия "Старт процесса", каждый из которых настроен на обработку своего сигнала. Так действие из узла "Старт процесса по финансовой СЗ" обрабатывает сигнал "StartFinancial", а из "Старт процесса по обычной СЗ" - "StartCommon".

Параметры действия из узла "Инициализация финансовой СЗ":

workflowExample59

Параметры действия из узла "Инициализация обычной СЗ":

workflowExample60

Для реализации создания карточки по шаблону и открытию её в диалоговом окне используется действие "Диалог" расположенное в узлах "Инициализация финансовой СЗ" и "Инициализация обычной СЗ".

Параметры диалога, инициализирующего финансовую СЗ:

workflowExample61

Параметры диалога, инициализирующего обычную СЗ:

workflowExample62

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

Кнопка "Отправить", у обоих диалогов, настроена идентично:

workflowExample63

В сценарии необходимо указать вызов метода StoreAndOpenCardAsync(WorkflowDialogContext) выполняющего сохранение и последующее открытие инициализированной карточки служебной записки:

await this.StoreAndOpenCardAsync(dialog);

Сам метод расположен в основном скрипте процесса (см. Редактор процесса):

#using System.Threading.Tasks;

#using Tessa.Cards;
#using Tessa.Extensions.Default.Server.Workflow.KrProcess;
#using Tessa.Extensions.Default.Shared.Workflow.KrProcess;
#using Tessa.Extensions.Default.Shared.Workflow.KrProcess.ClientCommandInterpreter;

/// <summary>
/// Асинхронно сохраняет и открывает на клиенте инициализируемую карточку служебной записки.
/// </summary>
/// <param name="dialog">Контекст скриптов обработки диалогов в Workflow Engine.</param>
/// <returns>Асинхронная задача.</returns>
protected async Task StoreAndOpenCardAsync(WorkflowDialogContext dialog)
{
	var fileManager = this.Context.Container.Resolve<ICardFileManager>();
	var tokenProvider = this.Context.Container.Resolve<IKrTokenProvider>();

	var dialogCard = await dialog.GetCardObjectAsync();

	// Обработка файлов приложенных к инициализируемой карточке служебной записки.
	await using (var container = await fileManager.CreateContainerAsync(dialogCard, cancellationToken: this.Context.CancellationToken))
	{
		// Подготовка контента приложенных и/или изменённых файлов для последующего сохранения.
		foreach(var dFile in container.FileContainer.Files)
		{
			if(!dFile.Content.HasData)
			{
				await dFile.ReplaceAsync(await dialog.GetFileContentAsync(dialogCard.Files.Single(i => i.RowID == dFile.ID)));
			}
		}

		var storeResponse = await container.StoreAsync((c, request, ct) =>
		{
			tokenProvider.CreateToken(request.Card.ID).Set(request.Card.Info);
			return new ValueTask();
		},
		cancellationToken: this.Context.CancellationToken);

		this.ValidationResult.Add(storeResponse.ValidationResult);
		if (!storeResponse.ValidationResult.IsSuccessful())
		{
			return;
		}
	}

	// Добавление клиентской команды на открытие инициализированной карточки во вкладке Tessa Client.
	if (!(this.Context.ResponseInfo.TryGetValue(KrProcessSharedExtensions.KrProcessClientCommandInfoMark, out var commandsObj)
		&& commandsObj is List<object> commands))
	{
		commands = new List<object>();
		this.Context.ResponseInfo[KrProcessSharedExtensions.KrProcessClientCommandInfoMark] = commands;
	}

	commands.Add(
		new KrProcessClientCommand(
			DefaultCommandTypes.OpenCard,
			new Dictionary<string, object>
			{
				[KrConstants.Keys.NewCardID] =  dialogCard.ID
			}).GetStorage());

	// Установка инициализированной карточки служебной записки в качестве основной карточки процесса.
	this.Context.SetMainCard(dialogCard.ID);
}

После инициализации карточки служебной записки начинается процесс её согласования.

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

Все действия "Управление историей" в данном процессе имеют следующие параметры:

workflowExample64

Параметры Группа истории заданий и Родительская группа привязаны к параметрам процесса (см. Форма для создания привязки) "Process.HistoryGroup" и "Process.ParentHistoryGroup", соответственно, и имеют следующие значения: "Согласование - цикл" и "Согласование".

Обратите внимание:

  • Для правильной инициализации маршрута необходимо размещать действие "Инициализация маршрута" перед любыми действиями из группы "Маршруты".

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

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

Более подробно про особенности действий из группы "Маршруты" см. в разделе Особенности действий.

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

  1. Категория заявки равна "Финансовая СЗ".

    Для проверки условия используется сценарий, проверяющий текущее значение идентификатора категории на равенство идентификатору категории "Финансовая СЗ":

    (await this.GetCardAsync()).DocumentCommonInfo.CategoryID == new Guid(0xd51477de, 0x8664, 0x473d, 0xab, 0x5f, 0xd1, 0xee, 0x0e, 0x60, 0x52, 0xc6)

    workflowExample65

  2. Категория заявки равна "Прочие СЗ".

    Для проверки условия используется сценарий, проверяющий текущее значение идентификатора категории на равенство идентификатору категории "Прочие СЗ":

    (await this.GetCardAsync()).DocumentCommonInfo.CategoryID == new Guid(0x39779be7, 0x8715, 0x49af, 0x84, 0x37, 0x1b, 0x8b, 0x55, 0xd1, 0x1e, 0x24)

    workflowExample66

  3. Неизвестная категория заявки.

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

    workflowExample67

Изменение категории СЗ реализовано, через отправку задания типа "Доработка" из действия "Задача" расположенного в узле "Изменение категории СЗ".

workflowExample68

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

Предоставление финансового обоснования реализовано через диалог, расположенный в узле "Предоставление обоснования", настроенный следующим образом:

workflowExample69

Диалог имеет одну кнопку "Отправить" настроенную следующим образом:

workflowExample70

В сценарии выполняется проверка задания комментария или приложения файлов:

const string justificationSectionAlias = "WfeJustification";
const string commentAlias = "Comment";

var dCard = await dialog.GetCardObjectAsync();
var hasFiles = dCard.TryGetFiles()?.Count > 0;

// Не указан комментарий в поле "Комментарий к обоснованию" карточки диалога и не приложен ни один файл?
if(string.IsNullOrEmpty(dCard.Sections[justificationSectionAlias].Fields.Get<string>(commentAlias))
	&& !hasFiles)
{
	this.ValidationResult.AddError(this, "Пожалуйста, приложите файл финансового обоснования или заполните комментарий.");
}

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

#using System.Threading.Tasks;
#using Tessa.Cards;

const string justificationSectionAlias = "WfeJustification";
const string commentAlias = "Comment";

const string bSend = "Send";
const string mCardFileCategoryName = "Финансовое обоснование";

if(dialog.ButtonName == bSend)
{
	// Перенос комментария из поля "Комментарий к обоснованию" карточки диалога в одноимённое поле карточки СЗ.
	(await this.GetCardObjectAsync()).Sections.GetOrAdd(justificationSectionAlias).Fields[commentAlias] = (await dialog.GetCardObjectAsync()).Sections[justificationSectionAlias].Fields[commentAlias];

	// Перенос файлов, приложенных к карточке диалога в карточку СЗ.
	var mCardFileContainer = (await this.Context.GetFileContainerAsync(cancellationToken: this.Context.CancellationToken)).FileContainer;
	var dCardFileContainer = (await dialog.GetFileContainerAsync()).FileContainer;

	foreach(var dFile in dCardFileContainer.Files)
	{
		if(!dFile.Content.HasData)
		{
			var result = await dFile.EnsureContentDownloadedInUIAsync(cancellationToken: this.Context.CancellationToken);
			this.ValidationResult.Add(result);
			if(result.HasErrors)
			{
				return;
			}
		}

		await mCardFileContainer
			.BuildFile(dFile.Name)
			.SetContent(dFile.Content)
			.SetVersionToken(
				(ft, ct) =>
				{
					var lastVersion = dFile.Versions.Last();

					ft.Created = lastVersion.Created;
					ft.CreatedByID = lastVersion.CreatedByID;
					ft.CreatedByName = lastVersion.CreatedByName;

					ft.Hash = lastVersion.Hash;

					return new ValueTask();
				})
			.SetCategory(mCardFileCategoryName)
			.AddWithNotificationAsync(cancellationToken: this.Context.CancellationToken);
	}
}

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

workflowExample71

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

#using Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine;

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

var period = (await this.Context.GetAsync<double?>(WorkflowConstants.KrApprovalActionVirtual.SectionName, WorkflowConstants.KrApprovalActionVirtual.Period) ?? 1) - WorkflowHelper.GetProcessCycle(this.Context.ProcessInstance.Hash) + 1;

if(period < 1)
{
	period = 1;
}

WorkflowEngineHelper.Set(this.Context.ActionInstance.Hash, period, WorkflowConstants.KrApprovalActionVirtual.SectionName, WorkflowConstants.KrApprovalActionVirtual.Period);

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

this.Process.SentToRebuild = this.Session.User.Name;
this.Process.RebuildComment = taskCard.KrTask.Comment;

После согласования с руководителем и финансовым департаментом, финансовое обоснование отправляется на согласование с главным бухгалтером. Оно реализовано с помощью действия "Диалог" из узла "Согласование обоснования". Его параметры:

workflowExample72

Диалог имеет две кнопки:

  1. Согласовано

    workflowExample73

  2. На доработку

    workflowExample74

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

const string justificationSectionAlias = "WfeJustification";
const string commentAlias = "Comment";

const string fileCategoryName = "Финансовое обоснование";

var dCard = await dialog.GetCardObjectAsync();
var mCard = await this.GetCardObjectAsync();

dCard.ID = Guid.NewGuid();

// Перенос комментария к финансовому обоснованию из карточки СЗ в карточку диалога.
dCard.Sections[justificationSectionAlias].Fields[commentAlias] = mCard.Sections[justificationSectionAlias].Fields[commentAlias];

// Подготовка и копирование файлов из карточки СЗ в карточку диалога.
mCard.Files.RemoveAll(i => !string.Equals(i.CategoryCaption, fileCategoryName, StringComparison.Ordinal));

var result = await CardHelper.CopyFilesAsync(
	mCard,
	dCard,
	this.Context.Container,
	cancellationToken: this.Context.CancellationToken);
this.ValidationResult.Add(result);

if(result.HasErrors)
{
	return;
}

var dCardFiles = dCard.Files;

// Сохранение информации о внешнем источнике контента файла.
var fileIDContentSources = new Dictionary<string, object>(dCardFiles.Count, StringComparer.Ordinal);
foreach(var dCardFile in dCardFiles)
{
	fileIDContentSources.Add(dCardFile.RowID.ToString("N"), dCardFile.ExternalSource.FileID.ToString("N"));
}

this.Process.FileIDContentSources = fileIDContentSources;

Валидация полей выполняется в сценарии валидации диалога:

const string justificationSectionAlias = "WfeJustification";
const string verificationResultAlias = "VerificationResult";
const string bRebuildAlias = "Rebuild";

var verificationResult = (await dialog.GetCardObjectAsync()).Sections[justificationSectionAlias].Fields.Get<string>(verificationResultAlias);

if(dialog.ButtonName != null)
{
	if(string.IsNullOrEmpty(verificationResult))
	{
		this.ValidationResult.AddError(this, "Заполните, пожалуйста, поле \"Результат проверки\".");
		return;
	}

	if(string.Equals(dialog.ButtonName, bRebuildAlias, StringComparison.Ordinal))
	{
		this.Process.SentToRebuild = this.Session.User.Name;
		this.Process.RebuildComment = verificationResult;
	}
}

Для переноса файлов и комментария из поля "Результат проверки" карточки диалога в карточку СЗ используется сценарий сохранения диалога:

#using System.IO;
#using System.Threading.Tasks;

#using Tessa.Cards;
#using Tessa.Cards.Numbers;

const string bAgreedAlias = "Agreed";
const string bRebuildAlias = "Rebuild";

const string justificationSectionAlias = "WfeJustification";
const string verificationResultAlias = "VerificationResult";

const string mCardFileCategoryName = "Финансовое обоснование";

var mCard = await this.Context.GetMainCardAsync(cancellationToken: this.Context.CancellationToken);
var dCard = await dialog.GetCardObjectAsync();
var dCardFiles = dCard.TryGetFiles();

// В карточке диалога нет файлов?
if(dCardFiles?.Any() != true)
{
	return;
}

if(string.Equals(dialog.ButtonName, bAgreedAlias, StringComparison.Ordinal)
	|| string.Equals(dialog.ButtonName, bRebuildAlias, StringComparison.Ordinal))
{
	Dictionary<Guid, Guid> fileIDContentSources;

	if(this.Process.FileIDContentSources is Dictionary<string, object> fileIDContentSourcesObjDict)
	{
		fileIDContentSources = fileIDContentSourcesObjDict.ToDictionary(i => Guid.ParseExact(i.Key, "N"), j => Guid.ParseExact((string)j.Value, "N"));
	}
	else
	{
		fileIDContentSources = null;
	}

	Guid? GetFileIDContentSource(Guid fileRowID)
	{
		if(fileIDContentSources != null
			&& fileIDContentSources.TryGetValue(fileRowID, out var fileIDContentSource))
		{
			return fileIDContentSource;
		}
		return default;
	}
	mCard.Sections[justificationSectionAlias].Fields[verificationResultAlias] = dCard.Sections[justificationSectionAlias].Fields[verificationResultAlias];

	var mCardFileContainer = (await this.Context.GetFileContainerAsync(cancellationToken: this.Context.CancellationToken)).FileContainer;
	var mFiles = mCardFileContainer.Files;

	// Удаление файлов из основной карточки, удалённых из карточки диалога.
	var deletedFileIDCollection = mFiles
		.Where(mFile => string.Equals(mFile.Category?.Caption, mCardFileCategoryName, StringComparison.Ordinal))
		.Select(mFile => mFile.ID)
		.Except(dCardFiles
			.Select(dCardFile => GetFileIDContentSource(dCardFile.RowID))
			.Where(mFileID => mFileID.HasValue)
			.Cast<Guid>()).ToArray();

	for(var i = 0; i < deletedFileIDCollection.Length; i++)
	{
		await mFiles.RemoveWithNotificationAsync(mFiles.TryGet(deletedFileIDCollection[i]), this.Context.CancellationToken);
	}

	// Перенос файлов из карточки диалога в основную карточку.
	var dCardFileContainer = (await dialog.GetFileContainerAsync()).FileContainer;

	ValidationResult result;
	foreach(var dFile in dCardFileContainer.Files)
	{
		if(!dFile.Content.HasData)
		{
			result = await dFile.EnsureContentDownloadedInUIAsync(cancellationToken: this.Context.CancellationToken);
			this.ValidationResult.Add(result);
			if(result.HasErrors)
			{
				return;
			}
		}

		var fileIDContentSource = GetFileIDContentSource(dFile.ID);

		// Файл был перенесён из основной карточки?
		if(fileIDContentSource.HasValue)
		{
			var mFile = mFiles.TryGet(fileIDContentSource.Value);

			if(dFile.TryGetActualVersion().Number > 1)
			{
				result = await mFile.ReplaceAsync(await dFile.Content.GetAsync(this.Context.CancellationToken), this.Context.CancellationToken);
				this.ValidationResult.Add(result);

				if(result.HasErrors)
				{
					return;
				}
			}

			result = await mFile.RenameAsync(dFile.Name, this.Context.CancellationToken);
			this.ValidationResult.Add(result);

			if(result.HasErrors)
			{
				return;
			}
		}
		else
		{
			result = (await mCardFileContainer
				.BuildFile(dFile.Name)
				.SetContent(dFile.Content)
				.SetVersionToken(
					(ft, ct) =>
					{
						var lastVersion = dFile.Versions.Last();

						ft.Created = lastVersion.Created;
						ft.CreatedByID = lastVersion.CreatedByID;
						ft.CreatedByName = lastVersion.CreatedByName;

						ft.Hash = lastVersion.Hash;

						return new ValueTask();
					})
				.SetCategory(mCardFileCategoryName)
				.AddWithNotificationAsync(cancellationToken: this.Context.CancellationToken)).result;
			ValidationResult.Add(result);

			if(result.HasErrors)
			{
				return;
			}
		}
	}
}

Доработка при согласовании внутри компании выполняется действием "Доработка", расположенным в одноимённом узле:

workflowExample75

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

#using Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine;

var sentToRebuild = (string)this.Process.SentToRebuild;

if (!string.IsNullOrEmpty(sentToRebuild))
{
	var digest = $"Служебная записка возвращена на доработку: {sentToRebuild}";
	var comment = (string)this.Process.RebuildComment;

	if(!string.IsNullOrWhiteSpace(comment))
	{
		digest += Environment.NewLine + Environment.NewLine + comment;
	}

	WorkflowEngineHelper.Set(
		this.Context.ActionInstance.Hash,
		digest,
		WorkflowConstants.KrAmendingActionVirtual.SectionName,
		WorkflowConstants.KrAmendingActionVirtual.Digest);
}

Перейдём к рассмотрению реализации процесса исполнения СЗ.

При переходе СЗ на исполнение у неё изменится состояние на "На исполнении" в действии "Смена состояния" узла "На исполнении".

После чего процесс снова разветвляется в зависимости от категории СЗ в действии "Условие" узла "Категория заявки". Условия в данном действии аналогичны ранее рассмотренным в действии "Условие" узла "Категория заявки". Только отсутствует обработка варианта "Неизвестная категория СЗ".

Если категория заявки "Финансовая СЗ", то она отправляется на исполнение в узел "Исполнение финансовой СЗ" для обработки действием "Выполнение задачи", иначе в узел "Исполнение обычной СЗ".

Параметры действия из узла "Исполнение финансовой СЗ" указаны на рисунке:

workflowExample76

Вывод комментария вернувшего СЗ на доработку выполняется с помощью сценария предобработки:

#using Tessa.Extensions.Default.Shared.Workflow.WorkflowEngine;

if (!string.IsNullOrEmpty((string)this.Process.RejectComment))
{
	WorkflowEngineHelper.Set(
		this.Context.ActionInstance.Hash,
		"Инициатор заявки отклонил выполнение с комментарием:"
		+ Environment.NewLine
		+ this.Process.RejectComment,
		WorkflowConstants.KrResolutionActionVirtual.SectionName,
		WorkflowConstants.KrResolutionActionVirtual.Digest);
}

Действие, расположенное в узле "Исполнение обычной СЗ" имеет следующие параметры:

workflowExample77

После исполнения СЗ у неё изменяется состояние на "Исполнен" в действии "Смена состояния" в одноимённом узле.

Параметры действия "Настраиваемое задание", расположенного в узле "Подтвердить выполнение", приведены на следующем рисунке:

workflowExample78

Параметры настраиваемых вариантов завершения:

  1. Выполнено.

    Вариант завершения не имеет параметров отличных от значений по умолчанию.

    workflowExample79

  2. Не принято.

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

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

    var comment = (string)taskCard.KrTask.Comment;
    
    if (string.IsNullOrWhiteSpace(comment))
    {
    	this.ValidationResult.AddError(this, "Пожалуйста, укажите комментарий.");
    	return;
    }
    
    this.Process.RejectComment = comment;

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

    workflowExample80

Скачать настроенный процесс, описанный в данном разделе, можно по ссылке.

8.3. Создание действий

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

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

Дескриптор действия

В первую очередь нужно создать объект-дескриптор действия. Для этого нужно создать свой экземпляр объекта с типом WorkflowActionDescriptor. Данный объект содержит описание действия и связь с карточкой настроек из типов карточек. Данный объект можно создать как статическое поле какого-нибудь класса. Регистрировать данный объект в Unity не нужно.
WorkflowActionDescriptor имеет следующий набор свойств:

  • ID - определяет уникальный идентификатор типа действия и является идентификатором типа карточки с настройками. Обязательный параметр для заполнения.

  • Icon - имя ресурса с иконкой для действия. Выбранная иконка отображается на боковой панели с действиями и как иконка по умолчанию для новых узлов при добавлении действия. По умолчанию имеет значение "Thin1".

  • Group - определяет имя группы, в которую включено данное действие на боковой панели. По умолчанию имеет значение "$WorkflowEngine_Groups_Main" (Основные).

  • Order - определяет порядок действий на боковой панели. По умолчанию равен 100.

  • IsStandAlone - определяет, является ли данное действие одиночным (см. раздел Особенности действий). По умолчанию имеет значение false.

  • ProcessNodeExit - определяет, должно ли действие обрабатывать системный Exit-сигнал (см. раздел Особенности действий). По умолчанию имеет значение false.

  • Methods - массив дескрипторов компилируемых методов действия.

Пример
public readonly static WorkflowActionDescriptor WfeLoanSetStateDescriptor =
    new WorkflowActionDescriptor(WfeLoanSetStateActionTypeID)
    {
        Group = "Кредитная заявка",
        Icon = "Thin411",
        Methods = new []
		{
			CustomMethodDescriptor,
		},
    };

Дескриптор метода

Если в действиях предполагается использование кастомных методов, описанных в настройках действия, то для дескриптора действия нужно создать дескриптор метода. Данный дескриптор также используется для формирования связи между выгруженным в .csproj проектом и местом хранения самих скриптов в настройках действия.
WorkflowActionMethodDescriptor содержит следующие свойства, которые можно задать:

  • MethodName - имя компилируемого метода.

  • ReturnType - тип возвращаемого результата. По умолчанию имеет значение void.

  • Parameters - набор пар значение типа string, обозначающих пары тип параметра-имя параметра. Если не задан, метод не имеет дополнительных параметров.

  • StorePath - путь к месту в парметрах действия, где хранится текст скрипта. Если задан ComplexDescriptor, то данное поле определяет путь к месту не в параметрах действия, а в строке.

  • ErrorDescription - описание места возникновения ошибки при возникновении ошибки компиляции в данном методе.

  • MethodDescription - описание метода при выгрузке процесса в проект .csproj. Если не задано, описание формируется автоматически.

  • ComplexDescriptor - описание генератора методов, если метод создается по табличной секции.

WorkflowActionMethodDescriptor имеет следующие методы:

WorkflowActionMethodsComplexDescriptor содержит следующие свойства, которые можно задать:

  • ListPath - путь к месту в параметрах действия, где хранится таблица со скриптами. Путь к скрипту внутри строки определяется по StorePath внутри описания метода.

  • GetMethodNameSuffix - функция, которая принимает строку в виде IDictionary<string, object> и возвращает суффикс, добавляемый к имени метода. Должен быть задан.

  • GetErrorDescription - функция, которая принимает оригинальный ErrorDescription дескриптора метода, строку в виде IDictionary<string, object> и возвращает описание места возникновения ошибки при возникновении ошибки компиляции в данном методе переданной строки. Если не задан, то возвращается ErrorDescription из дескриптора метода.

  • GetMethodDescription - функция, которая принимает оригинальный MethodDescription дескриптора метода, строку в виде IDictionary<string, object> и номер строки в таблице и возвращает описание сгенерированного метода при выгрузке процесса в проект .csproj. Если не задано, описание формируется автоматически.

Пример генерации метода
public static WorkflowActionMethodDescriptor TaskInitMethod = new WorkflowActionMethodDescriptor()
	{
		ErrorDescription = "Возникла ошибка в скрипте инициализации", // Описание ошибки

		MethodName = "InitMethod", // Имя метода

		Parameters = new [] { new Tuple<string, string>("CardTask", "task") }, // метод принимает параметр с типом CardTask и именем task

		StorePath = new[] { "InitScript" }, // Текст метода будет хранится в поле InitScript
	};
Пример генерации методов по таблице
public static WorkflowActionMethodDescriptor TaskEventMethod = new WorkflowActionMethodDescriptor()
	{
		ErrorDescription = "Возникла ошибка в событии {0}", // Описание ошибки

		MethodName = "Event_", // Имя метода без суффикса

		Parameters = null, // метод без параметров

		StorePath = new[] { "Script" }, // Текст метода будет хранится в поле Script в каждой строке

		ComplexDescriptor = new WorkflowActionMethodsComplexDescriptor()
		{
			// Таблица со строками хранится по ключу Events в параметрах действия
			ListPath = new[] { "Events" },

			// Возвращаем Event_ + идентификатор строки для гарантирования уникальности имени метода
			GetMethodNameSuffix = (hash) => hash.TryGet<Guid>("RowID").ToString("N"),

			// Возвращаем описание ошибки с указанием имени события, где возникла ошибка
			GetErrorDescription =
				(text, hash) => LocalizationManager.Format(
					text,
					WorkflowEngineHelper.Get<string>(hash, "Event", "Name")),

			// Формируем описание метода с помощью имени события и номера строки
			GetMethodDescription =
				(text, index, hash) =>
					LocalizationManager.Format(
						"Событие {0} на строке {1}",
						WorkflowEngineHelper.Get<string>(hash, "Event", "Name"),
						index + 1),
		},
	};

Обработчик действия

Далее необходимо реализовать обработчик действия. Для этого необходимо создать свой тип для обработки действия. Он должен наследоваться от WorkflowActionBase. В базовый конструктор необходимо передать объект-дескриптор для данного действия. Создавать два класса для обработки по одному дескриптору нельзя. Реализованный тип необходимо зарегистрировать в Unity с указанием какого-нибудь уникального имени.
Для данного класса можно реализовать или переопределить следующий ряд методов:

  • Execute - основной метод, который выполняет обработку действия. Обязателен для реализации действия.
    Метод имеет следующие параметры:

    • context (тип IWorkflowEngineContext) - контекст обработки процесса.

    • scriptObject (тип IWorkflowEngineCompiled) - объект со всеми скомпилированными скриптами действия. Может быть равен null, если конкретное действие не содержит ни одного скрипта.

Пример

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

protected override void Execute(IWorkflowEngineContext context, IWorkflowEngineCompiled scriptObject)
{
    if (context.Signal.Type == WorkflowSignalTypes.Default)
    {
        var card = context.MainCard;

        int? stepID = context.Get<int?>("ActionSection", "Step", "ID"),
             stageID = context.Get<int?>("ActionSection", "Stage", "ID"),

        string stageName = context.Get<string>("ActionSection", "Stage", "Name"),
               stepName = context.Get<string>("ActionSection", "Step", "Name");

        card.Sections["MainLoanSection"].Fields["ProcessStepID"] = stepID;
        card.Sections["MainLoanSection"].Fields["ProcessStepName"] = stepName;
        card.Sections["MainLoanSection"].Fields["ProcessStagesID"] = stageID;
        card.Sections["MainLoanSection"].Fields["ProcessStagesName"] = stageName;
    }
}
  • Compile - метод, используемый системой для формирования дополнительных методов для компилируемых объектов по настройкам действия. Все основные методы действия, завязанные на данных действия должны быть описаны через дескрипторы методов в дескрипторе действия. Метод возвращает true, если есть методы для компиляции, иначе возвращает false.
    Метод имеет следующие параметры:

    • builder (тип IWorkflowCompilationSyntaxTreeBuilder) - объект, используемый для добавления новых методов для компиляции действия.

    • action (тип WorkflowActionStorage) - действие со всеми его параметрами.

Пример

Пример реализации метода:

public override bool Compile(IWorkflowCompilationSyntaxTreeBuilder builder, WorkflowActionStorage action)
{
	// Вызываем базовую реализацию метода
	var result = base.Compile(builder, action);

    // Получаем код скрипта
    var methodBody = action.Hash.TryGet<string>("Script");

    // Добавляем дополнительный метод только если задан основной метод скрипта
    if (!string.IsNullOrWhiteSpace(methodBody))
    {
        // Добавляем новый метод, возвращающий void с именем Script и без параметров.
        // В случае ошибки компиляции выведется сообщения вида: Ошибка в сценарии {0}, где {0} - имя объекта, в котором произошла ошибка, например "Ошибка в сценарии в действии "WorkflowScriptAction""
        builder
            .AddMethod(
                "void",
                "ScriptWithCallInfo",
                null,
                body: $"AddInfo(\"Method Script called\"); {methodBody}",
                errorDescription: "Ошибка в сценарии {0}");

        return true;
    }

    return result;
}
  • PrepareForExecute - метод, используемый системой при создании нового экземпляра действия. Используется для того, чтобы очистить новый экземпляр действия от ненужных параметров.
    Метод имеет следующие параметры:

    • actionState (тип WorkflowActionStateStorage) - объект экземпляра процесса.

    • context (тип IWorkflowEngineContext) - контекст обработки процесса.

Пример

Пример реализации метода:

public override void PrepareForExecute(WorkflowActionStateStorage actionState, IWorkflowEngineContext context)
{
    // Удаляем значение по ключу Script, т.к. сам текст скрипта нам не нужен для каждого экземпляра.
    actionState.Hash.Remove("Script");
}
  • PrepareForSave - метод, используемый системой при сохранении версии шаблона. Позволяет как-то модифицировать шаблон процесса при сохранении действия.
    Метод имеет следующие параметры:

    • action (тип WorkflowActionStorage) - сохраняемое действие.

    • node (тип WorkflowNodeStorage) - сохраняемый узел, к которому относится данное действие.

    • process (тип WorkflowProcessStorage) - сохраняемый шаблон процесса, к которому относится данный узел.

  • CheckActive - метод, используемый системой для проверки, является ли данное действие активным. Если хотя бы одно действие узла активно, экземпляр узла не удаляется.
    Метод имеет следующие параметры:

    • context (тип IWorkflowEngineContext) - контекст обработки процесса.

Пример

Пример реализации метода:

protected override bool CheckActive(IWorkflowEngineContext context)
{
	// Если в параметрах действия задан параметр с иеменм TaskID, то действие считается активным
	// За наличие или отсутствие данного значения обычно отвечает само действие (в методе Execute)
	return context.Get<Guid?>("TaskID").HasValue;
}

Обработчик редактора действия

Также необходимо реализовать обработчик для редактора действия. Для этого необходимо создать свой тип для обработки редактора действия. Он должен наследоваться от WorkflowActionUIHandlerBase. В базовый конструктор необходимо передать объект-дескриптор для данного действия. Создавать два класса для обработки по одному дескриптору нельзя. Реализованный тип необходимо зарегистрировать в Unity с указанием какого-нибудь уникального имени.
Для данного класса можно реализовать или переопределить следующий ряд методов:

  • UpdateFormAsync - метод обновления формы редактора действия при ее первом открытии. Может использоваться для организации работы UI редактора действия. Реализация по умолчанию ничего не делает.
    Метод имеет следующие параметры:

    • action (тип WorkflowStorageBase) - редактируемое действие. Может иметь тип WorkflowActionStorage или WorkflowActionStateStorage в зависимости от того, происходит редактирование шаблона или экземпляра действия.

    • node (тип WorkflowStorageBase) - узел, которому принадлежит редактируемое действие. Может иметь тип WorkflowNodeStorage или WorkflowNodeStateStorage в зависимости от того, происходит редактирование шаблона или экземпляра узла.

    • process (тип WorkflowStorageBase) - редактируемый процесс. Может иметь тип WorkflowProcessStorage или WorkflowProcessStateStorage в зависимости от того, происходит редактирование шаблона или экземпляра процесса.

    • cardModel (тип ICardModel) - модель карточки редактора действия. Содержит в себе все контролы редактора и объект карточки, сгенерированный для действия.

    • actionTemplate (тип WorkflowActionStorage) - шаблон действия, к которому относится редактируемый экземпляр. Данный параметр передается только, если происходит редактирование экземпляра действия.

    • cancellationToken (тип CancellationToken) - объект, с помощью которого можно отменить асинхронную задачу.

Пример

Пример реализации метода, в котором мы очищаем значение одного поля, если производится установка значения другого поля:

public override Task UpdateFormAsync(
    WorkflowStorageBase action,
    WorkflowStorageBase node,
    WorkflowStorageBase process,
    ICardModel cardModel,
    WorkflowActionStorage actionTemplate = null,
    CancellationToken cancellationToken = default)
{
    var card = cardModel.Card;
    var mainSection = card.Sections["MainSection"];
    mainSection.FieldChanged += (s, e) =>
    {
        switch (e.FieldName)
        {
            case "Period":
                if (e.FieldValue != null)
                {
                    mainSection.Fields["Planned"] = null;
                }
                break;
            case "Planned":
                if (e.FieldValue != null)
                {
                    mainSection.Fields["Period"] = null;
                }
                break;
        }
    };

    Task.CompletedTask;
}
  • InvalidateFormAsync - метод, вызываемый системой при завершении жизни редактора действия. Может использоваться для аннулирования подписок на события или высвобождения неких ресурсов, если действие использует что-то подобное. Реализация по умолчанию ничего не делает.
    Метод имеет следующие параметры:

    • cardModel (тип ICardModel) - модель карточки редактора действия. Содержит в себе все контролы редактора и объект карточки, сгенерированный для действия. Имеет значение null, если форма редактора действия не открывалась.

    • cancellationToken (тип CancellationToken) - объект, с помощью которого можно отменить асинхронную задачу.

  • Validate - метод, вызываемый при валидации действия. Возвращает объект ValidationResult с сообщением о результате валидации. Реализация по умолчанию возвращает ValidationResult.Empty
    Метод имеет следующие параметры:

    • action (тип WorkflowActionStorage) - действие, валидация которого происходит.

    • node (тип WorkflowNodeStorage) - узел, которому принадлежит проверяемое действие.

    • process (тип WorkflowStorageBase) - процесс, к которому принадлежит проверяемое действие.

Пример

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

public override ValidationResult Validate(
    WorkflowActionStorage action,
    WorkflowNodeStorage node,
    WorkflowProcessStorage process)
{
    if (string.IsNullOrWhiteSpace(action.Hash.TryGet<string>("Script")))
    {
        return ValidationResult.FromText(
            GetValidateFieldMessage(action, node, "Сценарий"),
            ValidationResultType.Warning);
    }

    return ValidationResult.Empty;
}
  • AttachToCardCore - метод, вызываемый системой для организации привязки данных карточки редактора действия и параметров действия, а также для создания привязки параметров действия к связям. Реализация действия по умолчанию организует привязку параметров по следующим правилам:

    • Все строковые секцие содержатся в структуре вида

      SectionName: {
          FieldName1: Value1,     -- Физическая колонка
          FieldName2: Value2,     -- Физическая колонка
          ...
          ComplexFieldName: {     -- Комплексная колонка
              FieldName1: Value1  -- Физическая колонка комплексной колонки (имя без префикса)
              ...
          }
      }
    • Все строки и поля табличных секций содержатся в структуре вида

      SectionName: [
          {                           -- Строка 1
              RowID: <RowID>,         -- ID строки
              FieldName1: Value1,     -- Физическая колонка
              FieldName2: Value2,     -- Физическая колонка
              ...
              ComplexFieldName: {     -- Комплексная колонка
                  FieldName1: Value1  -- Физическая колонка комплексной колонки (имя без префикса)
                  ...
              }
          },
          {                           -- Строка 2
              RowID: ...
              ...
          },
          ...
      ]

Метод имеет следующие параметры:

  • bindingContext (тип WorkflowEngineBindingContext) - контекст привязки параметров к карточке редактора.

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

  • AttachEntrySection - производит привязку строковой секции с указанным именем по указанному пути.

  • AttachTableSection - производит привязку табличной секции с указанным именем по указанному пути.

  • AttachField - производит привязку поля строковой секции с заданным именем и типом по указанному пути. Предварительно нужно заполнить bindingContext.Section для использования данного метода.

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

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

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

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

Привязка параметров к связям процесса позволяет своевременно обновлять параметры, которые имеют ссылку на связь.

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

Пример

Пример реализации метода для действия задания:

protected override void AttachToCardCore(WorkflowEngineBindingContext bindingContext)
{
    // Привязываем поле InitTaskScript к шаблону, предварительно указав секцию, в которой производится привязка
    bindingContext.Section = bindingContext.Card.Sections.GetOrAdd(WorkflowActionTypes.TaskSectionName);
    AttachFieldToTemplate(
        bindingContext,
        "InitTaskScript",
        typeof(string),
        WorkflowActionTypes.TaskSectionName,
        "InitTaskScript");

    // Привязываем оставшиеся поля секции
    AttachEntrySection(
        bindingContext,
        WorkflowActionTypes.TaskSectionName,
        WorkflowActionTypes.TaskSectionName);

    // Привязываем табличные секции к шаблону действия
    AttachTableSectionToTemplate(
        bindingContext,
        WorkflowActionTypes.TaskOptionsSectionName,
        WorkflowActionTypes.TaskOptionsSectionName);

    AttachTableSectionToTemplate(
        bindingContext,
        WorkflowActionTypes.TaskOptionLinksSectionName,
        WorkflowActionTypes.TaskOptionLinksSectionName);

    AttachTableSectionToTemplate(
        bindingContext,
        WorkflowTaskActionBase.EventsSectionName,
        WorkflowTaskActionBase.EventsSectionName);

    // Указываем привязку к связям поля LinkID из секции с вариантами завершения
    AddLinkBinding(bindingContext, new [] { "Link", "ID" }, WorkflowActionTypes.TaskOptionLinksSectionName);
}

8.4. Создание расширений на проверку доступа к тайлам

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

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

Тип карточки с расширением должен опираться на не виртуальные секции для хранения данных, а также должен иметь секцию BusinessProcessButtonExtension со всеми ее полями.

Интерфейс IWorkflowEngineTileManagerExtension имеет следующие свойства:

  • ID (тип данных Guid) - уникальный идентификатор расширения.

  • ExtensionTypeID (тип данных Guid) - идентификатор типа карточки расширения.

  • Name (тип данных string) - отображаемое имя расширения.

  • Order (тип данных int) - определяет порядок отображения контролов в окне настройки кнопки.

Интерфейс IWorkflowEngineTileManagerExtension имеет следующие методы:

  • CheckTileAccessForVisibility - метод для проверки доступа к группе тайлов на видимость. Данный метод получает список идентификаторов проверяемых тайлов и карточку, для который выполняется проверка. Для глобальных тайлов объект card равен null. Метод возвращает список идентификаторов тайлов, для которых проверка прошла успешно.
    Пример реализации метода для проверки состояния карточки:

    public override IEnumerable<Guid> CheckTileAccessForVisibility(List<Guid> tileIDs, Card card)
    {
        // Если проверка идет вне контекста карточки, то возвращаем полный список тайлов
        if (card == null)
        {
            return tileIDs;
        }
    
        using (dbScope.Create())
        {
            var db = dbScope.Db;
    
            if (card.Sections.TryGetValue("KrApprovalCommonInfoVirtual", out var krSection)
                && krSection.Fields.TryGetValue("StateID", out var stateIDObj))
            {
                var stateID = stateIDObj == null ? 0 : (int)stateIDObj;
    
                // запрос на проверку состояния карточки
                return db.SetCommand(
                    dbScope.BuilderFactory
                        .Select().C("bpbe", "ButtonRowID")
                        .From("KrCheckStateTileExtension", "s").NoLock()
                        .InnerJoin("BusinessProcessButtonExtension", "bpbe").NoLock()
                            .On().C("s", "ID").Equals().C("bpbe", "ID")
                        .Where().C("s", "StateID").Equals().P("StateID").And().C("bpbe", "ButtonRowID").In(tileIDs)
                        .Build(),
                    db.Parameter("StateID", stateID))
                    .LogCommand()
                    .ExecuteScalarList<Guid>();
            }
        }
    
        // Если карточка не имеет состояния, то возвращаем пустой список
        return EmptyHolder<Guid>.Collection;
    }
  • CheckTileAccessForExecute - метод для проверки доступа на исполнение конкретного тайла. Метод возвращает результат валидации проверки доступа.
    Данный метод получает в качестве параметров:

    • tileInfo (тип данных WorkflowEngineTile) - объект со всеми данными исполняемого тайла.

    • cardID (тип данных Guid) - идентификатор карточки, в рамках которой происходит исполнение тайла.

    • cardGetter (тип данных Func<Card>) - функция для получения объекта карточки.
      Пример реализации метода для проверки состояния карточки:

      public override ValidationResult CheckTileAccessForExecute(WorkflowEngineTile tileInfo, Guid cardID, Func<Card> cardGetter)
      {
          using(dbScope.Create())
          {
              var result = db.SetCommand(
                  dbScope.BuilderFactory
                      .Select().Top(1).V(true)
                      .From("KrCheckStateTileExtension", "s").NoLock()
                      .InnerJoin("BusinessProcessButtonExtension", "bpbe").NoLock()
                          .On().C("bpbe", "ID").Equals().C("s", "ID")
                      .LeftJoin("KrApprovalCommonInfo", "kr").NoLock()
                          .On().C("kr", "MainCardID").Equals().P("CardID")
                      .Where().C("s", "StateID").Equals().Coalesce(b => b.C("kr", "StateID").V(0))
                          .And().C("bpbe", "ButtonRowID").Rquals().P("TileID")
                      .Build(),
                  db.Parameter("CardID", cardID),
                  db.Parameter("TileID", tileInfo.TileID))
                  .LogCommand()
                  .ExecuteScalar<bool?>() ?? false;
      
              if (result)
              {
                  return ValidationResult.Empty;
              }
              else
              {
                  return ValidationResult.FromText(
                      this,
                      "$KrTileExtensions_CheckState_AccessDenied",
                      ValidationResultType.Error);
              }
          }
      }

Интерфейс IWorkflowEngineTileManagerUIExtension имеет следующие свойства:

  • ID (тип данных Guid) - уникальный идентификатор расширения. Должен соответствовать ID расширения, указанном в классе расширения, реализующем IWorkflowEngineTileManagerExtension.

Интерфейс IWorkflowEngineTileManagerUIExtension имеет следующие методы:

  • ModifyButtonRow - Метод для модификации значения в колонке Настройки для строки из таблицы кнопок бизнес-процесса.
    Данный метод получает в качестве параметров:

    • context (тип данных IWorkflowEngineTileManagerUIExtensionContext) - контекст для обработки расширений IWorkflowEngineTileManagerUIExtension. Для добавления данных следует использовать StringBuilder по свойству context.Result.
      Пример реализации метода:

      public void ModifyButtonRow(IWorkflowEngineTileManagerUIExtensionContext context)
      {
      	// Если для интересующей нас секции нет строк с данными, то в настройки ничего не записываем
      	if (context.AllButtonRows.TryGetValue(extendedSectionName, out var contextRoleRows)
      		&& contextRoleRows.Count > 0)
      	{
      		// Если другие настройки уже произвели запись результата, то записываем с новой строки
      		if (context.Result.Length > 0)
      		{
      			context.Result.AppendLine();
      		}
      
      		context.Result.Append(LocalizationManager.Localize("$KrTileExtensions_CheckState_States"));
      		context.Result.Append(string.Join("; ", contextRoleRows.Select(x => LocalizationManager.Localize((string)x["StateName"]))));
      	}
      }

8.5. Создание кастомного базового класса процесса

Для создания своего базового класса процесса нужно реализовать новый класс, наследуемый от WorkflowEngineCompiledBase, и зарегистрировать его в IWorkflowEngineCompiledBaseRegistry. Реализованный базовый класс обязательно должен иметь атрибут public и не иметь атрибута sealed, а также иметь конструктор без параметров.

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

Пример

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

using Tessa.Cards;
using Tessa.Workflow.Compilation;

namespace Tessa.Extensions.Demo.Server.WorkflowEngine.Wfe
{
    public class WfeCompiledBase : WorkflowEngineCompiledBase
    {
        public void SetParams(CardTask task)
        {
            Signal.TaskID = task.RowID;
            Signal.PerformerID = task.UserID;
        }
    }
}

Вот пример его регистрации:

this.UnityContainer.Resolve<IWorkflowEngineCompiledBaseRegistry>()
    .Register<WfeCompiledBase>(new Guid("8555B8AA-A035-45F8-B216-0F96D443D07E"), "Тестовый базовый класс")
    ;

9. Импорт процесса BPMN

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

Конвертацию процесса при необходимости можно доработать под свои нужды с помощью доработки или реализации своих конвертеров объейтов нотации BPMN. Более подробно об этом написано в разделе Доработка конвертации процесса.

Для того, чтобы импортировать процесс, нужно:

  1. Открываем или создаем шаблон бизнес-процесса, открываем версию процесса, в которую хотим импортировать структуру процесса из BPMN.

  2. Нажимаем кнопку "Импортировать" на панели с кнопками в редакторе процесса.

    workflowBPMN1

  3. В открывшемся окне выбираем тип файла - Процесс BPMN.

    workflowBPMN2

  4. Выбираем файл процесса и нажимаем кнопку "Открыть".

    workflowBPMN3

  5. Система конвертирует процесс BPMN в процесс на конструкторе бизнес-процессов.

    workflowBPMN4

9.1. Ограничения

Конструктор процессов не реализует нотацию BPMN 2.0 полностью, поэтому при импорте процесса, описанного с помощью данной нотации, есть ряд ограничений.

В базовой реализации конвертации процессов BPMN в процесс конструктора бизнес-процессов игнорируются следующие элементы BPMN:

  • Пулы и линии (Pools and Lanes). Все содержимое пулов и линий конвертируется.

  • Потоки сообщений (Message flow), которые идут от/к пулу. Система конвертирует потоки сообщений, которые соединяют узлы различных пулов.

  • Задача хореографии (Choreography Task).

  • Объект данных (Data Object).

  • Сообщение (Message).

  • Группа (Group).

  • Соединитель страниц (Off-Page Connector).

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

В базовой реализации конвертации процессов BPMN в процесс конструктора бизнес-процессов следующие элементы BPMN имеют ограничения и особенности при конвертации:

  • Поток операций (Sequence Flow) - в процесс на конструкторе не передается информацию о типе потока операций (условный, по умолчанию). Данные настройки в бизнес-процессе конструктора определяются настройкой условий в связи.

  • Текстовая аннотация (Text Annotation) - в BPMN текстовая аннотация может быть привязана к нескольким элементам с помощью ассоциаций (Association). Текстовые аннотации в конструкторе могут быть привязаны только к одному элементу, поэтому при конвертации текстовой аннотации из BPMN переносится связь только с первым элементом (первый элемент определяется структурой данных процесса).

  • Действие (Activity) - настройки действия Цикличность действия (Activity Looping), Многоэкземплярность (Multiple Instances) и Маркер Ad Hoc (Ad-Hoc Marker) не переносятся в бизнес-процесс конструктора. Логика данных настроек в бизнес-процессе определяется действиями в узле и входящими в узел связями.

  • Подпроцес (Sub-Process) и Транзакция (Transaction) - данные элементы не переносятся в процесс, написанный на конструкторе, но переносяится содержимое данных процессов. Обусловлено это тем, что в конструкторе процессов нет поддержки подпроцессов встроенных в процесс. Все подпроцессы создаются как отдельные шаблоны процесса.

9.2. Настройка импортированного процесса

Рассмотрим абстракный процесс согласования заявки на отпуск. В нотации BPMN он мог бы выглядеть примерно следующим образом:

workflowBPMN5

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

workflowBPMN6

В первую очередь можно поправить внешний вид процесса в конструкторе:

workflowBPMN7

Узел запуска процесса по умолчанию ожидает сигнал Start. Оставим данное поведение и не будем дополнительно настраивать действия данного узла.

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

workflowBPMN8

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

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

workflowBPMN9

При использовании действия Уведомление с действием Задание следует ограничить список обрабатываемых сигналов, указав обрабатываемый сигнал Default. В противном случае при каждом действии с заданием (взятие в работу, возврат на роль, завершение) система будет отправлять уведомление.
Действие Задание в настройках имеет поле Уведомление, которое позволяет указать уведомление, которое придет исполнителю задания при его создании. Это позволяет отправить и задание и уведомление одним действием.

Объединять данные узлы не обязательно, иногда бывает полезно визуально показать в процессе, что происходит отправка уведомления.

Узлы с отправкой уведомления о согласовании, не согласовании и доработки заявки настраиваются по одной схеме:

  1. Добавляем действие Уведомление

  2. Удаляем действие Сценарий

  3. Настраиваем действие Уведомление, чтобы соответствующ сотруднику приходило соответствующее уведомление.

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

Узел завершения процесса не требует доработки и по умолчанию завершает данный процесс при переходе на него.

9.3. Доработка конвертации процесса

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

Для того, чтобы реализовать свой конвертер объекта BPMN нужно:

  1. Сделать свою реализацию интерфейса IWorkflowEngineBPMNObjectConverter<T>, где T - тип конвертируемого объекта BPMN (список всех типов находится в пространстве имен Tessa.Workflow.BPMN.Classes). Лучше всего использовать в качестве базового класса WorkflowEngineBPMNObjectConverterBase<T> или его открытого наследника, в зависимости от объекта, для которого создается конвертер.

  2. Зарегистрировать ваш класс в Unity.

  3. Зарегистрировать ваш класс в IWorkflowEngineBPMNObjectConverterResolver с указанием в качестве ключа - тип объекта, для которого будет использоваться конвертер (тип T из первого пункта).

Все платформенные конвертеры находятся в пространстве имен Tessa.Workflow.BPMN.Converters.

Пример переопределения конвертера для объекта tUserTask (задание пользователя):

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Tessa.Platform.Storage;
using Tessa.Workflow.Actions.Descriptors;
using Tessa.Workflow.BPMN.Classes;
using Tessa.Workflow.Storage;

namespace Tessa.Workflow.BPMN.Converters
{
    public class MyTUserTaskConverter : TUserTaskConverter
    {
        #region Constructors

        public MyTUserTaskConverter(IWorkflowEngineBPMNObjectConverterResolver objectConverterResolver)
            : base(objectConverterResolver)
        {
        }

        #endregion

        #region Base Overrides

        protected override async Task PrepareForConvertAsyncCore<CoreT>(IWorkflowEngineBPMNObjectConverterContext<CoreT, tUserTask> context)
        {
            await base.PrepareForConvertAsyncCore(context);

            // Базовая реализация создает узел WE для элементов узлов BPMN и записывает его в context.BPMNObjectInfo["Node"]
            WorkflowNodeStorage node = context.BPMNObjectInfo.TryGet<WorkflowNodeStorage>("Node");

            var name = node.Name;

            // Добаляем действие Задание
            var action = node.Actions.Add();
            action.ActionTypeID = WorkflowActionDescriptors.TaskDescriptor.ID;
            action.Order = 0;
            action.Caption = name;
            action.Hash = new Dictionary<string, object>(StringComparer.Ordinal)
            {
                // Здесь можно заполнить параметры действия некими настройками
            };
            action.SetName(name);
        }

        protected override string GetNodeName(tUserTask element)
        {
            // Переопределяем имя для узлов данного типа в WE
            return "UserTask";
        }

        #endregion
    }
}

Пример его регистрации:

// Регистрируем в Unity
this.UnityContainer.RegisterType<MyTUserTaskConverter>(new ContainerControlledLifetimeManager());

// Регистрируем как конвертер для объекта
this.UnityContainer.Resolve<IWorkflowEngineBPMNObjectConverterResolver>()
    .Register<MyTUserTaskConverter>(typeof(tUserTask))
    ;