Руководство оператора#

Доступ к приложению#

Доступ к Designer (BPMD) Platform V Flow (BPM) (далее – Platform V Flow Designer) осуществляется под учетной записью пользователя через сервис авторизации.

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

Ролевая модель описана в разделе «Ролевая модель».

Перечень браузеров, рекомендуемых для доступа оператора к пользовательскому интерфейсу, приведен в Руководстве по установке в разделе «Браузеры».

Безопасность АРМ оператора обеспечивается, исходя из уровня конфиденциальности информации и других требований ИБ.

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

Вход и выход из учетной записи#

Вход#

Для получения доступа к функциям приложения:

1. Запустите веб-браузер на своем устройстве.

2. В адресной строке браузера введите URL-адрес сервера приложения. Для получения URL-адреса сервера приложений обратитесь к администратору приложения.

3. Чтобы авторизоваться от имени пользователя, введите авторизационные данные (имя пользователя, пароль).

Выход#

Для выхода из учетной записи нажмите кнопку Выйти:

Появится сообщение:

Если недоступен сервис аутентификации или отсутствует подключение к сети, появится надпись:

В этом случае дождитесь восстановления сети и нажмите кнопку Войти.

Использование приложения оператором#

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

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

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

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

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

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

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

1. Создание модели процесса в среде разработки компонента BPMD.

2. Импорт моделей в среду исполнения компонента Engine (BPMX) продукта Platform V Flow (BPM).

3. Запуск модели на проигрывание в среде исполнения BPMX.

4. Выполнение действий оператора (если требуется) в компоненте TaskList (UTSK) продукта Platform V Flow (BPM).

5. Контроль завершения процесса в консоли администратора BPMX.

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

Компонент Designer (BPMD) продукта Platform V Flow (BPM) – это среда разработки и моделирования бизнес-процессов, позволяющая пользователю с помощью наглядных средств визуального проектирования запрограммировать бизнес-процесс для дальнейшего его исполнения.

Компонент BPMD решает следующие задачи:

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

• Подключение сервисов посредством протоколов http и json-rpc:

  • с использованием каталога сервисов МЕТА (не будет доступен внешним пользователям);

  • с помощью файла с описанием API в спецификации OpenAPI;

  • вручную.

• Бесшовное добавление задач, требующих участия пользователей в процесс.

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

• Механизм валидации и типизированные переменные среды сокращают количество ошибок при разработке.

Ролевая модель#

Системная роль#

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

Бизнес-роли#

• Владелец (owner).

• Менеджер (APPLICATION_FULL_ACCESS).

• Редактор (APPLICATION_EDIT).

• Наблюдатель (APPLICATION_VIEW).

Решение о наделении пользователя определенной ролью принимает Владелец/Менеджер. В рамках одного приложения пользователь может быть наделен только одной бизнес-ролью.

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

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

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

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

Объекты доступа#

Изменение уровня доступа (бизнес-роли) к контенту (приложению) осуществляется на вкладке Доступ в настройках приложения.

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

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

Файл - атомарный элемент Приложения, который может являться, например, моделью, json-формой, xml- или json- файлом, скриптом (JavaScript или Groovy), отладочным ресурсом.

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

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

Доступность функций с контентом описаны ниже.

Доступы при работе с шаблонами дистрибутива#

Доступы при работе с дистрибутивами#

Доступы при работе с приложениями#

Действия с файлами#

Блокировка совместного редактирования#

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

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

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

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

3. Разблокировка происходит при бездействии в течении N минут после сохранения модели или при завершении пользовательской сессии.

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

4. По истечении времени бездействия происходит снятие блокировки с файла.

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

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

Приложения#

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

Список приложений располагается на главной странице.

Список доступных действий с приложением размещен/отображается на главной странице.

В случае отсутствия настроек для выполнения действия - происходит переход в настройки приложения.

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

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

Создание приложения#

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

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

• Название – название приложения (обязательное поле при создании);

• Описание;

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

Для синхронизации приложения с внешним хранилищем:

Git – настройки подключения к Git:

• URL – путь к Git-репозиторию;

• Ветка – ветка в этом репозитории;

• Базовый путь – путь к папке с файлами моделей в репозитории;

Для назначения доступа к приложению:

Пользователи – создание списка пользователей: * Менеджер; * Редактор; * Наблюдатель.

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

Возможно запускать сразу на несколько настроенных путей и типов запуска.

Для типа запуска "Rest API Engine" также допустимо указание его в качестве отладочного, что подразумевает deploy и старт единичного процесса в Engine напрямую из BPMD.

Engine:

Тип – выбор из значений "DPM"/"Rest API Engine";

• Для "DPM":

  • Deployment endpoint - URL до точки, куда необходимо направить модель;

  • Код объекта релизной деятельности;

  • Версия.

• Для "Rest API Engine":

  • Deployment endpoint - URL до точки куда необходимо направить модель;

  • Launch endpoint - URL модуля Gateway, через который вызывается исполнение процесса (при использовании для отладки);

  • ID модуля - уникальное наименование модуля bpmx-engine, что указывается как id в конфигурационном файле компонента BPMX (при использовании для отладки);

  • UI отладчика - URL UI консоли компонента BPM User Plane (BPMU) продукта Platform V Flow (BPM) - сетевой адрес тестовой консоли без дополнительных endpoint до ресурсов (при использовании для отладки).

Для "DPM"

Для "Rest API Engine"

Редактирование параметров приложения#

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

Для редактирования доступны те же поля, что и при создании приложения.

Удаление приложения#

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

Для этого необходимо перейти в настройки приложения и на вкладке Общее нажать кнопку Удалить приложение.

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

Создание шаблона дистрибутива#

Создание и просмотр существующих шаблонов приложения доступно в настройках приложения на вкладке Шаблоны.

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

Создание дистрибутива#

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

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

Следующим шагом является создание и конфигурация/выбор ранее созданного шаблона дистрибутива.

width=1000px}

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

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

• Опубликовывать в Engine (только для зафиксированного);

• Синхронизировать в Git (только для зафиксированного);

• Просмотреть историю действий;

• Скачать архивом;

• Удалить (только для незафиксированного).

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

Дистрибутивы имеют статусную модель:

• Draft – не зафиксировано (отправка в Git и BPMX не разрешена). Стартовый статус для каждого нового дистрибутива. При статусе Draft можно вносить изменения, например, выбирать нужные версии моделей из приложения в дистрибутиве и т.п.

• Ready – фиксация осуществляется с новой кнопкой замочек. Статус Ready появляется в момент фиксации дистрибутива. Фиксировать дистрибутив могут пользователи с уровнем доступа Владелец и Менеджер и Редактор. Обратный переход невозможен. После фиксации дистрибутив становится доступным к отправке в Git и запуску в BPMX.

При нажатии на значок появляется всплывающее окно с подсказкой.

Запуск релизов в BPMX (с выбором множества настроек) и отправка в Git (с приложением релиза сравнения)#

• При нажатии на Отправить в Git результат сравнения публикуемого релиза с другим зафиксированным релизом этого приложения появляется модальное окно Приложить результаты сравнения:

  • если список релизов пустой, тогда появляется подсказка «Нет других зафиксированных релизов» и кнопка «Отправить в Git результат сравнения публикуемого релиза с другим зафиксированным релизом этого приложения» не активна;

  • если список релизов не пустой, тогда кнопка «Отправить в Git результат сравнения публикуемого релиза с другим зафиксированным релизом этого приложения» – активна.

• При изменении приложения появляется Выберите релиз для сравнения:

  • при клике на «Выберите релиз для сравнения» появляется выпадающий список номеров зафиксированных релизов приложения;

  • пользователь выбирает релиз, с которым будет сравнение. При клике на кнопку «Опубликовать»:

  • форма и кнопка блокируются;

  • на странице с релизами отображается статус синхронизации «В процессе»;

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

• Результаты публикации бывают нескольких видов:

  • ошибка при публикации. Если при публикации произошла ошибка, то пользователю отобразить сообщение «При публикации релиза <номер релиза> возникла ошибка»;

  • успешная публикация:

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

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

Примеры активных и неактивных кнопок при отправке в Git (с приложением релиза сравнения):

Примеры возможных пользовательских сценариев (Rest API)#

Настройка запуска в BPMX при создании нового приложения#

Основной поток

1. Пользователь авторизуется в BPMD (далее Платформа).

2. Открывает окно создания нового приложения (нажимает на кнопку Создать приложение/"Create application").

3. Вводит название приложения и переходит во вкладку Запуск/"Run".

4. Нажимает на кнопку Добавить настройку.

5. Заполняет следующие поля: 5.1. Название: нужное название настройки. 5.2. Тип: выбирает значение REST API Engine. 5.3. Endpoint: заполняет не по регулярному выражению.

6. Платформа подсвечивает поле красным и выводит подсказку Неверный формат URL/"Invalid URL format".

7. Пользователь в поле Endpoint исправляет значение: вводит его по регулярному выражению.

8. Нажимает на кнопку Добавить еще настройку.

9. Платформа отображает поля для ввода новой настройки: 9.1. Название. 9.2. Тип.

10. Пользователь заполняет следующие поля: 10.1. Название: нужное название настройки. 10.2. Тип: выбирает значение REST API Engine. 10.3. Endpoint: заполняет его по регулярному выражению так, что значение = значению из пункта 7.

11. Платформа подсвечивает поле Endpoint оранжевым и выводит подсказку: Такой endpoint уже существует/ "This endpoint is already exists".

12. Пользователь нажимает Создать/"Create".

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

14. Кнопка Запустить/"Run" доступна.

Альтернативные потоки

• Если Пользователь не ввел endpoint.

Альтернативный поток начинается после пункта 5.2 основного потока:

1. Пользователь оставил пустым поле Endpoint и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь не ввел название.

Альтернативный поток начинается после пункта 4 основного потока:

1. Пользователь оставил пустым поле «Название» и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь вводит дублирующее название.

Альтернативный поток начинается после пункта 10.1 основного потока:

1. Пользователь ввел название настройки, которая уже существует и нажимает на кнопку Создать»/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Такое название уже существует/"This name is already exists".

Настройка запуска в BPMX в существующем приложении#

1. Пользователь авторизуется в BPMD.

2. Выбирает существующее приложение.

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

4. Наводит курсор на кнопку Настроить приложение/"Customize the application".

5. Платформа открывает окно настроек приложения

6. Пользователь переходит во вкладку Запуск/"Run" и нажимает на кнопку Добавить настройку.

7. Заполняет следующие поля: 7.1. Название: нужное название настройки.
   7.2. Тип: REST API Engine.
   7.3. Endpoint: вводит не по регулярному выражению.

8. Платформа подсвечивает поле красным и выводит подсказку Неверный формат URL/"Invalid URL format".

9. Пользователь в поле Endpoint исправляет значение: вводит его по регулярному выражению.

10. Пользователь нажимает на кнопку Добавить еще настройку.

11. Платформа отображает поля для ввода новой настройки: 11.1. Название.
    11.2. Тип.

12. Пользователь заполняет следующие поля: 12.1. Название: нужное название настройки.
    12.2. Тип: выбирает значение REST API Engine.
    12.3. Endpoint: заполняет его по регулярному выражению так, что значение = значению из пункта 7.

13. Платформа подсвечивает поле "Endpoint" оранжевым и выводит подсказку: Такой endpoint уже существует/ "This endpoint is already exists".

14. Пользователь нажимает Сохранить/"Save"

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

16. Кнопка Запустить/"Run" доступна.

Альтернативные потоки

• Если Пользователь не ввел endpoint:

Альтернативный поток начинается после пункта 7.2 основного потока:

1. Пользователь оставил пустым поле Endpoint и нажимает на кнопку Сохранить/"Save".

