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

Примечание

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

Версия 2.10

Обновление PostgreSQL

PostgreSQL обновлен с версии 12 до 16.3, в связи с этим теперь требуется обязательная установка расширения TimescaleDB. См. подробнее в инструкциях по ручному обновлению и с помощью Docker.

Обновление Opensearch

Opensearch обновлен с версии 2.7.0 на версию 2.14.0. Подробнее см. в инструкциях по обновлению вручную и с помощью Docker.

Обновление OrientDB

• OrientDB обновлен с версии 3.2.23 до версии 3.2.32. Подробнее см. в инструкции по обновлению вручную.

Пароли БД

В URL подключения datasource используется пароль, который отображается в разделе "Параметры системы", что является небезопасным.

Для решения проблемы был создан PasswordService, который при инициализации получает все пароли из backend.properties с префиксом org.unidata.mdm.system.password и заменяет плейсхолдер пароля вида #[your value] на значение пароля.

Например, для параметра:

org.unidata.mdm.system.datasource.url=jdbc:postgresql://${POSTGRES_ADDRESS}/${DATABASE_NAME:postgres}?user=${POSTGRES_USERNAME}&password=#[org.unidata.mdm.system.password.postgres]&currentSchema=org_unidata_mdm_system,public&ApplicationName=Unidata-System

Если установка системы производилась вручную, и в файле backend.properties присутствуют пароли, то их можно вынести как свойства с префиксом org.unidata.mdm.system.password и использовать #[...] в местах использования паролей.

Если установка производилась через Docker, то никакие дополнительные действия не требуются.

Также реализован обработчик для паролей PostgreSQL, который возвращает пароль в url-encoded формате. Это позволяет использовать специальные символы в пароле:

org.unidata.mdm.system.password.postgres=${POSTGRES_PASSWORD}

Расширенное логирование краулеров

Доработано логирование запросов и ответов краулеров DIS. Теперь при запросе к серверам DIS происходит логирование с указанием URL и параметров запроса. Также в случае ошибки при запросе также добавлено логирование с указанием URL и параметров запроса.

Параметры запроса: crawlerType, count (page count), from (page starts from), runId.

Поиск по справочникам

Все справочники индексируются в новый индекс [dg_lookup] аналогично типам активов, атрибуты индексируются по шаблону [имя_справочника]#[имя_атрибута] : значение.

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

См.также

REST-модуля поиска по единому индексу справочников.

Версия 2.9

1. Обновление системных требований

Зависимость TimescaleDB теперь обязательна для работы системы.

2. Изменение формата хранения файловых массив-атрибутов

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

3. Доработка AssignedProcessesFilter

Для точки расширения типа AssignedProcessesFilter (функция кастомной фильтрации назначенных на актив бизнес-процессов) в качестве аргумента был добавлен processSettingsStore, что позволяет при помощи processSettingsStore.getList в функции фильтрации получить список всех бизнес-процессов, имеющихся в системе.

4. Отображение доп. параметров

Улучшено отображение длинных значений доп. параметров различных объектов системы. Если значение не помещается в ячейку таблицы, то у ячейки появится всплывающая подсказка, отображающая полностью ее содержимое (Рисунок 1).

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

Изменения касаются свойств актива/справочника, свойств связей и типов связей, источников данных, перечислений, единиц измерения. Изменения НЕ применялись в дополнительных параметрах разделов "Пользователи" и "Роли".

Рисунок 1 – Отображение длинных значений доп. параметров

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

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

6. Объединение reindexDataJob и reindexDgDataJob

Операция переиндексации ДГ reindexDgDataJob объединена со стандартной операцией переиндексации reindexDataJob.

Если в системе ранее была создана операция reindexDGDataJob, то после обновления системы до новой версии все инстансы операции будут удалены.

Для сохранения информации о таких операциях рекомендуется перед обновлением провести экспорт операций в JSON файл с помощью кнопки "Экспорт" в разделе "Операции". Далее при обновлении необходимо вручную (в случае необходимости) создать новые операции с нужными параметрами.

Необходимо учесть, что если для каких-то других операций reindexDGDataJob была звеном цепочки (т.е. автоматически запускалась после успешного/неудачного завершения), то информация об этом не будет экспортирована, а цепочки при обновлении на новую версию будут разорваны.

7. Поиск записей по синонимам значений атрибутов

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

Если Opensearch установлен локально, то необходимо добавить файл synonyms.txt в ${OPENSEARCH_HOME}/config/.

Подробнее о настройке синонимов см. в статье.

Версия 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.

2. Обновление 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), то возможны два варианта обновления:

• Восстановление данных через операцию переиндексации данных со следующими параметрами:

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

Перед обновлением необходимо выполнить экспорт БД через консоль 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
   

3. Управление статусами вручную через 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 – Модальное окно с уведомлением об изменениях

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

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

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

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

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

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

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

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

Версия 2.5

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

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

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

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

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

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

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

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

2. Миграция с 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.

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

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

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

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