Важные изменения

Примечание

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

Версия 2.8

1. Хранение вершин и ребер в OrientDB

Изменен принцип хранения вершин и ребер в OrientDB.

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

Теперь для всех классов вершин создается один класс в OrientDB (record_), для всех классов ребер создается один класс в OrientDB (relation_). Таким образом все вершины/ребра независимо от их класса сохраняются в один класс в OrientDB (record_/relation_).

Важно: После обновления системы до версии 2.8 необходимо запустить операцию "Задача переиндексации DG" со следующими включенными параметрами:

  • Писать лог ошибок;

  • Проиндексировать активы;

  • Обновить маппинги графа;

  • Очищать граф;

  • Проиндексировать связи.

2. Оптимизация механизма истории запусков сканеров

  • Переработан механизм учета истории запусков сканеров. Новый механизм Scanner Log сохраняет только факты изменений активов и связей физического слоя (создание, обновление, удаление).

    • Таблица лога активов - org_unidata_dg_data.asset_logs.

    • Таблица лога связей - org_unidata_dg_data.relation_logs.

    • Данные старых таблиц снэпшотов запусков org_unidata_dg_data.asset_snapshots и org_unidata_dg_data.relation_snapshots, а также индекса default_default_snapshots сохранены, но обновляться не будут. Таблицы и индекс будут удалены в следующих релизах.

  • Реализована миграция снэпшотов запусков на новый механизм логов.

    • Важно: Мигрируется только актуальное состояние активов и связей ИС. Результаты старых запусков после обновления станут недоступны.

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

    • Операции удаления и очистки работают на вычисляемых по логу снэпшотах ИС.

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

3. Доработка моделей краулеров и объектов физического слоя

  • Добавлена поддержка тегов физического слоя для типов связей и вложенных объектов. Теперь теги поддерживают объекты: типы активов, вложенные объекты, связи и типы связей, а также атрибуты типов активов, вложенных объектов и связей.

  • Запрещена возможность создания дочерних типов активов бизнес слоя (созданных пользователем без тега layer:physical) для типов активов из физического слоя.

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

Версия 2.7

  1. Сортировка без выбранного актива

Добавлена индексация отображаемых имен активов и их типов (поля $display_name, $type_display_name). После индексации в поиске по активам доступен поиск и сортировка по отображаемым именам.

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

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

Проверка доступна по rest-запросу /v1/meta/model/draft-warnings.

  1. Обновление OrientDB с версии 3.2.4 до 3.2.23

Варианты обновления:

Примечание

В любом из вариантов рекомендуется выполнить экспорт БД перед обновлением.

  1. С помощью Docker / Локальная установка с выделенной директорией для хранения данных

  • С помощью Docker - действий при обновлении не требуется.

  • Локальная установка - при установке новой версии необходимо указать в ${ORIENTDB_HOME}/config/orientdb-server-config.xml путь к директории с данными.

<properties>
   <entry name="server.database.path" value="/opt/homebrew/var/db/orientdb" />
</properties>

  1. Локальная установка без выделенной директории для хранения данных

Если OrientDB установлен локально без выделенной директории для хранения данных (данные хранятся в ${ORIENTDB_HOME}/databases), то возможны два варианта обновления:

../../_images/image0025.png

  • Экспорт и импорт БД:

Перед обновлением необходимо выполнить экспорт БД через консоль OrientDB. Пример:

  1. Запустите консоль OrientDB:

    ${ORIENTDB_HOME}/bin/orientdb-console.sh

  2. Выполните подключение к БД:

    connect remote:{host}:{port}/{db_name} {user} {password}

    Пример:

    connect remote:localhost:2424/dg root root

  3. Запустите экспорт БД:

    export database {path_to_export_file}

    Пример:

    export database dg.export

После установки новой версии OrientDB необходимо создать новую БД и выполнить импорт:

  1. Запустите консоль OrientDB:

    ${ORIENTDB_HOME}/bin/orientdb-console.sh

  2. Выполнить подключение к БД:

    connect remote:{host}:{port}/{db_name} {user} {password}

    Пример:

    connect remote:localhost:2424/dg root root

  3. Запустить импорт БД:

    import database {path_to_export_file}

    Пример:

    import database dg.export

  1. Управление статусами вручную через REST

  • Получение списка доступных ручных переходов согласно таблице переходов:

    GET v1/data-status/manual