2. Платформа не сохраняет настройки приложения, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь не ввел название:

Альтернативный поток начинается после пункта 6 основного потока:

1. Пользователь оставил пустым поле Название и нажимает на кнопку Сохранить/"Save".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь вводит дублирующее название

Альтернативный поток начинается после пункта 12.1 основного потока:

1. Пользователь ввел название настройки, которая уже существует и нажимает на кнопку Сохранить/"Save".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Такое название уже существует/"This name is already exists".

Удаление существующей настройки запуска приложения#

1. Пользователь авторизуется в BPMD (далее Платформа).

2. Выбирает существующее приложение.

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

4. Наводит курсор на кнопку Настроить приложение/"Customize the application".

5. Платформа открывает окно настроек приложения.

6. Пользователь переходит во вкладку Запуск/"Run".

7. Платформа отображает список настроек запуска.

8. Пользователь нажимает на кнопку Удалить.

9. Пользователь нажимает на кнопку Сохранить/"Save".

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

Запуск приложения в BPMX с главной страницы#

1. Пользователь авторизуется в BPMD (далее Платформа).

2. Выбирает существующее приложение.

3. Наводит курсор на кнопку Запустить – кнопка активна.

4. Нажимает на кнопку Запустить.

5. Платформа открывает модальное окно Запуск для выбора настройки запуска: выпадающий список Настройка запуска – Не выбрано.

6. Пользователь выбирает настройку.

7. Платформа активирует кнопку Запустить.

8. Пользователь нажимает на кнопку Запустить/"Run".

9. Платформа блокирует модальное окно и выполняет запуск приложения в соответствии с выбранной настройкой. 9.1. В случае успешной операции модальное окно закрывается и выводится сообщение Запуск приложения <Название приложения> выполнен. 9.2. При возникновении ошибки модальное окно не закрывается и выводится соответствующее сообщение:

   

Примеры возможных пользовательских сценариев#

Настройка запуска в BPMX#

1. Пользователь авторизуется в BPMD (далее Платформа).

2. Открывает окно создания нового приложения (жмет на кнопку Создать приложение/"Create application").

3. Вводит название приложения и переходит во вкладку Запуск/"Run".

4. Нажимает на кнопку Добавить настройку.

5. Заполняет следующие поля: 5.1. Название: нужное название настройки.
   5.2. Тип: выбирает значение DPM.
   5.3. Deployment endpoint.
   5.4. Код объекта релизной деятельности. 5.5. Версия.

6. Нажимает на кнопку Добавить еще настройку.

7. Платформа отображает поля для ввода новой настройки: 10.1. Название.
   10.2. Тип.

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

9. Пользователь проверяет, что кнопка Запустить/"Run" доступна.

Альтернативные потоки

• Если Пользователь не заполняет обязательные поля:

1. Пользователь оставил пустыми поля: URL, Код объекта релизной деятельности, Версия и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь не ввел название:

1. Пользователь оставил пустым поле Название и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку Заполните обязательное поле/"Required field".

• Если Пользователь ввел дублирующее название настройки запуска:

1. Пользователь ввел название настройки, которая уже существует и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку: Такое название уже существует/"This name is already exists".

• Если Пользователь заполнил поля Код объекта релизной деятельности и Версия с ошибками

1. Пользователь ввел пробелы в поле Код объекта релизной деятельности и поле Версия и нажимает на кнопку Создать/"Create".

2. Платформа не создает приложение, подсвечивает поле красным и выводит подсказку: Удалите пробелы/ "Please, delete the spaces".

Загрузка приложения в BPMX с главной станицы#

1. Пользователь авторизуется в BPMD (далее Платформа).

2. Выбирает существующее приложение.

3. Наводит курсор на кнопку Запустить – кнопка активна.

4. Нажимает на кнопку Запустить.

5. Платформа открывает модальное окно Запуск для выбора настройки запуска: 5.1. Выпадающий список Настройка запуска – Не выбрано.
   5.2. Поле Логин не заполнено.
   5.3. Поле Credential не заполнено.
   5.4. Кнопка Запустить заблокирована.

6. Пользователь заполняет обязательные поля.

7. Платформа активирует кнопку Запустить.

8. Пользователь нажимает на кнопку Запустить/"Run".

9. Платформа блокирует модальное окно и выполняет запуск приложения в соответствии с выбранной настройкой: 9.1. В случае успешной операции модальное окно закрывается и выводится сообщение Запуск приложения <Название приложения> выполнен. 9.2. При возникновении ошибки модальное окно не закрывается и выводится соответствующее сообщение:

   

Объекты приложения#

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

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

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

Создание объекта#

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

• Нажать на само приложение или папку внутри приложения. Затем нажать на иконку в виде документа со знаком "+" внутри .

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

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

Переименование объекта#

Переименование объекта происходит через пункт Переименовать в контекстном меню объекта.

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

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

Перемещение объекта#

Перемещение файла/папки осуществляется при помощи drag and drop этого файла в необходимую область в дереве проектов.

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

Удаление объекта#

Удаление объекта происходит через пункт Удалить в контекстном меню объекта.

Импорт объектов в приложение#

Компонент BPMD поддерживает импорт как единичных файлов, так и архивов (только с расширением .zip).

Для импорта доступны только файлы со следующими расширениями:

• .bpmn - модель;

• .js;

• .json;

• .groovy;

• .xml;

• .mask.json - маска;

• .form.json - форма;

• .msg.json - сообщение;

• .var.json - ресурсный файл

Импорт объектов в приложение доступен двумя способами:

1. В корень приложения. При добавлении объекта через иконку, в пункте Файл с устройства доступен выбор – файлов или архива (импортировать архив вместе с файлами нельзя).

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

   

Правила при импорте:

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

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

3. Максимальный размер архива доступный для импорта - 10 Мб.

4. В случае импорта объектов, дублирующих существующие в приложении по полному пути до объекта и наименованию, импортируемый объект сравнивается с существующим.

5. В случае если импортируемый объект - файл и его содержимое отличается от существующего в приложении (сравнение по хеш суммам), то создается новая версия существующего файла с body из импортируемого файла. В комментарии к автоматически созданной версии указывается: Данная версия была автоматически создана при импорте архива.

   1. Если его содержимое не отличается, то новая версия создаваться не будет.

6. В случае если объект - папка, происходит объединение двух объектов, где соответственно объединяется их содержимое.

   1. Если импортируемая папка пуста, то объединения не будет.

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

   1. Возможный пользовательский выбор:

      • Продолжить импорт без указанных файлов;

      • Отменить импорт.

        

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

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

   2. При переименовании не предусмотрено изменение расширения файла.

      

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

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

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

Отладка модели в Engine#

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

Интерфейс отладочного запуска представлен двумя опциями:

1. Отладить в Engine - позволяет указать параметры для деплоя и запуска модели (предварительно настроенный отладочный стенд (обязательно), бизнес ключ, ключ идемпотентности, стартовое сообщение, payload).
2. Быстрая отладка - повтор последнего запуска со всеми выбранными в нем параметрами.

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

На запуск отправляется основная модель, из контекстного меню которой был вызван запуск, и прикрепленные к ней файлы. Прикрепленные файлы (js\groovy, retryPolicy, bpmn call activity, forms.json) определяются автоматически по атрибутам связанности.

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

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

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

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

5. Для поля Payload кроме ручного ввода присутствует возможность выбора содержимого файла с типом msg.json;

   1. При выборе файла проверяется его соответствие структуре для стартового сообщения;

   2. При любом несоответствии заявленной структуре - выводится все содержимое файла в поле Payload, при этом поле наименования сценария скрыто;

   3. В случае соответствия структуре – извлекается его содержимое и выводится scenario для указанного messageName в выпадающий список ниже;

   4. В случае получения только одного scenario и payload - его значение выводится в выпадающий список, при этом список блокируется - значение payload попадает сразу в текстовое поле Payload;

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

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

   7. В случае отсутствия scenario для указанного messageName, но присутствия payload - все равно выводится весь файл;

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

6. Существуют 4 варианта ответа при попытке запуска:

   1. Запущено - возвращается id экземпляра (ссылка) запущенного процесса;

   2. Не запущено - возвращается id процесса (ссылка) и ошибка запуска;

   3. Не отправлено - возвращается ошибка загрузки;

   4. Ошибка модели - указываются некорректные элементы, что препятствуют развертыванию.

Ожидаемая структура файла с типом msg.json:

[{
        "messageName": "имя сообщения из модели - опционально, если задан - мы фильтруем по нему, пустое/отсутствующее имя для сообщений без имени и/или типа",
        "scenario": "обязательное описание для payload - строка, что видна при выборе payload в форме запуска",
        "payload": {"JSON":"data"}
        }]

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

Инструменты моделирования#

Палитра#

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

• Начальное событие (Start Event);

• Промежуточное событие-обработчик/Граничное событие (Intermediate Catch Event/Boundary Event);

• Конечное событие (End Event);

• Развилка (GateWay);

• Задача (Task);

• Подпроцесс (Sub Process).

Контекстное меню элемента#

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

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

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

Удалить элемент с диаграммы можно, выбрав в контекстном меню иконку в виде мусорного ведра .

Свойства элемента#

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

Для элементов типа Task, Collaboration, Lane и Group возможно пользовательское изменение размеров:

Просмотр модели в виде блока кода#

Опция Код предоставляет возможность просмотра модели в XML-формате без возможности ее редактирования. Для этого необходимо нажать на Код и ознакомиться с содержимым модели в открывшемся модальном окне.

Копирование и вставка элементов#

Копирование осуществляется при выборе одного или нескольких элементов и использовании комбинации ctrl+c/тулбара в нижней правой области редактирования.

Выбор нескольких элементов модели доступен:

• при использовании зажатой клавиши shift и последовательного клика на необходимые элементы;

• инструментом панели свойств Лассо.

Вставка элементов может быть осуществлена как в исходную модель, так и в любую другую модель того же приложения. Ранее скопированные в буфер обмена элементы вставляются при нажатии комбинации ctrl+v/тулбара в нижней правой области редактирования.

Особенности копирования:

1. Элемент Lane не копируется.

2. При выборе одного из объединяющих элементов (pool/participant, sub process) при вставке будут добавлены: сам объединяющий элемент и все его содержимое независимо от того, были ли отдельно выбраны некоторые элементы внутри объединяющего или нет.

3. При вставке скопированного элемента или группы элементов генерируются новые идентификаторы для этих элементов. Все остальные настройки сохраняются (включая ссылки на ресурсные файлы для модели).

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

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

   • В случае наличия переменных с одинаковыми именами, но различающимися настройками в исходной модели и модели приемнике – в последней создадутся переименованные копии (name(1)) вставляемых переменных, пользователь при вставке получит уведомление о переименовании.

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

Отмена/возврат отмены#

Отмена и возврат последних совершенных действий при проектировании модели осуществляется при помощи стандартных комбинаций ctrl+z/ctrl+y или панели инструментов в нижней правой области редактирования.

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

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

Панель пользователя#

В нижней области экрана доступна панель пользователя, состоящая из двух разделов Консоль и Валидация.

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

1. Импорт файла/архива в приложение (со всеми соответствующими ошибками и уведомлениями)

2. Отправка приложения в Git

3. Запуск модели в Engine (история быстрых запусков моделей в среду исполнения с названием стенда, временем запуска, составом пакета с версиями)

   1. Для каждого успешного запуска сохраняется ссылка на модель и инстанс процесса к среде исполнения

   2. Для неуспешных запусков сохраняется информация об ошибке

4. Деплой всего приложения в Engine

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

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

2. В момент быстрого запуска также валидируются подключенный к ней bpmn-модели (через call-activity) и модели политик повторных вызовов

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

Сохранение изменений#

