Контекстная модель программирования

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

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

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

В OpenBPM Engine CDI экземпляр процесса может быть связан с областью видимости CDI, и такая связь представляет единицу работы. Это особенно полезно, если единица работы сложна, например когда реализация пользовательской задачи состоит из сложной последовательности различных форм и в ходе этого взаимодействия нужно сохранять состояние, не привязанное к процессу. В конфигурации по умолчанию экземпляры процесса связываются с самой "широкой" активной областью видимости, начиная с conversation и с переходом к request, если контекст conversation не активен.

Связывание conversation с экземпляром процесса

При разрешении бинов @BusinessProcessScoped или внедрении переменных процесса используется уже существующая связь между активной областью видимости CDI и экземпляром процесса. Интеграция OpenBPM Engine CDI предоставляет бин io.openbpm.bpm.engine.cdi.BusinessProcess для управления этой связью, в частности:

  • методы startProcessBy*(…​), повторяющие соответствующие методы RuntimeService и позволяющие запустить, а затем связать бизнес-процесс;

  • resumeProcessById(String processInstanceId), позволяющий связать экземпляр процесса с переданным идентификатором;

  • resumeTaskById(String taskId), позволяющий связать задачу с переданным идентификатором (и, соответственно, соответствующий экземпляр процесса).

После завершения единицы работы, например пользовательской задачи, можно вызвать метод completeTask(), чтобы разорвать связь conversation/request с экземпляром процесса. Это сообщает движку, что текущая задача завершена, и позволяет экземпляру процесса продолжить выполнение.

Обратите внимание, что бин BusinessProcess является @Named-бином, а значит, его методы можно вызывать через expression language, например со страницы JSF. Следующий фрагмент JSF2 начинает новую conversation и связывает её с экземпляром пользовательской задачи, идентификатор которой передаётся как параметр запроса (например, pageName.jsf?taskId=XX):

<f:metadata>
  <f:viewParam name="taskId" />
  <f:event type="preRenderView" listener="#{businessProcess.startTask(taskId, true)}" />
</f:metadata>

Декларативное управление процессом

OpenBPM Engine CDI позволяет декларативно запускать экземпляры процесса и завершать задачи с помощью аннотаций. Аннотация @io.openbpm.bpm.engine.cdi.annotation.StartProcess позволяет запускать экземпляр процесса либо по "key", либо по "name". Обратите внимание, что экземпляр процесса запускается после завершения аннотированного метода. Пример:

@StartProcess("authorizeBusinessTripRequest")
public String submitRequest(BusinessTripRequest request) {
  // do some work
  return "success";
}

В зависимости от конфигурации процессного движка OpenBPM Engine код аннотированного метода и запуск экземпляра процесса будут выполнены в рамках одной и той же транзакции. Аннотация @io.openbpm.bpm.engine.cdi.annotation.CompleteTask работает аналогичным образом:

@CompleteTask(endConversation=false)
public String authorizeBusinessTrip() {
    // do some work
    return "success";
}

Аннотация @CompleteTask позволяет завершить текущую conversation. По умолчанию conversation завершается после возврата из вызова движка. Это поведение можно отключить, как показано в примере выше.

Работа с бинами @BusinessProcessScoped

С помощью OpenBPM Engine CDI жизненный цикл бина можно привязать к экземпляру процесса. Для этого предоставляется собственная реализация контекста, а именно BusinessProcessContext. Экземпляры бинов BusinessProcessScoped сохраняются как переменные текущего экземпляра процесса. При развёртывании бины, аннотированные BusinessProcessScoped, проверяются на "passivation capable", то есть они должны реализовывать интерфейс Serializable, а их ссылки (зависимости) также должны быть "passivation capable". Подробнее о критериях "passivation capable" можно прочитать в спецификации CDI: https://docs.jboss.org/cdi/spec/1.0/html_single/#passivatingscope.

Ниже приведён пример process-scoped бина, удовлетворяющего требованиям "passivation capable":

@Named
@BusinessProcessScoped
public class BusinessTripRequest implements Serializable {
        private static final long serialVersionUID = 1L;
        private String startDate;
        private String endDate;
        // ...
}

Иногда требуется работать с process-scoped бинами без существующей связи с экземпляром процесса, например до запуска процесса. Если экземпляр процесса в данный момент не активен, экземпляры бинов BusinessProcessScoped временно сохраняются в локальной области видимости (то есть в Conversation или Request, в зависимости от контекста). Если позже эта область видимости будет связана с экземпляром бизнес-процесса, экземпляры бинов будут перенесены в экземпляр процесса.

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

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

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