Это многостраничный печатный вид этого раздела. Нажмите что бы печатать.

Вернуться к обычному просмотру страницы.

Камунда.РФ

1 - Функциональные характеристики ПО

Камунда.РФ 7/8

Исполнение процессов

  • Исполнение моделей BPMN и DMN с высокой производительностью.
  • Поддержка синхронных и асинхронных задач.
  • Интеграция с внешними системами через REST API, Java API, Kafka и др.
  • Поддержка внешних задач (External Tasks) — взаимодействие с микросервисами и внешними приложениями.
  • Механизмы транзакционности и отката (rollback) при сбоях.

Управление и администрирование

  • Возможность динамической миграции и версионирования процессов.
  • Поддержка кластеризации и масштабирования.

Интеграционные возможности

  • REST API и Java API для взаимодействия с внешними системами.
  • Поддержка Spring Boot и Kubernetes для облачного развёртывания.
  • Возможность работы с различными СУБД (PostgreSQL, MySQL, Oracle и др.).
  • Поддержка событийной архитектуры (Event-driven) через Kafka, RabbitMQ и др.

Технологические особенности

  • Основаны на Java (JVM).
  • Легковесный движки процессов, легко встраиваемый в приложения.
  • Возможность развёртывания как standalone-приложения или микросервиса.
  • Совместимость с BPMN-стандартами позволяет использовать модели из других BPM-систем.
  • Требуется знание BPMN и Java для эффективной настройки.

Камунда.РФ Пульт

  • Веб-приложение для администраторов и аналитиков.
  • Мониторинг выполнения процессов и решений в реальном времени.
  • Просмотр состояния экземпляров процессов, задач и событий.
  • Возможность запуска экземпляра процесса для выбранной схемы напрямую из интерфейса Камунда.РФ Пульт.
  • Поиск и устранение инцидентов (ошибок выполнения).
  • Возможность ручного вмешательства в процесс (retry, cancel).
  • Инструмент аналитики и отчетности.
  • Сбор и визуализация статистики выполнения процессов.
  • Дашборды с метриками производительности (время выполнения, узкие места и т. д.).
  • Мониторинг и трассировка выполнения процессов

1.1 - Обзорная архитектура

Платформа «Камунда.РФ» разрабатывается как комплексное решение для автоматизации и управления бизнес-процессами организации.

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

При реализации проекта и развитии его модулей мы преследуем следующие цели:

№ Цель Мотивация / Описание

1

Совместимость

Клиенты не должны тратить ресурсы на обновление кодовой базы, переписывание компонентов и прочие действия при переходе на "Камунда.РФ" с Camunda 7 или Camunda 8

2

Безопасность

Система должна поставляться с обновлёнными версиями зависимостей и исправленными уязвимостями, обнаруженными до даты релиза. Система должна проходить регулярные проверки информационной безопасности.

3

Надёжность

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

4

Поддерживаемость

Система должна предоставлять инструменты для контроля своего состояния и контроля входящих в неё компонентов

Обзорная архитектура

Решение разбито на несколько изолированных компонентов:

  • Камунда.РФ 7 – Движок BPMN-процессов на базе Camunda 7.24.X

    • Расширение "История" – Расширение для Камунда.РФ 7, позволяющее хранить исторические данные по бизнес-процессам во внешнем хранилище, без влияния на выполнение текущих процессов.

  • Камунда.РФ 8 – Движок BPMN-процессов на базе Camunda 8.5.X

    • Расширение "История" – Расширение (exporter) для Камунда.РФ 8, позволяющее хранить исторические данные по бизнес-процессам во внешнем хранилище, без влияния на выполнение текущих процессов.

  • Пульт – Модуль управления и отслеживания состояния выполняемых процессов

Компоненты могут быть развернуты и работать как по отдельности, так и в составе одного технического решения.

Камунда.РФ 7

Сервис выполнения бизнес-процессов в нотации BPMN 2.0, может выполняться как Standalone-решение, так и Embedded-решение.

Может выполняться в любом окружении, поддерживающем Java Virtual Machine версии 17+, для работы требуется наличие СУБД PostgreSQL версии 12+.

В стандартной поставке требуется только наличие СУБД. При подключении расширения История дополнительно требуется наличие подключения к Apache Kafka или совместимому решению для выгрузки исторических данных.

Камунда.РФ 8

Может выполняться в любом окружении, поддерживающем Java Virtual Machine версии 17+, для работы требуется наличие постоянного дискового хранилища для хранения оперативных данных по выполняемым процессам. В стандартной поставке не требует дополнительных компонентов. При подключении расширения История дополнительно требуется наличие подключения к Apache Kafka или совместимому решению для выгрузки исторических данных.

Камунда.РФ Пульт

Пульт состоит из двух элементов:

  1. SPA-приложения, содержащего пользовательский интерфейс

  2. Crawler — API для SPA-приложения и коллектора исторических данных.

Для хранения данных о выполняемых процессах пульту необходима СУБД ClickHouse версии не ниже 24.8. Для управления бизнес-процессами (повтор инцидентов, изменения значений переменных, перемещение процесса на предыдущий или следующий шаг) компоненту необходим доступ к серверам Платформы 7 / 8, с которыми он будет взаимодействовать.

Расширения "История" для Камунда.РФ 7/8

Используется для выгрузки исторических данных Камунда.РФ 7/8 или Camunda 7/8 в отдельное хранилище. Расширение подключается как плагин к решению. Для работы требуется наличие подключения к Apache Kafka.

Расширение "История" предназначено для решения проблем, связанных с накоплением больших объёмов исторических данных в Камунда.РФ 7, которые негативно влияют на производительность и увеличивают затраты на хранение. Решение реализовано в виде дополнительного расширения для Камунда.РФ 7 и внешнего сервиса, обеспечивающего обработку и хранение истории.

Расширение реализует вынос исторических данных из основной СУБД (PostgreSQL) во внешнее хранилище на базе ClickHouse с использованием Apache Kafka (или совместимого брокера, например RedPanda) в качестве промежуточного буфера.

history work
Figure 1. Схема взаимодействия

2 - Руководство по установке ПО

2.1 - Камунда.РФ 7

2.1.1 - Камунда.РФ 7 в Spring Boot приложении

Введение

В данной инструкции описан процесс создания нового пустого Spring Boot приложения, которое при запуске автоматически поднимает Камунда.РФ 7 (Spring Boot) с использованием embedded базы данных H2.

Камунда.РФ 7 подключается как зависимость, опубликованная в корпоративном Nexus-репозитории.

Инструкция ориентирована на локальный запуск разработчиком.

Предварительные требования

  • Java 17+

  • Maven 3.8+

  • Доступ к корпоративному Nexus:

    • Maven-репозиторию

Создание Spring Boot проекта

Создайте новый Spring Boot проект любым удобным способом (Spring Initializr, IDEA, вручную).

Минимальные параметры:

  • Project: Maven

  • Language: Java

  • Spring Boot: 3.x

  • Packaging: jar

Настройка доступа к Nexus (Maven)

Для загрузки зависимостей Камунда.РФ 7 из Nexus необходимо настроить аутентификацию Maven.

Откройте файл ~/.m2/settings.xml и добавьте:

<settings>
  <servers>
    <server>
      <id>kamundarf-nexus</id>
      <username>YOUR_USERNAME</username>
      <password>YOUR_PASSWORD</password>
    </server>
  </servers>
</settings>

Далее подключите репозиторий в pom.xml:

<repositories>
  <repository>
    <id>kamundarf-nexus</id>
     <url>https://nexus.boos.solutions/repository/kamundarf-mvn/</url>
  </repository>
</repositories>

Подключение Камунда.РФ 7

Добавьте зависимости Камунда.РФ 7 в pom.xml.

<dependencies>

    <!-- Содержит  ядро BPMN, ProcessEngine, сервисы (RuntimeService, TaskService и др.) -->
    <dependency>
        <groupId>rf.kamunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter</artifactId>
        <version>${kamundarf.version}</version>
    </dependency>

    <!-- REST API: RESTful эндпоинты для взаимодействия с движком через HTTP -->
    <dependency>
        <groupId>rf.kamunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
        <version>${kamundarf.version}</version>
    </dependency>

    <!-- Веб-интерфейсы - Cockpit (мониторинг), Tasklist (задачи), Admin (управление) -->
    <dependency>
        <groupId>rf.kamunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
        <version>${kamundarf.version}</version>
    </dependency>

    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <scope>runtime</scope>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jdbc</artifactId>
    </dependency>

</dependencies>

После этого нужно сконфигурировать Камунда.РФ 7 в файле application.yml и Камунда.РФ 7 будет автоматически сконфигурирована и поднята при старте приложения.

Минимальная конфигурация application.yml

Камунда.РФ 7 будет использовать embedded/in-memory H2 базу данных. Это удобно для локальной разработки и тестирования.

server:
  port: 8080
spring:
  datasource:
    url: jdbc:h2:mem:process-engine;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
    driver-class-name: org.h2.Driver
    username: sa
    password: sa
  h2:
    console:
      enabled: true
      path: /h2-console
camunda:
  bpm:
    history-level: full
    admin-user:
      id: demo
      password: demo
      firstName: Demo
    filter:
      create: All tasks
    database:
      schema-update: true

Запуск приложения

Локальный запуск:

mvn spring-boot:run

Или:

mvn clean package
java -jar target/camunda-demo.jar

В логах должно появиться сообщение об успешном запуске Process Engine.

После запуска:

  • Веб-интерфейс приложения будет доступен по адресу: http://localhost:8080/camunda

  • Логин: demo

  • Пароль: demo

Использование других баз данных

Камунда.РФ 7 поддерживает различные СУБД:

  • PostgreSQL

  • H2

  • MySQL / MariaDB

  • Oracle

  • MSSQL

  • DB2

Для смены базы данных необходимо:

  1. Подключить JDBC-драйвер в pom.xml

  2. Изменить spring.datasource.*

  3. Указать тип БД

Пример для PostgreSQL:

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/camunda
    username: camunda
    password: camunda
    driver-class-name: org.postgresql.Driver

camunda:
  bpm:
    database:
      type: postgres
      schema-update: true

Основные свойства Камунда.РФ 7 в application.yml

Ниже перечислены основные параметры конфигурации Камунда.РФ 7, которые чаще всего используются в Spring Boot приложениях.

Базовый префикс

Все свойства Камунда.РФ 7 настраиваются через префикс:

camunda:
  bpm:

Настройки базы данных

camunda:
  bpm:
    database:
      type: h2                # Тип БД: h2 | postgres | mysql | oracle | mssql
      schema-update: true     # true | false | create | drop-create
Свойство Описание

database.type

Тип используемой базы данных

database.schema-update

Управление схемой БД (true — автообновление)

Администратор Камунда.РФ 7

Создание технического пользователя при старте приложения.

camunda:
  bpm:
    admin-user:
      id: admin
      password: admin
      first-name: Admin
      last-name: User
      email: admin@example.com
Свойство Описание

admin-user.id

Логин администратора

admin-user.password

Пароль администратора

admin-user.first-name

Имя

admin-user.last-name

Фамилия

admin-user.email

Email (необязательно)

Web-приложение Камунда.РФ 7

camunda:
  bpm:
    webapp:
      application-path: /camunda
Свойство Описание

webapp.application-path

Контекст Камунда.РФ 7 Web App

История и аудит

camunda:
  bpm:
    history-level: full       # none | activity | audit | full
Свойство Описание

history-level

Уровень сохранения исторических данных

Job Executor (фоновые джобы)

camunda:
  bpm:
    job-execution:
      enabled: true
      core-pool-size: 3
      max-pool-size: 10
Свойство Описание

job-execution.enabled

Включение Job Executor

job-execution.core-pool-size

Базовое количество потоков

job-execution.max-pool-size

Максимальное количество потоков

Авторизация и безопасность

camunda:
  bpm:
    authorization:
      enabled: true
Свойство Описание

authorization.enabled

Включение авторизации Камунда.РФ 7

Метрики

camunda:
  bpm:
    metrics:
      enabled: true
      db-reporter-activate: true
Свойство Описание

metrics.enabled

Сбор метрик движка

db-reporter-activate

Сбор метрик в БД

Полный минимальный пример

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.5.8</version>
    </parent>

    <groupId>org.example</groupId>
    <artifactId>camunda-demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>camunda-demo</name>
    <description>camunda-demo</description>

    <properties>
        <java.version>21</java.version>
        <kamundarf.version>1.0.0-SNAPSHOT</kamundarf.version>
    </properties>

    <repositories>
      <repository>
        <id>company-nexus</id>
         <url>https://nexus.boos.solutions/repository/kamundarf-mvn/</url>
      </repository>
    </repositories>

    <dependencies>
        <dependency>
            <groupId>rf.kamunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
            <version>${kamundarf.version}</version>
        </dependency>
        <dependency>
            <groupId>rf.kamunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
            <version>${kamundarf.version}</version>
        </dependency>
        <dependency>
            <groupId>rf.kamunda.bpm.springboot</groupId>
            <artifactId>camunda-bpm-spring-boot-starter</artifactId>
            <version>${kamundarf.version}</version>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