Чтобы сохранить внесенные изменения, нужно нажать на кнопку «Сохранить» или «Сохранить все».

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

Сравнение версий#

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

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

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

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

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

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

Просмотр контекста#

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

Контекст приложения складывается из задекларированных переменных в процессах (файлах BPMN).

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

Контекст представлен в виде таблицы, которую возможно использовать в информационных целях. Для изменения контекста необходимо перейти в файл модели bpmn. Таблица содержит информацию о задекларированных в файлах bpmn (процессах) переменных:

• описание;

• имя переменной (доступно копирование имени переменной, при этом все остальные ее настройки не копируются);

• тип;

• теги (все теги, назначенные на переменную);

• файл (доступна фильтрация таблицы по одному или нескольким моделям приложения).

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

Элементы модели процесса#

Процесс (Process)#

Свойства процесса#

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

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

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

Декларация переменных#

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

1. Нажать на свободную от элементов модели область.

2. В левом модальном окне отобразится информация по настройкам процесса.

3. Выбрать вкладку Переменные/"Variables", где будет выведен список переменных контекста данного процесса.

4. Нажать на button-icon «+».

5. Будут выведены дополнительные поля задания переменной.

6. Пользователем задается: 6.1. Имя переменной *Обязательное поле, доступна только латиница. 6.2. Описание *Не обязательное.
   6.3. Тип данных переменной *Обязательное поле, список доступных типов данных приведен ниже. См. Таблица маппинга типов данных для переменных.
   6.4. Тег/теги для переменной *Не обязательное.

7. Нажать Применить.

8. Новая переменная сохранена в область процесса.

Таблица маппинга типов данных для переменных#

Пример.

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

Тегирование переменных#

В случае если переменная протегирована предустановленным тегом Замаскировано/"masked", то ее значения будут замаскированы (закрыты) при просмотре контекста в runtime (в режиме работы DataIndex по умолчанию).

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

Принцип работы механизма задания тегов:

1. Нажимаем input field/«Теги».

2. Система отображает единственный системный тег замаскировано/"masked".

3. Выбираем тег, он автоматически присваивается к редактируемой переменной.

4. В случае если пользователь хочет создать кастомный тег, то он вводит его наименование в input field в форме, расположенной ниже и нажимает добавить.

5. Кастомный тег добавляется в список тегов для переменных процесса и присваивается редактируемой переменной.

Маскирование переменных контекста#

Разработчик процесса на этапе его проектирования может загрузить файл с масками. Файл может быть только в формате *.mask.json и содержит объект настройки видимости переменных.

• json.path - выражение вида JsonPath Expression (более подробную информацию можно получить во внешней документации и базируется на com.jayway.jsonpath -> json-path);

• options - объект с параметрами маскирования. Содержит в себе:

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

  • regExpMode: "show/hide" - условие применения маски.

Объявление условия применения маски регулярным выражением (regExp направлен на скрытие информации или наоборот на обнаружение нескрываемых символов) остается на стороне потребителя. При выборе regExpMode равным "show" - символы, попадающие под регулярное выражение, показываются, остальные скрываются. При выборе regExpMode равным "hide" - символы, попадающие под регулярное выражение, скрываются, остальные показываются.

Один файл с масками может быть использован для разных моделей. Файл *.mask.json лежит в общем дереве приложения и загружается вместе с моделью процесса. Маски из файла *.mask.json имеют первый приоритет, но не исключают сокрытие переменных по тегу masked.

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

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

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

Хранение и версионирование файла масок осуществить аналогично текущему механизму хранения и версионирования ресурсных файлов.

Применение файла с масками не распространяется на дочерние процессы. Если нужно маскировать контекст внутри Call-Activity файл с масками должен быть прикреплен к процессу внутри Call-Activity.

Маскирование при наличии тега masked и регулярного выражения из файла:

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

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

• Если переменная контекста размечена тегом masked и в файле для нее указано регулярное выражение, она скрывается согласно паттерну маски.

• Если переменная контекста не размечена тегом masked, но в файле для нее указано регулярное выражение, она скрывается согласно паттерну маски.

• Если переменная контекста не размечена тегом masked и в файле для нее не указан паттерн маски, она не маскируется.

JSON-схема для валидации файла масок:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Validation of *.mask.json resource file",
  "version": "1.0",
  "type": "object",
  "properties": {
    "maskPatterns": {
      "description": "Array of objects with mask pattern",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "jsonPath": {
            "description": "Path to variable in context",
            "type"       : "string"
          },
          "options": {
            "description": "Masking settings",
            "type": "object",
            "nullable": true,
            "properties": {
              "regExp": {
                "description": "Regular expression to find substring in value of variable",
                "type": "string"
              },
              "regExpMode": {
                "description": "Whether to show or to hide substring",
                "type"       : "string"
              }
            },
            "required": ["regExp", "regExpMode"]
          }
        },
        "additionalProperties": false,
        "required": ["jsonPath"]
      }
    }
  },
  "additionalProperties": false
}

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

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

Для указания Семейства бизнес-процессов процесса необходимо:

1. Перейти в свойства процесса;

2. Перейти на вкладку Процесс и заполнить поле Семейство бизнес-процессов:

При валидации процесса с незаполненным Семейством бизнес-процессов (businessFamily) на вкладке Валидации выводится предупреждение. Осуществление загрузки модели из BPMD в BPMX данное предупреждение не блокирует, но если на указанной инсталляции BPMX выставлен признак контроля заполненности семейства бизнес-процессов загрузка будет выполнена с ошибкой "Значение businessFamily не может быть пустым", кроме того, в случае если значение businessFamily не соответствует паттерну, заданному на инсталляции, при загрузке будет получена ошибка "Для процессов {process1}, {processN} - значение businessFamily не соответствует регулярному выражению {PlaceHolder} заданному в конфигурации {configName}".

Настройка доступа к просмотру контекста процесса в runtime#

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

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

Для сокрытия определенных переменных при предоставленном доступе ко всему контексту процесса см. раздел «Тегирование переменных» настоящего документа.

Настройка владельца процесса#

Для указания роли владельца процесса необходимо:

1. Перейти на вкладку Доступ и заполнить на ней поле Роль владельца:

XML представление:

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

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<bpmn2:definitions 
        xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" 
        xmlns:activiti="http://activiti.org/bpmn" 
        xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" 
        xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" 
        xmlns:di="http://www.omg.org/spec/DD/20100524/DI" 
        xmlns:sbt="http://com.sbt/bpms/modeler" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        exporter="Platform V Flow Designer" 
        exporterVersion="5.0.0" 
        id="Definitions_3b362dc" 
        targetNamespace="https://sbertech.ru/bpm/bpmn/1.0">

Пример XML представления начального события с типом Сообщение:

<bpmn2:startEvent id="Event_1s6v7ea" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableStartEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_dosovv2" messageRef="Element_a41l1z3" />
</bpmn2:startEvent>

События#

События (Events) используются для моделирования происходящего во время исполнения процесса.

В моделях используются следующие события:

События графически изображаются как круг, но с разными границами. Символ внутри, если он есть, указывает на Тип события (Event definition).

Возможны 5 вариантов типов событий:

• Сообщение (Message);

• Таймер (Timer);

• Сигнал (Signal);

• Ошибка (Error);

• Останов (Terminate).

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

Существует две категории событий:

• Событие-обработчик (Catch Event);

• Событие-инициатор (Throw Event).

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

• Начальное событие (Start Event);

• Промежуточное событие-обработчик (Intermediate Catch Event);

• Граничное событие (Boundary Event).

Начальное событие#

Начальное событие (Start Event) показывает, где процесс (или подпроцесс) начнется.

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

Графическое представление:

Начальное событие изображается как круг с одной тонкой окружностью:

XML представление:

Пример XML представления начального события с типом Сообщение:

<bpmn2:startEvent id="Event_1s6v7ea" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableStartEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_dosovv2" messageRef="Element_a41l1z3" />
</bpmn2:startEvent>

Настройка параметров:

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

Промежуточное событие#

Промежуточные события делятся на 2 вида: событие-обработчик (Intermediate catch event) и событие-инициатор (Intermediate throw event).

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

Промежуточное событие-инициатор (Intermediate Throw Event) используется для инициирования Типа события (Event Definition). После инициирования поток исполнения переходит далее по модели процесса.

Сообщение, передаваемое в Catch Event и Throw Event, должно иметь уникальное наименование в пределах разных процессов.

Графическое представление:

Общее отображение промежуточного события:

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

XML представление:

Пример XML представления промежуточного события:

• событие-обработчик с типом Сообщение

<bpmn2:intermediateCatchEvent id="Event_0htla81" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableIntermediateCatchEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_20shdlk" messageRef="Element_a41l1z3" />
</bpmn2:intermediateCatchEvent>

• событие-инициатор с типом Сообщение

<bpmn2:intermediateThrowEvent id="Event_0y5p1dq" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableIntermediateThrowEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_76f81h5" contextVariable="" />
</bpmn2:intermediateThrowEvent>

Настройка параметров:

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

Граничное событие#

Граничное событие (Boundary Event) используется для ожидания срабатывания Типа события (Event Definition) во время выполнения элемента, к которому оно прикреплено. Поэтому оно не используется без добавления типа события и должно обязательно находиться на задаче или подпроцессе. Ожидание будет отменено после того, как поток исполнения пойдет дальше. В этом его отличие от промежуточного события-обработчика.

Графическое представление:

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

XML представление:

Пример XML представления граничного события с типом Сообщение:

<bpmn2:boundaryEvent id="Event_1822vax" name="" attachedToRef="Activity_00rmo3e" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableBoundaryEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_33nudq3" messageRef="Element_a41l1z3" />
</bpmn2:boundaryEvent>

Настройка параметров:

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

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

Конечное событие#

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

Графическое представление:

Конечное событие изображается как круг с одной жирной окружностью:

XML представление:

Пример XML представления конечного события с типом Останов:

<bpmn2:endEvent id="Event_055ia5q" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableEndEvent">
    <bpmn2:terminateEventDefinition />
</bpmn2:endEvent>

Настройка параметров:

Типы событий#

Типы событий (Event Definitions) определяют поведение событий. Поэтому они используются только в событиях, самостоятельно не используются.

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

• Таймер (Timer);

• Сообщение (Message);

• Ошибка (Error);

• Сигнал (Signal);

• Останов (Terminate).

Выбор типа события происходит на вкладке Тип события в поле Тип события:

Таймер#

Настройка параметров. Вкладка «Тип события» в событии:

Рассмотрим различные варианты настройки Таймера:

1. Дата в соответствии с ISO8601. Пример:

   2011-03-11T12:13:14 – таймер сработает 11 марта 2011 года в 12:13:14

   Пример кода:

   <timerEventDefinition>
       <timeDate xsi:type="tFormalExpression"><![CDATA[2011-03-11T12:13:14]]></timeDate>
   </timerEventDefinition>
   

2. Цикл в формате ISO8601. Примеры:

   2007-03-01T13:00:00Z/2008-05-11T15:30:00Z – указание начальной и конечной даты;

   2007-03-01T13:00:00Z/P1Y2M10DT2H30M – указание начальной даты и длительности;

   P1Y2M10DT2H30M/2008-05-11T15:30:00Z – указание длительности и конечной даты.

   Пример кода:

   <timerEventDefinition>
       <timeCycle xsi:type="tFormalExpression"><![CDATA[2007-03-01T13:00:00Z/2008-05-11T15:30:00Z]]></timeCycle>
   </timerEventDefinition>
   

