Руководство по системному администрированию#

Термины и сокращения#

Сценарии администрирования#

Загрузка моделей процессов#

Фабрики (потребители), работающие с Engine Platform V Flow, должны самостоятельно загружать (деплоить) модели в Engine.

Загрузка моделей на стенд Engine при автоустановке своей поставки#

Шаги:

1. Выполнить начальную настройку ТУЗ Jenkins Credential. Если стенд:

   • ПСИ или ПРОМ, то:

     • Создать ТУЗ в домене Альфа;

     • Создать Jenkins Credential с этим ТУЗ'ом;

     • Запросить права для ТУЗ'а на запуск job по развертыванию моделей;

   • Тестовый (ИФТ, НТ) – начальные настройки уже выполнены (переходим к следующему пункту);

2. Прописать шаг по развертыванию моделей в job автоустановки. Настройки в файлах actions.xml (на уровне АС) и smoke.conf (на уровне стенда);

3. Выполнить вызов job автоустановки.

Загрузка моделей процессов с помощью Jenkins job#

Jenkins job Deploy_Models_By_Zones/Deploy_Models_Cred

Развертывание моделей на стенды Engine выполняется только через вызов Jenkins job.

Целевой вариант: развертывание моделей с использованием ТУЗ на заданные ММТ-зоны.

Права на запуск job развертывания моделей выдаются ТУЗ.

На Тестовых стендах используется общая ТУЗ, находящаяся в общем Jenkins Credential. На ПСИ и ПРОМ у каждой фабрики своя ТУЗ, прописанная в Jenkins Credential фабрики.

Загрузка моделей вручную на стенды Engine не выполняется.

Формат поставки моделей#

Есть два варианта предоставления моделей для загрузки:

• Архив с моделями входит в поставку, при этом:

  • Дистрибутив соответствует формату поставки;

  • Архивы с моделями в дистрибутиве должны находиться в архиве: other/bpmnModels*.zip, при этом:

    • ограничение на размер каждого найденного архива с моделями other/bpmnModels*.zip: 1'048'576 байт;

    • ограничение на количество архивов с моделями по маске other/bpmnModels*.zip: нет.

  • Дистрибутив выложен на Nexus SBRF;

  • Только при соблюдении этих условий job сможет успешно извлечь и обработать модели из поставки;

• Модели (bpmn-файлы) запакованы в архив, при этом:

  • Дистрибутив выложен на Nexus SBRF;

  • Модели (bpmn-файлы) находятся на верхнем уровне;

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

Job развертывания моделей автоматически определяет формат поставки моделей:

• Если в архиве по полученной ссылке (distrib_url) есть файлы other/bpmnModels*.zip, то развертываются все модели из найденных по маске файлов;

• Иначе модели берутся из корня архива, полученного по ссылке (distrib_url).

Подготовка для вызова Deploy_Models_By_Zones job#

Данный раздел относится только к ПСИ и ПРОМ стендам.

Для Тестовых стендов (ИФТ, НТ) настройки уже выполнены.

Каждая фабрика для вызова job Deploy_Models_By_Zones должна получить права на его запуск.

Надо понимать, что на каждом Jenkins-сервере существует свой job Deploy_Models_By_Zones.

Поэтому работы на стороне Jenkins'а (создание Credential и предоставление прав на запуск job от имени ТУЗ'а) надо выполнять на каждом Jenkins-сервере.

Для этого надо:

1. Создать ТУЗ для фабрики: Создание ТУЗ в рамках DevOps активностей;

2. Создать Jenkins Credential с типом Username with password и указать в качестве Username - вашу ТУЗ; Пример создания сredential some_cred, хранящего логин пользователя и его пароль:

   

3. Запросить для ТУЗ из Jenkins Credential права на запуск job по развертыванию моделей. В результате ваша ТУЗ получит права на запуск нужного job по развертыванию моделей.

Вызов Deploy_Models_By_Zones/Deploy_Models_Cred job из автоустановки поставки

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

1. Задать параметры вызова job загрузки моделей.

   1. Для этого в файле smoke.conf (находится в репозитории в папке стенда), в блоке прописать параметры. Важно: Имя подсистемы (Subsystem) может быть произвольным, но должно совпадать в файлах actions.xml и smoke.conf.

   2. Выберите пример в зависимости от способа запуска job:

      1. Вызов job Deploy_Models_By_Zones с использованием ТУЗ. Целевой вариант

         1. 

      2. Вызов job Deploy_Models_Cred с использованием ТУЗ, без учета ММТ зон. Планируется к выведению

         1. 

2. Оформить вызов job загрузки моделей из автоустановки.

   1. Для этого в файле actions.xml, в блок добавить шаг по загрузке моделей. Важно: Имя подсистемы (Subsystem) может быть произвольным, но должно совпадать в файлах actions.xml и smoke.conf.

   2. Выберите пример в зависимости от способа запуска job:

      1. Вызов job Deploy_Models_By_Zones с использованием ТУЗ. Целевой вариант

         1. 

      2. Вызов job Deploy_Models_Cred с использованием ТУЗ, без учета ММТ зон. Планируется к выведению

         1. 

Далее необходимо запустить ваш job автоустановки (в автоматическом или ручном режиме).

На шаге install_BPM_models будет выполнено обращение к job Deploy_Models_By_Zones от имени и с правами указанного ТУЗ (в рекомендуемом варианте запуска).

Для тестовых стендов будет использоваться Jenkins Credentials BPM_models_cred, в котором используется ТУЗ sbt-bpms-tech.

Для ПСИ и ПРОМ стендов будут использоваться Jenkins Credentials и ТУЗ, созданные для каждой фабрики.

В job будут переданы:

• Имя стенда (параметр stand);

• Ссылка на дистрибутив с моделями (параметр distrib_url);

• Список зон, на который будет выполняться загрузка моделей (параметр zones).

В результате модели будут развернуты на указанный стенд Engine.

Вызов job Deploy_Models_By_Zones из произвольного job

Вызывать job Deploy_Models_By_Zones можно не только из EIP-автоустановки, но и из произвольных job.

Сделать это можно с помощью Groovy-кода в pipeline и вызова triggerRemoteJob через генератор кода.

Пример:

node ("masterLin") {
    model_url='https://sbrf-nexus.ca.sbrf.ru/nexus/service/local/repositories/Nexus_PROD/content/Nexus_PROD/CI00642471_BPM/TESTMODELS/1.0.3/TESTMODELS-1.0.3-distrib.zip'
    stand="BOSTON"
    triggerRemoteJob (
        remoteJenkinsUrl: 'https://sbt-qa-jenkins.ca.sbrf.ru/jenkins',
        job: 'OASABP/PPRB_BPM_UBP/Deploy_Models_By_Zones',
        auth: CredentialsAuth(credentials: 'id_of_your_Jenkins_credential'),
        parameters: "stand=${stand}\ndistrib_url=${model_url}",
        enhancedLogging: true,
        maxConn: 1
    )
}

В качестве значения параметра Credentials укажите ID созданного Jenkins Credentials. Не путайте с логином ТУЗ, который прописан внутри Jenkins Credentials.

Автоматическая загрузка моделей на тестовых стендах Engine после очистки базы данных.#

Периодически на тестовых стендах Engine выполняется очистка хранилища моделей (Oracle база данных). В этом случае после очистки хранилища, модели надо заново загрузить.

Администраторы Engine после очистки хранилища запускают специальный Jenkins job. Этот job вызывает Jenkins job фабрик, работающих со стендами BPM.

Назначение job фабрик:

• выбрать нужную поставку с моделями процессов этой фабрики (потребителя);

• установить ее на заданный стенд Engine.

Установка выбранных моделей выполняется через job Deploy_Models_By_Zones.

Другими словами, Jenkins job внешних команд реализуют логику выбора – какую именно модель/модели загрузить на стенд. И затем вызывают загрузку выбранных моделей.

Действия после очистки хранилища

Действия команд фабрик по интеграции с job автоматической загрузки моделей на стенд Engine после очистки хранилища:

1. Создать в Jenkins job. В качестве устанавливаемой поставки фабрики с моделями процессов можно использовать и фильтры. В этом случае отпадает потребность в актуализации ссылки в job фабрик;

2. Дать права на запуск своего job, если требуется.

Управление конфигурацией#

Настройка режима работы#

Предусмотрено 2 режима предоставления услуг Flow:

• Без поддержки мультитенантности;

• С поддержкой мультитенантности - Один потребитель в одной инсталляции (multiinstance);

Режим работы определяется переменной multitenancy.mode в файле application.yml:

Для режима multiinstance файл конфигурации должен содержать заполненные переменные:

• multitenancy.resourceName - идентификатор ресурса потребителя;

• multitenancy.commonName - commonName из сертификата потребителя.

При валидации конфигурационного файла, должны быть соблюдены следующие правила:

Если валидация не прошла успешно, приложение не запускается. В лог приложения добавляется соответствующая запись.

Настройка аутентификации#

Режимы авторизации описаны в документе "Руководство разработчика" п. Авторизация и аутентификация пользователя в системе.

Dev режим#

Для Dev режима аутентификационные параметры настраиваются в файле application.yml в блоке auth.

Доступны настройки:

• Адреса ресурсов для получения и обновления токена;

• Время жизни токена/refresh токена.

auth:
  refreshToken:
    path: '/user/auth/refresh'
  token:
    path: '/user/auth/token'
    accessLifetime: 3000
    refreshLifetime: 86400

Режим Keycloak#

Аутентификация с помощью сервиса Keycloak в режиме Direct Access Grants настраивается в файле application.yml в блоке auth.

Доступны настройки:

• Адреса ресурсов для получения и обновления токена;

• Время жизни токена/refresh токена.

auth:
  refreshToken:
    path: 'Ресурс получения токена'
  token:
    path: 'Ресурс обновления токена'
keycloak:
   realm: 'Название Realm'
   auth-server-url: 'URL сервера аутентификации'
   resource: 'Имя ресурса'
   credentials:
     secret: 'Секрет сервера авторизации'

В режиме Keycloak к ролям ресурсов добавляется префикс с именем ресурса.

Например, если в токене ролевая модель выглядит как:

{
  "resources": {
    "res1": [
      "role1",
      "role2"
    ],
    "res2": [
      "role1",
      "role3"
    ]
  }
}

В приложении роли будут следующие: res1_role1, res1_role2, res2_role1, res2_role3.

Режим ОСА#

Аутентификация с помощью сервиса ОСА в режиме настраивается в файле application.yml в блоке auth.

Доступны настройки:

• auth.multitenant - true/false - режим работы ОСА.

auth.multitenant: true

Очистка истории#

Устаревшие данные в таблицах истории, по выполненным процессам, занимают место в БД и их необходимо периодически очищать.

В качестве концепции решения было выбрано декларативное секционирование.

Достоинства декларативного подхода

Триггеры больше не нужны:

1. Вставка проходит быстрее

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

3. Генерируется ошибка в случае направления в неподходящую секцию

При работе с секциями:

1. Можно присоединять/отсоединять секции

2. Есть явные ограничения целостности секций

3. Возможно секционирование по выражению в ключе разбиения

4. Можно создавать подсекции

Описание алгоритма разбиения таблиц на партиции и очистка устаревших записей

1. Созданы скрипты для разбиения таблиц с префиксом Historic и таблицы BpmsByteArrayEntityImpl на партиции

Алгоритм создания скрипта:

• Создано поле cdate (поле, по которому идет партиционирование таблиц), которому присвоено значение даты старта процесса, либо, если это новая запись, то текущая дата.

• Сгенерированы партиции по cdate на пол года вперед, т.к. нет функции автоматического создания партиций для записей выходящих за максимальное значение границы партиции.

• Все глобальные индексы переделаны на локальные.

2. Созданы скрипты для создания новых процедур, которые будут нарезать будущие партиции для таблиц уже партиционированных с префиксом Historic и таблицы BpmsByteArrayEntityImpl по cron.

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

Если включена опция engine.cleaner.transferRunningEnable, то перенести данные по незавершенным процессам в партицию дата очистки + 7 дней, что гарантирует то, что они не будут удалены во время очистки

Удалены будут партиции, которые соответствуют условию: текущее время - глубина очистки > времени старта процесса!!!

4. Создана таблица InsertLockJobEntityImpl, которая блокируется на запись целиком, в то время пока идет вставка строки с job.

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

5. Создан scheduler, необходимый для вставки job insertLockJob для очистки истории, которые будут вызывать процедуры очистки

6. Создан scheduler, необходимый для вызова процедур по созданию партиций на будущее

7. Для настройки очистки внутренних таблиц Engine, необходимо указать соответствующие опции в файле application.yml.