application.yml

camunda:
  bpm:
    database:
      type: h2
      schema-update: true
    admin-user:
      id: admin
      password: admin
    history-level: full
    webapp:
      application-path: /camunda

Архив с примером приложения Скачать ZIP

Итог

В результате получаем:

  • Пустой Spring Boot проект

  • Камунда.РФ 7, поднимающуюся автоматически при старте

  • Embedded H2 для локальной разработки

  • Возможность легко переключиться на любую поддерживаемую БД

2.1.2 - Развёртывание Камунда.РФ 7 в Kubernetes с Helm

Требования к внешним сервисам и инфраструктуре

В этом разделе перечислено всё, что должно быть предварительно настроено в вашем окружении перед началом установки Камунда.РФ 7.

Инфраструктура

  • Доступы, адреса, учетные записи (предоставляются после приобретения Камунда.РФ)

    • Docker Registry, в котором лежит образ Камунда.РФ 7

    • Helm Registry, где лежит helm chart для Камунда.РФ 7

  • Kubernetes 1.23+

  • Helm 3.x

  • Доступ к кластеру Kubernetes (или кластер minikube)

  • Postgresql 15+

Программное обеспечение для установки

Для выполнения инструкций по установке должны быть установлены следующие утилиты:

Note
 Если у вас возникли сложности с установкой idn под вашу операционную систему, замените $(idn камнуда.рф) на xn–80aalwlg5b.xn–p1ai во всех командах

Компоненты

В этом разделе описываются основные компоненты приложения, которые будут развернуты в Kubernetes.

Компонент

Тип

Камунда.РФ 7

Deployment

Репозиторий и подготовка

На этом этапе подготовим окружение Kubernetes для установки Камунда.РФ 7: добавим репозиторий, настроим базу данных и создадим необходимые секреты.

Переменные окружения

Подготовьте переменные среды окружения:

export REPO_NAME="kamundarf"
export HELM_REGISTRY="oci://$(idn камунда.рф)"
export REGISTRY_USERNAME="ваш-логин"
export REGISTRY_PASSWORD="ваш-пароль"

Установите kubectl для работы с пространством имен, в котором будет производиться работа.

kubectl config set-context --current --namespace=kamundarf7 (1)

  1. Если пространство не создано в кластере, создайте его командой:

    kubectl create namespace kamundarf7

Авторизация в Helm-registry

В этом разделе проверяем подключение к реестру с Helm-чартами.

helm registry login $HELM_REGISTRY --username $REGISTRY_USERNAME --password $REGISTRY_PASSWORD

Параметры команды:

  • $REPO_NAME - название репозитория в вашей системе

  • $HELM_REGISTRY — адрес реестра с Helm-чартом Камунда.РФ 7

  • $REGISTRY_USERNAME — имя пользователя для авторизации в реестре Helm-чартов

  • $REGISTRY_PASSWORD — пароль или токен для авторизации в реестре Helm-чартов

Настройка базы данных ( postgresql )

Если у вас нет развернутой БД в кластере Кубернетес, вы можете быстро развернуть ее, используя следующую команду:

export DB_USER=kamundarf7
helm install db oci://registry-1.docker.io/bitnamicharts/postgresql --set auth.database=$DB_USER --set auth.username=$DB_USER
export DB_PASSWORD=$(kubectl get secret db-postgresql -o jsonpath="{.data.password}" | base64 -d)

Если у вас уже есть БД, то подключитесь к ней и создайте отдельного пользователя и базу данных для Камунда.РФ 7.

Создайте секрет для подключения к БД

kubectl create secret generic database-secret \
  --from-literal=user=$DB_USER \
  --from-literal=password=$DB_PASSWORD

Где

  • $DB_USER - имя пользователя для подключения к базе данных

  • $DB_PASSWORD - пароль от пользователя для подключения к базе данных

Создание секрета доступа к Docker Registry Камунда.РФ

Чтобы Kubernetes мог скачать образ Камунда.РФ 7 из приватного реестра (docker registry), необходимо создать секрет с данными для аутентификации.

kubectl create secret docker-registry krf-registry-secret \
  --docker-server=$(idn камунда.рф) \
  --docker-username=$REGISTRY_USERNAME \
  --docker-password=$REGISTRY_PASSWORD \
  --docker-email=devops@yourdomain.com

Где

  • $REGISTRY_USERNAME - имя пользователя для доступа к реестру Камунда.РФ

  • $REGISTRY_PASSWORD - пароль от пользователя для доступа к реестру Камунда.РФ

Подготовка values.yaml

Создайте файл kamundarf7.yaml с описанием параметров установки Камунда.РФ 7.

replicaCount: 1

image:
  tag: 1.0.0-SNAPSHOT # Версия, которую необходимо установить

imagePullSecrets:
  - name: krf-registry-secret

db:
  secretName: "database-secret"
env:
  DB_DRIVER: org.postgresql.Driver
  DB_URL: jdbc:postgresql://db-postgresql:5432/kamundarf7 # Если у Вас была развернута БД или параметры подключения отличаются, измените их тут
  JAVA_OPTS: "-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"

Установка чарта

Используем Helm для установки Камунда.РФ 7 в наш кластер Kubernetes, используя подготовленный файл values.yaml.

helm upgrade --install kamundarf7 oci://$HELM_REGISTRY/kamundarf/helmstore/kamundarf7  --values kamundarf7.yaml

Подключение модуля истории

Модуль истории позволяет сохранять историю процессов в Kafka-совместимый брокер сообщений. Существует два сценария подключения:

Сценарий 1: Встроенный брокер сообщений

В этом сценарии брокер сообщений разворачивается вместе с Камунда.РФ 7 в кластере Kubernetes.

Для включения встроенной Kafka внесите следующие изменения в файл kamundarf7.yaml созданный на предыдущем шаге:

replicaCount: 1

image:
  tag: 1.0.0-SNAPSHOT # Версия, которую необходимо установить

imagePullSecrets:
  - name: krf-registry-secret

db:
  secretName: "database-secret"
env:
  DB_DRIVER: org.postgresql.Driver
  DB_URL: jdbc:postgresql://db-postgresql:5432/kamundarf7 # Если у Вас была развернута БД или параметры подключения отличаются, измените их тут
  JAVA_OPTS: "-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"

kafka:
  enabled: true
  replicaCount: 1

plugins:
  history:
    enabled: true
    useEmbedded: true
    topic: process-events
    rawTopic: process-events-raw

После внесения изменений выполните команду:

helm upgrade --install kamundarf7 oci://$HELM_REGISTRY/kamundarf/helmstore/kamundarf7  --values kamundarf7.yaml

Сценарий 2: Внешнний брокер сообщений

В этом сценарии используется существующий брокер сообщений развернутый в кластере Kubernetes.

Для подключения внешнего брокера внесите следующие изменения в файл kamundarf7.yaml:

replicaCount: 1

image:
  tag: 1.0.0-SNAPSHOT # Версия, которую необходимо установить

imagePullSecrets:
  - name: krf-registry-secret

db:
  secretName: "database-secret"
env:
  DB_DRIVER: org.postgresql.Driver
  DB_URL: jdbc:postgresql://db-postgresql:5432/kamundarf7 # Если у Вас была развернута БД или параметры подключения отличаются, измените их тут
  JAVA_OPTS: "-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"

kafka:
  enabled: false

plugins:
  history:
    enabled: true
    useEmbedded: false
    bootStrapServers:
      - "external-kafka:9092"
    topic: process-events

После внесения изменений выполните команду:

helm upgrade --install kamundarf7 oci://$HELM_REGISTRY/kamundarf/helmstore/kamundarf7  --values kamundarf7.yaml

Ознакомьтесь с документацией по настройке модуля Истории.

Доступ к приложению

После установки необходимо проверить, что приложение запустилось корректно, и настроить к нему доступ извне кластера.

После установки проверьте сервис:

kubectl get pods

Пример вывода (требуется, чтобы в ready было 1/1)

NAME                                      READY   STATUS    RESTARTS   AGE
kamundarf7-78546d488d-7fr6s              1/1     Running   0          7m48s

Камунда.РФ 7 будет доступна на порту 8080 внутри кластера. Для внешнего доступа можно включить ingress.

kamundarf7.yaml
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: kamundarf-7.example.com
      paths:
        - path: /
          pathType: Prefix

Либо можно прокинуть порт

kubectl port-forward  svc/kamundarf7 8080:8080

После этой команды можно будет зайти на http://localhost:8080

Настройки Камунда.РФ 7

В этом разделе подробно описаны ключевые настройки, которые позволяют гибко настроить поведение Камунда.РФ 7. Настройки можно задавать как через переменные окружения, так и через файл values.yaml.

Переменная Назначение

CATALINA_HOME

Указывает путь к корневому каталогу Apache Tomcat внутри контейнера. В данном случае: server/apache-tomcat-10.1.42/.

DB_DRIVER

Класс JDBC-драйвера базы данных. Например: org.postgresql.Driver или com.mysql.cj.jdbc.Driver.

DB_URL

JDBC-URL подключения к БД. Пример: jdbc:postgresql://db-host:5432/kamundarf7.

DB_CONN_MAXACTIVE

Максимальное количество активных соединений в пуле. Оптимальное значение зависит от размера БД и нагрузки. По умолчанию — 20.

DB_CONN_MINIDLE

Минимальное количество "ленивых" соединений — те, что доступны но неактивны. Снижает overhead на создание новых соединений.

DB_CONN_MAXIDLE

Максимальное количество неиспользуемых соединений, которые могут оставаться в пуле. Балансирует скорость против потребления ресурсов.

DB_VALIDATE_ON_BORROW

Если true, соединение будет валидироваться при взятии из пула (например, через SELECT 1).

DB_VALIDATION_QUERY

Запрос для проверки активности соединения. Обычно SELECT 1 — универсальный для любой БД.

SKIP_DB_CONFIG

Если не пусто, пропускает конфигурацию БД во время старта.

WAIT_FOR

Список зависимостей (например, адреса БД, Kafka и т.д.), которые Камунда.РФ 7 должна дождаться перед стартом. Указывается через запятые.

WAIT_FOR_TIMEOUT

Максимальное время (в секундах) ожидания всех зависимостей из WAIT_FOR. После превышения таймера контейнер завершится с ошибкой.

TZ

Часовой пояс внутри контейнера. UTC — стандарт для продакшн, чтобы избежать рассинхронизации логов.

DEBUG

Включение отладочного режима. При true будут активированы расширенные логи.

JAVA_OPTS

Аргументы JVM. Например: -Xms512m -Xmx1024m -XX:+UseG1GC. Позволяет тонко настроить GC, heap, профилирование и безопасность.

Настройка через values.yaml

Кроме переменных окружения, настройки можно задавать через файл values.yaml. Ниже приведены основные параметры, которые можно настроить:

Параметр Назначение

replicaCount

Количество реплик приложения. По умолчанию: 1.

image.repository

Репозиторий образа Камунда.РФ 7. По умолчанию: камунда.рф/kamundarf/kamundarf-tomcat.

image.tag

Тег образа Камунда.РФ 7. По умолчанию: 1.0.0.

image.pullPolicy

Политика загрузки образа. По умолчанию: IfNotPresent.

serviceAccount.create

Создавать ли ServiceAccount. По умолчанию: false.

service.type

Тип сервиса. По умолчанию: ClusterIP.

service.port

Порт сервиса. По умолчанию: 8080.

ingress.enabled

Включить ли Ingress. По умолчанию: false.

db.secretName

Имя секрета с данными для подключения к БД. По умолчанию: database-secret.

db.driver

Драйвер БД. По умолчанию: org.postgresql.Driver.

db.url

URL подключения к БД. По умолчанию: jdbc:postgresql://{{ .Release.Name }}-postgresql:5432/kamundarf7.

plugins.history.enabled

Включен ли модуль истории. По умолчанию: false.

plugins.history.topic

Топик Kafka для модуля истории. По умолчанию: data.

postgresql.enabled

Включить ли встроенную PostgreSQL. По умолчанию: false.

kafka.enabled

Включить ли встроенную Kafka. По умолчанию: false.

Параметры плагина истории

Параметр Назначение

plugins.history.image