3. Длительность в формате ISO8601. Примеры:

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

   PT3H – таймер истечет через 3 часа.

   PT30M – таймер истечет через 30 минут

   P6W – таймер истечет через 6 недель

   P2Y10M15DT10H30M20S – срок исполнения задачи истечет через 2 года 10 месяцев 15 дней 10 часов 30 минут 20 секунд.

   Пример кода:

   <timerEventDefinition>
       <timeDuration xsi:type="tFormalExpression"><![CDATA[P2D]]></timeDuration>
   </timerEventDefinition>
   

Рекомендуемое минимальное значение таймера – не менее 2 с. Данное значение обусловлено периодом задержки вычитывания сообщений в Kafka.

4. Допускается также указание в поле Значение таймера переменной. Для этого нужно использовать выражение вида ${timer}, где timer – переменная.

   Пример кода:

   <timerEventDefinition>
       <timeDuration xsi:type="tFormalExpression"><![CDATA[${timer}]]></timeDuration>
   </timerEventDefinition>
   

5. Также таймер можно задавать в формате Cron. Примеры:

   0 0/5 * * * ? – выражение создает триггер, который будет срабатывать каждые 5 минут;

   10 0/5 * * * ? – выражение создает триггер, который будет срабатывать каждые 5 минут 10 секунд;

   0 30 10-13 ? * WED,FRI – выражение создает триггер, который срабатывает в 10:30, 11:30, 12:30 и 13:30 каждую среду и пятницу.

   Пример кода:

   <bpmn2:timerEventDefinition id="a65416da-6d2c-4b5c-bcf5-dee806e04c2f">
       <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression" id="a6c78f48-71c6-4a62-946a-52fde3d90e40"><![CDATA[0 0/5 * * * ?]]></bpmn2:timeCycle>
   </bpmn2:timerEventDefinition>
   

Сообщение#

Настройка параметров. Вкладка Тип события в событии:

Сообщение

Поле Сообщение содержит имя сообщения, которое будет ожидаться/отправляться (отправляется в случае Intermediate throw message event и End message event). Поле является выпадающим списком, для выбора доступны все сохраненные в модели сообщения. Можно выбрать значение или нажать на кнопку +Добавить элемент и ввести новое имя сообщения.

При выборе Сообщения отображается подсказка:

Для catch и throw событий-сообщений доступна настройка параметров для реализации исполнения событий как взаимодействие через Kafka в BPMX.

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

• throw события-сообщения: указанное наименование сообщения будет являться topic Kafka по умолчанию (для отправки в него сообщений).

• catch события-сообщения: для идентификатора процесса и названия сообщения необходимо указать в конфигурации BPMX настройки topic Kafka и группы потребителей (для получения сообщений).

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

• CloudEvents

• Synapse

//Пример сообщения в обертке CloudEvent
{
  "ce_id" : "C234-1234-1234", // Идентификатор события. Заполняется в Engine UUID
  "ce_source" : "myprocess", // Информация об источнике события. Заполняется значением source, которое указано в настройках (engine.messages.source)
  "ce_type" : "message_name", // Данный атрибут описывает тип отправляемого события. Заполняется в Engine наименованием сообщения
  "ce_time" : "2018-04-05T17:31:00Z", // Время возникновения события
  "datacontenttype" : "application/json", // Тип содержимого сообщения (поле data). Поддерживаемое для Engine значение - "application/json"
  "data" : { // В данном поле передается сообщение
    "appinfoA" : "abc",
    "appinfoB" : 123,
    "appinfoC" : true
  },
  "specversion" : "1.0", // Версия спецификации. Поддерживаемая версия 1.0
  "kogitoprocinstanceid" : "e100e33c-220f-4bd7-93cb-8bf5fc941ec6", // Идентификатор экземпляра процесса-отправителя события
  "kogitoprocrefid": "", // Идентификатор экземпляра процесса-получателя события
  "kogitoglobalprocrefid": "" // Идентификатор «родственных» процессов, задаваемый инициатором сообщения
}

//Пример сообщения в обертке Synapse
{
  "header" : {
    "evtType": "message_name", // Тип события. Заполняется наименованием сообщения
    "evtVersion": "", // Версия схемы события. Заполняется в Engine значением 1
    "srcModule" : "myprocess", // Идентификатор источника события. Заполняется значением source, которое указано в настройках (engine.messages.source)
    "evtId" : "Уникальный идентификатор события", // Уникальный идентификатор события. Заполняется в Engine UUID
    "evtDate" : "Время возникновения события", // Дата возникновения события
    "kogitoprocinstanceid" : "e100e33c-220f-4bd7-93cb-8bf5fc941ec6", // Идентификатор экземпляра процесса-отправителя события
    "kogitoprocrefid": "", // Идентификатор экземпляра процесса-получателя события
    "kogitoglobalprocrefid": "" // Идентификатор «родственных» процессов, задаваемый инициатором сообщения
  },
  "body" : { "В данном поле передается сообщение"}
}

Throw события#

Message intermediate throw event

При отправке сообщения в Kafka с помощью message intermediate throw event - параметры корреляции имеют следующие значения:

• kogitoprocinstanceid - идентификатор экземпляра процесса, сгенерировавшего сообщение.

Данное поле сохраняется, далее используется для последующей синхронизации.

Message end event

При отправке сообщения в Kafka (в указанный topic в настройках процесса) с помощью message end event - параметры корреляции имеют следующие значения:

• kogitoprocinstanceid - идентификатор экземпляра процесса, сгенерировавшего сообщение;

• kogitoprocrefid - идентификатор процесса, которому предназначается сгенерированное сообщение. Не заполняется в случае интеграции с внешними АС.

Поле kogitoprocrefid содержит id экземпляра процесса (Flow), который является инициатором запуска текущего экземпляра, если этот экземпляр был инициирован сообщением.

Message start event

Ожидает сообщение в формате, генерируемом Message Intermediate throw event.

При старте процесса сообщением в Kafka из внешней системы с помощью message start event должны быть следующие параметры корреляции:

• kogitoglobalprocrefid - идентификатор родственных процессов, задаваемый инициатором.

Catch события#

Для инициирования catch-событий через REST API доступна возможность настройки ожидаемого сообщения в формате JUEL-выражения (то есть имя сообщения будет вычисляться в runtime). Для реализации взаимодействия через Kafka такая настройка сообщения недоступна.

Message intermediate catch event/ Message boundary event/ message boundary event (non-interrupring)

• Ожидает сообщение в формате, генерируемом Message end event. Т.е. сообщение должно содержать поля для корреляции сообщений:

  • kogitoprocinstanceid - идентификатор экземпляра процесса, сгенерировавшего сообщение. Не заполняется в случае получения данных от внешних АС.

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

Описание параметров настройки BPNX для работы с Kafka в части событий в Руководстве по установке компонента Engine Platform V Flow, «Настройки для отправки/получения сообщений по событиям в процессах».

Примеры настройки параметров доступны в Руководстве по системному администрированию компонента BPMX, «Настройки для отправки/получения сообщений по событиям в процессах».

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

Дополнительно

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

Пример кода:

<bpmn2:intermediateCatchEvent id="Event_0wwts6r" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableIntermediateCatchEvent">
    <bpmn2:messageEventDefinition id="MessageEventDefinition_dz1x7fq" messageRef="Element_2rguchj" />
</bpmn2:intermediateCatchEvent>

<bpmn2:message id="Element_2rguchj" name="message1" />

Если для событий планируется реализация через Kafka, то невозможна настройка названия сообщения в формате выражения

Переменная контекста

Данное поле появляется для настройки только для throw событий-сообщений. Данное поле необходимо заполнять при настройке взаимодействия через Kafka для событий, в нем указывается название переменной контекста процесса, информация из которой передается в сообщение:

Информация о переменной в xml-файле bpmn-модели процесса сохраняется следующим образом:

Пример:

<bpmn2:extensionElements>
    <sbt:inputParamList>
        <sbt:inputParam xsi:type="sbt:InputParam" sbt:id="2a285f0e-1c42-4310-915c-6679cc0b7977">
            <sbt:name>mapp_var</sbt:name>
        </sbt:inputParam>
    </sbt:inputParamList>
</bpmn2:extensionElements>

Сигнал#

Настройка параметров. Вкладка «Тип события» в событии:

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

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

Пример кода:

<bpmn2:intermediateCatchEvent id="Event_0wwts6r" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableIntermediateCatchEvent">
    <bpmn2:signalEventDefinition id="SignalEventDefinition_47av8sx" signalRef="Element_enal4gv" />
</bpmn2:intermediateCatchEvent>

<bpmn2:signal id="Element_enal4gv" name="signal1" />

Ошибка#

Настройка параметров. Вкладка «Тип события» в событии:

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

Пример кода:

<bpmn2:boundaryEvent id="Event_0wwts6r" name="" attachedToRef="Activity_0duusmv" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableBoundaryEvent">
    <bpmn2:errorEventDefinition id="ErrorEventDefinition_d1fyzci" errorRef="Element_5wx1299" />
</bpmn2:boundaryEvent>

<bpmn2:error id="Element_5wx1299" name="err_code1" errorCode="err_code1" />

Останов#

Тип события Останов (Terminate) вызывает немедленное завершение выполнения процесса или подпроцесса, при этом все его активные потоки управления прерываются.

Использование типа Останов позволяет значительно упростить разработку процессов, в которых применяется подход "left over". Например, уточнения или запросы каких-то документов (у заявителя, или в иных системах, или у других пользователей), когда после принятия решения по объекту процесса необходимо прервать все «побочные» уточняющие ветки процесса, потому что они больше не представляют ценности для основного результата процесса. После исполнения события Останов (Terminate) процесс переходит в состояние Выполнен (COMPLETED), дочерние процессы, которые были прерваны – в состояние Ошибка (FAILED).

Тип события Останов может быть только у Конечного события.

Пример кода:

<bpmn2:endEvent id="Event_055ia5q" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableEndEvent">
    <bpmn2:terminateEventDefinition id="f8188136-4269-4b18-bfe2-2a56cab39dfa"/>
</bpmn2:endEvent>

Задачи#

Ручное выполнение#

Задача Ручное выполнение (Manual Task) обрабатывается как сквозное действие, автоматически продолжая процесс.

Графическое представление:

Ручное выполнение изображается как прямоугольник с иконкой руки в левом верхнем углу:

XML представление:

<bpmn2:manualTask id="3169fe3f-dfc4-425c-b42b-cd1b38152730" name="name" />

Настройка параметров:

Пользовательская задача#

Пользовательская задача (User Task) – это задача, которая должна быть выполнена человеком. В Platform V Flow для работы с пользовательскими задачами используется компонент UTSK.

Графическое представление:

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

XML представление:

<userTask id="41ff9467-3614-4061-8418-85ecc36099d1" name="UserTask1" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableUserTask" activiti:assignee="Executor1" sbt:managerRole="ManagerRole" sbt:excludedUsers="Executor1_1" activiti:priority="80" activiti:dueDate="2011-03-11T12:13:14" sbt:formType="formUrl" activiti:formKey="https://">
    <extensionElements>
        <sbt:description id="46338d34-28d2-4805-9a0b-7c29534da608"><![CDATA[Описание задачи]]></sbt:description>
        <sbt:extraAttributes>
          <sbt:extraAttribute xsi:type="sbt:ExtraAttribute" sbt:id="ExtraAttribute_0hliijp">
            <sbt:extraAttributeName>Идентификатор заявки</sbt:extraAttributeName>
            <sbt:processVarName>id</sbt:processVarName>
            <sbt:type>STRING</sbt:type>
            <sbt:code>id</sbt:code>
            <sbt:visibility>visible</sbt:visibility>
            <sbt:order>1</sbt:order>
            <sbt:linked>false</sbt:linked>
          </sbt:extraAttribute>
        </sbt:extraAttributes>
        <sbt:taskListenerList>
            <sbt:taskListener xsi:type="sbt:TaskListener" sbt:id="f7fd1098-c89e-44e8-b7a6-45d713f1a0b3" sbt:expression="#{execution.setVariable('excludeLastAssigneeUsername', task.getAssignee()};" sbt:event="complete" />
        </sbt:taskListenerList>
    </extensionElements>
    <multiInstanceLoopCharacteristics isSequential="true" activiti:collection="assigneeList" activiti:elementVariable="assignee">
        <completionCondition xsi:type="tFormalExpression"><![CDATA[${nrOfCompletedInstances/nrOfInstances >= 0.6 }]]></completionCondition>
    </multiInstanceLoopCharacteristics>
