Конструктор процессов

Окно запуска и параметры процесса

Щелкните элемент StartEvent (Событие начала процесса) на холсте. Свойства элемента StartEvent будут отображаться на панели свойств. В разделе Основное заполним поле Id как StartEvent1. Это идентификатор процессной задачи. Каждая задача в модели должна иметь уникальный Id. Настоятельно рекомендуем заполнять это и другие поля подобных идентификаторов с использованием только латинских букв, т.к. этот Id может использоваться в программном коде скриптов и отчетов.

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

В раскрывающемся списке Тип формы доступно несколько значений.

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

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

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

Заполним поля в появившемся окне:

• Процессная переменная – назовем ее userList. Для хранения своих данных бизнес-процесс использует переменные.

• В поле Заголовок напишем – Согласующие.

• Тип – выберите из выпадающего списка значение User list (список пользователей) т.к. в нашем примере согласовывать документ будут несколько участников.

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

• Поставим флажок Обязательный – для запуска и работы нашего процесса список участников согласования — это обязательный параметр.

• Поле Компонент UI (пользовательского интерфейса) оставим заполненным по умолчанию. Для экранов запуска процессов согласования это не имеет значения т.к. для параметров (с типом User list и User) будет использоваться привычный компонент выбора из справочника Подразделения.

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

Теперь можно перейти к созданию процессных задач.

Процессные задачи

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

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

Для этого нужно выбрать элемент StartEvent и щелкнуть значок Append task во всплывающем меню:

А потом выберем значок Change type чтобы сменить тип задачи на «Пользовательскую задачу» (User Task):

На панели инструментов заполним id задачи - Task_approval и Имя задачи - Согласовать.

Теперь укажем, что наша задача многоэкземплярная (предназначена не для единственного исполнителя, а для списка участников) и должна выполняться «параллельно» (т.е. должна быть направлена на исполнение сразу всем ее участникам). Настроить это можно ниже, в разделе Многоэкземплярная.

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

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

Просто нажмем кнопку Да и позволим конструктору самостоятельно донастроить нашу задачу.

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

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

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

Для пользовательских задач в процессах согласования следует выбирать Тип формы – Диалоговое окно. На этом окне будут размещены обязательные для бизнес-логики согласования документов поля:

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

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

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

Можно задать режим открытия этого окна. Обычно это Диалог – небольшое окно открывается поверх других окон на экране.

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

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

Стандартными для бизнес-логики согласования вариантами решения являются:

1. Согласен – полностью согласен с текстом документа.

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

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

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

Для каждого варианта решения надо указать:

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

   • approve - согласен;

   • approveWithRemarks – согласен с незначительными замечаниями;

   • reject – не согласен, отклоняю;

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

2. Заголовок – понятное для пользователя обозначение решения. То, как будет выглядеть надпись этого решения на экране у пользователя.

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

Выше, на снимке экрана, мы заполнили три типичных варианта решения для задачи согласования: Согласен, Не согласен, Согласен с замечаниями.

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

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

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

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

Выберите в модели нашу задачу Согласовать и щелкните значок Append task во всплывающем меню:

А потом выберем значок , чтобы сменить тип задачи на «Вызов сервиса» (Service Task):

Теперь наша задача выглядит вот так

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

1. В разделе Основное отредактируем Id задачи, чтобы сделать его более информативным - Task_Result. И напишем Имя задачи - Определение результата.

2. В разделе «Подробности» поле Тип оставим без изменения (Бин Spring). Выберем в выпадающем списке Имя бина (сервиса) - simpledoc_BprocVedocApproveService. Это сервис Ведок, предоставляющий вспомогательные методы для процессов согласования. Здесь работает подбор содержимого по мере ввода, ускоряя выбор

   

   А в поле Метод выберите значение setStandardApprovePrecessResult(String executionId). Что делает этот метод – будет рассказано ниже.

3. В разделе Параметры метода введите параметр execution.id и поставьте флажок «переменная». Здесь execution.id - это служебная процессная переменная, она указывает на наш экземпляр процесса в котором мы хотим определить результат согласования.

Больше для этой задачи ничего настраивать не потребуется.

Мы создали задачу «Определение результата» для вызова вспомогательного сервиса Ведок и его метода setStandardApprovePrecessResult, который найдет выполняющийся процесс используя переменную execution.id, разберет все решения участников согласования и установит стандартный результат согласования данной версии документа.

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

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