Образ плагина истории. По умолчанию: камунда.рф/kamundarf/other/ginger-ext-c7-history:1.0.2.

plugins.history.enabled

Включен ли модуль истории. По умолчанию: false.

plugins.history.mode

Режим работы плагина. По умолчанию: ALL.

plugins.history.source

Источник данных. По умолчанию: пусто.

plugins.history.sourceAddress

Адрес источника данных. По умолчанию: пусто.

plugins.history.bootStrapServers

Список серверов Kafka. По умолчанию: пустой список.

plugins.history.topic

Топик Kafka для модуля истории. По умолчанию: data.

plugins.history.rawTopic

Топик Kafka для сырых данных. По умолчанию: raw-data.

plugins.history.contentType

Тип контента. По умолчанию: JSON.

plugins.history.keySerializer

Сериализатор ключей. По умолчанию: org.apache.kafka.common.serialization.StringSerializer.

plugins.history.acks

Уровень подтверждения сообщений. По умолчанию: all.

plugins.history.retries

Количество попыток повторной отправки. По умолчанию: 3.

plugins.history.lingerMs

Время задержки перед отправкой сообщений. По умолчанию: 1.

plugins.history.libs

Путь к библиотекам. По умолчанию: /libs.

plugins.history.useEmbedded

Использовать ли встроенную Kafka. По умолчанию: false.

2.2 - Камунда.РФ 8

2.2.1 - Камунда.РФ 8 с использованием Docker Compose

Введение

В данной инструкции описан запуск Камунда.РФ 8 в локальном окружении с использованием Docker Compose.

Предварительные требования

  • Доступы, адреса, учетные записи (предоставляются после приобретения Камунда.РФ)

    • Docker Registry, в котором лежит образ Камунда.РФ 8

  • Docker 24+

  • Docker Compose v2

Аутентификация в Docker Registry

Образ Zeebe хранится в приватном Docker Registry, поэтому перед запуском необходимо выполнить аутентификацию.

docker login harbor.boos.solutions

Введите логин и пароль пользователя, имеющего доступ к репозиторию kamundarf/kamundarf8 (предоставляются после приобретения Камунда.РФ).

Docker Compose конфигурация

Для запуска используется следующий docker-compose.yml:

name: KamundaRF

networks:
  net:
    driver: bridge

services:
  kamundarf8:
    image: harbor.boos.solutions/kamundarf/kamundarf8:1.0.0
    container_name: kamundaRF
    environment:
      ZEEBE_BROKER_NETWORK_HOST: 0.0.0.0
      ZEEBE_BROKER_GATEWAY_CLUSTER_HOST: 0.0.0.0
      ZEEBE_BROKER_GATEWAY_ENABLE: "true"
      ZEEBE_RESTORE: "false"
      ROCKSDB_MUSL_LIBC: "false"
    ports:
      - 26500:26500
      - 9600:9600
    extra_hosts:
      host.testcontainers.internal: host-gateway
    networks:
      - net

Запуск приложения

Локальный запуск:

docker compose up -d

Чтобы посмотреть логи Zeebe используйте:

docker compose logs -f zeebe

Итог

В результате разворачивается локальное окружение с Камунда.РФ 8.

2.2.2 - Установка Камунда.РФ 8 в Kubernetes с Helm

Требования к внешним сервисам и инфраструктуре

В этом разделе перечислено всё, что должно быть предварительно настроено в вашем окружении перед началом установки.

Инфраструктура

  • Доступы, адреса, учетные записи (предоставляются после приобретения Камунда.РФ)

    • Docker Registry, в котором лежит образ Камунда.РФ 8

    • Helm Registry, где лежит helm chart для Камунда.РФ 8

  • Kubernetes 1.24+

  • Helm 3.x

  • Kafka >= 3.3.1

  • Доступ к кластеру и namespace

Программное обеспечение для установки

Для выполнения инструкций по установке на вашем клиентском компьютере должны быть установлены следующие утилиты.

Note
 Если у вас возникли сложности с установкой idn под вашу операционную систему, замените $(idn камнуда.рф) на xn–80aalwlg5b.xn–p1ai во всех командах.

Репозиторий и подготовка

На этом этапе подготовим окружение Kubernetes для установки Камунда.РФ 8.

Настройте kubectl для работы с пространством имен, в котором будет производиться работа.

kubectl config set-context --current --namespace=kamundarf8 # (1)

  1. Если пространство не создано в кластере, создайте его командой:

    kubectl create namespace kamundarf8

Переменные окружения

Подготовьте переменные среды:

export REPO_NAME="kamundarf"
export HELM_REGISTRY="oci://$(idn камунда.рф)"
export REGISTRY_USERNAME="ваш-логин"
export REGISTRY_PASSWORD="ваш-пароль"

Авторизация в Helm-registry

В этом разделе проверяем подключение к реестру с Helm-чартами.

helm registry login $HELM_REGISTRY --username $REGISTRY_USERNAME --password $REGISTRY_PASSWORD

Создание секрета доступа к Docker Registry Камунда.РФ

Чтобы Kubernetes мог скачать образ Камунда.РФ 8 из приватного реестра (docker registry), необходимо создать секрет с данными для аутентификации.

kubectl create secret docker-registry krf-registry-secret \
  --docker-server=$(idn камунда.рф) \
  --docker-username=$REGISTRY_USERNAME \
  --docker-password=$REGISTRY_PASSWORD \
  --docker-email=devops@yourdomain.com

Где

  • $REGISTRY_USERNAME - имя пользователя для доступа к реестру Камунда.РФ

  • $REGISTRY_PASSWORD - пароль пользователя для доступа к реестру Камунда.РФ

Установка Helm-чарта Камунда.РФ 8

Подготовка параметров развертывания

Необходимо настроить основные параметры развертывания в файле kamundarf8.yaml. Если файл отсутствует, создайте его.

kamundarf8.yaml
global:
  image:
    tag: 1.0.0-SNAPSHOT
    pullSecrets:
      - name: krf-registry-secret    # Созданный секрет для скачивания образов
  elasticsearch: # Отключаем ElasticSearch
    enabled: false

elasticsearch:
  enabled: false


zeebe:
  enabled: true                         # Включает деплой всех ресурсов Zeebe
  debug: false                          # Режим отладки

  # Настройка кластера Zeebe
  clusterSize: "1"                      # Кол-во реплик брокера (узлов)
  partitionCount: "2"                   # Кол-во партиций в кластере
  replicationFactor: "1"               # Фактор репликации каждой партиции

  # Количество ресурсов для zeebe broker
  resources:
    requests:
      cpu: 500m
      memory: 1200Mi
    limits:
      cpu: 660m
      memory: 1920Mi
  # Хранение данных
  persistenceType: disk                 # Используется хранилище на диске
  pvcSize: "10Gi"                       # Размер PVC на каждого брокера
  pvcAccessModes: ["ReadWriteOnce"]     # Режим доступа к PVC
  pvcStorageClassName: ''
Table 1. Описание параметров конфигурации
Параметр Описание Значение по умолчанию

global.image.tag

Версия образа Камунда.РФ

1.0.0-SNAPSHOT

global.image.pullSecrets

Секрет для доступа к приватному реестру

krf-registry-secret

global.elasticsearch.enabled

Включение/выключение Elasticsearch

false

zeebe.enabled

Включение/выключение Zeebe

true

zeebe.clusterSize

Количество реплик брокера

1

zeebe.partitionCount

Количество партиций

2

zeebe.replicationFactor

Фактор репликации

1

Развертывание

Используем Helm для установки Камунда.РФ 8 в наш кластер Kubernetes, используя подготовленный файл kamundarf8.yaml.

helm upgrade --install kamundarf-8 oci://$HELM_REGISTRY/kamundarf/helmstore/kamundarf8 --values kamundarf8.yaml

Проверка установки

После установки проверьте статус компонентов:

kubectl get pods
kubectl get svc

Пример вывода (требуется, чтобы в столбце READY было 1/1):

NAME                                        READY   STATUS    RESTARTS   AGE
kamundarf-8-zeebe-0                         1/1     Running   0          2m19s
kamundarf-8-zeebe-gateway-856cb4767-88lr9   1/1     Running   0          4m41s

2.2.3 - Камунда.РФ 8 с Kafka Exporter

Назначение Kafka Exporter

Kafka Exporter используется для публикации событий из Камунда.РФ 8 в Kafka (или Kafka-compatible брокерах, например Redpanda).

Экспортер позволяет:

  • получать события жизненного цикла процессов

  • обрабатывать события job’ов

  • сохранять историю процессов во внешних системах

  • строить аналитику и мониторинг

Предварительные требования

  • Запущенная Камунда.РФ 8

  • Kafka или Kafka-compatible брокер (например Redpanda)

  • Docker / Docker Compose

  • JAR-файл Kafka Exporter (его можно скачать из закрытого nexus-репозитория)

Структура каталогов

Рекомендуемая структура проекта:

.
├── docker-compose.yml
├── agent/
│   └── zeebe-kafka-exporter.jar
└── config/
    └── broker.yaml

Каталог agent/ используется для хранения расширений Zeebe

Подключение Exporter к контейнеру Zeebe

Kafka Exporter должен быть смонтирован внутрь контейнера Zeebe.

Пример конфигурации в docker-compose.yml:

zeebe:
  image: <zeebe-image>
  volumes:
    - ./agent/zeebe-kafka-exporter.jar:/tmp/zeebe-kafka-exporter.jar

В результате JAR-файл будет доступен в контейнере по пути:

/tmp/zeebe-kafka-exporter.jar

Конфигурация broker.yaml

Экспортер подключается через конфигурацию Zeebe Broker.

Пример минимальной настройки Kafka Exporter:

zeebe:
  broker:
    exporters:
      kafka:
        className: rf.kamunda.exporters.kafka.KafkaExporter
        jarPath: /tmp/zeebe-kafka-exporter.jar
        args:
          producer:
            servers: "redpanda:9092"
            config: |
              clusterName: "clusterName"

Описание параметров

Параметр Описание

className

Полное имя класса экспортера

jarPath

Путь к JAR-файлу внутри контейнера

args.bootstrapServers

Адрес Kafka брокера

args.config.clusterName

Название вашего кластера

Проверка загрузки Exporter

После запуска Zeebe в логах должно появиться сообщение о загрузке экспортера.

Проверка логов:

docker compose logs -f zeebe

Ожидаемые признаки:

  • отсутствие ошибок загрузки JAR

  • сообщение об инициализации Kafka Exporter

  • успешное подключение к Kafka

Конфигурация экспортера

zeebe:
  broker:
    exporters:
      kafka:
        className: rf.kamunda.exporters.kafka.KafkaExporter
        # Указывает расположение JAR-файла экспортера
        jarPath: /path/to/zeebe-kafka-exporter.jar
        args:
          # Управляет количеством записей, буферизуемых в одном пакете,
          # перед принудительной отправкой (flush).
          # Значение по умолчанию — 100
          maxBatchSize: 100

          # Максимальное время блокировки (в миллисекундах), если пакет заполнен.
          # Если пакет заполнен и приходит новая запись, экспортёр будет ждать,
          # пока не освободится место в пакете, либо пока не истечёт
          maxBlockingTimeoutMs: 1000

          # Как часто ожидающие пакеты должны отправляться (flush)
          # в Kafka-брокер.
          flushIntervalMs: 1000

          # Конфигурация, специфичная для Kafka-продюсера
          producer:
            # Список адресов подключения к Kafka-брокерам.
            # Формат должен соответствовать: "host:port"
            servers: "redpanda:9092"

            # Определяет, сколько времени продюсер будет ждать подтверждения
            # от Kafka-брокера перед повторной попыткой отправки запроса
            requestTimeoutMs: 5000

            # Период корректного завершения работы продюсера
            # при остановке (в миллисекундах)
            closeTimeoutMs: 5000

            # Идентификатор Kafka-продюсера
            clientId: zeebe

            # Любые параметры в этом разделе будут переданы напрямую
            # в ProducerConfig. Это можно использовать для настройки
            # аутентификации, сжатия и т.п.
            config: |
               linger.ms=5
              buffer.memory=8388608
              batch.size=32768
              max.block.ms=5000
              clusterName: "myCluster"
        records:
          # Если тип значения записи не указан в конфигурационном файле,
          # будет использовано значение, заданное в defaults
          defaults: { type: "event", topic: zeebe }

          # Для записей со значением типа DEPLOYMENT
          deployment: { topic: zeebe-deployment }

          # Для записей со значением типа DEPLOYMENT_DISTRIBUTION
          deploymentDistribution: { topic: zeebe-deployment-distribution }

          # Для записей со значением типа ERROR
          error: { topic: zeebe-error }

          # Для записей со значением типа INCIDENT
          incident: { topic: zeebe-incident }

          # Для записей со значением типа JOB_BATCH
          jobBatch: { topic: zeebe-job-batch }

          # Для записей со значением типа JOB
          job: { topic: zeebe-job }

          # Для записей со значением типа MESSAGE
          message: { topic: zeebe-message }

          # Для записей со значением типа MESSAGE_SUBSCRIPTION
          messageSubscription: { topic: zeebe-message-subscription }

          # Для записей со значением типа MESSAGE_START_EVENT_SUBSCRIPTION
          messageStartEventSubscription: { topic: zeebe-message-subscription-start-event }

          # Для записей со значением типа PROCESS
          process: { topic: zeebe-process }

          # Для записей со значением типа PROCESS_EVENT
          processEvent: { topic: zeebe-process-event }

          # Для записей со значением типа PROCESS_INSTANCE
          processInstance: { topic: zeebe-process-instance }

          # Для записей со значением типа PROCESS_INSTANCE_RESULT
          processInstanceResult: { topic: zeebe-process-instance-result }

          # Для записей со значением типа PROCESS_MESSAGE_SUBSCRIPTION
          processMessageSubscription: { topic: zeebe-process-message-subscription }

          # Для записей со значением типа TIMER
          timer: { topic: zeebe-timer }

          # Для записей со значением типа VARIABLE
          variable: { topic: zeebe-variable }