</userTask>

Настройка параметров:

Подробное описание некоторых параметров:

1. Срок завершения необходимо указывать в одном из следующих форматах: Java.util.Date, java.util.String (ISO8601), ISO8601 time-duration. Примеры заполнения поля:

   • P2D – срок исполнения задачи истечет через 2 дня. Этот же период можно представить в часах: PT48H;

   • PT3H – срок исполнения задачи истечет через 3 часа;

   • PT30M– срок исполнения задачи истечет через 30 минут;

   • P6W – срок исполнения задачи истечет через 6 недель;

   • P2Y10M15DT10H30M20S – срок исполнения задачи истечет через 2 года 10 месяцев 15 дней 10 часов 30 минут 20 секунд.

   Можно указать срока завершения задачи через переменную. Для этого можно использовать выражение вида ${userTaskDueDate}, где userTaskDueDate – переменная, в которой хранится значение срока исполнения.

2. Приоритет должен иметь значение от 0 до 100 в зависимости от важности задачи. Можно ориентироваться на следующие диапазоны значений приоритета:

   • 0–39: Низкий;

   • 40–59: Средний;

   • 60–100: Высокий.

3. Обработчик события ожидается в формате выражения, в котором указывается метод, его аргументы в формате ('ключ', значение).

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

   1. Create - событие наступает при создании пользовательской задачи

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

4. Типы завершения:

   1. Внешняя. Пользовательская задача будет выполняться во внешней форме, реализуемой сторонними сервисами. Адрес формы – поле, содержащее путь к форме задачи, которая будет открываться при нажатии кнопки «Начать» на портале компонента UTSK. Путь к форме должен быть представлен в формате: react:bpms-*наименование проекта*-ui?formName=*наименование формы, либо пользователь может указать абсолютную ссылку. Пример: react:bpms-flexprice-ui?formName=managerPrimaryForm.

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

   2. Быстрая. Содержит настройки, необходимые для создания окна выполнения пользовательской задачи с помощью встроенного редактора компонента UTSK, без необходимости перехода на внешнюю UI форму. Поддерживается максимум 5 вариантов завершения. Пример передаваемого JSON:

       {
       "completions": {
          "title": "Согласование договора",
          "description": "Согласование деталей договора перед заключением",
          "options": [
            {
              "label": "Согласовать",
              "result": {
                "agreementResult": "Согласовать"
              }
            },
            {
              "label": "Отклонить",
              "result": {
                "agreementResult": "Отклонить"
              }
            }
          ]
        }
      }
      

   3. JSON форма. Содержит настройки, необходимые для создания задач на платформе jsonforms.io.

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

Задача Выполнение сценария (Script Task) исполняет скрипт, написанный в ней или в прикрепленном файле. Скрипт может использовать переменные процесса и создавать новые переменные.

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

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

Графическое представление:

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

Выполнение сценария поддерживает два режима ввода скрипта:

1. Вручную - означает, что пользователь прописывает и отлаживает скрипт непосредственно внутри элемента;

2. Файл - означает, что пользователь прикрепляет ранее созданный в приложении файл скрипта. (Поддерживается прикрепление файлов с расширениями groovy, js)

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

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

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

Методы execution поддерживаемые в скриптах и JUEL выражениях#

Object getVariable(String name) // Получить переменную процесса с указанным переменной

Map<String, Object> getVariables(List<String> names) // Получить указанные переменные процесса

Map<String, Object> getVariables() // Получить все переменные процесса

List<String> getVariableNames() // Получить список имен переменных процесса  

Object setVariable(String name, Object value) // Добавить переменную процесса

void setVariables(Map<String, Object> variables) // Добавить несколько переменных процесса

void removeVariable(String name) // Удалить переменную процесса

void removeVariables(List<String> names) // Удалить несколько переменных процесса

boolean hasVariable(String name) // Проверить наличие указанной переменной

boolean hasVariables() // Проверить наличие переменных в контексте

Object getJsonVariable(String name) // Получение всей структуры переменной типа json

Object getJsonVariable(String name, String path) // Получение структуры по указанному пути переменной типа json

boolean hasJsonField(String name, String path) // Проверяет наличие указанного поля в переменной

FlowElement getCurrentFlowElement() // Получить информацию об исполняющемся шаге 

String getExternalIds() // Получить список внешних идентификаторов

String getGlobalProcessInstanceId() // Получить глобальный идентификатор процесса

String getId() // Получить идентификатор текущего потока исполнения

Execution getParent() // Получить родительский поток исполнения

String getProcessDefinitionKey() // Получить идентификатор процесса

String getProcessInstanceId() // Получить глобальный идентификатор процесса

String getRootProcessInstanceId() // Получить идентификатор корневого процесса

Date getStartTime() // Получить время старта экземпляра

Objec getUnhandledResponse() // Получение обработки для ошибок исполнения

Обработка сложных объектов#

Для обращения к вложенным переменным в сложном объекте/массиве используется метод getJsonVariable.

Пример, в контекстной переменной "var" может находиться объект, строка или экранированная строка:

 {
  "answerEPK": {
    "epkEntity": {
      "ucpId": "1664902004138970096",
      "version": 19,
      "names": [{
        "surname": " Иванов",
        "name": "Иван",
        "patronymic": "Иванович"}],
      "clientStatus": 1,
      "gender": null,
      "clientGroups": [95, 3],
      "phoneNumbers": [
        {
          "phoneNumber": "+7 (999) 99999",
          "startDate": "2022-04-14T16:50:05.100+00:00"
        },
        {
          "phoneNumber": "+7 (999) 99999",
          "startDate": "2022-04-14T16:50:05.100+00:00"
        }
      ]
    }
  }
}

//Для получения строки:
execution.getJsonVariable("var","answerEPK.epkEntity.phoneNumbers[0].phoneNumber")
Результат: "+7 (999) 99999"

//Для получения объекта N в массиве:
execution.getJsonVariable('var', 'answerEPK.epkEntity.phoneNumbers[0]')
Результат: {"phoneNumber": "+7 (999) 99999",
            "startDate": "2022-04-14T16:50:05.100+00:00"}

//Для получения null:
execution.getJsonVariable("var","answerEPK.epkEntity.gender")
Результат: "null"

//Для получения значения, что является датой - выводится как строка:
execution.getJsonVariable('var', 'answerEPK.epkEntity.phoneNumbers[0].startDate')
Результат: "2022-04-14T16:50:05.100+00:00"
        
// Для JSON который содержит поле, которое содержит массив строк типа:
{"phoneNumbers": ["+7903333333","+7444555555", "+7 (999) 99999"]}
        
// Возможно использовать такое выражение при использование в шлюзе выражения для проверки вхождения:
${execution.getJsonVariable("var", "answerEPK.epkEntity.phoneNumbers").contains("+7444555555")} Результат: true

Работа с отладочным окном для скриптов и выражений#

При необходимости расширения области ввода или отладке скрипта необходимо нажать Отладить.

На открывшемся поверх модели экране представлены:

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

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

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

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

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

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

     • Значения переменных могут быть любого валидного с позиции валидации JSON-файла типа данных

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

     • Один файл может быть использован более чем в одном скрипте Для исполнения скрипта возможно использовать кнопку Выполнить скрипт или hot key F10.

3. В панели разработчика появляется дополнительная вкладка Отладка скрипта, содержащая в себе:

   • Консоль - отображает результат исполнения скрипта или его ошибки

   • Переменные - в нем появляются контекстные переменные по итогу успешного исполнения скрипта.

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

Пример наполнения файла var.json значениями для переменных скрипта:

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

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

XML представление:

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

<bpmn2:scriptTask id="d9c4d75b-e278-4bf7-9032-6f284fdfd859" sbt:marker.type="Markable"                                                                                        
    sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableScriptTask" name="New Script Task" scriptFormat="groovy">
    <bpmn2:script><![CDATA[execution.setVariable("processInstanceId", execution.getProcessInstanceId());]]></bpmn2:script>
</bpmn2:scriptTask>

• Задача Выполнение сценария, когда в параметре Режим выбрано Файл:

<bpmn2:task id="Activity_f9caee3" name="Map" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.externalScriptTask" 
    sbt:scriptFile="mapVariables.js">
</bpmn2:task>

Настройка параметров:

Поддерживаемая версия groovy: 2.5.14

Контроль над заданием переменных в скриптах#

(Поведение справедливо для встроенных скриптов и для отдельных файлов js, groovy в приложении)

При обращении к глобальной переменной через скрипт (js, groovy) возможно непреднамеренное изменение контекста.

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

Вызов сервиса#

Вызов сервиса (Service Task) – это задача для взаимодействия с внешними сервисами по различным протоколам:

• REST;

• JSON-RPC.

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

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

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

Начиная с BPMX 5.x произошел переход с Apache HttpClient на WebClient. Соответственно, произошли изменения в классах исключений, отбрасываемых при исполнении REST и JSON-RPC задач.

Для задач вызова сервиса поддерживается сериализация данных только в формате JSON.

Графическое представление:

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

Настройка параметров:

Описание задания параметров при вводе вручную:

Входные параметры:

Предусловие: Пользователь обладает полномочиями редактирования приложения. В настройках service task выбран тип вызова сервиса «Вручную».

2. Переходим на вкладку Запрос и выбирает Входные параметры.

3. В случае работы с REST task: заполняем Наименование параметра, Расположение, Источник.

   1. В случае работы с JSON_RPC task: заполняем Наименование параметра, Источник.

4. В случае выбора Источник, Выражение появляется поле ввода Значение с указателем Введите выражение.

5. Вводим выражение и нажимаем Добавить.

6. В случае выбора Источник, Переменная в Значение появляется выпадающий список переменных контекста.

7. Вводим имя переменной в input field/«Имя переменной» с поиском по переменным контекста области usertask и выпадающим списком уже указанных для usertask переменных (которое сейчас Значение).

8. Выбираем переменную и нажимаем Добавить.

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

Выходные параметры:

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

1. Выбираем пункт Выходные параметры и задаем наименование выходного параметра.

2. Выбираем из выпадающего списка тип источника данных параметра Выражение или Переменная.

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

4. В случае выбора источник, в поле Значение доступен ввод выражения.

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

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

7. Выбираем переменную и переходим к вводу следующего параметра при необходимости.

Альтернативный поток 2. «Целевая Переменная» не задана ранее:

1. В случае если переменная не задана, то нажимаем на button-icon «+».

2. Открывается окно задания новой переменной.

3. Заполняем:

   • Имя переменной Обязательное поле;

   • Описание Не обязательное;

   • Тип данных переменной Не обязательное, по умолчанию string;

   • Тег/теги для переменной Не обязательное.

4. Нажимаем Применить

Описание задания параметров при получении из файла#

При успешной загрузке файла на вкладке «Запрос» отображаются поля:

1. Адрес API/API URL - input с автозаполнением; подтягивается список url'ов из файла;

   • пользователь может выбрать значение, полученное из файла или ввести свое;

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