Параметры: идентификация объекта (namespace, typeName, subject)

  • Переход к выбранному статусу:

    POST v1/data-status/manual

Параметры: идентификация объекта (namespace, typeName, subject), идентификатор выбранного статуса (status), флаг принудительного перехода (force).

Версия 2.6

  1. Обновление прав пользователя без выхода из системы

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

  • Если пользователь обновляет собственные настройки, то изменения автоматически обновятся на UI.

  • Еcли пользователь обновляет настройки другого аккаунта, то на экране пользователя, имеющего активную сессию, отобразится модальное окно с возможностью принять обновления (Рисунок 1).

Модальное окно с уведомлением об изменениях

Рисунок 1 – Модальное окно с уведомлением об изменениях

  1. Переход с Elasticsearch на OpenSearch с сохранением данных аудита

В инструкцию по переходу с Elasticsearch на Opensearch добавлены дополнительные шаги для сохранения данных аудита. Ознакомьтесь с действиями, которые необходимо выполнить.

  1. Дополнительные события аудита

При обновлении системы с существующей БД новые события аудита будут доступны только после выполнения следующих действий:

  • В параметр системы "Хранилище журнала аудита" (org.unidata.mdm.core.audit.enabled.storages) добавьте значение "index".

  • Обновите пути аудита "Маршруты сообщений модуля Core" (org.unidata.mdm.system.messaging.domains.core-messaging) из core.xml.

  1. Изменения в бизнес-процессах, требующие обновления

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

Версия 2.5

  1. Обновление модели данных, имеющей вложенные типы связей

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

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

  1. Измените направление вложенных типов связей на "Однонаправленная".

  2. Изменить параметр "Кардинальность" всех связей с вложенными типами на x:1.

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

  4. Опубликуйте черновик модели данных.

  5. Запустите операцию "Задача переиндексации DG" со всеми включенными параметрами (флаги Писать лог ошибок и Обработать лог ошибок могут быть включены по желанию).

  1. Миграция с Elasticsearch на OpenSearch

Предупреждение

В релизе 2.5 Юниверс DG перешла с Elasticsearch на OpenSearch. Появились изменения публичного API

  • Изменилась сигнатура org.unidata.mdm.search.service.SearchService#setIndexSettings. Настройки передаются как IndexSettings, а не Map<String, Object>. Пример использования нового класса: org.unidata.mdm.job.reindex.service.impl.ReindexDataJobPrepareItemWriter#PREPARE_INDEX_PARAMS.

  • org.unidata.mdm.search.service.impl.AdminComponentImpl#getNodesInfo переименован в org.unidata.mdm.search.service.impl.AdminComponentImpl#getNodesCount и возвращает число узлов. Если необходима остальная информация по узлам, требуется доработка.

  • Конструкторы AdminComponentImpl, SearchComponentImpl и SearchServiceImpl принимают org.unidata.mdm.search.service.impl#OpenSearchClientWrapper вместо org.elasticsearch.client.Client.

  • Изменен класс, возвращаемый protected-методами BaseComponentImpl.

  • Изменен класс, возвращаемый public-методами SearchComponentImpl. Обработкой таких значений занимается org.unidata.mdm.search.service.impl.SearchServiceImpl#extractSearchResult(org.unidata.mdm.search.context.SearchRequestContext, java.util.List<org.universe.opensearch.client.opensearch.core.SearchResponse<com.fasterxml.jackson.databind.node.ObjectNode>>).

  • В параметре org.unidata.mdm.core.audit.enabled.storages изменено одно из возможных значений: es → index.

  1. Проверки аутентификации по имени пользователя и IP адресу

В релизе 2.5 была добавлена задача по очистке старых паролей, а также проверки аутентификации пользователей.

При установке системы с нуля или обновлении с более старых версий необходимо в файл backend.properties внести параметр org.unidata.mdm.core.job.clean.inactive.passwords.cronex или INACTIVE_PASSWORD_CLEAN_JOB_CRONEX переменную среды контейнера для запуска очистки паролей.

Остальные параметры доступны для редактирования через UI и не требуют дополнительной записи в файл.