Пример docker-compose файла

Важно иметь следующую структуру каталогов:

.
├── docker-compose.yml
├── agent/
│   └── zeebe-kafka-exporter.jar
└── config/
    └── broker.yaml

docker-compose.yml

name: KamundaRF
networks:
  net:
    driver: bridge
volumes:
  redpanda: null

services:
  redpanda:
    command:
      - redpanda
      - start
      - --kafka-addr internal://0.0.0.0:9092,external://0.0.0.0:19092
      - --advertise-kafka-addr internal://redpanda:9092,external://localhost:19092
      - --pandaproxy-addr internal://0.0.0.0:8082,external://0.0.0.0:18082
      - --advertise-pandaproxy-addr internal://redpanda:8082,external://localhost:18082
      - --schema-registry-addr internal://0.0.0.0:8081,external://0.0.0.0:18081
      - --rpc-addr redpanda:33145
      - --advertise-rpc-addr redpanda:33145
      - --mode dev-container
      - --smp 1
      - --default-log-level=info
    image: docker.redpanda.com/redpandadata/redpanda:v25.1.9
    container_name: redpanda
    volumes:
      - redpanda:/var/lib/redpanda/data
    networks:
      - net
    ports:
      - 18081:18081
      - 18082:18082
      - 19092:19092
      - 19644:9644
  console:
    container_name: redpanda-console
    image: docker.redpanda.com/redpandadata/console:v3.1.3
    networks:
      - net
    entrypoint: /bin/sh
    command: -c 'echo "$$CONSOLE_CONFIG_FILE" > /tmp/config.yml; /app/console'
    environment:
      CONFIG_FILEPATH: /tmp/config.yml
      CONSOLE_CONFIG_FILE: |
        kafka:
          brokers: ["redpanda:9092"]
        schemaRegistry:
          enabled: true
          urls: ["http://redpanda:8081"]
        redpanda:
          adminApi:
            enabled: true
            urls: ["http://redpanda:9644"]
    ports:
      - 8080:8080
    depends_on:
      - redpanda
  zeebe:
    image: harbor.boos.solutions/kamundarf/kamundarf8:1.0.0-SNAPSHOT
    depends_on:
      - redpanda
    volumes:
      - ./agent/zeebe-kafka-exporter.jar:/tmp/zeebe-kafka-exporter.jar
      - ./config/broker.yaml:/usr/local/zeebe/config/application.yaml
    environment:
      - ZEEBE_BROKER_NETWORK_HOST=0.0.0.0
      - ZEEBE_BROKER_GATEWAY_CLUSTER_HOST=0.0.0.0
      - ZEEBE_BROKER_GATEWAY_ENABLE=true
      - ZEEBE_RESTORE=false
      - ROCKSDB_MUSL_LIBC=false
    extra_hosts:
      host.testcontainers.internal: host-gateway
    ports:
      - 26500:26500
      - 9600:9600
    networks:
      - net
  simple-monitor:
    image: ghcr.io/camunda-community-hub/zeebe-simple-monitor:2.6.0
    container_name: zeebe-simple-monitor
    depends_on:
      - zeebe
      - redpanda
    networks:
      - net
    environment:
      SPRING_PROFILES_ACTIVE: kafka

      ZEEBE_CLIENT_BROKER_GATEWAYADDRESS: zeebe:26500
      ZEEBE_CLIENT_SECURITY_PLAINTEXT: "true"

      SPRING_KAFKA_BOOTSTRAP_SERVERS: redpanda:9092
    ports:
      - 8082:8082

broker.yml

zeebe:
  broker:
    exporters:
      kafka:
        className: rf.kamunda.exporters.kafka.KafkaExporter
        jarPath: /tmp/zeebe-kafka-exporter.jar
        args:
          producer:
            servers: "redpanda:9092"
            config: |
              linger.ms=5
              buffer.memory=8388608
              batch.size=32768
              max.block.ms=5000
              clusterName: "cluster"

Локальный запуск:

docker compose up

В результате вы получите:

Сервис Адрес

Zeebe Gateway

localhost:26500

Redpanda Console

http://localhost:8080

Zeebe Simple Monitor

http://localhost:8082

Здесь используется Kafka-compatible брокер - Redpanda. Отправленные сообщения можно посмотреть в Redpanda Console. Отслеживать и запускать процессы можно через Zeebe Simple Monitor.

Итог

Kafka Exporter является ключевым механизмом интеграции Камунда.РФ 8 с внешними системами хранения.

Ниже прикреплен пример в котором содержится:

  • docker-compose файл

  • Конфигурация для брокера

  • Инструкция по скачиванию экспортера

  • spring-boot приложение которое инициализирует несколько воркеров для исполнения задач и деплоит простой процесс в Камунда.РФ 8, которым можно управлять через Web-интерфейс (localhost:8082)

Скачать ZIP

2.3 - Камунда.РФ Пульт

2.3.1 - Развёртывание Камунда.РФ Пульт в Kubernetes с Helm

Требования к внешним сервисам и инфраструктуре

В этом разделе перечислено всё, что должно быть предварительно настроено в вашем окружении перед началом установки Камунда.РФ Пульт.

Инфраструктура

  • Доступы, адреса, учетные записи (предоставляются после приобретения Камунда.РФ)

    • Docker Registry, в котором лежит образ Камунда.РФ 7

    • Helm Registry, где лежит helm chart для Камунда.РФ 7

  • Kubernetes 1.23+

  • Helm 3.x

  • Доступ к кластеру Kubernetes

Программное обеспечение для установки

Для выполнения инструкций по установке на вашем клиентском компьютере должны быть установлены следующие утилиты.

Note
 Если у вас возникли сложности с установкой idn под вашу операционную систему, замените $(idn камнуда.рф) на xn–80aalwlg5b.xn–p1ai во всех командах.

Репозиторий и подготовка

На этом этапе мы подготовим окружение Kubernetes для установки Камунда.РФ Пульт: добавим репозиторий, создадим необходимые секреты и настроим конфигурацию.

Переменные окружения

Подготовьте переменные среды:

export REPO_NAME="kamundarf"
export HELM_REGISTRY="oci://$(idn камунда.рф)"
export REGISTRY_USERNAME="ваш-логин"
export REGISTRY_PASSWORD="ваш-пароль"

Авторизация в Helm-registry

В этом разделе проверяем подключение к реестру с Helm-чартами.

helm registry login $HELM_REGISTRY --username $REGISTRY_USERNAME --password $REGISTRY_PASSWORD

Создание секрета доступа к Docker Registry Камунда.РФ

Чтобы Kubernetes мог скачать образ Камунда.РФ 8 из приватного реестра (docker registry), необходимо создать секрет с данными для аутентификации.

kubectl create secret docker-registry krf-registry-secret \
  --docker-server=$(idn камунда.рф) \
  --docker-username=$REGISTRY_USERNAME \
  --docker-password=$REGISTRY_PASSWORD \
  --docker-email=devops@yourdomain.com

Где

  • $REGISTRY_USERNAME - имя пользователя для доступа к реестру Камунда.РФ

  • $REGISTRY_PASSWORD - пароль пользователя для доступа к реестру Камунда.РФ

Подготовка pult.yaml

Создаем файл pult.yaml, в котором переопределяем стандартные настройки Helm-чарта под наши нужды: указываем наш образ, настраиваем доступ к API и настраиваем ingress для внешнего доступа.

Минимально требуется переопределить следующие переменные:

Tip
 > Надо создать файл pult.yaml

В конфигурации по умолчанию Helm-чарт производит установку следующих компонентов:

  1. СУБД PostgreSQL – для управления данными

  2. СУБД ClickHouse – как хранилище исторических данных

  3. Брокер Apache Kafka  – для обмена сообщениями между компонентами системы

  4. Crawler – Бэк-энд компонент Камунда.РФ Пульт

  5. Pult – Фронт-энд компонент Камунда.РФ Пульт

  6. Keycloak – OAuth2-сервер для авторизации пользователей

  7. КамундаРФ 7 – как движок бизнес процессов

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

  1. Crawler – Бэк-энд компонент Камунда.РФ Пульт

  2. Pult – Фронт-энд компонент Камунда.РФ Пульт

  3. ClickHouse – как хранилище исторических данных

Подготовим файл конфигурации для установки Камунда.РФ Пульт в наш кластер Kubernetes.

pult.yaml
keycloak:
  domain: pult.test

ginger-api-crawler:
  domain: pult.test

camunda-pult:
  domain: pult.test

kamundarf7:
  domain: pult.test

Установка чарта

После подготовки файла окружения развернем наше решение.

helm upgrade --install pult oci://$(idn камунда.рф)/kamundarf/helmstore/pult-all-in-one --values pult.yaml

Как добавить новый сервер

Внесите изменения в файл pult.yaml

pult.yaml
ginger-api-crawler:
  domain: xpult.test
  crawler:
    servers:
      # Идентификатор сервера
      new-server:
        # Тип сервера Cam7 - Сервер KamundaRF7 Cam8 - Сервер KamundaRF8
        type: Cam7
        name: "Новый сервер" # Название сервера для отображения в интерфейсе
        servers: # Полный путь к RestApi сервера
          - "http://some-external-service/camunda/engine-rest"
        topic: ext-service # Имя топика для обмена сообщениями
        auth: # Способ авторизации сервера
          type: none

Настройки

Конфигурация базы данных

Настройки подключения к базам данных PostgreSQL и ClickHouse.

Переменная Описание По умолчанию

postgres-operator.enabled

Включение оператора PostgreSQL

true

db_cluster.storageClass

Класс хранения для кластера БД

standard

db_cluster.databases.keycloak.user

Имя пользователя для базы данных Keycloak

keycloak

db_cluster.databases.kamundarf7.user

Имя пользователя для базы данных KamundaRF7

kamundarf7

keycloak.externalDatabase.host

Хост внешней базы данных для Keycloak

db

keycloak.externalDatabase.database

Имя базы данных для Keycloak

keycloak

Конфигурация Keycloak

Настройки аутентификации и авторизации через Keycloak.

Переменная Описание По умолчанию

keycloak.enabled

Включение Keycloak

true

keycloak.httpRelativePath

Относительный путь для доступа к Keycloak

/auth/

keycloak.ingress.enabled

Включение Ingress для Keycloak

true

keycloak.ingress.hostname

Доменное имя для доступа к Keycloak

{{ .Values.domain }}

keycloak.image.repository

Репозиторий образа Keycloak

kamundarf/other/keycloak

keycloak.image.tag

Тег образа Keycloak

0.0.2

keycloak.keycloakConfigCli.enabled

Включение CLI конфигурации Keycloak

true

keycloak.keycloakConfigCli.configuration.master.yaml.realm

Название realm в Keycloak

master

keycloak.keycloakConfigCli.configuration.master.yaml.loginTheme

Тема интерфейса Keycloak

pult

keycloak.keycloakConfigCli.configuration.master.yaml.users[0].username

Имя пользователя по умолчанию

testuser

keycloak.keycloakConfigCli.configuration.master.yaml.users[0].credentials[0].value

Пароль пользователя по умолчанию

password

keycloak.keycloakConfigCli.configuration.master.yaml.clients[0].clientId

ID клиента для crawler

crawler

keycloak.keycloakConfigCli.configuration.master.yaml.clients[0].secret