2. Метод/Method - input с автозаполнением; подтягивается список из файла, выбор ограничен значением в поле API URL: 2.1. Если API URL не выбран, то метод выбрать нельзя, поле заблокировано. 2.2. Если метод один, то он сразу подтягивается в поле. 2.3. Если пользователь указал свой API URL, то метод он также может ввести самостоятельно, при этом Платформа предлагает методы: get, post, patch, delete, put, trace, option, head.

3. Тайм-аут/timeout: 3.1. Подсказка к полю Timeout по формату ввода: Введите значение и единицу измерения«»:

   • nD = количество дней;

   • nH = количество часов;

   • nM = количество минут;

   • n.nS = количество секунд, если значение десятичное, то разделителем может быть точка или запятая;

   • T = обязательно должно указываться перед nH, nM, n.nS;

   • P = обязательное обозначение периода;
     Пример: P1DT2H3M4.5S. 3.2. Допускается ввод чисел, ".", ",", P, H, D, T, M, S.

4. Политика повторных вызовов/retry policy - по умолчанию установлено значение «Из файла»;

5. Идентификатор политики повтора/retry policy id - описание политики повтора/Retry policy description по умолчанию не заполнены;

6. Тип содержимого тела запроса/request body payload type - перенесено в блок «Входные параметры» в виде переключателя map/string: 6.1. Map (значение по умолчанию) - при выборе: 6.1.1. Скрываются входные параметры категории Тело запроса, указанные для типа string. 6.2. Отображается: 6.2.1. Заглушка, если в списке нет параметров. 6.2.2. Список входных параметров из файла. 6.3. String - при выборе: 6.3.1. Скрываются входные параметры категории Тело запроса, указанные для типа map. 6.3.2. Добавляется по умолчанию параметр request типа String. 6.3.3. Блокируется кнопка Удалить параметр. 6.4.4. Блокируется кнопка Добавить параметр для категории Тело запроса. 6.5.5. Убирается возможность выбрать значение Тело запроса при редактировании или добавлении параметров в других категориях или на общем уровне Входные параметры.

7. Заголовок Content-Type/ Header Content-Type - выпадающий список: 7.1. Всплывающая подсказка к полю: Поддерживается только тип контента "application/json". 7.2. Значение берется из requestBody.content выбранного метода. 7.2.1. Если значение задано, то оно отображается в поле. 7.2.2. Если значение не указано, то подсвечивается красным как обязательное. 7.2.3. Если значение является "application/xml", то Тип содержимого тела запроса обязательно должен быть типа String, а значением входного параметра должен быть сериализованный XML.

8. Заголовок Authorization/ Header Authorization: 8.1. Параметр отображается только при наличии в файле/методе securitySchemes/security иначе отображается заглушка: Нет параметров и кнопка Добавить заголовок (при клике на кнопку открывается модальное окно Заголовок (Authorization) в режиме создания). 8.2. Заголовок отображается в виде списка из одного элемента - по умолчанию промаркирован красным бейджем. 8.3. При клике открывается модальное окно Заголовок (Authorization) в режиме редактирования: 8.3.1. Источник - выпадающий список; по умолчанию = Выражение. 8.3.2. Значение - не заполнено; обязательно для заполнения.

9. Заголовок Accept/ Header Accept - выпадающий список:
   9.1. Значение из responses.content выбранного метода.

10. Входные параметры/input parameters - отображается список входных параметров с разбивкой по категориям: Путь/ Переменная запроса/Тело запроса/Заголовок. 10.1. Данные берутся из parameters и requestBody: 10.1.1. Маркировка параметров - все параметры маркируются бейджами: 10.1.1.1. Красный - если у параметра required = true и не указано значение. 10.1.1.2. Зеленый - если у параметра указано значение. 10.1.1.3. Серый - если у параметра required = false и не указано значение. 10.2. Добавить еще / Add more - кнопка; При клике на кнопку должно открываться модальное окно Входные параметры. 10.3. Добавить параметр/ Add parameter - кнопка; При клике на кнопку в каждой из категорий, должно открываться модальное окно Входные параметры, где значение поля Расположение соответствует категории. В этом случае расположение также можно поменять. 10.4. Удалить параметр / Delete parameter - кнопка: 10.4.1. Активна, если у параметра required = false; при клике на кнопку параметр удаляется из списка, если в категории это был последний параметр, то отображать заглушку: Нет элементов, счетчик параметров уменьшается на единицу. 10.4.2. Заблокирована, если у параметра required = true; при наведении курсора на иконку, отображать подсказку: Параметр является обязательным.

Добавление/редактирование заголовка "Authorization"#

Заголовок запроса Authorization включает в себя данные пользователя для проверки подлинности пользовательского агента с сервером.

Состав:

1. источник - выпадающий список; по умолчанию = Выражение;

2. значение/value - обязательное поле: в нем можно указать любое значение.

Заполнение/редактирование входных параметров#

Состав:

1. наименование/name - обязательное поле, input со счетчиком (максимум 255 символов) - название параметра из файла;

   1. запрещены следующие названия для параметра с расположением = «заголовок»: Content-Type, Accept, Authorization, включая вариации: accept, authorization, content-Type/ content-type/ Content-type

   2. если введен запрещенный заголовок, то поле подсвечивается красным и отображается снизу подсказка: «Нельзя использовать в названии заголовка вариации значений: Content-Type, Authorization, Accept»

2. признак обязательности параметра - чек-бокс:

   1. значение определяется при первоначальной загрузке из файла по признаку required у параметра: если значение true, то устанавливается маркер в чек-бокс, в противном случае маркер не устанавливается (нет данных/ значение = false);

   2. у ранее созданных моделей по значению признака sbt:required атрибута sbt:inputParam в xml модели: если значение true, то устанавливается маркер в чек-бокс, в противном случае маркер не устанавливается (нет данных/ значение = false).

3. расположение/location - выпадающий список:

   1. Путь/Тело запроса/Переменная запроса /Заголовок определяется по файлу при редактировании при создании (in path = Путь/ in query = Переменная запроса/ in header = Заголовок/ requestBody = Тело запроса);

   2. если нажата общая кнопка, то отображается значение по умолчанию = Тело запроса;

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

4. тип/type - выпадающий список; тип параметра из файла

   1. Integer → Long

   2. Number → Double

   3. String → String

   4. Boolean → Boolean

   5. Array → List

   6. Object → Map

5. источник/source - выпадающий список: Переменная/ Выражение; по умолчанию выбрано значение = «Выражение»

6. значение/value - обязательное поле:

   1. если Источник = Выражение, то поле «Значение» - это поле для ввода и в нем можно указать любое значение

   2. если источник = Переменная, то поле «Значение» - это выпадающий список с переменными; список должен быть отсортирован по типу данных переменных

7. кнопка «Отменить» - активна; при клике модальное окно закрывается, все внесенные в окне изменения сбрасываются

8. кнопка «Сохранить изменения»/ «Добавить» - активируется при заполнении обязательных полей; при клике:

   1. в тело модели вносятся указанные изменения;

   2. модальное окно закрывается;

   3. список входных параметров обновляется:

      1. параметр отображается согласно выбранному расположению;

      2. маркируется зеленым, т.к. значение заполнено;

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

Отображение массива#

1. При загрузке отображается название параметра

2. В поле Тип устанавливается значение = List (выбор переменных ограничивается значением list)

3. В поле Расположение устанавливается значение = "Тело запроса",

4. Отображается подсказка о параметрах массива, расположенная под полем Название.

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

1. При загрузке из файла параметра с типом enum, он конвертируется в параметр с типом string;

2. При редактировании такого параметра отображается тип = string и выбор переменных также ограничивается типом string;

3. Также под полем Название отображается подсказка с возможными значениями, которые может принимать параметр.

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

Отображение Enum#

1. При загрузке из файла параметра с типом enum, он конвертируется в параметр с типом string;

2. При редактировании такого параметра отображается тип = string и выбор переменных также ограничивается типом string;

3. Под полем Название отображается подсказка с возможными значениями, которые может принимать параметр.

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

Отображение allOf/anyOf/oneOf#

allOf:

1. При обработке файла Open API используются параметры из основной схемы + параметры из дополнительной схемы:

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

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

anyOf/oneOf:

1. При загрузке из файла при наличии anyOf/oneOf, в списке отображается обязательный параметр requestBody;

2. При редактировании такого параметра тип = map, и ограничивается выбор переменных типом map;

3. В поле Расположение устанавливается значение = «Тело запроса»;

4. В подсказке отображаются возможные значения (все схемы с их составом + дискриминатор).

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

Отображение объекта#

1. При загрузке из файла параметра с типом object, он конвертируется в параметр с типом map;

2. Под полем Название отображается подсказка с описанием объекта.

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

При успешной загрузке файла на вкладке «Ответ» отображаются поля:

1. Маппинг параметров 1 к 1/Direct output mapping — чек-бокс: 1.1. Если отметка не установлена, то пользователь может настроить выходные параметры (отображается блок Выходные параметры).
   1.2. Если отметка установлена, то данные выходных параметров передаются в переменную контекста процесса по умолчанию (блок Выходные параметры скрывается).

2. Выходные параметры/Output parameters - позитивные выходные параметры (HTTP-коды: 100-199, 200-299). 2.1. При загрузке из файла выходные параметры не парсятся, список остается пустым с возможностью добавлять любое количество выходных параметров вручную. 2.2. При работе с существующей моделью источник, переменная и ее значение определяются по xml-модели и список выходных параметров маркируется согласно правилам:

   • красный бейдж - значение и целевая переменная не заполнены;

   • зеленый бейдж - значение и целевая переменная заполнены;

   • (предупреждение) - Целевая переменная не найдена в переменных Процесса или является повтором;

   • запрещено указывать в качестве источника для разных выходных параметров одну и ту же переменную;

   • в качестве названия параметра отображается название целевой переменной, если название не указано, то отображается пустой параметр;

   • если переменной нет в списке переменных контекста, то устанавливается источник = Выражение;

   • удалить параметр / Delete parameter - кнопка:

     • активна - при клике параметр удаляется из списка и счетчик уменьшается на единицу;

   • при клике на название параметра или на кнопку «Добавить» открывается модальное окно «Выходные параметры».

3. Обработка HTTP ошибок/ HTTP errors mapping — отображаются стандартные ошибки HTTP (HTTP-коды: 300-e, 400-e, 500-e) по данным из responses:
   3.1. Отображается список с маркировкой:

   • добавляется в список код ошибки из файла и маркируется красным бейджем, т.к. нет указан код ошибки BPMN;

   • после указания кода ошибки BPMN, элемент списка маркируется зеленым бейджем;

   • при работе с импортированной моделью также проверяется наличие кода HTTP и кода BPMN (sbt:bpmnErrorCodeзначение</sbt:bpmnErrorCode>sbt:httpCodeзначение</sbt:httpCode>), если пара значений неполная, то также элемент списка маркируется красным бейджем;

   • при клике на кнопку «Добавить» открывается модальное окно Обработка HTTP ошибок в режиме создания;

   • при клике на элемент списка открывается модальное окно Обработка HTTP ошибок в режиме редактирования элемента списка;

4. Обработка исключений/Exceptions mapping — список исключений; по умолчанию не заполнен. 4.1. отображается список с маркировкой:

   • при работе с импортированной моделью проверяется наличие исключений (sbt:exceptionErrorMappingList → sbt:exceptionErrorMapping → sbt:bpmnErrorCode & sbt:exceptionName), если пара значений не полная, то элемент списка маркируется красным бейджем;

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

Добавление/редактирование исключений#

Окно открывается в двух режимах:

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

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

Состав:

1. Наименование исключения/ Exception name — input со счетчиком:

   1. обязательное;

   2. максимум 255 символов.

2. Код ошибки BPMN/ BPMN error code — input со счетчиком:

   1. обязательное;

   2. максимум 255 символов.