Для этого, аналогичным образом создадим последнюю задачу с типом Вызов сервиса в модели процесса и присвоим для нее Имя «Установка статуса».

Раздел «Подробности» для задачи заполним абсолютно аналогично, но в поле Метод выберем setStandardDocStatus(String executionId).

Этот метод сервиса устанавливает статус документа, соответствующий результату согласования.

Мы реализовали в модели весь наш бизнес-процесс. Остается последний шаг - добавим событие завершения процесса (End event) и укажем его имя «Завершение процесса».

Завершенная модель нашего простого процесса выглядит так:

Развертывание процесса

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

Проверка работы процесса

Теперь проверим, как работает созданный нами процесс в Ведок.

Зайдем в Ведок под одним из пользователей, которому мы разрешили запуск нашего процесса «Согласование КП». Создадим новое коммерческое предложение или откроем существующее.

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

Выберем его и попробуем запустить.

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

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

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

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

Откроется экран с подробными данными об истории согласования данной версии документа. На вкладке Ход выполнения мы видим какое решение приняли участники нашего тестового согласования КП.

А на вкладке Диаграмма можем увидеть знакомое нам графическое представление процесса, созданного нами в конструкторе, в нотации BPNM 2.0 .

Окно запуска и параметры процесса

Для события StartEvent (Событие начала процесса) на холсте укажем имя «Старт процесса».

В разделе Форма укажем Тип формы Диалоговое окно и определим параметры, которые нужно будет ввести на экране запуска процесса.

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

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

Добавим в диалоговое окно запуска параметр с именем процессной переменной userList, типом User list (список пользователей) и заголовком Согласующие. После этого добавим параметр для указания того, кто будет делать финальное утверждение. Дадим процессной переменной имя finalApproveUser, типом User и заголовком Утверждающий.

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

Процессные задачи: первый этап

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

Создадим в модели первую процессную задачу - Рассмотреть.

Для этого нужно выбрать элемент StartEvent и щелкнуть значок Append task во всплывающем меню:

Сменим тип задачи на User task (Пользовательская задача), в разделе Основное в качестве Id укажем preApprove, а в поле Имя «Предв. рассмотрение». Срок предварительного рассмотрения в нашем примере не ограничивается, поэтому поле Срок исполнения мы оставим пустым.

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

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

В разделе Исполнители для поля Источник исполнителей выберем значение Поставщик пользователей. А после этого в поле Поставщик пользователей в выпадающем списке выберем значение simpledoc_ChefOfInitiator (руководитель инициатора).

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

Если справочник Подразделения настроен как в примере на снимке экрана выше, то при запуске процесса согласования менеджером Отдела продаж (Затевахин Николай) поставщик пользователей simpledoc_ChefOfInitiator определит, что руководителем инициатора процесса является начальник отдела продаж (Новиков Николай).

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

Мы это уже делали в первом примере используя раздел Форма расположенный на правой панели.

Укажем Тип формы – Диалоговое окно. Режим открытия этого окна - Диалог.

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

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

Для этого добавим новый элемент Развилка.

Укажем Id элемента как ExclusiveGateway_Step1, а в качестве имени - «Развилка первого этапа».

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

Укажем для этой задачи Id mainApprove и имя «Основное согласование». Больше пока для задачи настраивать не будем.

Сразу создадим вторую задачу из Развилки с Id setRejectStatus и именем Результат согласования. Теперь модель нашего процесса выглядит так:

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

Для настройки условия перехода щелкните по стрелке, ведущей из Развилки к задаче Основное согласование, укажите id preApproveConfirm, имя Одобрено. После чего настроим условия перехода по этому пути.

В качестве Источника условия выберем Результат пользовательской задачи. В поле Пользовательская задача в выпадающем списке выберем нашу задачу Предв. рассмотрение. А в качестве Результата задачи, при котором процесс пойдет по этому пути выберем результат с кодом approve (Одобряю).

Аналогично настроим условия перехода к задаче Результат согласования в случае решения с кодом reject (Отклоняю). В качестве Id запишем preApproveReject, а в поле Имя заполним Отклонено.

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

Процессные задачи: второй этап (основное согласование)

Теперь настроим вторую задачу процесса - Основное согласование. Щелкните на полотне конструктора по этой задаче и измените ее тип на User task (Пользовательская задача).

И заполним ее параметры в панели справа – Id и Имя.

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

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

