Skip to content

Інтеграція BI

В прикрепленном архиве готовый Docker Compose файл bi_mirror_client.tar.gz ссылки из описания относяться к содержимому архива

Обзор

Docker Compose конфигурация mirror-clients для обеспечения интеграции с qlik

Интеграция выглядит следующим образом

Qlik <-- MongoDB <--> Mirror Client <-- Mirror Service

Взаимодействие Mirror Client <-- Mirror Service требует авторизации посредством установки AUTH_TOKEN

CDB Mirror Service представлен отдельными сервисами для синхронизации объектов процедур/реестров/джобера.

В docker-compose.yml они также представлены разными сервисами

  • procedures_client
  • procedures_dgf_client
  • registry_client
  • jobber_client

Но при этом взаимодействуют в одной MongoDB и складывают информацию в разные коллекции.

Запуск

Запуск может производиться на несколько окружений PROD/NON_PROD

Для запуска требуется установить переменные окружения:

  • AUTH_TOKEN - токен авторизайии
  • CLIENT_DATABASE_NAME - название Mongo базы данных
  • CLIENT_DATABASE_USERNAME - имя пользователя Mongo базы данных
  • CLIENT_DATABASE_PASSWORD - пароль пользователя Mongo базы данных

Сделать это можно либо записав его в файл соответствующего окружения .env.non_prod или .env.prod.

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

export AUTH_TOKEN=....
export CLIENT_DATABASE_NAME=....
export CLIENT_DATABASE_USERNAME=....
export CLIENT_DATABASE_PASSWORD=....

После задания переменных, можно непосредственно запустить mirror-clients выполнив:

  • docker-compose --env-file ./.env.non_prod up -d - NON_PROD
  • docker-compose --env-file ./.env.prod up -d - PROD

Сервисы настроены на автоматический перезапуск при возникновении проблем

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

Файлы .env**** содержат в себе переменные окружения необходимые для запуска

  • AUTH_TOKEN - токен авторизайии
  • MIRROR_SERVER_DOMAIN - домен базовой инсталяции CDB
  • MIRROR_SERVER_DOMAIN_DGF - домен DGF инсталяции CDB
  • CLIENT_DATABASE_NAME - название Mongo базы данных
  • CLIENT_DATABASE_USERNAME - имя пользователя Mongo базы данных
  • CLIENT_DATABASE_PASSWORD - пароль пользователя Mongo базы данных
  • AUTO_WIPE_DATA - автоматическая очистка при отставании синхронизации (не требует изменений)
  • STARTUP_DELAY - задержка в секундах до старта синхронизации (не требует изменений)

Ручная пересинхронизация

Если возникает необходимость для ручной пересинхронизации, например по какой-то причине (одному богу известной) нет каких-то объектов, то необходимо запустить следующую команду

  • docker-compose -f resync-docker-compose.yml --env-file ./.env.non_prod up -d - NON_PROD
  • docker-compose -f resync-docker-compose.yml --env-file ./.env.prod up -d - PROD

При этом базовый запуск сервисов mirror-clients не надо трогать, они должны в запушеном ранее состоянии

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

Mongo коллекции и соотношение Search API endpoints к коллекциям.

Имена Mongo коллекций, в которые помещаются объекты всегда можно увидить/изменить в конфигурационных файлах

за это отвечает значение db_collection в секции каждого объекта синхронизации.

Значение db_ts_collection и соответствующие Mongo коллекций (в названии колекции присутствует окончание _ts), являются служебными и не требуют вмешательства

В данном конфигурации будут созданы следующие коллекции содержащие информацию для qlik:

Итерирование объектов в Mongo коллекциях

Search API endpoints принимали дату в url и производили итерацию под капотом. При работе с Mongo необходимо будет использовать следующие запросы:

  • для объектов процедур

    db.procedures.find({"_meta.systemDateModified": {$gte: new ISODate("2012-01-12T20:15:31Z")}}).sort({"_meta.systemDateModified":1})

  • для остальных объектов (временно пока они не перешли на использование _meta.systemDateModified)

    db.registry.find({"dateModified": {$gte: new ISODate("2012-01-12T20:15:31Z")}}).sort({"dateModified":1})

Edited by Pavel Kuzmenko