Настройка свойств процесса в Camunda Modeler

Первое, что нужно сделать после создания нового процесса (диаграммы BPMN) в Camunda Modeler — это настроить его свойства в панели свойств (Property Panel) — см. рис.

Сразу заметим, что на крупных предприятиях со зрелыми системами управления бизнес-процессами для разработчиков существует строгая инструкция относительно того, какие свойства обязательны для заполнения и какие значения следует им присваивать для единообразия и стандартизации. Например, при взгляде на имя бизнес-процесса должно быть понятно, к какому подразделению он относится и для чего предназначен. Часто такие инструкции называются «Naming Conventions» (Соглашения об именовании).

Далеко не все свойства процесса очевидны, поэтому рассмотрим их в этом разделе.

На вкладке General свойств процесса можно Id (Идентификатор), Name (Имя) и Version tag (Тэг версии) для процесса. С идентификаторами процесса все непросто, поэтому остановимся на них подробнее.

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

Первое свойство процесса, которое необходимо заполнить на вкладке General окна свойств процесса — это свойство Id (Идентификатор). Можно считать это имя техническим именем процесса, по которому к процессу будут обращаться приложения. Отметим следующие моменты:

• Id — это название данного свойства процесса в CamundaModeler (оно отображается в значение атрибута Id элемента process в генерируемом XML). Но как только этот процесс будет развернут на сервере, для данного атрибута сервер будет использовать другое наименование: Key (Ключ). И для запуска процесса по Id потребуется использовать методы с упоминанием ключа, например:

processEngine.getRuntimeService().startProcessInstanceByKey(«Invoice_Check»);

При вызове этого метода будет запущена последняя версия процесса Invoice_Check (для вызова произвольной версии придется использовать вспомогательный класс ProcessDefinition).

А вот id для развернутой на сервере версии будет генерироваться автоматически (как технический уникальный ключ базы данных). Он может выглядеть примерно так:

Invoice_Check:2:ca360213-618d-11e8-b470-0242ac11001b

А может и так:

69b50396-6256-11e8-9121-0242ac11001c

Все зависит от различных факторов, в том числе от длины вышеупомянутого ключа (то есть атрибута id в XML процесса, созданного в Camunda Modeler).

Такой уникальный идентификатор (который на сервере Camunda и называется id) тоже можно использовать для запуска процесса, но разработчики Camunda настоятельно рекомендуют использовать key.

Добавим еще, что Camunda генерирует уникальные идентификаторы не только для определений процесса, но и для его экземпляров (если процесс запускался 50 раз, то у каждого созданного экземпляра будет уникальный идентификатор, и это тоже id).

В общем, нужно запомнить, что Id процесса в Camunda Modeler становится ключом (key) для процесса при развертывании процесса на сервере Camunda, и именно этот ключ рекомендуется использовать для запуска процесса.

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

• Технически для значения Id используется тип данных QName из стандарта XML, и поэтому:
  • Идентификатор должен начинаться с буквы;
  • Далее могут идти другие буквы, цифры и символы подчеркивания;
  • Пробелы в Id не допускаются;
  • Настоятельно рекомендуется, чтобы количество символов в идентификаторе не превышало 32;
  • Лучше сразу установить правила использования прописных и строчных букв, чтобы потом не путаться. Например, заглавной может быть первая буква в каждом слове;
  • Использование русских букв настоятельно не рекомендуется во избежание проблем.
• С точки зрения правил BPMN настоятельно рекомендуется, чтобы в идентификаторе процесса использовалось значимое существительное (возможно, вместе с прилагательными и другими существительными) плюс глагол, который описывает главное действие этого процесса.

В большинстве известных автору организаций используется стандарт именования процесса вида

Credit_Card_Claim_Check

Такое наименование является значимым, легко читаемым и соответствующим как требованиям Camunda, так и рекомендациям стандарта BPMN.

Также разработчиками системы Camunda очень рекомендуется при сохранении диаграммы в файл сделать так, чтобы название файла совпадало с названием процесса (если диаграмма состоит из одного процесса). Например, в нашем случае сохраняемый файл диаграммы мог бы называться Credit_Card_Claim_Check.bpmn.

Следующее свойство процесса — это свойство Name (Имя). Оно может использоваться как описание процесса. Его вполне можно заполнить по-русски, в нем допускаются пробелы и различные служебные символы, и длина его практически не ограничена. Имя можно использовать, например, для того, чтобы найти экземпляры процесса с данным именем среди активных или архивных («исторических») экземпляров. На предприятии лучше изначально стандартизировать и зафиксировать в регламенте правила присвоения имен бизнес-процессам (аналогично идентификаторам). В XML это свойство прописывается в атрибут name элемента process.