Если мы заполним поле Срок следующим образом ${approveDeadline}, то при выполнении процесса Ведок отобразит в этом поле значение переменной процесса approveDeadline. Но инициатор может не указывать Срок при запуске и не ограничивать время согласования. В виду технических особенностей платформы BPMN в этом случае в переменную approveDeadline будет записана дата 31.12.2099 в качестве «условно бесконечного» срока выполнения. Чтобы скрыть от пользователей это и некоторые другие технические нюансы работы с датами, заполним это поле следующим образом: ${simpledoc_BprocVedocApproveService.displayDeadlineDate(approveDeadline)}

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

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

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

А нам остается настроить раздел Форма в котором мы, как обычно, укажем Тип формы «Диалоговое окно» и предоставим участникам задачи варианты выбора Результата. Для задачи основного согласования решениями могут быть:

• «Согласен» (код approve)

• «Не согласен» (код reject)

• «Согласен с замечаниями» (код approveWithRemarks)

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

После этого изменим тип граничного условия на Таймер граничного события (Timer Boundary Event).

И заполним поля Id и Имя.

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

Выберите в поле Тип таймера значение Дата. А поле Дата заполните как ${approveDeadline}. Это укажет процессу, что таймер прерывания задачи процесса должен сработать в срок, который хранится в переменной approveDeadline.

Теперь задача Основное согласование будет прервана, если не завершится до указанного при запуске процесса срока.

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

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

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

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

В итоге наша модель приобретет вот такой вид

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

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

Теперь диаграмма процесса выглядит более наглядно.

Процессные задачи: третий этап (утверждение)

Сменим тип задачи Утверждение на User task (пользовательская задача). И настроим ее аналогично задаче Основное согласование с тем исключением, что у нас это однопользовательская задача.

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

И настроим диалоговое окно для выбора вариантов решений утверждающим решения: signed (Утверждаю) и reject (Отклоняю).

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

Остается добавить последнюю задачу Установка статуса документа. Добавим ее в модель перетащив из левого меню элементов. Заполним Имя и Id. И добавим в модель завершающий элемент – End Event (Событие завершения).

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

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

Настройка служебных задач процесса

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

В завершении разработки модели нового процесса – настроим эти задачи.

Задача Результат - Отменено выполняется после отмены выполнения процесса из-за нарушения срока основного согласования. Единственное ее назначение – установить результат согласования Отменено.

Изменим тип этой задачи на Script task (Выполнение скрипта) и заполним справа раздел Подробности.

Нажмем кнопку редактора скрипта и в открывшемся окне введем единственную строчку: return 'CANCELED' А в поле Переменная результата укажем служебную процессную переменную хранения результата процесса: approveProcessResult.

Задача Результат согласования тоже должна установить результат согласования, но определить его на основе решений участников процесса. Мы уже это делали в первом примере, настраивая его задачу Определение результата. Воспользуемся способом определения результата процесса при помощи сервиса simpledoc_BprocVedocApproveService сменив тип задачи на Service Task.

Задачу Установка статуса тоже настроим шаблонным способом, как мы это делали в первом примере.

Теперь мы завершили создание модели нового процесса.

Развертывание и проверка процесса

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

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

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

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

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

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

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

В нашем примере процесс мы запустили от имени менеджера отдела продаж, а руководителем отдела продаж является Новиков Николай (user5).

Зайдем в Ведок под этим пользователем и проверим папку На согласование. В папке есть активная задача по нашему процессу с наименованием Согласование партнерского договора и это именно задача Предв. рассмотрение – все как мы настроили в модели процесса.

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

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

Как и ожидалось, бухгалтер получил задачу Основное согласование по процессу Согласование партнерского договора.

При выполнении задачи основного согласования мы видим три варианта решения, определенных нами в модели процесса. Выберем Согласен.

Проделаем тоже самое под вторым участником основного согласования (Самоделкин, user1).

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

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

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

Созданный нами процесс работает корректно, так как мы это задумали.

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

Зарегистрируем еще один договор, запустим его на согласование с использованием нашего процесса, но в этот раз укажем Срок при запуске процесса. Для простоты тестирования отведем на согласование всего несколько минут.

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

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

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

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

У первого участника последовательного согласования, на котором произошло прерывание процесса, в качестве решения мы видим Автоотмена. Срок нарушен, результат согласования корректно установлен в значение Отменено.

Перейдя в согласуемый документ мы увидим, что в нем поле Статус установлено верно.

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

Стандартные процессные переменные

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