Настройка дросселирования нагрузки#

Дросселирование нагрузки – это принудительное ограничение работы приложения, применяемое для защиты от чрезмерной нагрузки и потери данных.

В процессе оценки загруженности анализируются:

• Пул подключений к БД;

• Пул потоков исполнения процессов.

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

Дросселирование нагрузки работает в двухфазном режиме:

• первая фаза - ввод ограничений на создание новых подключений к БД или новых потоков исполнения процессов;

• вторая фаза - сброс части подключений или потоков находящихся в работе.

Для настройки дросселирования нагрузки в Engine необходимо указать соответствующие опции в файле application.yml блок Engine:

• throttlingEnable - Включение/выключение дросселирования нагрузки;

• throttlingStateIntervalInMilliseconds - интервал проверки работоспособности системы в миллисекундах;

• executeProcessThreadPoolSize - Размер пула потоков для исполнения экземпляров процессов (числовое значение);

• executeProcessThreadPoolThrottlingMark - Максимальная утилизация пула процессов - верхняя граница (в процентах) до включения второй фазы дросселирования нагрузки;

• jdbcPoolThrottlingMark - Максимальная утилизации пулов потоков подключения к БД - верхняя граница (в процентах) до включения второй фазы дросселирования нагрузки;

• jdbcPoolThrottlingMarkForNewProcesses - Максимальная утилизации пулов потоков подключения к БД - верхняя граница (в процентах) до включения первой фазы дросселирования нагрузки;

• executeNewProcessThreadPoolThrottlingMark - Максимальная утилизация пула для новых процессов - верхняя граница (в процентах) до включения первой фазы дросселирования нагрузки;

• executeJobThreadPoolThrottlingMark - Максимальная утилизация пула Job (пока не используется);

• executeNewJobThreadPoolThrottlingMark - Максимальная утилизация пула для новых Job (пока не используется).

throttlingEnable: false
throttlingStateIntervalInMilliseconds: 5000
executeJobThreadPoolThrottlingMark: 80
executeNewJobThreadPoolThrottlingMark: 50
executeNewProcessThreadPoolThrottlingMark: 50
executeProcessThreadPoolSize: 135
executeProcessThreadPoolThrottlingMark: 80

Размер пула соединений с БД задается в блоке Database файла application.yml.

Настройки персистирования#

Точки персистирования - это точки сохранения в БД информации для внутреннего использования Engine (сохраняется текущее состояние процесса (execution)).

Список возможных точек персистирования:

• START_EVENT(StartEvent);

• END_EVENT(EndEvent);

• SERVICE_TASK(ServiceTask);

• SCRIPT_TASK(ScriptTask);

• USER_TASK(UserTask);

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

• RECEIVE_TASK(ReceiveTask);

• DEACTIVATE(Deactivate) - выключение точек персистирования.

Для настройки персистирования в Engine необходимо указать соответствующие опции в файле application.yml.

Настройки персистирования содержатся в блоке Engine:

• persistPoints - перечисление точек персистирования для шагов бизнес процессов (для отключения необходимо указать Deactivate).

persistPoints: 'StartEvent,UserTask,IntermediateCatchEvent,ReceiveTask,ServiceTask'

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

Для работы Engine Platform V Flow необходимо настроить подключение к БД. Для настройки подключения к БД необходимо указать соответствующие опции в файле application.yml. Работа с БД осуществляется через pg_bouncer. Для этого в URL для подключения должен быть указан не порт БД, а порт pg_bouncer.

В данный момент используются две БД master и StandIn.

Приложение может работать с 3мя типами БД:

1. postgresql (версия не ниже 11.14);

2. oracle (версия не ниже 12);

3. H2 (нет требований по версионированию).

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

• driverClassName - имя класса драйвера;

• idleTimeout - максимальное время бездействия, по истечении этого времени соединение будет автоматически прервано;

• jdbcUrl - путь к БД, в качестве порта должен быть указан порт pg_bouncer:

  • prepareThreshold=0 - в конце строки отключает механизм preparedstatement (этот механизм временно не работает с pg_bouncer);

• maximumPoolSize - максимальный размер пула соединений;

• username - имя пользователя для подключения к БД (пароль хранится в разделе secrets);

• isolatedLockPool - настройки отдельного пула для записи блокирующих событий (включается настройкой database.isolatedLockPool.enabled):

  • maximumPoolSize - максимальный размер пула соединений;

  • minimumIdle - минимальное количество незанятых соединений пула;

  • idleTimeout - таймаут бездействия пула.

• retry - настройки повторных попыток выполнения запросов

  • backOffPeriod - период между повторными запросами в БД

  • maxAttempts - количество попыток повторных запросов в БД

database:
  master:
    driverClassName: org.postgresql.Driver
    idleTimeout: 12000
    jdbcUrl: jdbc:postgresql://tkled-pprb00112.vm.esrt.cloud.sbrf.ru:5433/bdengine
    maximumPoolSize: 250
    minimumIdle: 125
    username: BPMS
    isolatedLockPool:
      maximumPoolSize: 40
      minimumIdle: 20
      idleTimeout: 12000
  standin:
    driverClassName: org.postgresql.Driver
    idleTimeout: 12000
    jdbcUrl: jdbc:postgresql://tkled-pprb00112.vm.esrt.cloud.sbrf.ru:5433/bdengine
    maximumPoolSize: 250
    minimumIdle: 125
    username: BPMS
    isolatedLockPool:
      maximumPoolSize: 40
      minimumIdle: 20
      idleTimeout: 12000
  isolatedLockPool:
    enabled: true
  retry:
    backOffPeriod: 200
    maxAttempts: 3

Настройки идемпотентности#

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

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

Если при запуске экземпляра процесса ключ не указан, то каждый раз производится старт нового экземпляра процесса.

В конфигурации системы также задается параметр - окно идемпотентности т.е. временной диапазон в который не допустимо создавать экземпляры процессов с одинаковым ключом идемпотентности;

Настройки идемпотентности содержатся в файле application.yml в блоке Engine:

• waitForProcessIdempotenceStarted - время ожидания идемпотентного старта процесса;

• idempotenceMaxRetryCount - максимально допустимое количество retry при идемпотентном старте;

• apiMessageLogInterval - окно идемпотентности.

engine:
   idempotenceMaxRetryCount: 5
   waitForProcessIdempotenceStarted: 200
   apiMessageLogInterval: 3600000