Далее идет свойство Version Tag (Тэг версии). Это свойство — текстовое и заполняется в произвольной форме. Значения его могут выглядеть, например, как «1.1» или «1.5-patch2» — в соответствии с тем, как принято на предприятии. В XML для диаграммы это свойство прописывается в атрибут versionTag элемента process.

Отметим, что, как и в случае с идентификатором, версий для процессов в Camunda предусмотрено две:

1. versionTag — определяется разработчиком процесса вручную в CamundaModeler, могут использоваться значения в произвольной форме, записывается в атрибут versionTag генерируемого для процесса кода XML;
2. version — генерируется автоматически при развертывании процесса на сервере Camunda, прописывается в качестве атрибута процесса в таблице базы данных, является числовым значением, значение version увеличивается автоматически при повторном сохранении на сервер измененного файла проекта.

Для того, чтобы запустить процесс с нужной версией (или найти его) можно использовать любой из этих атрибутов: не путайте их! Обычно, конечно, разработчики стараются использовать атрибут versionTag, значение которого более предсказуемо.

Просмотреть информацию об имени процесса, его идентификаторе, версии и теге версии можно в Camunda Cockpit (см. рис.)

Далее на вкладке General свойств процесса Camunda идет свойство Executable (Исполняемый) (а вместе с ним логично будет рассмотреть и свойство Startable (Стартуемый), которое расположено ниже на этой же вкладке).

Свойство Executable отображается в атрибут isExecutable элемента process. Смысл его понятен: только процессы, для которых значение этого свойства установлено в true, можно запускать на выполнение. Значение true устанавливается практически для всех процессов. Исключением являются процессы, которые создаются для целей демонстрации каких-то концепций или моделей без намерения эти процессы запускать на выполнение. Для них для свойства isExecutable устанавливается значение false, но обычно такие процессы вообще нет смысла помещать на сервер Camunda, дополнительно загружая базу данных.

Свойство Startable отображается в атрибут isStartableInTasklist элемента process (этот атрибут появляется только в случае, если установить значение этого свойства в false, потому что по умолчанию любой процесс является стартуемым). Смысл этого свойства понятен из самого названия атрибута isStartableInTasklist: только если для него установлено true, пользователь сможет стартовать процесс через Web-приложение Camunda Tasklist. Есть смысл установить для этого свойства значение false и, таким образом, запретить пользователю запускать его через Tasklist, например, когда:

• данный процесс является подпроцессом и должен запускаться только родительским процессом;
• данный процесс должен запускаться автоматически, например, при появлении сообщения для Message Start Event (Стартовое событие-сообщение).

Следующие два свойства процесса, которые находятся в разделе External Task Configuration (Конфигурация внешней задачи) — это свойства Task Priority (Приоритет задачи) и Job Priority (Приоритет задания). В генерируемом XML они отображаются, соответственно, в атрибуты taskPriority и jobPriority для элемента process.

Параметр jobPriority определяет приоритет, который будет присвоен процессу, запускаемому в автоматическом режиме (например, при срабатывании стартового события-таймера). Параметр taskPriority определяет приоритет по умолчанию для внешних задач процесса (external tasks). Внешние задачи — это задачи, которые передаются для выполнения внешней программе/службе (а затем процесс BPMN получает результаты его выполнения). В качестве примера можно привести, например, преобразование формата файла, которое производится внешней службой.

Как для taskPriority, так и для jobPriority по умолчанию используется значение 0, что означает: самый низкий приоритет. Менять эти значения нужно только в том случае, если вы хотите поднять приоритет для какого-то процесса/его внешних задач. Вместо явно указанного значения можно использовать вычисляемое выражение.

Отметим, что определить приоритеты можно как декларативно (настроив нужные значения в Camunda Modeler), так и программно, через API для сервера Camunda. Программное изменение имеет приоритет перед декларативным. Например, можно сделать так, чтобы при запуске процесса руководителем он получал больший приоритет, чем процессы, которые запускают подчиненные.

Следующие свойства процесса в Camunda Modeler находятся на вкладке General в разделе Candidate Starter Configuration (Кандидаты для запуска процесса): свойство Candidate Starter Groups (Группы-кандидаты для запуска) и свойство Candidate Starter Users (Пользователи-кандидаты для запуска). В качестве значений для этих свойств можно указать (через запятую) группы или пользователей сервера Camunda соответственно (см. рис).

Рис. Настройка групп-кандидатов и пользователей-кандидатов для запуска процесса в Camunda Modeler

Только те пользователи, которые будут явно указаны в Candidate Starter Users (или те, которые входят в группы, указанные в Candidate Starter Groups) смогут запускать данный процесс.

Отображаются данные свойства в XML-атрибуты candidateStarterGroups и candidateStarterUsers соответственно. Точно так же, как в случае с другими свойствами процесса, те значения, которые указаны в XML, после развертывания процесса на сервере можно переопределить программно.

