Кастомизированная реализация

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

Предоставление кастомизированного бэкенда для истории

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

Архитектура истории

Каждый раз, когда состояние рантайм-сущности меняется, компонент ядра выполнений в движке управления процессами триггерит события для истории. Чтобы придать этому процессу гибкость, создание событий истории, как и наполнение событий истории данными из рантайм-структур делегируется продюсеру событий истории (History Event Producer). Продюсер выдается в структурах данных для рантайма (например, ExecutionEntity или`TaskEntity`), создает новое событие истории и наполняет его данными из рантайм-структур.

Событие затем доставляется в обработчик событий истории (History Event Handler), который представляет собой бэкенд истории. Приведенный выше рисунок содержит логический компонент под названием event transport (транспорт события). Он должен представлять канал между ядром движка управления процессами, создающим события, и обработчиком события истории. В реализации по умолчанию события доставляются в обработчик событий истории синхронно, внутри одной и той же JVM. Тем не менее теоретически возможно посылать поток событий в другую JVM (возможно, запущенную на другой машине) и делать доставку асинхронной. Неплохо подошла бы транзакционная очередь сообщений (JMS).

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

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

  • Предоставить кастомизированную реализацию интерфейса {{< javadocref page="org/camunda/bpm/engine/impl/history/handler/HistoryEventHandler.html" text="HistoryEventHandler" >}}.

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

ОБРАБОТКА КОМПОЗИТНОЙ ИСТОРИИ:

Обратите внимание, что если вы предоставите кастомизированную реализацию HistoryEventHandler и подключите ее к движку управления процессами, она получит более высокий приоритет, чем используемый по умолчанию DbHistoryEventHandler, который после этого использоваться больше не будет. Последствием такого действия станет то, что движок перестанет вести запись в базу данный истории, и вы не сможете использовать сервис истории для отправки запросов к логу аудита. Если вы не хотите отменять поведение по умолчанию, а хотите только предоставить дополнительный обработчик событий, вы можете использовать класс io.openbpm.bpm.engine.impl.history.handler.CompositeHistoryEventHandler, который распределяет события между обработчиками из коллекции.

SPRING BOOT:

Обратите внимание, что предоставление вашего кастомизированного HistoryEventHandler в окружении на Spring Boot Starter работает несколько иначе. По умолчанию стартер Spring Boot от Camunda Spring Boot использует CompositeHistoryEventHandler, который оборачивает список реализаций HistoryEventHandler, которые вы можете предоставить через свойство конфигурации двжика customHistoryEventHandlers. Если вы хотите заменить используемый по умолчанию DbHistoryEventHandler, вам надо в явном виде установить свойство конфигурации движка enableDefaultDbHistoryEventHandler в значение false.

Реализация кастомного уровня истории

Чтобы предоставить кастомный уровень истории, необходимо реализовать интерфейс io.openbpm.bpm.engine.impl.history.HistoryLevel. Реализация кастомного уровня истории должна быть добавлена к конфигурации движка управления процессами лмбо через конфигурацию, либо через плагин движка управления процессами.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

  <bean id="processEngineConfiguration" class="io.openbpm.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration" >

    <property name="customHistoryLevels">
      <list>
        <bean class="io.openbpm.bpm.example.CustomHistoryLevel" />
      </list>
    </property>

  </bean>

</beans>

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

public int getId() {
  return 42;
}

public String getName() {
  return "custom-history";
}

Если уровень истории подключен, то метод

boolean isHistoryEventProduced(HistoryEventType eventType, Object entity)

будет вызываться для каждого события истории, чтобы определить, должно ли событие сохраняться в истории. Типы событий, используемые в движке, можно найти по адресу io.openbpm.bpm.engine.impl.history.event.HistoryEventTypes (см. [Javadocs][1]).

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

Обратитесь к этому [полному примеру][2], чтобы получить лучший обзор.

Наследование времени удаления

Исторические экземпляры наследуют время удаления link:{{< relref "#removal-time" >}}[] из соответствующего исторического экземпляра верхнего уровня. Если кастомный уровень истории сконфигурирован таким образом, чтобы исторический экземпляр верхнего уровня не записывался, время удаления будет недоступно.

Следующие исторические экземпляры считаются экземплярами верхнего уровня:

  • Экземпляр batch

  • Экземпляр корневого процесса

  • Экземпляр корневого решения

Логи операций пользователя и кастомный уровень истории

Следующая реализация требуется для разрешения логирования пользовательских операций:

public boolean isHistoryEventProduced(HistoryEventType eventType, Object entity) {
  if (eventType.equals(HistoryEventTypes.USER_OPERATION_LOG)){
    return true;
  }
  ...
}

[1]: http://docs.camunda.org/latest/api-references/javadoc/org/camunda/bpm/engine/impl/history/event/HistoryEventTypes.html

[2]: https://github.com/camunda/camunda-bpm-examples/tree/master/process-engine-plugin/custom-history-level

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

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

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