Функциональный StandIn#

Для обеспечения возможности проведения технологических работ с БД без недоступности системы используется механизм функционального StandIn. Данный механизм предполагает наличие двух контуров БД (master и StandIn) и один набор подов sberflow-engine и engine-replica, подключенных к обоим контурам БД.

Master контур используется как основной, StandIn контур как резервный. Sberflow engine осуществляет логическую репликацию данных между контурами БД, используя внешний сервис - Прикладной журнал (далее ПЖ).

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

Диаграмма взаимодействия контуров: Master & StandIn

Для возможности работы платформы Engine в режиме StandIn, необходимо настроить параметры подключение к БД для обоих экземпляров (sberflow-engine и engine-replica) согласно пункту Настройки подключения к БД.

Включение и настройка StandIn осуществляется через секрет engine-appjounalsettings-secret:

• standin.enabled - Вкл/выкл функционального StandIn;

• standin.func.retryEnabled - Вкл\выкл повторов при получении статуса STANDIN\NORMAL;

• standin.func.retryCount - Количество попыток повтора получения статуса STANDIN\NORMAL;

• standin.func.retryBackOffTime - Временной диапазон на повтор получения статуса STANDIN\NORMAL;

• standin.journal-log-expiration-interval - Время жизни записей в таблице с логом векторов;

• journal-log-cleaner-schedule - Выражение в формате cron для job очистки записей из таблицы с логом векторов;

• standin.cloud.client.zoneId - Код зоны в прикладном журнале;

• standin.cloud.client.kafka - Настройки подключения к kafka прикладного журнала;

Пример конфигурации:

standin:
      enabled: true
      func:
        retryBackOffTime: 5000
        retryCount: 18
        retryEnabled: false
      journal-log-expiration-interval: '5 hour'
      journal-log-cleaner-schedule: '0 0 3 * * ?'
      cloud:
        client:
          zoneId: 'SBERFLOW'
          stub: false
          heartBeatPeriod: 1000
          kafka:
            bootstrapServers: 10.116.72.65:9092
            producerConfig:
              "[security.protocol]": SSL
              "[ssl.key.password]": ${SSL_KEY_PASSWORD}
              "[ssl.keystore.location]": /opt/keystore/kafka/server.keystore.jks
              "[ssl.keystore.password]": ${SSL_KEYSTORE_PASSWORD}
              "[ssl.truststore.location]": /opt/keystore/kafka/trust.jks
              "[ssl.truststore.password]": ${SSL_TRUSTSTORE_PASSWORD}
              "[ssl.keystore.type]": JKS
              "[ssl.truststore.type]": JKS
              "[ssl.protocol]": TLS
              "[ssl.enabled.protocols]": TLSv1.2
              "[ssl.endpoint.identification.algorithm]": ~
            consumerConfig:
              "[security.protocol]": SSL
              "[ssl.key.password]": ${SSL_KEY_PASSWORD}
              "[ssl.keystore.location]": /opt/keystore/kafka/server.keystore.jks
              "[ssl.keystore.password]": ${SSL_KEYSTORE_PASSWORD}
              "[ssl.truststore.location]": /opt/keystore/kafka/trust.jks
              "[ssl.truststore.password]": ${SSL_TRUSTSTORE_PASSWORD}
              "[ssl.keystore.type]": JKS
              "[ssl.truststore.type]": JKS
              "[ssl.protocol]": TLS
              "[ssl.enabled.protocols]": TLSv1.2
              "[ssl.endpoint.identification.algorithm]": ~
          concurrency: 10
          groupId: group_1

Настройка spring actuator#

Блок Management содержит настройки spring actuator, необходимые для получения метрик для модуля Контроль инцидентов.

Для настройки доступа к данным spring actuator, необходимо указать порт на котором будут доступны данные: server.port 8888, а также список endpoint по которым необходимо получать данные.

Список метрик приложения

management:
  server: 
    port: 8888 
  endpoints:
    enabled-by-default: false
    web.exposure.include: health,metrics,threaddump,prometheus
  endpoint:
    metrics.enabled: true
    health:
      enabled: true
      show-details: always
    threaddump.enabled: true
    prometheus.enabled: true

Настройка параметров для API#

Список методов пользовательского API доступен для просмотра в Confluence.

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

Дополнительно в файле конфигурации application.yml в блоке API должны быть настроены следующие переменные:

• api.validation.enabled: true – включение валидации http запросов (некорректные запросы будут отброшены сразу с ошибкой 400 не доходя до исполнения);

• api.system.uri – префикс для системных запросов (/system);

• api.user.uri - префикс для пользовательских запросов (/user);

• api.user.validation.enabled - включение валидации для системных запросов;

• api.system.validation.enabled – включение валидации для пользовательских запросов.

api:
 validation: 
   enabled: true
 user: 
   uri: '/user'
   validation: 
     enabled: true
 system:
   uri: '/system'
   validation: 
     enabled: true

Настройка spring части системы#

В файле конфигурации application.yml в блоке spring должны быть настроены следующие переменные:

• spring.flyway.enabled: false – отключает автоматическую конфигурацию flyway, настройки конфигурации будут взяты из блоков datasource и flyway;

• cloud.config.enabled: false –выключение конфигурации через cloud config server (т.е. все настройки будут взяты из текущего файла).

spring:
  flyway:
    enabled: false
  main:
    allow-bean-definition-overriding: true
  cloud:
    config:
      enabled: false

Настройки адаптивного retry#

Подробно работа адаптивного retry описана в "Руководстве прикладного разработчика", раздел Настройка политик повторного вызова, Adaptive

Конфигурирование настроек для адаптивного retry осуществляется через файл application.yml, блок Engine.

Для конфигурирования доступны следующие переменные:

• engine.no.api.wait.time - Время ожидания срабатывания адпативного retry для ошибок тип no api;

• engine.no.api.maximum.time - Максимальное время ограничения адаптивного retry для ошибок типа no api, после которого ограничение по ошибке удаляется с узла;

• engine.no.resources.wait.time - Время ожидания срабатывания адпативного retry для ошибок тип no resources;

• engine.no.resources.maximum.time - Максимальное время ограничения адаптивного retry для ошибок типа no resources, после которого ограничение по ошибке удаляется с узла;

• engine.cron.no.api.wait.time - Расписание срабатывания адпативного retry для ошибок типа no api в формате cron;