Секрет клиента для crawler

test

Конфигурация Kafka

Настройки брокера сообщений Apache Kafka.

Переменная Описание По умолчанию

kafka.enabled

Включение Kafka

true

kafka.replicaCount

Количество реплик Kafka

1

kafka.controller.replicaCount

Количество контроллеров Kafka

1

kafka.listeners.client.protocol

Протокол для клиентского listener

PLAINTEXT

kafka.listeners.client.containerPort

Порт для клиентского listener

9092

kafka.service.ports.client

Порт сервиса Kafka

9092

kafka.persistence.enabled

Включение персистентности для Kafka

true

kafka.persistence.size

Размер хранилища для Kafka

8Gi

Конфигурация ClickHouse

Настройки хранилища исторических данных ClickHouse.

Переменная Описание По умолчанию

clickhouse.enabled

Включение ClickHouse

true

clickhouse.auth.username

Имя пользователя ClickHouse

test

clickhouse.auth.password

Пароль пользователя ClickHouse

test

clickhouse.shards

Количество шардов ClickHouse

1

clickhouse.replicaCount

Количество реплик ClickHouse

1

clickhouse.image.repository

Репозиторий образа ClickHouse

bitnamilegacy/clickhouse

clickhouse.image.tag

Тег образа ClickHouse

25.7.5

Конфигурация ginger-api-crawler

Настройки бэкэнд компонента Камунда.РФ Пульт.

Переменная Описание По умолчанию

ginger-api-crawler.enabled

Включение ginger-api-crawler

true

ginger-api-crawler.image.repository

Репозиторий образа crawler

kamundarf/other/crawler

ginger-api-crawler.image.tag

Тег образа crawler

0.0.1-SNAPSHOT

ginger-api-crawler.ingresHost

Доменное имя для crawler

{{ .Values.domain }}

ginger-api-crawler.camunda.bpm.adminUser.id

ID администратора Camunda

demo

ginger-api-crawler.camunda.bpm.adminUser.password

Пароль администратора Camunda

demo

ginger-api-crawler.spring.datasource.url

URL подключения к ClickHouse

jdbc:clickhouse://{{ .Release.Name }}-clickhouse:8123/default

ginger-api-crawler.spring.kafka.consumer.bootstrapServers

Адрес брокера Kafka для потребителя

{{ .Release.Name }}-kafka:9092

ginger-api-crawler.spring.kafka.producer.bootstrapServers

Адрес брокера Kafka для производителя

{{ .Release.Name }}-kafka:9092

ginger-api-crawler.crawler.camunda7GroupId

Группа для Camunda 7

kam7

ginger-api-crawler.crawler.camunda8GroupId

Группа для Camunda 8

kam8

ginger-api-crawler.crawler.writeQueue.topic

Топик очереди записи

write-queue

Конфигурация camunda-pult

Настройки фронтэнд компонента Камунда.РФ Пульт.

Переменная Описание По умолчанию

camunda-pult.enabled

Включение camunda-pult

true

camunda-pult.image.repository

Репозиторий образа pult

xn–80aalwlg5b.xn–p1ai/kamundarf/pult

camunda-pult.image.tag

Тег образа pult

10478db6

camunda-pult.ingress.enabled

Включение Ingress для pult

true

camunda-pult.ingress.className

Класс Ingress controller’а

nginx

camunda-pult.ingress.hosts[0].host

Доменное имя для pult

{{ .Values.domain }}

camunda-pult.ingress.hosts[0].paths[0].path

Путь для доступа к pult

/

camunda-pult.ingress.hosts[0].paths[0].pathType

Тип обработки пути

ImplementationSpecific

Конфигурация kamundarf7

Настройки движка бизнес процессов Камунда.РФ 7.

Переменная Описание По умолчанию

kamundarf7.enabled

Включение kamundarf7

true

kamundarf7.image.tag

Тег образа kamundarf7

1.0.0-SNAPSHOT

kamundarf7.plugins.history.enabled

Включение плагина истории

true

kamundarf7.plugins.history.topic

Топик для истории

kamundarf7-raw

kamundarf7.plugins.history.rawTopic

Топик для сырых данных истории

kamundarf7-raw

kamundarf7.plugins.history.bootStrapServers[0]

Адрес брокера Kafka

paio-kafka:9092

kamundarf7.db.secretName

Имя секрета с данными БД

kamundarf7.db.credentials.postgresql.acid.zalan.do

kamundarf7.db.secretUsernameKey

Ключ имени пользователя в секрете

username

kamundarf7.db.secretPasswordKey

Ключ пароля в секрете

password

kamundarf7.ingress.enabled

Включение Ingress для kamundarf7

true

kamundarf7.ingress.hosts[0].host

Доменное имя для kamundarf7

{{ .Values.domain }}

kamundarf7.ingress.hosts[0].paths[0].path

Путь для доступа к kamundarf7

/camunda

kamundarf7.ingress.hosts[0].paths[0].pathType

Тип обработки пути

ImplementationSpecific

3 - Руководство по эксплуатации ПО

3.1 - Камунда.РФ Пульт

Инструкция по работе с «Камунда.РФ Пульт»

Начало работы

Вход в систему

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

Вход в систему

После успешной авторизации пользователь автоматически попадает в раздел «Дашборд».

Обзор интерфейса

Интерфейс платформы представляет собой интуитивно понятную и удобную среду для управления бизнес-процессами. Спроектирован и разработан для эффективной навигации и быстрого доступа ко всем ключевым функциям системы.

Структура интерфейса

Интерфейс системы представлен на рисунке ниже, состоит из:

  • бокового меню навигации (1);

  • верхней панели управления (2);

  • рабочей области (3).

Структура интерфейса
1. Боковое меню навигации

Для перехода между разделами используется боковое меню навигации, состоящее из следующих разделов:

  • Дашборд – сводная информация об экземплярах процессов.

  • Схемы – управление схемами бизнес-процессов.

  • Экземпляры – мониторинг и управление экземплярами процессов.

  • Инциденты – мониторинг и управление ошибками и сбоями.

  • Показатели – графики потребления ресурсов и производительности.

Для раздела «Инциденты» в боковом меню отображается количественное значение всех активных экземпляров процесса в статусе «Инцидент» для всех серверов, к которым подключен Камунда.РФ Пульт.

Детальное описание функциональности каждого раздела представлено в соответствующих главах текущего документа.

Внизу панели бокового меню отображается информация о пользователе, включающая в себя его аватар и email. При клике отображается меню с кнопкой «Выйти» из системы.

Выход из системы
2. Верхняя панель управления

В верхней панели управления расположены кнопки:

  • «Скрыть/Показать» (1) для скрытия/разворачивания бокового меню;

  • «Смена темы» (2) для персонализации внешнего вида интерфейса.

Верхняя панель управления

Смена темы позволяет настроить цветовую схему интерфейса (светлая/темная) в соответствии с предпочтениями пользователя.

  • Светлая тема

Светлая тема

  • Тёмная тема

Темная тема
3. Рабочая область

Основное пространство для работы с выбранным разделом. Адаптируется под конкретный функционал раздела.

Раздел «Дашборд»

Раздел «Дашборд» представляет собой агрегированную информацию об экземплярах схем в системе с возможностью выбора сервера, на котором они развернуты, и временного периода. Обеспечивает быстрое получение сводной информации о состоянии системы и выполняющихся процессах для оперативного анализа и принятия решений.

Описание интерфейса

Интерфейс раздела «Дашборд» представлен на рисунке ниже.

Интерфейс дашборда
Интерфейс дашборда

Дашборд состоит из набора интерактивных блоков и элементов управления.

1. Система фильтрации и управления

Обеспечивает динамическое обновление данных во всех блоках дашборда на основе заданных фильтров.

Использование фильтра «Все серверы» позволяет переключаться между различными серверами системы для просмотра соответствующих данных. Включает в себя поиск сервера по полному или частичному наименованию с возможностью множественного выбора. По умолчанию фильтр не заполнен, отображается статистика по экземплярам процессов всех серверов, имеющихся в системе.

Фильтр «Период» позволяет задать временные рамки и ограничить выборку существующих экземпляров. Доступны предустановленные диапазоны: «День», «Неделя», «Месяц». По умолчанию фильтр заполнен значением «День», отображается статистика по экземплярам за текущий день.

2. Блок статистики по активности экземпляров

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

Блок статистики по активности экземпляров

В верхней части справа расположены три информационных блока, которые отображают агрегированные показатели по всем экземплярам за выбранный период времени:

  • «Запущено {число}» – общее количество запущенных экземпляров, дата старта которых попадает в выбранный период;

  • «Завершено {число}» – общее количество завершенных и отмененных экземпляров, дата завершения и отмены которых попадает в выбранный период;

  • «С инцидентами {число}» – общее количество экземпляров, в которых возникали инциденты в выбранный период времени.

Ниже отображается столбчатая диаграмма, отображающая запущенные, завершенные и экземпляры с инцидентом в разрезе дня (для периодов «Неделя», «Месяц») или часа (для периода «День»). Синим цветом выделены запущенные экземпляры, фиолетовым – завершенные, красным – экземпляры с инцидентом.

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

По клику на сегмент «Запущено»/«Завершено»/«С инцидентами» выполняется переход к списку экземпляров выбранной группы в разделе «Экземпляры процессов».

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

Блок статистики меню

3. Блок «Запущенные экземпляры»

Отображает топ-10 схем процессов с наибольшим количеством запущенных экземпляров. Все остальные схемы относятся к категории «Другие процессы» с указанием их общего количества.

Блок запущенные экземпляры

Данные обновляются автоматически при изменении сервера и/или временного периода на дашборде.

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

По клику на секцию выполняется переход к списку экземпляров выбранного процесса в разделе «Экземпляры процессов». Для сегмента «Другие процессы» отображается полный список всех запущенных экземпляров, не вошедших в топ-10.

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

4. Блок «Инциденты»

Предназначен для мониторинга и анализа инцидентов в разбивке по их типам, позволяя быстро определять наиболее частые источники проблем в системе. Дает наглядное представление о распределении инцидентов для приоритизации работ по их исправлению.

Блок инциденты

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

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

По клику на секцию выполняется переход к списку всех инцидентов выбранного типа в разделе «Инциденты». Для сегмента «Другие процессы» отображается полный список всех инцидентов, типы которых не вошли в топ-10.

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

5. Блок «Пользовательские задачи»

Отображает топ-10 пользовательских задач, запущенных в системе в заданный период времени. Все остальные (не вошедшие в топ-10) запущенные пользовательские задачи группируются в сегмент «Другие задачи» с указанием их общего количества.

Блок пользовательские задачи

Выбор временного периода определяет дату запуска задачи. Данные обновляются автоматически при изменении сервера и/или периода на дашборде.

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

По клику на секцию выполняется переход в раздел «Экземпляры процессов» к списку экземпляров, в которых была запущена выбранная пользовательская задача. Для сегмента «Другие задачи» отображается список всех запущенных экземпляров с пользовательскими задачами, типы которых не вошли в топ-10.

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

6. Блок «Самые долгие процессы»

Отображает топ-10 схем с наибольшим временем выполнения их экземпляров для указанного сервера за выбранный период.

Блок самые долгие процессы

Блок представлен в виде таблицы с двумя колонками:

  • «Процесс» – наименование или код схемы процесса с указанием версии.

  • «Время» – длительность выполнения схемы от старта до завершения или от старта до текущего момента, если экземпляр процесса еще активен.

По клику на наименование процесса осуществляется переход в карточку экземпляра выбранного процесса.

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

7. Блок «Процессы с инцидентами»

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

Блок процессы с инцидентами

Блок представлен в виде таблицы с двумя колонками:

  • «Процесс» – наименование или код схемы процесса с указанием версии.

  • «Статус» – статус экземпляра схемы процесса.

По клику на наименование схемы осуществляется переход в карточку экземпляра выбранного процесса.

По клику на кнопку «Все инциденты» отображается полный список инцидентов, дата возникновения которых попадает в указанный период, в разделе «Инциденты».

8. Блок «Часто запускаемые»

Отображает топ-10 часто запускаемых схем процессов для указанного сервера за выбранный период для анализа нагрузки на бизнес-процессы.

Блок часто запускаемые процессы

Блок представлен в виде таблицы с двумя колонками:

  • «Процесс» – наименование или код схемы процесса.

  • «Запусков» – количество запущенных экземпляров схемы за выбранный на дашборде период.

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

Раздел «Схемы»

Раздел предназначен для просмотра и мониторинга BPMN-схем бизнес-процессов, загруженных в систему, в режиме реального времени. Позволяет пользователю просматривать список всех схем, их версии, статусы запущенных экземпляров по данным схемам и основные показатели их выполнения. Здесь можно контролировать состояние бизнес-процессов, анализировать активные и завершённые экземпляры, а также выявлять процессы с инцидентами.