Следующее свойство процесса в Camunda — это свойство History Time To Live (Время жизни истории процесса).

При активной работе системы управления бизнес-процессами Camunda в базе данных быстро копится большой объем данных по завершенным («историческим») экземплярам процесса. Эти исторические данные приходится переносить в другое место/очищать. Процесс очистки истории (history cleanup) должен проводиться администраторами системы Camunda на регулярной основе, и именно в ходе этого процесса учитывается значение атрибута времени жизни истории процесса (атрибут historyTimeToLive в XML).

По умолчанию для этого атрибута используется пустое значение (NULL), что означает: завершенные экземпляры этого процесса не вычищать из базы данных, а хранить вечно. Если хранить вечно историю вам не нужно, то можно указать для этого атрибута значение в днях. Значение «0» означает: удалять экземпляры процесса сразу после их завершения.

Как обычно, поменять значение этого атрибута после развертывания процесса на сервере можно программно. Например, при помощи Java API:

processEngine.getRepositoryService().updateProcessDefinitionHistoryTimeToLive(processDefinitionId, 5);

или средствами REST API.

Последнее свойство для процесса на вкладке General в Camunda Modeler — это свойство Element Documentation (Документация элемента). Согласно стандарту BPMN 2.0, в любой элемент XML на диаграмме (элемент процесса, задачи и т.п.) можно поместить вложенный элемент documentation с «сопроводиловкой» для этого элемента. Например, для процесса это может быть описание, для задачи — инструкция по ее выполнению. Соответственно, значение свойства Element Documentation — это любой текст, который необходимо донести до пользователя.

Для задач и других вложенных элементов процесса документацию можно просмотреть из Camunda Cockpit (см. рис.)

К сожалению, документацию по самому процессу Cockpit не показывает, ее можно получить только программно, при помощи метода getDescription() в Java API или при помощи REST.

На вкладке Listeners (Прослушиватели) свойств процесса можно определить прослушиватели — специальные программные модули, которые будут запускаться в ответ на события запуска или завершения процесса (см. рис.)

Прослушиватели — один из встроенных в Camunda механизмов взаимодействия между процессами. Прослушиватель позволяет запустить внешний программный код одного из четырех типов:

1. JavaClass — класс Java, реализующий интерфейс camunda.bpm.engine.delegate.ExecutionListener
2. Expression (выражение) — выражение на языке JUEL (Java Unified Expression Language). В генерируемом коде XML такое выражение может выглядеть как

expression=»${myObject.callMethod(process, process.eventName)}»

3. Delegateexpression (выражение-делегат)— выражение, которое должно обращаться к объекту, реализующему интерфейс JavaDelegate или ActivityBehavior, например:

delegateExpression=»${myBean}»

В этом случае подразумевается, что в myBean реализован интерфейс JavaDelegate.

4. Script — возможность запустить на выполнение скрипт (inline, то код которого помещен внутрь самого XML-определения для процесса или Externalresource, то есть внешний скрипт).

Например, можно заполнить значения в окне свойств процесса так, как представлено на рис.

Рис. Пример встроенного скрипта на языке groovy для события запуска процесса

При запуске этого процесса в консольном окне Tomcat вы увидим наше сообщение (см. рис.).

С точки зрения формата поддерживаемых скриптов Camunda 7.12.0 «из коробки» поддерживает Groovy и JavaScript. Кроме того, заявлена поддержка JRuby и Jython, но для них необходимо подключить соответствующие JAR-пакеты.

Прослушиватели в Camunda существуют на трех уровнях:

1. На уровне всего ядра Camunda
2. На уровне конкретного процесса (мы сейчас в Camunda Modeler рассматривали прослушиватели именно на этом уровне)
3. На уровне отдельных элементов процесса, например, событий.

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

Последняя вкладка свойств процесса в Camunda Modeler — это вкладка Extensions (расширения) – см рис.

На этой вкладке можно определить любые дополнительные пары свойство/значения, которые будут записаны в XML-определение процесса и к которым можно будет обратиться программным способом. Например, в Java API значения этих свойств можно получить при помощи метода process.getExtensionElements(). Средствами REST API, к сожалению, напрямую к элементам расширения не обратиться.

Элементы расширения предусмотрены как для процессов Camunda, так и для вложенных элементов (например, задач) и позволяют хранить о них любую дополнительную информацию, которая вам нужна (например, уровень конфиденциальности, код отдела и т.п.) Добавлять новые свойства и их значения можно как декларативно, в Camunda Modeler, так и программно, через Java API. Чаще всего обращение к этим дополнительным свойствам производится в прослушивателях для передачи их значений внешним программным модулям.