• engine.cron.no.resources.wait.time - Расписание срабатывания адпативного retry для ошибок типа no resources в формате cron.

engine:
  noApi:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  noResources:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  cron:
    noApiWaitTime: '0 0/1 * * * ?'
    noResourcesWaitTime: '0 0/1 * * * ?'

Настройка отправки событий истории исполнения процесса#

Настройки отправки событий:

• enableProcessModelEvents - Включение/отключение отправки событий по моделям процессов;

• enableProcessInstanceEvents - Включение/отключение отправки событий по экземплярам процессов;

• enableVariableFiltering - Включение/отключение фильтрации переменных по категории (пример: К1,К2);

• enableVariables - Включение/отключение фильтрации переменных;

• format - Формат событий (none, cloud-events-spec, synapse-eda-spec);

• processInstanceUpdateEventTopic - Имя топика для событий обновления экземпляра процесса;

• processModelUpdateEventTopic - Имя топика для событий изменения модели;

• source - Источник события (в формате URI);

• variableTagsWhiteList - Список меток для фильтрации переменных (пример: К1,К2);

• kafka.producer - Параметры подключения к kafka брокеру:

  • bootstrap-servers - список node kafka кластера (пример: localhost:9093,localhost:9193);

  • client-id - идентификатор клиента, нужен для логирования на стороне брокера;

  • retries - количество повторных попыток отправки сообщения в случае ошибки;

  • buffer-memory - размер буфера отправки сообщений;

  • batch-size - размер пакета сообщений;

  • compression-type - Тип сжатия (none, gzip, snappy, lz4, zstd);

  • acks - Необходимое количество подтверждений для успешной записи;

  • ssl:

    • key-password - пароль от приватного ключа;

    • key-store-location - пусть к хранилищу ключей;

    • key-store-password - пароль от хранилища;

    • key-store-type - тип хранилища;

    • trust-store-location - путь к доверенному хранилищу ключей;

    • trust-store-password - пароль от хранилища;

    • trust-store-type - тип хранилища;

    • protocol - протокол безопасности (TLSv1.2, TLSv1.3).

  • security:

    • protocol - протокол взаимодействия с брокером (PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL).

  • properties:

    • max.block.ms - время для аллокации сообщения в буфере(включая время для получения метаданных от брокера);

    • delivery.timeout.ms - суммарное время ожидания отправки сообщения включая время хранения сообщения в буфере, время подтверждения доставки от брокера(должен быть не менее суммы параметров request.timeout.ms и linger.ms);

    • request.timeout.ms - время ожидания ответа на запрос от брокера;

    • linger.ms - время задержки перед отправкой сообщений из буфера в топик.

engine:
  events:
    enableProcessModelEvents: false
    enableProcessInstanceEvents: false
    enableVariableFiltering: false
    enableVariables: false
    format: none
    processInstanceUpdateEventTopic: process-instance-update-event
    processModelUpdateEventTopic: process-model-update-event
    source: bpms
    variableTagsWhiteList: К1,К2
    kafka:
      producer:
        bootstrap-servers: host1:9093, host2:9093
        client-id: bpms
        retries: 0
        buffer-memory: 1m
        batch-size: 16384
        compression-type: none
        acks: 1
        ssl:
          key-password: secret
          key-store-location: /path/to/key-store.jks
          key-store-password: secret
          key-store-type: JKS
          trust-store-location: /path/to/trusted-store.jks
          trust-store-password: secret
          trust-store-type: JKS
          protocol: TLSv1.2
        security:
          protocol: SSL
        properties:
          max.block.ms: 1000
          delivery.timeout.ms: 10000
          request.timeout.ms: 5000
          linger.ms: 1000

Схема события для процессов#

Схема события для экземпляров процессов#

Настройка интеграции с TaskList#

Настройка подключения к стенду HTM осуществляется через файл application.yml, блок Engine.

Для конфигурирования доступны следующие переменные:

• url стенда HTM;

• url.

htm:
  app:
    url: 'http://htm-portal-test-ci00636574-edevgen-utm.apps.dev-gen.sigma.sbrf.ru/htm-portal'
  engineBalancerHost: 'http://sberflow-engine-dev-ci00636574-edevgen-ts-bpm-dev.apps.dev-gen.sigma.sbrf.ru'

Настройка подключения к grafana#

Настройка подключения к grafana осуществляется через файл application.yml, блок Engine.

Для конфигурирования доступны следующие переменные:

• root - URL сервера grafana;

• orgId.

grafana-config:
  root: 'https://tkles-pprb00078.vm.esrt.cloud.sbrf.ru'
  orgId: 1

Настройка зон для работы Engine#

Создание перечня зон, в которых работает приложение, осуществляется через файл application.yml, блок available-zones.

Для каждой зоны должно быть задано:

• code - Уникальный идентификатор;

• name - Наименование;

• url - адрес сервера на котором развернут дополнительный экземпляр Engine.

available-zones:
  zones:
    - default:
        code: 'DEFAULT_ZONE'
        name: 'DEFAULT'
        url: http://sberflow-engine-dev-ci00636574-edevgen-ts-bpm-dev.apps.dev-gen.sigma.sbrf.ru

dynamic-invoker#

Параметр конфигурации равертывания системы:

• useBootstrap: true - Использовать bootstrap class loader для загрузки классов;

• useBootstrap: false - Использовать springBoot для загрузки классов.

dynamic-invoker:
  useBootstrap: false

Настройки работы с JOB#

Описание JOB и работа с ними описана в "Руководстве разработчика", п.Работа с job

Настройки работы с JOB осуществляются через файл application.yml, блок Engine.

Общие настройки для работы с job:

• resetExpiredJobsPageSize - количество job в «пачке» для возвращения в общую очередь;

• maxAsyncJobsDuePerAcquisition - размер «пачки» job, которые будут исполняться на одном ядре;

• asyncExecutorThreadPoolSize - размер пула потоков для исполнения jobs из таблицы JOB;

• activityAsyncExecutorMinThreadPoolSize - размер пула потоков для исполнения всех типов job кроме StatelessAsyncJobs;

• executeProcessMinThreadPoolSize - минимальное значение пула потоков для stateless jobs.

Настройки для таблицы InsertLockJob:

• insertJobLockExpirationTime - время исполнения InsertLockJobs в рамках одного ядра, по истечении которого lockExpirationTime и lockOwner будут сброшены для тех InsertLockJobs, где lockExpirationTime истекло;

