Этот тип действия позволяет передать данные из ELMA365 внешнему сервису, обработать их и получить ответ.
Делегированные действия передаются в сторонний микросервис по стандартизированному Web API (HTTP REST). Один сервис может реализовывать несколько действий, которые разделяются кодом.
Данное действие не использует скрипты, поэтому настраивается только на вкладках Настройки и Контекст.
Вкладка «Настройки»
Заполните поля на вкладке Настройки:
- Название — наименование действия в настройках модуля и в дизайнере бизнес-процессов;
- Название по умолчанию — наименование элемента, отображающееся при его добавлении на схему процесса;
- Цвет блока — цвет блока на схеме процесса;
- Описание — описание функциональных возможностей действия и его особенностей;
- Устаревшее — опция позволяет скрыть элемент из дизайнера бизнес-процессов, чтобы пользователи не смогли добавлять его на схемы новых процессов. Устаревшие действия продолжат работать без изменений в уже созданных процессах. Например, можно включить опцию для блока после обновления модуля;
- URL делегирования — адрес внешнего сервиса с указанием кода определённого действия в виде:
schema://domain:port/base/path/action-code. Нажмите значок {+} в поле, чтобы использовать в адресе переменные, созданные в пользовательском модуле на вкладке Настройки. С помощью значка f(x) в адрес можно добавить функцию DateTime(); - Количество повторов при ошибке — количество попыток выполнения действия;
- Пауза между повторами при ошибке (сек)* — частота попыток выполнения действия при возникновении ошибки.
Вкладка «Контекст»
Добавьте переменные, которые будут использоваться в настройках элемента на схеме бизнес-процесса. Контекст можно запросить из внешнего сервиса‑исполнителя или создать вручную, нажав + Добавить для каждой переменной. Подробнее о типах переменных читайте в статье «Типы данных в системе».
Отметьте, какие переменные являются входными и выходными. Это позволит сопоставить контекст действия и процесса, в котором оно используется.
Вы также можете настроить пользовательскую форму сопоставления, т. е. окно настроек блока действия. Оно откроется при добавлении блока на схему бизнес‑процесса. Например, на форме можно отобразить информационное поле с подсказками.
Подробнее о биндинге переменных читайте в статье «Биндинг переменных для действий в бизнес‑процессах».
Обратите внимание, если на вкладке Контекст вы хотите удалить неиспользуемые переменные из списка, убедитесь, что они не добавлены на пользовательскую форму сопоставления как отдельное поле или внутрь виджета. Иначе появится сообщение об ошибке.
После внесения данных на вкладках нажмите Сохранить и Опубликовать на верхней панели окна настроек действия. При включённом модуле действие появится в дизайнере бизнес-процессов на вкладке Интеграции. Блок можно добавить на схему процесса и задать настройки для его выполнения.
Принцип работы действия
Делегированное действие выполняется по следующему алгоритму:
- Заданный в настройках действия URL делегирования считывается сервисом-processor и вызывается его метод
/requests. В теле запроса передаются Исполнители и Контекст — значения входных контекстных переменных из настроек действия. - Когда сервису-исполнителю передаётся запрос на
/requests, происходит одно из следующих действий:
- действие выполняется, и выдаётся результат;
- запрашиваются дополнительные данные из сервиса-processor;
- при наличии всех данных, но невозможности синхронного выполнения действия, информация сохраняется, например, в базе данных. В сервис-processor отправляется ответ о том, что действие принято к исполнению, и передаётся URL метода, по которому отправляется идентификатор точки восстановления;
- при возникновении ошибки возвращается оповещение об этом.
- В зависимости от полученного ответа от сервиса-исполнителя, со стороны сервиса-processor происходит одно из следующих действий:
- при выполненном действии результат записывается в выходные переменные, настроенные в контексте действия. Выполнение бизнес-процесса продолжается;
- при необходимости запроса дополнительных данных, создаётся пользовательская задача. После её выполнения снова вызывается метод
/requests; - если действие было принято к исполнению, создаётся точка восстановления. Её идентификатор передаётся в сервис-исполнитель с помощью полученного URL;
- в случае ошибки происходит её анализ. Отправляется повторный запрос, согласно указанным в действии настройкам. С помощью шлюза в процессе можно также настроить дополнительную ветку, по которой продолжится ход в случае возникновения ошибки.
Запрос дополнительных данных в задаче
Для выполнения действия сервису-исполнителю могут потребоваться дополнительные данные от пользователя, например, электронная подпись. Тогда в ответ на вызов /requests сервис-исполнитель возвращает код 201. Инициатору процесса приходит задача, в которой прописываются: исполнители, контекст (данные), описание полей формы для задачи, список допустимых переходов.
Пользователь указывает нужную информацию. Затем сервис-processor снова вызывает метод /requests и передаёт сервису-исполнителю данные формы, выбранный переход, идентификатор исполнителя задачи. После этого сервис-исполнитель выполняет действие повторно.
Ожидание выполнения действия
В случае создания точки восстановления процесс останавливается до выполнения делегированного действия сервисом-исполнителем. Если на схеме процесса после действия настроено промежуточное событие-таймер, ожидание прервётся по истечении установленного времени.
После получения сервисом-исполнителем идентификатора точки восстановления он сохраняется, например, в базе данных. Затем происходит выполнение действия.
По окончании действия в сервис-processor передаётся информация о необходимости продолжения бизнес-процесса с точки восстановления. Для передачи результата делегированному действию используется метод Web API:
POST /pub/v1/bpm/restore-point/{id}/restore
В теле запроса передаётся обновленный контекст действия. Подробнее о продолжении процесса с точки восстановления читайте в справке по публичному API ELMA365.
Полученные данные записываются сервисом-processor в выходные переменные, настроенные в элементе, и процесс продолжается.
Прерывание выполнения действия
Прерывание или отмена делегированного действия происходит:
- при прерывании бизнес-процесса;
- при эскалации по таймеру.
Инициатором прерывания действия является сервис-processor. Он удаляет созданную точку восстановления и информирует сервис-исполнитель о необходимости отмены действия с помощью вызова.
API сервиса-исполнителя
Подробное описание интерфейса сервиса-исполнителя вы можете посмотреть в OpenAPI-схеме:
openapi: 3.0.0 |