3. Добавить элемент — кнопка:

   1. отображается только в режиме создания;

   2. при клике добавляется новая строка для ввода элемента;

   3. при клике на кнопку «Сохранить изменения» в списке обработки ошибок HTTP обновляются данные в выбранной строке.

Заполнение выходных параметров#

Состав:

1. Источник - выпадающий список: Переменная/ Выражение; по умолчанию выбрано значение = «Выражение».

2. Значение - обязательное поле: 2.1. Если Источник = Выражение, то поле «Значение» — это поле для ввода и в нем можно указать любое значение (установлено значение @RESULT).
   2.2. Если Источник = Переменная, то поле «Значение» — заблокированное поле ввода со значением по умолчанию; (установлено значение @RESULT).

3. Целевая переменная — список целевых переменных, в которые запишутся параметры;

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

Обработка HTTP-ошибок#

Состав:

1. HTTP код / HTTP code — input со счетчиком:
   1.1. Обязательное.
   1.2. Максимум 255 символов.

2. Код ошибки BPMN/ BPMN error code — input со счетчиком:
   2.1. Обязательное.
   2.2. Максимум 255 символов.

XML представление настроек#

Примеры XML-представлений задачи Вызов сервиса с типом JSON-RPC и REST смотрите ниже в пункте Примеры.

Отображение настроек REST:

<bpmn2:task id="bb3d66fa-ea87-4545-92e0-0afe8feec30d" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="http://api-mock-rest:8000/pet/ {petId}" sbt:initialUrl="http://api-mock-rest:8000/pet/{petId}
" sbt:methodName="post" sbt:retryPolicyModelId="" sbt:retryPolicyModelDescription="" sbt:timeout="PT10S" sbt:outputMapping="expression" sbt:apiSource="file" sbt:payloadType="map" sbt:buildingBlockId="" sbt:serviceType="ordinary" name="New Task">

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

Вручную → отсутствует sbt:retryPolicyModelPath
<bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="post" sbt:apiSource="file" sbt:timeout="" sbt:payloadType="map" sbt:outputMapping="direct" sbt:retryPolicyModelId="идентификатор политики повтора" sbt:retryPolicyModelDescription="описание политики повтора" sbt:buildingBlockId="">

Из файла (только файлы с расширением .xml) → добавляется sbt:retryPolicyModelPath
<bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="post" sbt:apiSource="manual" sbt:timeout="" sbt:payloadType="string" sbt:outputMapping="expression" sbt:retryPolicyModelPath="ret.xml" sbt:retryPolicyModelId="bc_interval_retry1" sbt:retryPolicyModelDescription="intervalRetry" sbt:buildingBlockId="">

Тип содержимого тела запроса указывается:

Map
<bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="get" sbt:apiSource="file" sbt:timeout="" sbt:payloadType="map" sbt:outputMapping="direct" sbt:retryPolicyModelId="идентификатор политики повтора" sbt:retryPolicyModelDescription="описание политики повтора" sbt:buildingBlockId="">

String
<bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="post" sbt:apiSource="file" sbt:timeout="" sbt:payloadType="string" sbt:outputMapping="expression" sbt:retryPolicyModelId="идентификатор политики повтора" sbt:retryPolicyModelDescription="описание политики повтора" sbt:buildingBlockId="">

Маппинг параметров 1 к 1 указывается:

да
<bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="get" sbt:apiSource="file" sbt:timeout="" sbt:payloadType="map" sbt:outputMapping="direct" sbt:retryPolicyModelId="идентификатор политики повтора" sbt:retryPolicyModelDescription="описание политики повтора" sbt:buildingBlockId="">
    нет
    <bpmn2:task id="Activity_335c5be" name="Go" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.RestTask" sbt:url="ap" sbt:methodName="delete" sbt:apiSource="file" sbt:timeout="" sbt:payloadType="string" sbt:outputMapping="expression" sbt:retryPolicyModelId="идентификатор политики повтора" sbt:retryPolicyModelDescription="описание политики повтора" sbt:buildingBlockId="">

Отображение входных параметров

Источник - выражение:
<sbt:inputParam xsi:type="sbt:InputParam" sbt:id="InputParam_dd0j5uu" sbt:required = "false">
    <sbt:name>id</sbt:name>
    <sbt:source>expression</sbt:source> <! -- новый атрибут для определения типа источника -->
    <sbt:type xsi:type="sbt:Value" text="java.lang.String"><![CDATA[java.lang.String]]></sbt:type>
    <sbt:variableName xsi:type="sbt:Value" text="efefr-frfr-frr-55r"><![CDATA[efefr-frfr-frr-55r]]></sbt:variableName>
    <sbt:inType>path</sbt:inType>
</sbt:inputParam>
        
Источник - переменная:
<sbt:inputParamList>
   <sbt:inputParam xsi:type="sbt:InputParam" sbt:id="InputParam_dd0j5uu" sbt:required = "true">
          <sbt:name>id</sbt:name>
    <sbt:source>variable</sbt:source> <! -- новый атрибут для определения типа источника -->
         <sbt:type xsi:type="sbt:Value" text="java.lang.String"><![CDATA[java.lang.String]]></sbt:type>
          <sbt:variableName xsi:type="sbt:Value" text="efefr-frfr-frr-55r"><![CDATA[efefr-frfr-frr-55r]]></sbt:variableName>
          <sbt:inType>path</sbt:inType>
       </sbt:inputParam>
</sbt:inputParamList>

Отображение выходных параметров

При маппинге 1 к 1 — sbt:outputParamList отсутствует

При ручной настройке:

источник - переменная:
<sbt:outputParamList>
         <sbt:outputParam xsi:type="sbt:OutputParam" sbt:id="OutputParam_5eljq8x">
            <sbt:variableName xsi:type="sbt:Value" text="test"><![CDATA[test]]></sbt:variableName>
            <sbt:expression xsi:type="sbt:Value" text="@RESULT"><![CDATA[@RESULT]]></sbt:expression>
          </sbt:outputParam>
</sbt:outputParamList>
        
        источник - выражение:
<sbt:outputParamList>
<sbt:outputParam xsi:type="sbt:OutputParam" sbt:id="OutputParam_d7o0ed6">
    <sbt:variableName xsi:type="sbt:Value" text="test"><![CDATA[test]]></sbt:variableName>
    <sbt:expression xsi:type="sbt:Value" text="111"><![CDATA[111]]></sbt:expression>
</sbt:outputParam>
</sbt:outputParamList>

Отображение заголовков

Заголовки располагаются в bpmn2:extensionElements

<bpmn2:extensionElements>
    <! -- список_входных_параметров -->
<sbt:httpHeaderList>
    <sbt:httpHeader xsi:type="sbt:HTTPHeader" sbt:id="ea6adedf-219f-4bb7-b52c-b9c3ad76ff65" sbt:required= "true">
            <sbt:name>myHeader</sbt:name>
            sbt:value>value</sbt:value>
            <sbt:type>String</sbt:type> <! -- новый атрибут для определения типа -->
            <sbt:source>variable</sbt:source> <! -- новый атрибут для определения источника -->
    </sbt:httpHeader>
    <sbt:httpHeader xsi:type="sbt:HTTPHeader" sbt:id="ea6adedf-219f-4bb7-b52c-b9c3ad76ff65" sbt:required= "true">
            <sbt:name>Authorization</sbt:name>
            <sbt:value>Basic YWxhZGRpbjpvcGVuc2VzYW1l</sbt:value>
            <sbt:type>String</sbt:type> <! -- новый атрибут для определения типа -->
            <sbt:source>expression</sbt:source> <! -- новый атрибут для определения источника --> 
    </sbt:httpHeader>
 </sbt:httpHeaderList>
</bpmn2:extensionElements>

Отображение HTTP-ошибок

Входит в bpmn2:extensionElements

<sbt:httpCodeErrorMappingList>
    <sbt:httpCodeErrorMapping xsi:type="sbt:HTTPCodeErrorMapping" sbt:id="HTTPCodeErrorMapping_8vt6ymv">
            <sbt:bpmnErrorCode>ERROR</sbt:bpmnErrorCode>
            <sbt:httpCode>300</sbt:httpCode>
    </sbt:httpCodeErrorMapping>
 </sbt:httpCodeErrorMappingList>

Отображение исключений

Входит в bpmn2:extensionElements

<sbt:exceptionErrorMappingList>
    <sbt:exceptionErrorMapping xsi:type="sbt:ExceptionErrorMapping" sbt:id="ExceptionErrorMapping_8why0n2">
            <sbt:bpmnErrorCode>ERROR BPMN</sbt:bpmnErrorCode>
            <sbt:exceptionName xsi:type="sbt:Value" text="Исключение"><![CDATA[Исключение]]></sbt:exceptionName>
    </sbt:exceptionErrorMapping>
</sbt:exceptionErrorMappingList>

Начиная с BPMX 5.x произошел переход с Apache HttpClient на WebClient. Соответственно, произошли изменения в классах исключений, отбрасываемых при исполнении REST и JSON-RPC задач.

Получение сообщения#

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

Графическое представление:

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

XML представление:

<receiveTask id="Activity_0duusmv" name="Go" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableRecieveTask">
</receiveTask>

Настройка параметров:

Вызов повторно-используемого действия#

Вызов повторно-используемого действия (Call Activity) – элемент процесса, позволяющий использовать в основном процессе глобальные, переиспользуемые процессы.

Графическое представление:

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

XML представление:

<bpmn2:callActivity id="Activity_192dvjz" name="" calledElement="model2.bpmn#Process_23d19e4" 
  sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableCallActivity" 
  sbt:retryPolicyModelPath="retryPolicyModel.xml" sbt:retryPolicyModelId="1" 
  sbt:retryPolicyModelDescription="Service unavailable">
    <bpmn2:extensionElements>
        <sbt:inList>
          <sbt:in xsi:type="sbt:in" sbt:id="In_4et2wg1" sbt:target="nameOfVariableInSubProcess" sbt:source="someVariableInMainProcess" />
        </sbt:inList>
        <sbt:outList>
          <sbt:out xsi:type="sbt:out" sbt:id="Out_asq5qrm" sbt:target="nameOfVariableInMainProcess" sbt:source="someVariableInSubProcess" />
        </sbt:outList>
    </bpmn2:extensionElements>
</bpmn2:callActivity>

Настройка параметров:

Подробное описание некоторых параметров:

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

   • Target – переменная контекста вызываемого процесса, в которую будет помещено полученное значение;

   • Тип – Тип передаваемого значения:

     • Источник – используется для прямой передачи значения переменной контекста основного процесса в контекст вызываемого процесса;

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

   • Значение – передаваемое значение, зависит от Типа:

     • для Типа Источник – название переменной контекста основного процесса;

     • для Типа Выражение – выражение;

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

   • Target – переменная контекста основного процесса, в которую будет помещено полученное значение;

   • Тип – Тип передаваемого значения:

     • Источник – используется для прямой передачи значения переменной контекста вызываемого процесса в контекст основного процесса;

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

   • Значение – передаваемое значение, зависит от Типа:

     • для Типа Источник – название переменной контекста вызываемого процесса;

     • для Типа Выражение – выражение;

Развилки#

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

Графическое представление:

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

Доступны 4 типа развилок:

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

Развилка «или/или»#

Развилка «или/или» используется для принятия решения в модели процесса.

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

Условие для перехода по конкретному потоку исполнения можно задать как в настройках потока, так и на вкладки "Исполнение" развилки, при условии того, что они уже указаны на схеме процесса. Условие может быть указано только при помощи JUEL Expression. Более подробно о правилах указания условия см. Работа с отладочным окном для скриптов и выражений.