Схемы

Интерфейс раздела «Схемы» представлен на рисунке ниже и содержит:

  1. Блок с общей информацией о добавленных схемах (1).

  2. Систему фильтрации (2).

  3. Таблицу схем процессов (3).

Схемы процессов

1. Общая информация о добавленных схемах

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

  • Блок «Всего схем» – общее количество добавленных BPMN-схем.

  • Блок «Активных схем» – текущее количество схем, в которых есть запущенные экземпляры в статусе «Активный» или «Инцидент».

  • Блок «Инцидентов» – текущее количество экземпляров по всем схемам в статусе «Инцидент».

  • Блок «Экземпляров запущено» – текущее количество экземпляров по всем схемам в статусе «Активный» или «Инцидент».

Данные в блоках динамически обновляются при применении фильтров к списку схем процессов.

2. Система фильтрации

Доступны следующие фильтры для детализации данных:

  • Поисковое поле – осуществляет поиск по названию, коду схемы (полное или частичное совпадение).

  • «Серверы» – выпадающий список с возможностью множественного выбора и поиска по наименованию сервера окружения, на котором развернута схема.

  • «Дата создания, от» – осуществляет поиск по дате и времени загрузки схемы в систему. Устанавливается от какого числа и времени ведется поиск.

  • «Дата создания, до» – осуществляет поиск по дате и времени загрузки схемы в систему. Устанавливается до какого числа и времени ведется поиск.

  • Чек-бокс «Только последние версии» – при активированном состоянии в таблице отображаются только актуальные (последние) версии схем процессов. Если чек-бокс не активен, в таблице отображаются схемы всех доступных версий. По умолчанию параметр установлен в активное положение.

При наличии установленных фильтров появляется кнопка сброса фильтрации - Кнопка очистки.

3. Таблица схем процессов

Таблица с детализированным списком BPMN-схем бизнес-процессов, отсортированным по дате добавления (от новых к старым).

Столбцы таблицы:

  • Схема – отображается наименование схемы процесса и/или код схемы. Данные в столбце являются гиперссылками для перехода на страницу «Карточка схемы».

  • Версия – версия схемы, загруженной в систему.

  • Сервер – наименование сервера окружения, на котором развернута схема.

  • Дата создания – дата и время добавления схемы процесса в систему.

  • Активные – текущее количество экземпляров схемы в статусе «Активный».

  • Завершенные – текущее количество экземпляров схемы в статусе «Завершён».

  • Инциденты – текущее количество экземпляров схемы в статусе «Инцидент».

  • Доступно действие «Скачать BPMN» – выполняет экспорт схемы с расширением .bpmn. Файл можно открыть в Camunda Modeler, Operate Modeler или любом BPMN-редакторе.

Также имеется возможность настройки отображения столбцов по кнопке «Настроить колонки» (иконка гаечного ключа): показать/скрыть или изменить порядок отображения колонок в таблице. Колонки «Схема», «Версия», «Дата создания» являются основными по умолчанию без возможности скрыть их.

Карточка схемы

Карточка схемы

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

Интерфейс страницы «Карточка схемы» представлен на рисунке ниже и содержит:

  1. Блок с общей информацией о схеме процесса.

  2. Схему процесса.

  3. Систему фильтрации.

  4. Таблицу экземпляров схемы и список инцидентов.

Карточка схемы

1. Общая информация о схеме процесса

Верхняя часть раздела содержит сводную информацию о схеме процесса:

  • Схема – отображается наименование (при наличии) схемы процесса или ее код с указанием версии.

  • Код схемы - код схемы процесса.

  • Сервер – наименование сервера окружения, на котором развернута схема.

  • Идентификатор – уникальный идентификатор схемы процесса.

  • Блок статистики – предназначен для анализа состояния бизнес-процесса на основе данных по экземплярам, запущенным по данной схеме. Содержит следующие данные:

    • иконка «Активные» – количество экземпляров схемы процесса в статусе «Активный».

    • иконка «Завершённые» – количество экземпляров схемы процесса в статусе «Завершён».

    • иконка «Инциденты» – количество экземпляров схемы процесса в статусе «Инцидент».

    • «В среднем» – среднее время прохождения схемы процесса.

    • «Мин. время» – минимальное время прохождения схемы процесса.

    • «Макс. время» – максимальное время прохождения схемы процесса.

При клике на иконку с количеством активных/инцидентов/завершенных экземпляров происходит фильтрация списка запущенных экземпляров просматриваемой схемы по соответствующему статусу в таблице «Экземпляры». Повторный клик по иконке снимает установленную фильтрацию.

2. Схема процесса

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

Блок содержит следующие элементы:

  • «Поиск элементов» – поле для быстрого поиска узлов схемы по названию (полное или частичное совпадение).

  • Режим «Показатели» – отображает числовые значения активных, завершённых задач и задач с инцидентом по каждому элементу схемы.

  • Режим «Теплокарта» – инструмент визуальной аналитики, который позволяет выявить узкие места и особенности выполнения экземпляров схемы процесса на основе реальных данных.

  • Индикатор активных – показывает количество экземпляров, которые сейчас находятся на узле схемы и имеют статус «Активный».

  • Индикатор отмененных – показывает количество отмененных экземпляров на узле схемы.

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

  • Кнопки управления схемой – кнопки для скачивания схемы и для изменения масштаба схемы (увеличение, уменьшение, сброс масштаба и центрирование схемы, разворачивание схемы на полный экран). Имеется возможность осуществить экспорт схемы процесса в двух форматах: BPMN и PNG. BPMN-файл можно открыть в Camunda Modeler, Operate Modeler или любом BPMN-редакторе.

Область видимости схемы можно расширять/сужать, потянув за нижний край, для более удобного анализа.

3. Система фильтрации

Под интерактивной BPMN-схемой расположена таблица экземпляров схемы процесса.

Для удобного и быстрого поиска экземпляров процесса можно использовать систему фильтров, представленную в виде:

  • общего поля поиска по ID и бизнес-ключу экземпляра;

  • списка статусов экземпляров;

  • ключу элемента схемы процесса;

  • поиска по дате запуска экземпляра (от и до).

При клике на конкретный узел на схеме процесса список экземпляров также фильтруется, отображаются экземпляры схемы процесса, которые имеют токен в статусе "Активный"/"Инцидент"/"Отменён" на выбранном узле. Повторный клик на узел сбрасывает примененную фильтрацию. В превью информации об узле можно увидеть:

  • наименование узла схемы процесса;

  • тип узла;

  • время выполнения;

  • наименование ключа элемента;

  • количество активных и экземпляров в инциденте конкретно на выбранном узле с возможностью перехода к соответствующему списку в разделе "Экземпляры".

Карточка схемы

4. Таблица экземпляров процесса

Таблица содержит детализированный список экземпляров, запущенных по выбранной BPMN-схеме бизнес-процесса, отсортированных по дате запуска (от новых к старым).

Столбцы таблицы «Экземпляры»:

  • ID – уникальный идентификатор экземпляра схемы процесса в системе. Данные в столбце являются гиперссылками для перехода на страницу «Карточка экземпляра»;

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

  • Состояние – состояние экземпляра схемы процесса (Активный, Инцидент, Завершён, Отменён);

  • Дата запуска – дата и время запуска экземпляра в системе;

  • Дата завершения – дата завершения экземпляра в системе. Если экземпляр схемы процесса не находится в статусе «Завершён»/«Отменён», то дата завершения не отображается;

  • Перечень доступных действий над экземплярами схемы - для каждого экземпляра доступно действие «Открыть трассировку» для просмотра детального трейсинга для каждого экземпляра (функциональность подробно описана в инструкции к Grafana Tempo). В зависимости от статуса экземпляра можно производить оперативные действия над ним:

    • если открыта корневая схема процесса и статус экземпляра «Активный» или «Инцидент», доступно действие «Отменить» (полное прекращение выполнения узла, действие необратимо);

    • если статус экземпляра «Инцидент», доступно действие «Повторить» (выполняет повторный запуск узла, находящегося в инциденте).

Также имеется возможность настройки отображения столбцов по кнопке «Настроить колонки» (иконка гаечного ключа): показать/скрыть или изменить порядок отображения колонок в таблице. Колонки «ID», «Бизнес-ключ», «Состояние» являются основными по умолчанию без возможности скрыть их.

Карточка схемы

5. Запуск нового экземпляра процесса

Над системой фильтрации таблицы «Экземпляры» расположена кнопка «Запустить», позволяющая стартовать новый экземпляр процесса просматриваемой схемы напрямую из системы Камунда РФ. Пульт.

По клику на кнопку «Запустить» отображается модальное окно «Запуск процесса» с полем для вставки JSON-объекта и кнопками «Отформатировать», «Минифицировать» и «Запустить».

Запуск процесса

Функция форматирования JSON позволяет привести введённый текст к структурированному и читаемому виду, если он является валидным JSON.

Функция минификации позволяет скомпоновать валидный JSON в одну строку, удалив лишние символы без изменения самого кода.

Указав валидный JSON-объект и нажав кнопку «Запустить», создается новый экземпляр процесса для выбранный схемы.

6. Сравнение версий схем процесса

Над системой фильтрации таблицы «Экземпляры» расположена кнопка «Сравнение версий», позволяющая проводить сравнительный анализ одной и той же схемы процесса разных версий.

По клику на кнопку «Сравнение версий» открывается модальное окно, содержащее:

  1. слева → выбор предыдущей версии рассматриваемой схемы (Версия А) и ее схема процесса (по умолчанию выбрана предыдущая версия схемы процесса - {текущая версия} - 1);

  2. справа → выбор текущей версии рассматриваемой схемы (Версия Б) и ее схема (по умолчанию выбрана схема процесса, из которой перешли в модальное окно сравнения схем процесса - {текущая версия});

  3. под схемами → таблица списка изменений («Добавлено», «Удалено», «Изменено», «Перемещено»).

Запуск процесса

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

Для изменений типа «Изменено» дополнительно отображается всплывающее окно с информацией о правках, внесенных в схему процесса.

Доступна выгрузка списка всех изменений в формате JSON по кнопке «Экспорт в JSON», а также в текстовом формате по кнопке «Экспорт в текст».

Тепловая карта

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

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

Теплокарта

1. Режим «Теплокарта»

Для активации режима теплокарты необходимо открыть карточку нужной BPMN-схемы и в блоке с визуализацией схемы переключить режим с «Показатели» на «Теплокарта».

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

Интенсивность цвета визуально отражает нагрузку или время выполнения каждого узла процесса.

Цветовая шкала

  • Зеленый цвет - низкие значения (узлы с минимальным временем выполнения или наименьшей частотой прохождения);

  • Желтый цвет - средние значения (узлы с умеренной нагрузкой или временем выполнения);

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

Статистика теплокарты напрямую зависит от экземпляров, отображенных в нижней таблице «Экземпляры» выбранной BPMN-схемы.

2. Настройка теплокарты

Теплокарта включает в себя два режима настройки отображения для ограничения выборки экземпляров процесса:

  1. По типу задач:

    1. все (пользовательские и автоматические задачи);

    2. пользовательские;

    3. автоматические задачи.

  2. По метрике:

    1. время;

    2. частота.

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

Выбор режимов отображения зависит от задачи или проблемы, которую необходимо решить. Например:

  • «Автозадачи» + «Время» - определить узкие места в выполнении сервисных задач, приоритизировать сервисы для оптимизации;

  • «Все задачи» + «Частота» - определить, какие маршруты наиболее востребованы бизнесом или оценить общую нагрузку на все узлы процесса;

  • «Пользовательские задачи» + «Время»/«Частота» - выявить потребность в автоматизации определенных ручных операций или распределить нагрузку между сотрудниками.

Раздел «Экземпляры процессов»

Экземпляр процесса — это конкретный запуск бизнес-процесса. Например, если есть процесс "Оформление кредита", значит каждый новый кредит будет создавать отдельный экземпляр этого процесса.

Экземпляры

Интерфейс страницы «Экземпляры процессов» представлен на рисунке ниже.

Интерфейс экземпляров

1. Таблица экземпляров