Предопределенные переменные для процесса согласования:

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

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

• approveEntity - ссылка на сущность (карточку) согласуемого документа.

• procStartDate - дата и время запуска экземпляра процесса.

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

Кроме того, доступна предопределенная переменная платформы BPM с именем execution, хранящая данные о текущем выполняемом процессе. Это может быть полезно для самостоятельного анализа решения по задачам процесса, вызова сервисов и т.п. (см. раздел Использование скриптов в модели процесса).

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

Коды стандартных решений по задачам согласования

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

• approve - согласен/подтверждаю. Такое решение по задаче процесса расценивается как положительное.

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

• reject – не согласен/отклоняю.

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

• taskDeadline - решение с таким id устанавливается автоматически для всех участников задачи, кто еще не успел вынести свое решение в момент прерывания задачи по таймеру. В интерфейсе Ведок решение отображается как «Автоотмена. Срок нарушен».

Стандартные значения результатов процесса согласования

Предопределённая переменная approveProcessResult хранит в себе результат процесса согласования. Результат процесса пользователи видят на экране экземпляра процесса

Или при просмотре истории согласования документа

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

Стандартные значения результатов согласования:

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

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

• WITH_REMARKS - есть замечания/с замечаниями. Проект не отклонен, но требует небольших доработок.

• REJECTED - отклонен. Процесс с таким статусом считается завершенным с отрицательным результатом.

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

• CANCELED - отменен/прерван. Такой результат устанавливается автоматически если процесс отменяется инициатором до его завершения. Или результат процесса CANCELED может быть установлен из модели процесса. Например, при отмене по таймеру срока.

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

Решения, вынесенные всеми участниками всех процессных задач тоже сохраняются в специальных процессных переменных. Имена этих переменных создаются особый «шаблонным» образом: [ID Задачи]_result .

Например, если в модели есть пользовательская задача с id «mainApprove» из нашей второй модели процесса, то решения по этой задаче будут сохранены в переменной с именем mainApprove_result.

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

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

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

Сервисы Ведок для использования в моделях процессов

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

1. Метод setStandardApprovePrecessResult(String executionId) - анализирует все решения по всем пользовательским задачам процесса и устанавливает результат согласования по стандартной логике в уже известную нам предопределенную переменную approveProcessResult. При этом используется следующий алгоритм определения результата процесса:

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

   • Если среди решений пользовательских задач нет решения signed, но есть хоть одно решение с кодом reject (отклонено/не согласен), то будет установлен результат согласования Отклонен.

   • Если нет решений signed и reject, но есть хоть одно решение с кодом approveWithRemarks (согласен с замечаниями), то будет установлен результат согласования С замечаниями.

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

2. Метод displayDeadlineDate(Date deadline) - предназначен для обработки дат в удобный для отображения вид. Например, значение поля Срок с экрана запуска процесса сохраняет свое значение в переменную approveDeadline. Но в виду технических особенностей применяемой платформы BPM, если поле не заполнено при запуске процесса, то в переменную сохраняется «условно-бесконечный срок» 31.12.2099. Метод позволяет обработать дату дедлайна и скрыть от пользователя не нужные ему технические тонкости. Для отображения пользователям дат рекомендуется использовать этот метод вместо прямого отображения значения процессной переменной.

3. Метод setStandardDocStatus(String executionId) - устанавливает стандартный статус «карточки» согласуемого в документа. Он это делает на основе кода результата процесса, хранимого в переменной approveProcessResult. Поэтому, перед вызовом этого метода результат процесса должен быть уже определен. Метод устанавливает для согласуемого документа тот статус, код которого совпадает с кодом результата процесса. В стандартной поставке Ведок значения Статусов в справочнике следующие:

   • «Согласован» - код APPROVED

   • «На согласовании» - код ON_APPROVE

   • «Отклонен» - код «REJECTED»

   • «С замечаниями» - код WITH_REMARKS

   • «Подтвержден» - код SIGNED

4. Есть метод setStandardApprovePrecessResult для расчета итога процесса из стандартной логики. Он заполняет переменную результата. Использование:

   

   Вызов его же через тип задачи «выражение»: ${simpledoc_BprocVedocApproveService.setStandardApprovePrecessResult(execution.id)}

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

   

