mybpm!
Скачать в формате: PDF pdf DOCX word
Установка MyBPM
Переменные окружения
Компонент MyBPM API
Требования к настройке баз данных со стороны платформы MyBPM
MyBPM WEB
Первый вход в систему
Трудности в установке и настройке
(Другое)

Компонент MyBPM API

Компонент MyBPM API распространяется как образ контейнера Docker. Примерное имя контейнера следующее:

out.mybpm.kz/mybpm-api-...

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

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

MyBPM API-сервис для своей работы требует следующие базы данных:

  1. MongoDB - это основная база данных. Здесь платформа MyBPM хранит оперативную информацию.

  2. MongoDB (Files) - здесь хранятся файлы. Можно эту базу-данных совместить с оперативной MongoDB. Но это не рекомендуется, так как характер работы с файлами сильно отличается.

  3. Apache Kafka - здесь платформа MyBPM хранит историческую информацию. Также кафка используется как брокер сообщений для синхронизации данных между различными компонентами платформы MyBPM.

  4. Apache Zookeeper - здесь платформа хранит свою конфигурацию. Желательно администраторам платформы иметь веб-интерфейс к Zookeeper. Например, ZooNavigator: https://zoonavigator.elkozmon.com/en/latest/

  5. ElasticSearch - здесь платформа MyBPM хранит оперативную информацию для поиска по ней (в MongoDB для поиска ходить запрещено)

  6. PostgreSQL - здесь обрабатываются различные алгоритмы с использованием реляционного механизма.

Требования к БД, к которым подключается компонент MyBPM API смотрите здесь

Конфигурация платформы MyBPM

Вся конфигурация платформы MyBPM находиться на сервере ZooKeeper поэтому рекомендуется иметь удобный интерфейс к нему, разработчики рекомендуют ZooNavigator: https://zoonavigator.elkozmon.com/en/latest/

Его можно быстро установить через докер: https://hub.docker.com/r/elkozmon/zoonavigator

В будущем планируется конфигурацию системы перенести полностью на MongoDB и отказаться от Zookeeper. Это будет сделано абсолютно бесшовно. А управление конфигурацией будет через Web-интерфейс, встроенный в платформу MyBPM.

Файлы конфигурации создаются автоматически со значениями по умолчанию. Эти значения уже настроены для оптимальной работы платформы MyBPM. Но иногда может возникнуть ситуации, что их можно поменять. После изменения этих параметров платформу MyBPM перезапускать НЕ нужно - они применяются на платформе НА ГОРЯЧУЮ.

Жонглирование подсистемой MyBPM API

MyBPM API содержит в себе подсистемы:

  1. REST-API: Подсистема обработки REST-сервисов и Web-сокетов

  2. Kafka Consumers: Подсистема обработки сообщений кафки

  3. Schedulers: Подсистема выполнения задач по расписанию.

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

Параллельная работа подсистем

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

Подсистема REST-API реализована по принципу БЕЗ-СОСТОЯНИЯ (state-less), поэтому, если один сервер не справляется с нагрузкой, можно запустить несколько копий и случайным образом выбирать обработчик запросов. Для этого можно использовать балансировщик нагрузки, и он может работать в любых режимах (случайный выбор, выбор менее нагруженного сервере и др. - это зависит от имеющегося ПО по управлению нагрузкой).

Подсистема REST-API всегда активна - её отключение делается недоступностью данного сервера для REST-запросов.

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

Подсистему Schedulers на одном сервере можно отключить с помощью переменной окружения:

  MYBPM_SCHEDULER_OFF

Описание переменных окружения здесь.

Подсистема Consumers - это набор обработчиков сообщений из кафки из различных топиков. Её распараллеливание решается самой архитектурой кафки. Главное чтобы топики в кафке содержали большое количество партиций. Рекомендуется 48 для малых систем. И 480 - для больших.

Подсистему Consumers на одном сервере можно отключить с помощью переменной окружения:

MYBPM_ALL_CONSUMERS_OFF