Страница "Экземпляры процессов" содержит таблицу всех экземпляров с их основными параметрами. Каждая строка таблицы содержит данные о конкретном экземпляре процесса, параметры которого указаны в соответствующих столбцах:

  • Экземпляр — уникальный идентификатор экземпляра;

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

  • Схема — название и код схемы, для которой запущен экземпляр;

  • Версия — версия схемы;

  • Сервер – сервер, на котором развернута схема процесса;

  • Статус — текущий статус экземпляра:

    • Активный — выполняется;

    • Инцидент — есть ошибка;

    • Завершён — успешно завершен;

    • Отменен.

  • Запущен — дата и время запуска экземпляра;

  • Длительность – время выполнения экземпляра;

  • Последняя активность - отображает период бездействия над экземпляром;

  • Завершён – дата и время окончания выполнения экземпляра;

  • Родительский экземпляр – уникальный идентификатор родительского экземпляра (при наличии).

Все колонки таблицы с экземплярами процессов поддерживают сортировку при нажатии на имя колонки.

Значения в колонках «Экземпляр» и «Родительский экземпляр» являются гиперссылками и при нажатии переводят пользователя на страницу с деталями выбранного экземпляра. Значения в колонке «Схема» также являются гиперссылками и при нажатии переводят пользователя на страницу выбранной схемы.

Также имеется возможность настройки отображения столбцов по кнопке «Настроить колонки» (иконка гаечного ключа): показать/скрыть или изменить порядок отображения колонок в таблице. Колонки «Экземпляр», «Бизнес-ключ», «Запущен» являются основными по умолчанию без возможности скрыть их.

Карточка схемы

2. Поиск и фильтрация экземпляров

Для удобного и быстрого поиска экземпляра процесса можно использовать систему фильтров, представленную в виде:

  • общего поля поиска ID и бизнес-ключу экземпляра;

  • выпадающего списка всех загруженных схем с их кодами и версиями с возможностью поиска по наименованию или коду схемы процесса;

  • списка статусов экземпляров;

  • названия сервера.

При переходе на страницу «Экземпляры процессов» фильтр по статусу по умолчанию содержит значения: «Активный», «Инцидент».

3. Расширенная фильтрация экземпляров

Можно воспользоваться дополнительными фильтрами, позволяющими:

  • выбирать только корневые процессы;

  • осуществлять поиск экземпляра по переменным и их значениям;

  • искать экземпляры по ID родительских экземпляров;

  • искать экземпляры по ключу элемента (узла схемы процесса);

  • включать в поиск или исключать из поиска список процессов по их ID;

  • устанавливать ограничение по дате запуска экземпляра;

  • устанавливать ограничение по дате завершения экземпляра;

  • использовать для поиска период возникновения инцидента;

  • искать по времени активности экземпляра;

  • искать по времени выполнения экземпляра.

Расширенная фильтрация экземпляров

Для установки дополнительных фильтров необходимо нажать кнопку «Применить фильтры», либо иконку в правом верхнем углу модального окна дополнительных фильтров. Для сброса установленных дополнительных фильтров необходимо нажать на иконку в правом верхнем углу модального окна дополнительных фильтров.

4. Статистика по экземплярам

Над таблицей экземпляров отображаются блоки со статистикой, которые содержат общее количество найденных, активных, завершенных/отмененных экземпляров, а также количество экземпляров, находящихся в инциденте. Статистика строится в соответствии с установленными фильтрами для таблицы экземпляров.

5. Действия над экземпляром

В зависимости от статуса экземпляра можно производить оперативные действия над ним:

  • если статус корневого экземпляра «Активный» или «Инцидент», доступно действие «Отменить»;

  • если статус экземпляра «Инцидент», доступно действие «Повторить».

Действия над экземпляром

Действия над экземпляром доступны в правой части каждой строки в таблице «Экземпляры процессов».

Для каждого экземпляра доступно действие «Открыть трассировку». Оно позволяет перейти в интерфейс Grafana и посмотреть детальный трейсинг для каждого экземпляра (функциональность подробно описана в инструкции к Grafana Tempo).

6. Действия над несколькими экземплярами

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

Действия над экземпляром

Карточка экземпляра

Интерфейс карточки экземпляра представлен на рисунке ниже.

Карточка экземпляра

1. Детали экземпляра

При клике на значение в колонке «Экземпляр» открывается страница с подробными деталями выбранного экземпляра. В верхней части страницы экземпляра отображаются следующие данные:

  • идентификатор экземпляра с возможностью копирования и его название;

  • ссылка на схему и ее версия, по которой этот экземпляр был запущен;

  • ссылка на родительский экземпляр (при наличии);

  • бизнес-ключ экземпляра с возможностью копирования;

  • сервер;

  • текущее состояние (статус) экземпляра;

  • дата и время запуска экземпляра;

  • дата и время завершения экземпляра.

В правом верхнем углу деталей экземпляра отображены кнопки для:

  • Открыть Grafana – открытия трассировки в Grafana;

  • Повторить – повтора экземпляра, если его статус "Инцидент";

  • Отменить – выполнения действия отмены экземпляра, если открыта карточка корневого экземпляра процесса.

2. Схема экземпляра

Центральная область страницы экземпляра выделена под схему, представляющую собой визуализацию BPMN и позволяющую быстро найти текущее положение экземпляра и его статус при помощи цветовой индикации:

  • зеленой рамкой отмечены успешно выполненные узлы схемы;

  • синей рамкой отмечен активный элемент схемы;

  • над выполняемым элементом схемы отображен синий круглый индикатор (в случае, если статус экземпляра «Активный») или красный треугольный индикатор (в случае статуса «Инцидент»). С помощью этой индикации можно быстро определить в каком месте схемы сейчас находится экземпляр.

Для удобства работы со схемой в нижнем правом углу есть кнопки для:

  • Скачать – скачивания схемы на локальный компьютер в формате .bpmn

  • Скачать – скачивания схемы на локальный компьютер в формате .png

  • Уменьшить – уменьшения масштаба схемы

  • Увеличить – увеличения масштаба схемы

  • Сброс – сброса масштаба и центрирования схемы в допустимой области отображения

  • Полный экран – разворачивания схемы на весь экран

Если необходимо быстро найти узел на схеме, можно воспользоваться строкой поиска по имени или коду узла – найденный элемент подсветится синим.

Область видимости схемы можно расширять/сужать, потянув за нижний край, для более удобного анализа.

3. Управление экземпляром

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

Детали узла

В модальном окне деталей также есть блок «Управление», в котором всегда доступно действие «Открыть трассировку» (позволяет перейти в интерфейс Grafana Tempo и проанализировать детальную трассировку прохождения экземпляром задач схемы) и в зависимости от типа узла могут быть доступны:

  • блок «Дочерние процессы» и действие «Перейти к экземпляру <имя_схемы_дочернего_экземпляра>», если выбранный элемент на схеме – это пройденный или активный в данный момент подпроцесс;

  • действие «Переместить», если выбран активный в данный момент узел;

  • действие «Отменить», если выбран активный или находящийся в инциденте в данный момент узел корневого экземпляра процесса - полное прекращение выполнения узла (действие необратимо);

  • действие «Повторить», если выбран находящийся в инциденте в данный момент узел – выполняет повторный запуск узла, находящегося в инциденте.

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

Детали узла

Действие перемещения позволяет "перепрыгнуть" на другой элемент диаграммы. Использовать перемещение нужно осторожно, так как оно может нарушить целостность данных. Необходимо проверить переменные процесса и убедиться, что установлены все необходимые данные для нового пути выполнения.

Перемещение экземпляра

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

4. История выполнения экземпляра

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

Таблица истории

Вкладка «История» отображает полную хронологию выполнения экземпляра:

  • последовательность всех выполненных шагов;

  • статус выполнения каждого шага;

  • тип узла;

  • время начала и окончания каждого действия.

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

Если у экземпляра есть вложенные подпроцессы, они отобразятся на вкладке «Дочерние процессы» в виде таблицы из колонок:

  • ID (содержит идентификатор дочернего экземпляра, идентификатор отображается в виде ссылки, по которой можно перейти в карточку экземпляра);

  • Состояние (статус экземпляра);

  • Название (имя и/или код схемы, по которой запущен дочерний экземпляр, с указанием ее версии);

  • Дата запуска;

  • Дата завершения.

Также имеется возможность настройки отображения столбцов по кнопке «Настроить колонки» (иконка гаечного ключа): показать/скрыть или изменить порядок отображения колонок в таблице. Колонки «ID», «Состояние», «Дата запуска» основными по умолчанию без возможности скрыть их.

Таблица дочерние

5. Инциденты

При наличии инцидентов, возникших в ходе выполнения текущего экземпляра, они отобразятся не только на схеме в виде красных индикаторов, но и на вкладке «Инциденты» в виде таблицы с деталями по:

  • ID инцидента;

  • Типу инцидента (характеру ошибки);

  • Сообщению об ошибке (содержит описание ошибки);

  • Статусу (решён инцидент или нет);

  • Дате и времени возникновения;

  • Дате и времени решения (при наличии).

Доступны следующие операции над инцидентом:

  • «Повторить»;

  • «Отменить» (если ошибка произошла в корневом экземпляре процесса).

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

Таблица инциденты

6. Переменные

Вкладка «Переменные» позволяет просматривать и анализировать данные процесса, контекст его выполнения. Переменные представлены в формате ключ-значение с указанием типа каждой переменной.

Переменные экземпляра

Если необходимо быстро найти в списке нужную переменную, можно воспользоваться полем поиска по ключу, значению или типу. С помощью кнопок доступно добавление («+ Добавить переменную») новой переменной экземпляра или изменение существующей (кнопка «Редактировать»). Также доступен просмотр значения переменной, если оно слишком большое (кнопка «i» - «Просмотреть»).

Добавление и редактирование переменных доступно только для экземпляров в статусе «Активный» или «Инцидент». Важно помнить, что изменение переменных может повлиять на логику процесса.

Раздел «Инциденты»

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

Инциденты

Интерфейс раздела «Инциденты» представлен на рисунке ниже.

Интерфейс инцидентов

1. Таблица инцидентов

Страница «Инциденты» содержит таблицу всех инцидентов с их основными параметрами. Каждая строка таблицы содержит данные о конкретном инциденте, параметры которого указаны в соответствующих столбцах:

  • ID – уникальный идентификатор инцидента;

  • Экземпляр – ID экземпляра процесса, в котором произошел инцидент;

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

  • Статус – текущий статус инцидента:

    • Не решён;

    • Решен;

    • Отменён.

  • Схема – наименование и/или код схемы процесса, в которой зафиксирован инцидент;

  • Версия схемы – версия схемы процесса;

  • Сервер – сервер, на котором развернута схема процесса;

  • Сообщение об ошибке – краткое описание ошибки;

  • Тип - тип ошибки в инциденте;

  • Дата – дата и время возникновения инцидента.

Для статусов «Решен»/«Отменен», которые являются терминальными, дополнительно отображается дата и время завершения инцидента в колонке «Статус».

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

Значения в колонках «Экземпляр» и «Схема» являются гиперссылками и при нажатии переводят пользователя на страницу с деталями выбранного экземпляра или схемы соответственно.

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

Настройка - инциденты

При клике на значение в колонке «Сообщение об ошибке» отображается модальное окно с деталями инцидента:

Детали ошибки

Имеется возможность:

  • Копировать – скопировать стек-трейс по кнопке;

  • перейти в Grafana для просмотра трассировки по кнопке «Открыть трассировку»;

  • закрыть модальное окно «Детали ошибки» по кнопке «Закрыть» или «х» в правом верхнем углу.

2. Поиск и фильтрация инцидентов

Для поиска инцидентов предусмотрена система фильтрации, представленная в виде:

  • общего поля поиска по сообщению или типу ошибки, ID инцидента или ID экземпляра, а также по бизнес-ключу;

  • выпадающего списка всех загруженных схем с их кодами и версиями с возможностью поиска по наименованию или коду схемы процесса;

  • выпадающего списка серверов;

  • списка статусов инцидента.

При переходе на страницу «Инциденты» в фильтре по статусу по умолчанию установлено значение «Не решён».

3. Расширенная фильтрация инцидентов

Расширенная фильтрация, доступная по нажатию на иконку, позволяет ограничить выборку инцидентов по дате и времени (от и до):

  • возникновения инцидента;

  • решения инцидента;

  • старта экземпляра процесса, в котором произошел инцидент.

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

Расширенная фильтрация инцидентов

Применяется автоматически после заполнения фильтров. Для сброса установленных фильтров необходимо нажать на иконку в правом верхнем углу модального окна дополнительных фильтров.

4. Статистика по инцидентам

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

5. Действия над инцидентами

Для инцидентов в статусе «Не решён» можно проводить оперативные действия над ними:

  • открыть трассировку;

  • повторить;

  • отменить, если инцидент произошел в корневом экземпляре процесса.

Действия над инцидентом

Для инцидентов в терминальном статусе («Решён»/«Отменён») доступно только действие «Открыть трассировку».

Все действия над инцидентами доступны в правой части каждой строки в таблице «Инциденты».

