Делегированное действие

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

Делегированные действия передаются в сторонний микросервис по стандартизированному Web API (HTTP REST). Один сервис может реализовывать несколько действий, которые разделяются кодом.

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

Вкладка «Настройки»

Заполните поля на вкладке Настройки:

delegated-activity-1

  • Название — наименование действия в настройках модуля и в дизайнере бизнес-процессов;
  • Название по умолчанию — наименование элемента, отображающееся при его добавлении на схему процесса;
  • Цвет блока — цвет блока на схеме процесса;
  • Описание — описание функциональных возможностей действия и его особенностей;
  • Устаревшее — опция позволяет скрыть элемент из дизайнера бизнес-процессов, чтобы пользователи не смогли добавлять его на схемы новых процессов. Устаревшие действия продолжат работать без изменений в уже созданных процессах. Например, можно включить опцию для блока после обновления модуля;
  • URL делегирования — адрес внешнего сервиса с указанием кода определённого действия в виде:schema://domain:port/base/path/action-code. Нажмите на значок {+} в поле, чтобы использовать в адресе переменные, созданные в пользовательском модуле на вкладке Настройки. С помощью значка f(x) в адрес можно добавить функцию DateTime();
  • Количество повторов при ошибке — количество попыток выполнения действия;
  • Пауза между повторами при ошибке (сек)* — частота попыток выполнения действия при возникновении ошибки.

Вкладка «Контекст»

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

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

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

Принцип работы действия

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

  1. Заданный в настройках действия URL делегирования считывается сервисом-processor и вызывается его метод /requests. В теле запроса передаются Исполнители и Контекст — значения входных контекстных переменных из настроек действия.
  2. Когда сервису-исполнителю передаётся запрос на /requests, происходит одно из следующих действий:
  • действие выполняется, и выдаётся результат;
  • запрашиваются дополнительные данные из сервиса-processor;
  • при наличии всех данных, но невозможности синхронного выполнения действия, информация сохраняется, например, в базе данных. В сервис-processor отправляется ответ о том, что действие принято к исполнению, и передаётся URL метода, по которому отправляется идентификатор точки восстановления;
  • при возникновении ошибки возвращается оповещение об этом.
  1. В зависимости от полученного ответа от сервиса-исполнителя, со стороны сервиса-processor происходит одно из следующих действий:
  • при выполненном действии результат записывается в выходные переменные, настроенные в контексте действия. Выполнение бизнес-процесса продолжается;
  • при необходимости запроса дополнительных данных, создаётся пользовательская задача. После её выполнения снова вызывается метод /requests;
  • если действие было принято к исполнению, создаётся точка восстановления. Её идентификатор передаётся в сервис-исполнитель с помощью полученного URL;
  • в случае ошибки происходит её анализ. Отправляется повторный запрос, согласно указанным в действии настройкам. С помощью шлюза в процессе можно также настроить дополнительную ветку, по которой продолжится ход в случае возникновения ошибки.  

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

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

Пользователь указывает нужную информацию. Затем сервис-processor снова вызывает метод /requests и передаёт сервису-исполнителю данные формы, выбранный переход, идентификатор исполнителя задачи. После этого сервис-исполнитель выполняет действие повторно.

Ожидание выполнения действия

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

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

По окончании действия в сервис-processor передаётся информация о необходимости продолжения бизнес-процесса с точки восстановления. Для передачи результата делегированному действию используется метод Web API:

POST /pub/v1/bpm/restore-point/{id}/restore

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

Полученные данные записываются сервисом-processor в выходные переменные настроенные в элементе, и процесс продолжается.

Прерывание выполнения действия

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

  • при прерывании бизнес-процесса;
  • при эскалации по таймеру.

Инициатором прерывания действия является сервис-processor. Он удаляет созданную точку восстановления и информирует сервис-исполнитель о необходимости отмены действия с помощью вызова:

API сервиса-исполнителя

Подробное описание интерфейса сервиса-исполнителя вы можете посмотреть в OpenAPI-схеме:

OpenAPI-схема