Дескриптор деплоймента processes.xml

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

Дескриптор деплоймента processes.xml содержит метаданные деплоймента для процессного приложения. Далее следует простой пример Дескриптор деплоймента processes.xml:

<process-application
  xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive name="loan-approval">
    <process-engine>default</process-engine>
    <properties>
      <property name="isDeleteUponUndeploy">false</property>
      <property name="isScanForProcessDefinitions">true</property>
    </properties>
  </process-archive>

</process-application>

Декларируется единичный деплоймент (process-archive). Архив процесса называется loan-approval и деплоится в движок управления процессами с именем default. Задаются два дополнительных свойства:

isDeleteUponUndeploy: это свойство контролирует, будет ли движок управления процессами удален и з базы данных при удалении процессного приложения. По умолчанию его значение устанавливается в false. Если это свойство установлено в true, удаление деплоймента процессного приложения ведет к удалению деплоймента (включая экземпляры процесса) из базы данных.
isScanForProcessDefinitions: если это свойство установлено в true, classpath процессного приложения будет автоматически просканирован на наличие пригодных для деплоймента ресурсов. Такие ресурсы должны именть имя, заканчивающееся на .bpmn20.xml, .bpmn, .cmmn11.xml, .cmmn, .dmn11.xml или .dmn.

См. справочник по дескрипторам деплоймента, содержащий полную документацию по синтаксису файла processes.xml.

Пустой processes.xml

Файл processes.xml может изначально быть оставлен пустым. В этом случае будут использованы значения по умолчанию. Пустой processes.xml соответствует следующей конфигурации:

<process-application
  xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive>
    <properties>
      <property name="isDeleteUponUndeploy">false</property>
      <property name="isScanForProcessDefinitions">true</property>
    </properties>
  </process-archive>

</process-application>

При пустом processes.xml будет проведено сканирование на определения процессов и единичный деплоймент в движок управления процессами по умолчанию.

Местоположение файла processes.xml

Местоположение по умолчанию файла processes.xml — это META-INF/processes.xml. Camunda 7 распарсит и обработает все файлы с именем processes.xml в classpath процессного приложения. Композитные процессные приложения (WAR / EAR) могут производить многочисленные поддеплойменты через предоставление файла META-INF/processes.xml.

В проекте, который базируется на Apache Maven, добавьте файл processes.xml в каталог src/main/resources/META-INF.

Кастомизированные местоположения для файла processes.xml

Если вы хотите задать кастомизированное местоположение для файла processes.xml, вам необходимо использовать свойсво deploymentDescriptors аннотации @ProcessApplication:

@ProcessApplication(
    name="my-app",
    deploymentDescriptors={"path/to/my/processes.xml"}
)
public class MyProcessApp extends ServletProcessApplication {

}

Предоставленные пути должны быть разрешаемы через метод загрузчика класса ClassLoader#getResourceAsStream(String), возвращаемый методом AbstractProcessApplication#getProcessApplicationClassloader() процессного приложения.

Поддерживаются несколько различных местоположений.

Конфигурирование движка управления процессами в файле processes.xml

Файл processes.xml может также использоваться для конфигурирования одного или нескольких движков управления процессами. Ниже приведен пример конфигурации движка управления проуессами внутри файла processes.xml:

<process-application
xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-engine name="my-engine">
    <configuration>io.openbpm.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration</configuration>
  </process-engine>

  <process-archive name="loan-approval">
    <process-engine>my-engine</process-engine>
    <properties>
      <property name="isDeleteUponUndeploy">false</property>
      <property name="isScanForProcessDefinitions">true</property>
    </properties>
  </process-archive>

</process-application>

Свойство <configuration>…</configuration> позволяет задавть имя класса конфигурации движка управления процессами для использования при сборке движка.

Задание tenant-id для архивов процессов в файле processes.xml

Для мультиарендности с идентификаторами арендаторов (Tenant-Id) вы можете задать tenant-id архива процесса через задание атрибута tenantId. Если tenant-id задан, то все относящиеся к нему ресурсы будут задеплоены для заданного tenant-id. Далее приведен пример файла processes.xml, который содержит один архив процесса с tenant-id:

<process-application
xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive name="loan-approval" tenantId="tenant1">
    <process-engine>default</process-engine>
    <properties>
      <property name="isDeleteUponUndeploy">false</property>
      <property name="isScanForProcessDefinitions">false</property>
    </properties>
  </process-archive>

</process-application>

Отметим, что файл processes.xml может содержать многочисленные архивы процессов с разными tenant-id.

Деплоймент процессного приложения