6. Метод calcIsoDurationMinutes(Date startDate, Date deadline, Long assigneeNumber) - предназначен для расчета продолжительности выполнения задачи в Минутах для числа ее участников, указанных в параметре assigneeNumber. Параметр startDate - дата и время начала выполнения, deadline - дата и время окончания. Он возвращает результат в виде строки в формате ISO 8601 с продолжительностью выполнения на одного участника. Такую строку продолжительности можно использовать для Таймера напрямую, указав ему соответствующий тип параметра.

7. Метод calcIsoDurationMinutes(Date deadline, Long assigneeNumber) - очень похож на предыдущий, но считает продолжительность выполнения начиная с текущего момента и срока (deadline).

8. Метод Date calcDeadlineDate(Date startDate, int durationSeconds) - рассчитывает дату и время срока выполнения исходя из времени начала (startDate) и продолжительности в секундах. В отличие от предыдущих методов он возвращает значение с типом Date. Его не получится напрямую подставить в Таймер условия, но можно использовать в задачах выполнения скриптов, которые будут вычислять нужные даты и сроки.

9. Метод Date calcDeadlineDate(int durationSeconds) аналогичен предыдущему, но считает дату и время Срока начиная с текущего момента.

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

setEntityStatusByCode( String statusCode, @NotNull Entity entity)

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

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

Один из вариантов указания исполнителей пользовательской задачи процесса - использование Поставщиков пользователей (User provider).

В Ведок существуют следующие поставщики пользователей:

1. simpledoc_ChefOfInitiator - руководитель инициатора процесса. Этот поставщик определяет руководителя подразделения инициатора процесса, используя справочник Подразделения. Он найдет сотрудника, связанного с должностью с признаком «руководитель» в подразделении инициатора процесса и вернет соответствующий идентификатор пользователя.

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

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

4. simpledoc_ProcessInitiator - пользователь, инициировавший процесс.

Использование скриптов в модели процесса

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

Использование скриптов может быть достаточно широким. Например, ниже приведен скрипт для обработки решений процессной задачи c id «mainApprove» по нестандартной логике:

В первой строке скрипт обращается к данным текущего экземпляра процесса через предопределенную переменную execution и запрашивает процессную переменную с решениями по задаче с кодом id ainApprove. Как ранее было сказано, такая переменная результата задачи процесса имеет шаблонное имя [ID Задачи]_result.

Если переменная не пустая - скрипт сохраняет из нее все решения в переменную taskOutcomes, а далее проверяет есть ли среди решений по задаче решения, с интересующими нас id. Если среди решений есть хоть одно с id reject - скрипт возвращает в качестве результата REJECTED, во всех иных случаях он вернет результат APPROVED. Т.е. даже если среди решений встречается решение с кодом approveWithRemarks (согласен с замечаниями) - скрип все равно вернет результат APPROVED.

Если переменная решений по задаче mainApprove_result пустая (такое может быть, если задача завершилась с ошибкой) - скрипт вернет строку «Can not find result variable» (переменная результатов не найдена).

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

Полезные советы и приемы

1. В интерфейсе и в конструкторе для пользовательских задач есть поле «Срок исполнения». Само по себе оно справочное и не вызывает отмены задачи по таймеру. Например, укажем в поле «Срок» для задачи «Pre_Approve» срок завершения процесса, как он заполнен на экране запуска процесса. Он отразится на экране в качестве ориентира для исполнителей, но задача не будет прервана по таймауту при наступлении этого срока.

   

   Если срок необязателен – лучше использовать выражение, ${simpledoc_BprocVedocApproveService.displayDeadlineDate(approveDeadline)} т.к. в качестве бессрочной даты используется 31.12.2099 год. Этот метод преобразует дедлайн корректно и не покажет на экране странную для пользователя дату.

2. 

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

   

3. Если надо создать этап процесса с последовательным исполнением и назначением срока для каждого отдельного участника – создается подпроцесс с последовательным выполнением и однопользовательской задачей согласования внутри. Исполнители подпроцесса назначаются аналогично многопользовательской задаче. Исполнитель однопользовательской задачи назначается как выражение ${userList_item.id} (т.е. текущий элемент списка исполнителей подпроцесса). Чтобы результат выполнения исполнителем такой специальной однопользовательской задачи записывался в коллекцию как у стандартной многопользовательской задачи – надо в дополнительных свойствах указать свойство с именем aadditionMaterialsultiInstanceTask. В качестве примера можно использовать модель стандартного процесса « Последовательное согл. (персон.срок)», в которой используется этот прием.

4. Можно простой сервисной задачей менять статус документа указав код