Описание переменных окружения здесь.

Настройка обработчиков в подсистеме Consumers

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

/mybpm/consumers/...

Этот путь можно поменять с помощью переменной окружения

MYBPM_CONSUMER_DIR

Описание переменных окружения здесь.

Тем самым можно распределить настройки одних серверов-consumer-ов в одном месте, а других - в другом. Это позволяет распределять обработку различных ТИПОВ сообщений из кафки по разным серверам.

Рассмотрим пример. Есть файл конфигурации:

/mybpm/consumers/BoiEvents.workerCount

В нём содержится следующий текст:

#
# Created at 2023-10-23 16:26:40
#
# Генерирует события инстанций БО по их изменениям и кидает их в кафку
boiKafkaToBoiEventKafka = 1
#
# Appended at 2023-10-23 16:26:40
#
# Парсит события инстанций БО для отображения их на клиенте
applyBoiEventKafkaToMongo = 1

Параметр boiKafkaToBoiEventKafka соответствует одному обработчику, который "Генерирует события..." - об этом сказано в комментарии к параметру выше. Цифра у этого параметра обозначает количество потоков, которые обрабатывают данные сообщения.

Например, Вы хотите, чтобы на сервере S1 обрабатывались только boiKafkaToBoiEventKafka в три потока, а на сервере S2 обрабатывались только applyBoiEventKafkaToMongo в четыре потока.

Для этого на сервере S1 установите переменную окружения MYBPM_CONSUMER_DIR=s1, а на сервере S2 установите переменную окружения MYBPM_CONSUMER_DIR=s2. После запуска этих серверов платформа создаст следующие конфиги:

/mybpm/consumers-s1/BoiEvents.workerCount
boiKafkaToBoiEventKafka = 1
applyBoiEventKafkaToMongo = 1

И:

/mybpm/consumers-s2/BoiEvents.workerCount
boiKafkaToBoiEventKafka = 1
applyBoiEventKafkaToMongo = 1

Здесь комментарии убраны, а первая строка - это путь к файлу.

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

/mybpm/consumers-s1/BoiEvents.workerCount
boiKafkaToBoiEventKafka = 3
applyBoiEventKafkaToMongo = 0

И:

/mybpm/consumers-s2/BoiEvents.workerCount
boiKafkaToBoiEventKafka = 0
applyBoiEventKafkaToMongo = 4

После сохранения этих файлов перезапускать сервера НЕ НУЖНО - платформа автоматически узнает об их изменении и обновит своё поведение.

Теперь будет работать всё так, как Вы запланировали.

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

Настройка расписания в подсистеме Schedulers

Расписания в подсистеме Schedulers тоже вынесены в конфигурационный файл. Конфигурация расписаний находиться по пути:

/mybpm/scheduler/core/...

Для ядра системы, и по пути:

/mybpm/scheduler/plugin/<plugin-id>/...

Для плагинов.

Эти файлы тоже создаются платформой автоматически и заполняются расписанием по умолчанию. Так же в эти конфиги добавлено описание как самих задач с расписанием, так и формата расписания.

Например, есть файл:

/mybpm/scheduler/core/BoProcessScheduler.scheduler-config.txt
executeProcesses = repeat every 10 min

(Здесь комментарии убраны, а первая строка - это путь к файлу.)

И Вам нужно увеличить интервал запуска этой задачи до тридцати минут. Тогда Вам нужно написать:

/mybpm/scheduler/core/BoProcessScheduler.scheduler-config.txt
executeProcesses = repeat every 30 min

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

/mybpm/scheduler/core/BoProcessScheduler.scheduler-config.txt.error

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

Так же Вам может понадобиться отключить вообще запуск данной задачи, для этого Вам нужно поставить символ решётки, вот так:

/mybpm/scheduler/core/BoProcessScheduler.scheduler-config.txt
executeProcesses = # repeat every 30 min

И тогда запуск этой задачи будет отменён.

УЧТИТЕ, решётка должна стоять ПОСЛЕ знака равно.