При деплойменте набора BPMN 2.0 файлов в движок управления процессами создается деплоймент процесса. Деплоймент процесса производится в базу данных движка, так что когда движок оснанавливается и запускается вновь, определения процесса могут быть соввтановлены из базы данных и их выполнение могло продолжиться. Когда процессное приложение выполняет деплоймент, в дополнение к деплойменту базы данных оно также создает регистрацию для этого деплоймента внутри движка управления процессами. Это иллюстрируется следующим графическим изображением:

Process Application Deployment

Деплоймент процессного приложения "invoice.war" иллюстрируется левой частью изображения:

Процессное приложение "invoice.war" деплоит файл invoice.bpmn в движок управления процессами.
Движок управления процессами проверяет базу данных на наличее предыдущего деплоймента. В нашем случае, такого деплоймента не существует. В результате создается новый деплоймент базы данных deployment-1 для определения процесса.
Процессное приложение регистрируется для deployment-1, а регистрация возвращается.

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

Регистрация позволяет движку управления процессами загружать дополнительные Java классы и ресурсы из процессного приложения при выполнении процессов. По контрасту с деплойментом базы данных, который может восстанавливаться при каждом перезапуске движка, регистрация процессного приложения хранится как in-memory состояние. Это in-memory состояние является локальным для индивидуального узла кластера, позволяя нам откатывать деплойменты и заново деплоить процессное приложение на конкретный узел кластера, не оказывая влияния на другие узлы и без необходимости перезапуска движка управления процессами.

Если Job Executor знает о деплойменте, выполнение джоб также остановится для сех джоб, созданных этим процессным приложением. Однако, в качестве прямого следствия этой остановки, регистрация тоже должна будет пересоздаваться при перезапуске сервера приложения. Это происходит автоматически, если процессное приложение принимает участие в жизненном цикле деплоймента сервера приложений. Например, ServletProcessApplications деплоятся как ServletContextListeners и, когда контекст сервлета стартует, он создает деплоймент и регистрацию в дуижке управления процессами. Процесс редеплоймента проиллюстрирован на следйющем изображении:

Process Application Redeployment

(a) Левая часть: invoice.bpmn не изменился:

Процессное приложение "invoice.war" деплоит файл invoice.bpmn в движок управления процессами.
Движок управления процессами проверяет базу данных на наличие предыдущего деплоймента. Поскольку deployment-1 все еще присутствует в базе данных, движок сравнивает XML-содержимое деплоймента в базе данных с файлом bpmn20.xml из процессного приложения. В нашем случае оба XML документа идентичны, что означает, что можно восстановить существующий деплоймент.
Регистрируется процессное приложение для существующего деплоймента deployment-1.

(b) Правая часть: invoice.bpmn изменился:

Процессное приложение "invoice.war" деплоит файл invoice.bpmn в движок управления процессами.
Движок управления процессами проверяет базу данных на наличие предыдущего деплоймента. Поскольку deployment-1 все еще присутствует в базе данных, движок сравнивает XML-содержимое деплоймента в базе данных с файлом invoice.bpmn из процессного приложения. В нашем случае обнаруживаются изменения, что означает, что необходимо создать новый деплоймент.
Движок управления процессами создает новый деплоймент deployment-2, содержащий обновленный процесс invoice.bpmn.
Процессное приложение регистрируется для нового деплоймента deployment-2 И существующего деплоймента deployment-1.

Возобновление предыдущего деплоймента (deployment-1) является функцией, называемой resumePreviousVersions и активируемой по умолчанию. Имеется две различные возможности для возобновления предыдущих деплойментов.

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

Вторая опция состоит в том, чтобы возобновлять деплойменты на основании их имени (точнее, на значении атрибута name в архиве процесса). Таким образом вы можете удалить процесс в новом деплойменте, но процессное приложение зарегистрирует само себя для предыдущих деплойментов и, следовательно, в том числе для удаленного процесса. Это делает возможным для все еще продолжающих выполнение экземпляров удаленного процесса продолжиться в этом процессном приложении.

Чтобы активировать это поведение, вы установили свойство isResumePreviousVersions в true, а свойство resumePreviousBy в deployment-name:

<process-application
  xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive name="loan-approval">
    ...
    <properties>
      ...
      <property name="isResumePreviousVersions">true</property>
      <property name="resumePreviousBy">deployment-name</property>
    </properties>
  </process-archive>

</process-application>

Если вы хотите деактивировать эту функцию, вам придется установить свойство в false в файле processes.xml:

<process-application
  xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <process-archive name="loan-approval">
    ...
    <properties>
      ...
      <property name="isResumePreviousVersions">false</property>
    </properties>
  </process-archive>

</process-application>

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

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

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