6. Действия над несколькими инцидентами

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

Массовые действия над инцидентами

Раздел «Показатели»

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

Описание интерфейса и функциональности

Интерфейс раздела «Показатели» представлен на рисунке ниже.

Показатели

Добавление нового блока

Для добавления нового блока на страницу «Показатели» пользователю необходимо нажать на кнопку «+ Добавить блок». После нажатия на кнопку открывается модальное окно «Добавление блока», содержащее следующие элементы:

  • Кнопка «Х» – закрывает модальное окно «Добавление блока» без сохранения изменений.

  • Поле «Вставьте код встраивания» – предназначено для ввода iframe-кода, используемого при добавлении блоков из системы Grafana. Содержит плейсхолдер "<iframe src="…​" width="100%" height="400"></iframe>".

  • Блок «Ширина блока» – позволяет выбрать размер отображения блока на странице «Показатели». Доступны следующие варианты отображения:

    • на 1/3 экрана;

    • на 1/2 экрана;

    • на всю ширину страницы.

  • Кнопки управления:

    • «Отмена» – закрывает модальное окно «Добавление блока» без сохранения изменений.

    • «Добавить» – сохраняет внесённые данные и отображает новый блок на странице «Показатели».

Добавление блока

В модальном окне «Добавление блока» пользователю необходимо заполнить поля, выбрать параметры отображения блока и нажать кнопку «Добавить» для сохранения изменений. Пример заполненного модального окна «Добавление блока» представлен на рисунке ниже.

Пример добавления блока

Удаление блока

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

Просмотр трассировки в Grafana Tempo

Система Пульт интегрирована с Grafana Tempo, которая предоставляет возможность:

  • просмотра цепочки вызовов от старта экземпляра процесса до финального статуса;

  • просмотра времени выполнения отдельных запросов и операций;

  • анализа результата выполнения каждой активности (успешно или неуспешно и почему);

  • анализа инцидентов и определения точного места возникновения ошибки;

  • определение зависимых операций, которые могли повлиять на сбой;

  • и многое другое.

Трассировка запросов позволяет проводить глубокую диагностику для анализа производительности, поиска узких мест и расследования причин инцидентов. Для максимально эффективного использования инструмента трассировки рекомендуется ознакомиться с подробной инструкцией к Grafana Tempo.

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

Переход в Grafana осуществляется из следующих разделов по кнопке «Открыть трассировку»:

  1. Карточка схемы процесса на вкладке «Инциденты» по клику на значение в колонке «Сообщение об ошибке» в модальном окне деталей инцидента;

  2. «Инциденты» – по клику на значение в колонке «Сообщение об ошибке» в модальном окне деталей ошибки.

  3. «Экземпляры процессов»;

    Трассировка из экземпляров

  4. Карточка экземпляра процесса:

Трассировка из карточки экземпляра

  • на схеме экземпляра по клику на пройденный или активный узел;

  • по кнопке в деталях экземпляра;

  • на вкладке «Инциденты» по клику на значение в колонке «Сообщение об ошибке» в модальном окне деталей инцидента.

    Трассировка из деталей ошибки

3.2 - Камунда.РФ 7

Введение

Камунда.РФ 7 — это независимая производная (fork) программного обеспечения с открытым исходным кодом Camunda Platform 7 Community Edition, распространяемого под лицензией Apache License 2.0. Проект развивает это ядро, фокусируясь на безопасности, локализации и поддержке для русскоязычных пользователей.

Архитектурно Камунда.РФ 7 состоит из следующих основных компонентов:

  • Process Engine — ядро/движок выполнения процессов

  • REST API — HTTP‑интерфейс управления для Process Engine

  • Database — хранение состояния Process Engine

Основные понятия Process Engine

  • Deployment — загрузки моделей в Process Engine

  • Process Definition — описания/определения процессов (BPMN‑диаграммы), являются составной частью Deployment

  • Process Instance — запущенные экземпляры процессов, на основе Process Definition

  • Activity Instance — пользовательские или сервисные задачи, в рамках Process Instance

  • Variable — переменные экземпляра процесса, хранящие состояние/данные

Предварительные требования

Деплой процесса через REST API

HTTP‑запрос

POST /engine-rest/deployment/create
Content-Type: multipart/form-data

Пример cURL

curl http://localhost:8080/engine-rest/deployment/create -XPOST \
-F "deployment-name=test" \
-F "data=@order-process.bpmn"

Результат

В ответе возвращается информация о Deployment и идентификаторы загруженных Process Definition.

{
    "deployedCaseDefinitions": null,
    "deployedDecisionDefinitions": null,
    "deployedDecisionRequirementsDefinitions": null,
    "deployedProcessDefinitions": {
        "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef": {
            "category": "http://bpmn.io/schema/bpmn",
            "deploymentId": "7ddbe3e3-dfb6-11f0-8730-56d6ece781ef",
            "description": null,
            "diagram": null,
            "historyTimeToLive": 1,
            "id": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
            "key": "OrderProcess",
            "name": null,
            "resource": "order-process.bpmn",
            "startableInTasklist": true,
            "suspended": false,
            "tenantId": null,
            "version": 3,
            "versionTag": null
        }
    },
    "deploymentTime": "2025-12-23T07:18:53.709+0300",
    "id": "7ddbe3e3-dfb6-11f0-8730-56d6ece781ef",
    "links": [
        {
            "href": "http://localhost:8080/engine-rest/deployment/7ddbe3e3-dfb6-11f0-8730-56d6ece781ef",
            "method": "GET",
            "rel": "self"
        }
    ],
    "name": "test",
    "source": null,
    "tenantId": null
}

Запуск процесса, создание экземпляра

HTTP‑запрос

POST /engine-rest/process-definition/key/{processKey}/start
Content-Type: application/json

Пример cURL

curl -X POST http://localhost:8080/engine-rest/process-definition/key/OrderProcess/start \
-H "Content-Type: application/json" \
-d '{
"variables": {
"orderId": { "value": "12345", "type": "String" }
}
}'

Результат

В ответе возвращается JSON с идентификатором экземпляра процесса:

{
    "businessKey": null,
    "caseInstanceId": null,
    "definitionId": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
    "definitionKey": "OrderProcess",
    "ended": false,
    "id": "824b08d5-dfb7-11f0-8362-56d6ece781ef",
    "links": [
        {
            "href": "http://localhost:8080/engine-rest/process-instance/824b08d5-dfb7-11f0-8362-56d6ece781ef",
            "method": "GET",
            "rel": "self"
        }
    ],
    "suspended": false,
    "tenantId": null
}

Получение статуса процесса

Получение информации по экземпляру

GET /engine-rest/process-instance/{id}

Пример cURL

curl http://localhost:8080/engine-rest/process-instance/824b08d5-dfb7-11f0-8362-56d6ece781ef

Результат

{
    "businessKey": null,
    "caseInstanceId": null,
    "definitionId": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
    "definitionKey": "OrderProcess",
    "ended": false,
    "id": "824b08d5-dfb7-11f0-8362-56d6ece781ef",
    "links": [],
    "suspended": false,
    "tenantId": null
}

Возможные статусы

  • ended = false — процесс активен

  • ended = true — процесс завершён

  • suspended = true — процесс приостановлен

Получение активных задач процесса

GET /engine-rest/process-instance/{processInstanceId}/activity-instances

Пример cURL

curl http://localhost:8080/engine-rest/process-instance/824b08d5-dfb7-11f0-8362-56d6ece781ef/activity-instances

Результат

{
    "activityId": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
    "activityName": null,
    "activityType": "processDefinition",
    "childActivityInstances": [
        {
            "activityId": "UserTask_HandlerOrder_1",
            "activityName": "Обработать заявку",
            "activityType": "userTask",
            "childActivityInstances": [],
            "childTransitionInstances": [],
            "executionIds": [
                "824b08d5-dfb7-11f0-8362-56d6ece781ef"
            ],
            "id": "UserTask_HandlerOrder_1:824d79d9-dfb7-11f0-8362-56d6ece781ef",
            "incidentIds": [],
            "incidents": [],
            "name": "Обработать заявку",
            "parentActivityInstanceId": "824b08d5-dfb7-11f0-8362-56d6ece781ef",
            "processDefinitionId": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
            "processInstanceId": "824b08d5-dfb7-11f0-8362-56d6ece781ef"
        }
    ],
    "childTransitionInstances": [],
    "executionIds": [
        "824b08d5-dfb7-11f0-8362-56d6ece781ef"
    ],
    "id": "824b08d5-dfb7-11f0-8362-56d6ece781ef",
    "incidentIds": [],
    "incidents": [],
    "name": null,
    "parentActivityInstanceId": null,
    "processDefinitionId": "OrderProcess:3:7dde06c5-dfb6-11f0-8730-56d6ece781ef",
    "processInstanceId": "824b08d5-dfb7-11f0-8362-56d6ece781ef"
}

Типовой жизненный цикл процесса

  1. Установка (Deployment) BPMN‑модели процесса

  2. Запуск процесса, создание экземпляра

  3. Мониторинг статуса через REST или Камунда.РФ Пульт

  4. Выполнение задач (пользовательских или сервисных)

  5. Экземпляр процесса продолжается или завершается

3.3 - Камунда.РФ 8

Камунда.РФ 8 — это независимая производная (fork) открытого программного обеспечения Camunda 8.5 (Zeebe), распространяемого под лицензией Apache License 2.0. Проект развивает это ядро, фокусируясь на безопасности, локализации и поддержке для русскоязычных пользователей.

Краткое описание Камунда.РФ 8

Камунда.РФ 8 — это платформа оркестрации процессов, построенная вокруг распределённого workflow-движка.

В отличие от Камунда.РФ 7 и Camunda 7:

  • нет встроенного BPMN-движка с состоянием в централизованной БД

  • используется event-sourcing и log-based storage

  • основной API — gRPC (REST используется ограниченно)

  • высокая горизонтальная масштабируемость

Основные компоненты, образующие кластер Камунда.РФ 8:

  • Камунда.РФ 8 Engine — движок выполнения процессов

  • Камунда.РФ 8 Gateway — точка входа для gRPC-клиентов

Основные понятия

  • Deployment — публикация ресурсов (BPMN-диаграмм) в кластер Камунда.РФ 8

  • Process Definition — BPMN-модель процесса

  • Process Instance — выполняющийся экземпляр процесса

  • Job — единица работы для Worker

  • Worker — клиент, выполняющий Job

Предварительные требования

  • Запущенный Камунда.РФ 8 кластер (см. инструкцию по установке)

  • gRPC-endpoint Камунда.РФ 8 Gateway

  • BPMN-файл процесса (например order-process.bpmn)

Подключение к Камунда.РФ 8 (пример)

Примеры ниже показаны концептуально. Реализация зависит от используемого SDK (Java, Go, Node.js).

Деплой процесса (DeployResource)

Назначение

Загружает BPMN/DMN ресурсы в кластер Камунда.РФ 8.

gRPC метод

Gateway/DeployResource

Пример (Java, концептуально)

client.newDeployResourceCommand()
.addResourceFile("order-process.bpmn")
.send()
.join();

Результат

Возвращается информация о деплое и версии process definition.

Запуск процесса (CreateProcessInstance)

gRPC метод

Gateway/CreateProcessInstance

Пример (Java)

client.newCreateInstanceCommand()
.bpmnProcessId("order-process")
.latestVersion()
.variables("{ "orderId": 12345, "amount": 1000 }")
.send()
.join();

Результат

Возвращается processInstanceKey — уникальный идентификатор экземпляра.

Получение статуса процесса

Особенность Camunda 8

Камунда.РФ 8 Engine/Gateway не предоставляет прямой gRPC-запрос «получить статус процесса».

Статус определяется косвенно через:

  • события в log stream

  • в Камунда.РФ Пульт, через подключенное расширение "История"

  • наличие активных jobs

Рекомендуемый способ

Для runtime-мониторинга используйте Operate.

Работа с Job (Workers)

Активация Job (ActivateJobs)

Gateway/ActivateJobs

Пример воркера (Java)

client.newWorker()
.jobType("payment-service")
.handler((jobClient, job) -> {
// бизнес-логика
jobClient.newCompleteCommand(job.getKey())
.send();
})
.open();

Завершение Job

gRPC метод

Gateway/CompleteJob

Job считается выполненной после успешного вызова.

Типовой жизненный цикл процесса

  1. Установка (Deployment) BPMN‑модели процесса

  2. Запуск процесса, создание экземпляра

  3. Мониторинг статуса через Камунда.РФ Пульт

  4. Worker активирует Job

  5. Worker завершает Job

  6. Экземпляр процесса продолжается или завершается