Spring Eventing Bridge

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

Движок процессов может быть подключён к шине событий Spring. Мы называем это «Spring Eventing Bridge». Это позволяет получать уведомления о событиях процесса с использованием стандартных механизмов событий Spring. По умолчанию интеграция со Spring Eventing включена через engine-плагин. Управление eventing осуществляется с помощью четырёх свойств openbpm.bpm.eventing:

openbpm.bpm.eventing.execution=true
openbpm.bpm.eventing.history=true
openbpm.bpm.eventing.task=true
openbpm.bpm.eventing.skippable=true

Первые три свойства управляют тремя потоками событий: событий выполнения (execution), задач (task) и истории (history) соответственно. Последнее свойство openbpm.bpm.eventing.skippable отвечает за регистрацию слушателей событий. Если его значение равно true, выполнение слушателей может быть пропущено через API или в Camunda Cockpit путём активации флага "skip listeners". В противном случае слушатели регистрируются как встроенные (built-in listeners) и выполняются безусловно.

Слушатели могут подписываться на потоки изменяемых (mutable) или неизменяемых (immutable) объектов событий. Последние особенно полезны в асинхронных сценариях обработки событий — например, при использовании TransactionalEventListener. Изменяемые объекты событий могут модифицироваться несколько раз между моментом создания события и моментом его получения слушателем, подписанным асинхронно. Неизменяемые объекты событий отражают данные на момент создания события, независимо от того, когда именно событие будет фактически получено слушателем.

В потоке событий выполнения (execution event stream) могут передаваться DelegateExecution (изменяемые) и ExecutionEvent (неизменяемые). Поток событий задач (task event stream) предоставляет DelegateTask (изменяемые) и TaskEvent (неизменяемые). В потоке событий истории (history event stream) публикуются только HistoryEvent (изменяемые).

Следующий пример демонстрирует, как события процессов могут приниматься в Spring-бинах. Таким образом, можно реализовывать task- и delegate-listeners, предоставляя Spring-бины с аннотированными методами, вместо реализации интерфейсов TaskListener и ExecutionListener.

import io.openbpm.bpm.engine.delegate.DelegateExecution;
import io.openbpm.bpm.engine.delegate.DelegateTask;
import io.openbpm.bpm.engine.impl.history.event.HistoryEvent;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;


@Component
class MyListener {

  @EventListener
  public void onTaskEvent(DelegateTask taskDelegate) {
    // handle mutable task event
  }

  @EventListener
  public void onTaskEvent(TaskEvent taskEvent) {
    // handle immutable task event
  }

  @EventListener
  public void onExecutionEvent(DelegateExecution executionDelegate) {
    // handle mutable execution event
  }

  @EventListener
  public void onExecutionEvent(ExecutionEvent executionEvent) {
    // handle immutable execution event
  }

  @EventListener
  public void onHistoryEvent(HistoryEvent historyEvent) {
    // handle history event
  }

}

Если метод, аннотированный @EventListener, возвращает результат, отличный от void, Spring выбрасывает его как новое событие в шину событий Spring. Это позволяет строить цепочки обработчиков событий для последовательной обработки. Для получения дополнительной информации о механизмах событий см. документацию Spring.

Указание типа события

Spring позволяет указывать, какое именно событие должно быть доставлено слушателю, с помощью SpEL-условия в аннотации @EventListener. Например, можно зарегистрировать слушатель для события задачи, которое срабатывает при создании пользовательской задачи с определённым ключом определения задачи (task definition key):

@Component
class MyTaskListener {

  @EventListener(condition="#taskDelegate.eventName=='create' && #taskDelegate.taskDefinitionKey=='task_confirm'")
  public void onTaskEvent(DelegateTask taskDelegate) {
  // handle task event fired by create of task_confirm task
  }
}

Упорядочивание слушателей событий

Слушатели одного и того же типа события могут выполняться в заданном порядке. Для этого используется аннотация @Order:

@Component
class MyTaskListener {

  @Order(1)
  @EventListener
  public void firstListener(DelegateTask taskDelegate) {
  // handle task event
  }

  @Order(2)
  @EventListener
  public void secondListener(DelegateTask taskDelegate) {
  // handle task event
  }

}

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org