Также Развилка «или/или» может соединять потоки управления. Развилка «или/или» не будет ждать, пока в ней соберутся потоки исполнения всех исполняющихся потоков управления, а каждый такой поток продолжит выполняться дальше самостоятельно.

Графическое представление:

Развилка «или/или» изображается как ромб с символом «х» внутри, напоминающим о логическом «ИЛИ»:

Настройки потоков исполнения, указанных из развилки:

При наведении на знак прицела напротив id потока управления, этот поток подсвечивается на схеме.

XML представление:

<bpmn2:exclusiveGateway id="a8d53e76-4eac-40a7-9fb5-04f13171a40e" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableExclusiveGateway" name="New Exclusive Gateway" gatewayDirection="Diverging">
    <bpmn2:incoming>e76c1ed2-9a5e-4433-95c8-0cbbcd57d269</bpmn2:incoming>
    <bpmn2:outgoing>c10109ac-08aa-4df1-a766-5df0ba9832e6</bpmn2:outgoing>
    <bpmn2:outgoing>a8aa845b-6ff3-452e-85e6-4dac4555d60a</bpmn2:outgoing>
    <bpmn2:outgoing>ff570165-48f5-4f96-b9f2-71dfe466904b</bpmn2:outgoing>
</bpmn2:exclusiveGateway>

Настройка параметров:

Развилка «и/или»#

Развилку «и/или» можно рассматривать как комбинацию Развилки «или/или» и Параллельной развилки. Можно прописать условия для выбора исходящего потока, и развилка будет их проверять. Те из них, у которых проверка выдаст «истинно», будут запущены для одновременного исполнения (при этом для каждого потока управления будет свой поток исполнения). Можно выбрать поток по умолчанию, по которому продолжится выполнение процесса в случае если ни одно условие не выполнилось. В случае если ни один поток не выбран по умолчанию, для пользователя в моменте проектирование отображается подсказка. Описание условий содержится в коде самих потоков управления – Sequence Flow.

Условие для перехода по конкретному потоку исполнения можно задать как в настройках потока, так и на вкладки "Исполнение" развилки, при условии того, что они уже указаны на схеме процесса. Условие может быть указано только при помощи JUEL Expression. Более подробно о правилах указания условия см. Работа с отладочным окном для скриптов и выражений.

Также Развилка «и/или» может соединять потоки управления. Развилка «и/или» будет ждать, пока в ней соберутся потоки исполнения всех исполняющихся потоков управления. Только когда соберутся все запущенные потоки, Развилка «и/или» позволит продолжить исполнение процесса одним объединенным потоком.

Графическое представление:

Развилка «и/или» изображается в виде ромба с символом круга внутри:

Настройки потоков исполнения, указанных из развилки:

XML представление:

<bpmn2:inclusiveGateway id="fa14bc0f-f581-458c-9903-d68f4e98debd" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableInclusiveGateway" name="New Inclusive Gateway"  gatewayDirection="Converging">
    <bpmn2:incoming>fa8f3019-6d5b-4fe1-aebb-02cbae2d535a</bpmn2:incoming>
    <bpmn2:outgoing>acb39d13-d3c8-43be-b64c-c6575554b478</bpmn2:outgoing>
    <bpmn2:outgoing>ff570165-48f5-4f96-b9f2-71dfe466904b</bpmn2:outgoing>
</bpmn2:inclusiveGateway>

Настройка параметров:

Параллельная развилка#

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

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

Графическое представление:

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

Настройки потоков исполнения, указанных из развилки:

XML представление:

<bpmn2:parallelGateway id="ffa4a847-56b0-43ed-91a2-668b9753f239" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableParallelGateway" name="New Parallel Gateway" gatewayDirection="Converging">
    <bpmn2:incoming>e614f726-0fe9-4184-a7a2-9157aa0b8a78</bpmn2:incoming>
    <bpmn2:incoming>bf23d547-616b-498f-a933-cc2c7126b1b2</bpmn2:incoming>
    <bpmn2:outgoing>a11eb55c-7df0-4cf6-bec8-b6956bbc7ed0</bpmn2:outgoing>
</bpmn2:parallelGateway>

Настройка параметров:

Развилка по событиям#

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

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

Графическое представление:

Развилка по событиям изображается в виде ромба со специфическим символом внутри:

Настройки потоков исполнения, указанных из развилки:

XML представление:

<bpmn2:eventBasedGateway id="cfcd7140-c3d3-4a18-b33e-c743d5c76729" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableEventBasedGateway" name="New Event Based Gateway" gatewayDirection="Diverging" eventGatewayType="Parallel" instantiate="true">
      <bpmn2:incoming>cf60b836-dab1-4b59-a860-e9847937f7ff</bpmn2:incoming>
      <bpmn2:outgoing>bd304eb4-6b58-4ae4-b873-5e32ae7a8118</bpmn2:outgoing>
      <bpmn2:outgoing>bdb7f27e-9192-465d-9364-7eace5c3d6d0</bpmn2:outgoing>
</bpmn2:eventBasedGateway>

Настройка параметров:

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

Потоки управления (Sequence Flows) соединяют различные элементы модели между собой.

Графическое представление:

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

XML представление:

<bpmn2:sequenceFlow id="Flow_0ourv8n" name="StartTask 2" sourceRef="Gateway_0m9s4gj" targetRef="Event_1kohbdg">
    <bpmn2:conditionExpression xsi:type="bpmn2:tFormalExpression"><![CDATA[${execution.getVariable("selectedTask") == 'task2'}]]></bpmn2:conditionExpression>
</bpmn2:sequenceFlow>

Настройка параметров:

Подпроцесс#

Часть процесса может быть объединена в Подпроцесс (Sub Proccess) для улучшения читаемости схемы и упрощения моделирования сложных процессов. Для подпроцесса могут быть определены собственные переменные, доступные только в контексте данного подпроцесса. Подпроцесс должен иметь одно начальное и одно конечное событие.

Графическое представление:

XML представление:

<bpmn2:subProcess id="Activity_1fk7goq" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableSubProcess">
    <bpmn2:startEvent id="Event_0hk5krp" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableStartEvent">
        <bpmn2:outgoing>Flow_0w06q3l</bpmn2:outgoing>
    </bpmn2:startEvent>
    <bpmn2:task id="Activity_1dwzzd4" name="">
        <bpmn2:incoming>Flow_0w06q3l</bpmn2:incoming>
        <bpmn2:outgoing>Flow_1n5w2kz</bpmn2:outgoing>
    </bpmn2:task>
    <bpmn2:sequenceFlow id="Flow_0w06q3l" name="" sourceRef="Event_0hk5krp" targetRef="Activity_1dwzzd4" />
    <bpmn2:endEvent id="Event_0fbk30y" name="" sbt:marker.type="Markable" sbt:sbtType="com.sbt.bpms.modeler.plugin.marker.markableEndEvent">
        <bpmn2:incoming>Flow_1n5w2kz</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:sequenceFlow id="Flow_1n5w2kz" name="" sourceRef="Activity_1dwzzd4" targetRef="Event_0fbk30y" />
</bpmn2:subProcess>

Настройка параметров:

Про параметры Множественной задачи смотрите раздел ниже «Настройка Множественной задачи».

Настройка множественной задачи#

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

Настройка Множественной задачи доступна для Подпроцесса (Sub Process).

Дополнительные переменные :

Для каждого экземпляра Множественной задачи доступны следующие переменные:

• nrOfInstances – общее количество созданных экземпляров;

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

• nrOfCompletedInstances – количество уже завершенных экземпляров.

Значения этих переменных можно получить, вызвав метод execution.getVariable(x).

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

Графическое представление:

Можно выбрать один из режимов работы Множественной задачи: Параллельно или Последовательно.

Графически выбранный режим обозначается тремя короткими линиями внизу элемента. Три вертикальные линии указывают на то, что экземпляры будут выполняться параллельно:

Три горизонтальные линии указывают на последовательное выполнение:

Настройка параметров:

1. Количество экземпляров рассчитывается один раз при входе в элемент. Есть два способа настроить это:

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

     

     Также можно передавать выражения, результатом которых является положительное число, например, ${nrOfOrders-nrOfCancellations}.

     Пример xml-кода:

     <bpmn2:multiInstanceLoopCharacteristics isSequential="false">
         <bpmn2:loopCardinality xsi:type="bpmn2:tFormalExpression"><![CDATA[2]]></bpmn2:loopCardinality>
     </bpmn2:multiInstanceLoopCharacteristics>
     

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

     

     Примеры xml-кода:

     <bpmn2:multiInstanceLoopCharacteristics isSequential="true" 
         activiti:collection="assigneeList" activiti:elementVariable="assignee" />
     

     Также можно передавать выражения, например:

     <userTask id="miTasks" name="My Task" activiti:assignee="${assignee}">
         <multiInstanceLoopCharacteristics isSequential="true"
             activiti:collection="${myService.resolveUsersForTask()}" activiti:elementVariable="assignee" >
         </multiInstanceLoopCharacteristics>
     </userTask>
     

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

   

   Пример xml-кода:

   <multiInstanceLoopCharacteristics isSequential="false"
       activiti:collection="assigneeList" activiti:elementVariable="assignee" >
       <completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</completionCondition>
   </multiInstanceLoopCharacteristics>
   

   В этом примере для каждого элемента assigneeList коллекции создаются параллельные экземпляры. Однако, когда 60% задач выполнено, другие задачи удаляются, и процесс идет дальше по потоку исполнения.

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

Настройка политики повторных вызовов#

Повторный вызов может быть настроен пользователем в случае необходимости для задач Вызов повторно-используемого действия (Call Activity) и Вызов сервиса (Service Task). Настройка осуществляется через xml-файл, содержащий описание политик повторного вызова. Один xml-файл может быть использован для нескольких моделей процессов.

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

Затем, при получении данных «Из файла», в свойствах элемента нужно указать путь к этому файлу в поле Файл политик повтора. Можно нажать кнопку Выбрать файл и в открывшемся диалоговом окне выбрать нужный xml-файл с политиками повторов.

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

Также данные по политике повторных вызовов могут быть внесены вручную. Для этого нужно выбрать режим «Вручную» и заполнить поля Идентификатор политики повтора и Описание политики повтора.

Пример xml-файла моделей политик повторных вызовов:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:retryPolicyModels xmlns:xs="https://sbertech.ru/bpm/retryPolicy/1.0"
    businessFamily="dul_family">
      <xs:retryPolicyModel id="DULRetryPolicy" description="Политика Retry ДЮЛ">
          <!-- id модели используется для связи с задачами, для которых она будет применима -->
          <xs:retryPolicies>
              <xs:retryPolicy description="Политика для TransportTimeoutException">
                  <xs:exceptions> <!--Список исключений, на которые нужно реагировать-->
                               <xs:exception>com.sbt.core.amqp.exceptions.TransportTimeoutException
                      </xs:exception>
                      <xs:exception>com.sbt.core.amqp.exceptions.TransportNoRouteException
                      </xs:exception>
                      <xs:exception>com.sbt.core.amqp.exceptions.UnavailableServiceException
                      </xs:exception>
                      <xs:exception>com.sbt.core.amqp.exceptions.TransportException
                      </xs:exception>
                      <xs:exception>com.sbt.pprb.ac.common.exception.CdmWrappedException
                      </xs:exception>
                  </xs:exceptions>
                  <xs:retryStrategy>
                      <xs:linear> <!-- задать количество повторных попыток и интервал -->
                          <xs:count>3</xs:count>
                          <xs:timeout>PT1M</xs:timeout>
                      </xs:linear>
                  </xs:retryStrategy>
              </xs:retryPolicy>
          </xs:retryPolicies>
      </xs:retryPolicyModel>
</xs:retryPolicyModels>

Работа с Конструктором форм#

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

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