• resetExpiredInsertLockJobsInterval - интервал сканирования сбрасывания lockExpirationTime и lockOwner

Настройки для таблицы TimerJob:

• timerJobAcquireWaitTimeInMillis - интервал(мс) сканирования Timer Jobs;

• asyncExecutorTimerLockTimeInMillis - время(мс) в пределах которого исполняются timerJobs, в рамках одного ядра.

Настройки для таблицы RetryPolicyJob:

• retryPolicyJobInterval - интервал(мс) сканирования retryPolicyJob;

• resetExpiredRetryPolicyJobsInterval - интервал(мс) сканирования сбрасывания lockExpirationTime и lockOwner для Retry Policy Jobs.

Настройки для таблицы Job:

• statelessResetExpiredJobsInterval - интервал(мс) сканирования сбрасывания lockExpirationTime и lockOwner для Stateless Async Jobs;

• statelessAsyncJobAcquireWaitTimeInMillis - интервал(мс) сканирования Stateless Async Jobs;

• JobLockExpirationTime - время исполнения Job в рамках одного ядра по истечении которого lockExpirationTime и lockOwner будут сброшены для всех Job в таблице кроме Stateless Async Jobs;

• asyncExecutorResetExpiredJobsInterval - интервал(мс) сканирования сбрасывания lockExpirationTime и lockOwner для Stateless Async Jobs.

engine:
  asyncExecutorResetExpiredJobsInterval: 10000
  insertJobLockExpirationTime: 1200000
  
  maxAsyncJobsDuePerAcquisition: 5
  resetExpiredJobsPageSize: 1000
  asyncExecutorThreadPoolSize: 10
  activityAsyncExecutorMinThreadPoolSize: 1
  jobLockExpirationTime: 1200000


  resetExpiredRetryPolicyJobsInterval: 10000
  resetExpiredInsertLockJobsInterval: 10000
  retryPolicyJobInterval: 10000
  
  statelessAsyncJobAcquireWaitTimeInMillis: 10000
  statelessResetExpiredJobsInterval: 10000
  
  timerJobAcquireWaitTimeInMillis: 10000
  asyncExecutorTimerLockTimeInMillis: 1200000
  asyncJobAcquireWaitTimeInMillis: 10000

Настройка трейсинга#

Структура идентификаторов OpenTracing должна позволять отслеживать информацию по бизнес процессам, исполняемым в среде исполнения Engine. Информация должна позволять понять, в рамках исполнения какого процесса, и на каком шаге, был сделан тот или иной удаленный вызов. Для обеспечения такой возможности стандартизирована трансляция определенных HTTP заголовков из входящих запросов в среду исполнения Engine во все исходящие вызовы, реализованные с помощью поддерживаемых протоколов интеграции. Заголовки трейсинга будут сгруппированы в переменной контекста tracingHeaders.

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

• REST API;

• JSON-RPC API;

• MMT API.

Настройки работы трейсинга осуществляются через файл application.yml, блок tracing.

Общие настройки для работы трейсинга:

• enabled - включение/выключение трейсинга;

• url - URL трейсинг-коллектора;

• name - наименование элемента трейсинга;

• spanKind - вид спана;

• responseSuccessCode - код успешного ответа от сервера;

• apiVersion - версия апи системы трейсинга;

• threadCount - размер пула потоков для отправки сообщений трейсинга.

Настройки фильтрации заголовков:

• useUFSHeaders - использование заголовков ufs-*;

• useMTHeaders - использование заголовков x-mt-*;

• useBaseHeaders - использование заголовков x-*;

• useX3Headers - использование заголовков x-b3-*;

• connectTimeout - таймаут (мс) для подключения к span-коллектору;

• readTimeout - таймаут (мс) для получения ответа от span-коллектора.

tracing:
  enabled: true
  url: http://some-host:8080/
  name: BPMS
  spanKind: CLIENT"
  responseSuccessCode: 202
  apiVersion: 2
  threadCount: 20
  useUFSHeaders: true
  useMTHeaders: true
  useBaseHeaders: true
  useX3Headers: true
  readTimeout: 30
  connectTimeout: 30

Транслируемые заголовки#

Блок Engine (Черновик)#

Настройки мониторинга:

• mbpEnabled - Вкл/выкл отправки точек мониторинга в систему мониторинга бизнес процессов;

Настройки cci (межкластерный индекс):

• cciIndexesEnabled - Вкл/выкл отправки process definition key в cci;

Настройки исполнения процессов:

• mmtTaskEnabled - Вкл/выкл функционала MMT task (Включает возможность загрузки моделей с наличием mmt task);

• databaseSchemaUpdate - Режим автоматического обновления/удаления схемы данных (при работе с Flyway необходимо указать false; drop-create - поддерживается);

• asyncExecutorActivate - Вкл/выкл асинхронных задач;

• processOwnerRestrictionEnabled - Вкл/выкл функционала Владелец процесса (ограничивает область видимости процессов для администраторов.

Настройки кеша:

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

• availableTaskCountCacheMaxSize - Максимальное количество значений в кеше с данными о количестве доступных пользовательских задачах.

Настройки пула:

• springAsyncExecutorPoolSize - Размер пула потоков для Srping async executor (используется для подготовки сообщений в StandIn);

• springAsyncExecutorPoolQueueCapacity - Размер очереди сообщений пула потоков для Srping async executor (используется для подготовки сообщений в StandIn).

engine:
  activityAsyncExecutorMinThreadPoolSize: 1
  apiMessageLogInterval: 3600000
  asyncExecutorActivate: true
  asyncExecutorResetExpiredJobsInterval: 10000
  
  asyncExecutorTimerLockTimeInMillis: 1200000
  asyncJobAcquireWaitTimeInMillis: 10000
  availableTaskCountCacheMaxSize: 1000
  availableTaskCountCacheTimeToLiveInMilliseconds: 60000
  cciIndexesEnabled: true
  classLoaderScannerIntervalInMilliseconds: 30000
  cleaner:
    batchSize: 1000
    byteArrayCleanEnable: true
    cron: '0 2 * * * SAT'
    depth: 30
    enable: false
    mode: 'BPMSHISTORICIDENTITYLINKENTITYIMPL,BPMSHISTORICEXTRAATTRIBUTEENTITYIMPL,BPMSIDENTITYLINKENTITYIMPL,BPMSVARIABLEINSTANCEENTITYIMPL,BPMSEXTRAATTRIBUTEENTITYIMPL,BPMSHISTORICVARIABLEINSTANCEENTITYIMPL,BPMSHISTORICACTIVITYINSTANCEENTITYIMPL,BPMSEVENTSUBSCRIPTIONENTITYIMPL,HISTORICRETRYPOLICYENTITYIMPL,BPMSEXECUTIONENTITYIMPL,BPMSJOBENTITYIMPL,BPMSTIMERJOBENTITYIMPL,MULTIINSTANCECOUNTERIMPL,BPMSTASKENTITYIMPL,RETRYPOLICYJOBENTITYIMPL,BPMSHISTORICTASKINSTANCEENTITYIMPL,BPMSBYTEARRAYENTITYIMPL,BPMSHISTORICDETAILENTITYIMPL,BPMSHISTORICPROCESSINSTANCEENTITYIMPL'
  cron:
    noApiWaitTime: '0 0/1 * * * ?'
    noResourcesWaitTime: '0 0/1 * * * ?'
  databaseSchemaUpdate: false
  executeJobThreadPoolThrottlingMark: 80
  executeNewJobThreadPoolThrottlingMark: 50
  executeNewProcessThreadPoolThrottlingMark: 50
  executeProcessMinThreadPoolSize: 1
  executeProcessThreadPoolSize: 135
  executeProcessThreadPoolThrottlingMark: 80
  executionMode: 'STICKY'
  namepsaceURL: ''
  htm:
    enabled: true
  idempotenceMaxRetryCount: 5
  insetJobLockExpirationTime: 1200000
  jdbcPoolThrottlingMark: 80
  jdbcPoolThrottlingMarkForNewProcesses: 50
  jobLockExpirationTime: 1200000
  maxDepthForScanner: 10
  maxAsyncJobsDuePerAcquisition: 5
  mbpEnabled: true
  mmtTaskEnabled: true
  noApi:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  noResources:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  persistPoints: 'StartEvent,UserTask,IntermediateCatchEvent,ReceiveTask,ServiceTask'
  processOwnerRestrictionEnabled: false
  resetExpiredJobsInterval: 10000
  resetExpiredJobsPageSize: 1000
  resetExpiredRetryPolicyJobsInterval: 10000
  resetExpiredInsertLockJobsInterval: 10000
  retryPolicyJobInterval: 10000
  springAsyncExecutorPoolQueueCapacity: 15
  springAsyncExecutorPoolSize: 10
  statelessAsyncJobAcquireWaitTimeInMillis: 10000
  statelessResetExpiredJobsInterval: 10000
  throttlingEnable: false
  throttlingStateIntervalInMilliseconds: 5000
  timerJobAcquireWaitTimeInMillis: 10000
  waitScannerTimeAfterNoWait: 200
  waitForProcessIdempotenceStarted: 200

Использование компонента#

Доставка моделей процессов#

Общая схема#

Дев стенды#

Загрузка моделей выполняется через curl (или аналогичные инструменты, которые позволяют передавать файлы), пример команды:

curl -F "name=@АРХИВ_С_МОДЕЛЯМИ.zip" http://ХОСТ:ПОРТ/activiti-rest/service/repository/deployments --user kermit:kermit

Формат поставки#

Плоский zip архив с XML моделями процесса Для поставки дистрибутива в платформу, архив с моделями должен находиться в каталоге <other/bpmModels.zip>.

Интеграция с внешними системами#

Аудит#

В связи с требованиями безопасности необходимо осуществлять передачу информации о произведенных действиях в АС Аудит.

Для настройки отправки сообщений в модуль «Аудит» необходимо в файле application.yml определить следующие переменные:

Взаимодействие производится через Rest API.

Среда исполнения осуществляет отправку следующих данных для фиксации события в АС Аудит:

1. Метамодель;

2. Событие.

Вызываемое АПИ зависит от режима работы Аудит (с поддержкой мультитенантности/ без поддержки мультитенантности):

• Регистрация метамодели. В режиме мультиинстанс регистрация метамодели должны быть произведена разово для каждого потребителя (каждого уникального resourceName):

  • http://audit2-client-proxy.apps.test-ose.ca.sbrf.ru/v1/metamodel;

  • http://audit2-client-proxy.apps.test-ose.ca.sbrf.ru/v1/rn/{rn}/metamodel;

• Отправка события:

  • http://audit2-client-proxy.apps.dev-gen.sigma.sbrf.ru/v1/event;

  • http://audit2-client-proxy.apps.dev-gen.sigma.sbrf.ru/v1/rn/{rn}/event.

Метамодель

curl -X POST http://audit2-client-proxy.apps.test-ose.ca.sbrf.ru/v1/metamodel -d @proxy-metamodel.json -H "Content-Type: application/json"

Пример содержимого proxy-metamodel.json (метамодель):

{
  "metamodelVersion": "00001",
  "module": "test_proxy_module",
  "description": "Тестовый модуль для тестирования proxy-приложения",
  "events": [
    {
      "name": "test-name-1",
      "description": "Тестовое событие №1",
      "success": true,
      "mode": "speed",
      "params": [
        {
          "name": "test-name-11",
          "description": "Тестовый параметр 1 события 1"
        }
      ]
    }
  ]
}

Событие

curl -X POST http://audit2-client-proxy.apps.dev-gen.sigma.sbrf.ru/v1/event -d @proxy-event.json -H "Content-Type: application/json"

Пример proxy-event.json (событие)

{
  "metamodelVersion": "00001",
  "name": "test-name-1",
  "session": "test_user_ticket:1234567987987987",
  "module": "test_proxy_module",
  "createdAt": 1585198271185,
  "userLogin": "test-proxy-user",
  "userName": "Иванов Иван Иванович",
  "userNode": "proxy-audit",
  "params": [
    {
      "name": "test-name-11",
      "value": "Значение параметра 1 события 1"
    }
  ],
  "tags": [
  "tag 1",
  "tag 2",
  "tag 3"
]
}

Журналирование#

Протоколирование операций для их дальнейшего анализа осуществляется в следующую директорию:

DloggingDir = home/logs
DloggingJSONFile = log.json

Для отправки событий журнала в Logger, sidecar-контейнер должен быть подключен к тому же каталогу, что обеспечит ему возможность чтения и обработки событий.

Для корректного разбора событий необходимо, чтобы формат событий соответствовал шаблону разбора fluent-bit. Формат событий описан в xml-файле конфигурации для библиотеки logback-spring.xml.

Для режима multiinstance файл logback-spring.xml содержит дополнительные атрибуты:

• RN- идентификатор ресурса (тип строка) - содержится в конфигурации экземпляра;

• CN из сертификата потребителя (тип строка) - содержится в конфигурации экземпляра;

• traceId - идентификатор трейса, с которым связан лог (тип строка), получение из заголовка x-b3-traceid.

Запись лога производится в json формате и требует подключения зависимости в pom.xml:

<dependency>
<groupId>net.logstash.logback</groupId>
<artifactId>logstash-logback-encoder</artifactId>
<version>6.3</version>
</dependency>

Интеграция с MMT (mmt-envoy) (опционально)#

В проекте ose необходимо развернуть proxy mmt envoy.

Template OpenShift envoy входит в поставку дистрибутива и требует:

1. Подготовку секретов с сертификатами:

   • envoy-secret - включает сертификаты envoy;

   • fluent-bit-sct - включает сертификаты подключения к брокерам кафки логгера;

2. Настройку стендозависимых параметров:

   • NAMESPACE - Имя namespace в котором разворачивается дистрибутив, берется из job. При использовании install_eip можно дополнительно не указывать;

   • CONTROL_PLANE - адрес control-plane (<имя сервиса control-plane>.<имя namespace control-plane>.svc.cluster.local) - Адреса подключений можно посмотреть на странице;

   • CONTROL_PLANE_PORT=8888 - порт control-plane;

   • BROKERS - брокеры Kafka логгер. адреса можно посмотреть на странице;

   • CLUSTER_NAME - Имя кластера OS (в формате dev-gen или dev-gen2);

Для работы интеграции htm-bridge с envoy mmt необходимо в jvm опциях htm указать адрес envoy на стенде: -Dtransport.url.endpoint=<envoy_route>/pprb-mmt

Интеграция с Прикладным журналом (опционально)#

Интеграция с Прикладным журналом осуществляется через kafka.

Для работы с ПЖ необходимо настроить подключение к kafka используя секрет engine-appjounalsettings-secret

Пример настройки:

standin:
      enabled: true
      func:
        retryBackOffTime: 5000
        retryCount: 18
        retryEnabled: false
      journal-log-expiration-interval: '5 hour'
      journal-log-cleaner-schedule: '0 0 3 * * ?'
      cloud:
        client:
          zoneId: 'SBERFLOW'
          stub: false
          heartBeatPeriod: 1000
          kafka:
            bootstrapServers: 10.116.72.65:9092
            producerConfig:
              "[security.protocol]": SSL
              "[ssl.key.password]": ${SSL_KEY_PASSWORD}
              "[ssl.keystore.location]": /opt/keystore/kafka/server.keystore.jks
              "[ssl.keystore.password]": ${SSL_KEYSTORE_PASSWORD}
              "[ssl.truststore.location]": /opt/keystore/kafka/trust.jks
              "[ssl.truststore.password]": ${SSL_TRUSTSTORE_PASSWORD}
              "[ssl.keystore.type]": JKS
              "[ssl.truststore.type]": JKS
              "[ssl.protocol]": TLS
              "[ssl.enabled.protocols]": TLSv1.2
              "[ssl.endpoint.identification.algorithm]": ~
            consumerConfig:
              "[security.protocol]": SSL
              "[ssl.key.password]": ${SSL_KEY_PASSWORD}
              "[ssl.keystore.location]": /opt/keystore/kafka/server.keystore.jks
              "[ssl.keystore.password]": ${SSL_KEYSTORE_PASSWORD}
              "[ssl.truststore.location]": /opt/keystore/kafka/trust.jks
              "[ssl.truststore.password]": ${SSL_TRUSTSTORE_PASSWORD}
              "[ssl.keystore.type]": JKS
              "[ssl.truststore.type]": JKS
              "[ssl.protocol]": TLS
              "[ssl.enabled.protocols]": TLSv1.2
              "[ssl.endpoint.identification.algorithm]": ~
          concurrency: 10
          groupId: group_1

Обновление сервиса#

Обновление БД с помощью flyway#

Установка базовой линии:

1. Выкачать дистрибутив flyway;

2. Настроить его на работу с БД под владельцем схемы BPMS;

3. Выполнить команду: flyway -user=BPMS -password=ПАРОЛЬ_ХОЗЯИНА_СХЕМЫ -url=jdbc:oracle:thin:@ХОСТ_СУБД:1521:SID_СУБД baseline;

4. Проверить создание таблицы с историей: select * from BPMS."flyway_schema_history".

Обновление БД:

1. Выкачать дистрибутив flyway;

2. Настроить его на работу с БД под владельцем схемы BPMS;

3. Выполнить команду: flyway -user=BPMS -password=ПАРОЛЬ_ХОЗЯИНА_СХЕМЫ -url=jdbc:oracle:thin:@ХОСТ_СУБД:1521:SID_СУБД -locations=filesystem:ПРИМЕР/path/to/distrib/sql/flyway/update/folder migrate;

4. Проверить наличие актуальных версий в таблице с историей: select * from BPMS."flyway_schema_history".

Настроить конфигурационные параметры в файле application.yml,

• блок flyway:

  • enabled - Управление запуском обновления схемы баз данных Master и StandIn при старте приложения;

  • readonlyUser - Настройка пользователя с правами доступа к базе данных Master и StandIn в режиме чтения;

• блок engine:

  • databaseSchemaUpdate - Режим автоматического обновления/удаления схемы данных (при работе с Flyway необходимо указать false);

• блок spring:

  • spring.flyway.enabled: false – отключает автоматическую конфигурацию flyway, настройки конфигурации будут взяты из блоков datasource и flyway.

flyway:
  master:
    readonlyUser: BPMS_READONLY
  migrationEnabled: true
  standin:
    readonlyUser: BPMS_READONLY

События системного журнала#

Все события, собираемые приложением во время работы, публикуются в АС Аудит и Журналирование.

События мониторинга#

В режиме мультиинстанс метрики отвечающие за работу приложения (Engine/Tasklist) дополнены:

• rn - соответствует resourceName потребителя.

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

Часто встречающиеся проблемы и пути их устранения#

Не выявлено.

Сценарии связанные с администрированием Engine Platform V Flow описаны в данном руководстве.