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

Версия 6.12

Пароли БД¶

В 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}

Версия 6.11

В Юниверс MDM версии 6.11 было осуществлено обновление PostgreSQL до версии 16.3, в связи с этим теперь требуется обязательная установка расширения TimescaleDB для корректной работы с большими объемами данных. В зависимости от вашей ОС, проверьте шаги установки TimescaleDB в руководстве по установке системы. Перед установкой рекомендуется проверить совместимость вашей версии PostgreSQL и версии TimescaleDB.

Важные проблемы версии 6.11

Некорректно объединяются записи с удаленными связями/классификациями. Поведение будет исправлено в следующих релизах.
При сопоставлении отсутствующая классификация/связь равнозначна незаполненному атрибуту классификации/связи (т.е. затронуты ситуации, когда матчинг настроен по атрибуту классификации/связи и в правиле включено сопоставление по null). Поведение будет исправлено в следующих релизах.
Запись внутри связи типа "Включение" не участвует в сопоставлении

Запись сможет участвовать в сопоставлении:

При редактировании записи-включения напрямую;

При любом редактировании записи, содержащей включение;

При запуске операции matchingJob.

При редактировании связи-включения запись внутри включения использует свое предыдущее состояние, а не новое (т.е. для сопоставления используются атрибуты записи от предыдущей ревизии записи);

При удалении связи-включения запись внутри включения не исключается из сопоставления. Такие записи удалятся из матчинга только при запуске matchingJob с пересозданием таблиц.

Также при удалении связи-включения классификации и другие связи в записи внутри включения не удаляются из БД/не помечаются неактивными в БД.

При отсоединении/объединении/клонировании/восстановлении частично могут встречаться те же проблемы, что и для создания/удаления записи-включения.

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

Изменение шаблона бизнес-процесса с проверкой качества

Шаблон бизнес-процесса согласования изменений с проверкой качества был изменен. Для корректной работы необходимо пересоздать бизнес-процесс с новым шаблоном.

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

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

Валидация входящих связей типа "Включение"

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

Примечание

Реестр может иметь несколько входящих связей типа "Включение" из разных реестров.

Миграция из предыдущих версий:

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

Чтобы удалить связи, несоответствующие валидации связей "Включение", необходимо выполнить следующие шаги:

Экспортируйте модель данных.
В экспортированном xml файле вручную удалите связи, которые несоответствуют валидации связей "Включение".
- Связь типа "Включение" имеет параметр relType="Contains".
Импортируйте исправленную модель данных с включенным флагом "Пересоздать".

Обновление Nginx

Для устранения уязвимостей необходимо обновить версию Nginx до 1.23.2-alpine.

Перечень уязвимостей:

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

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

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

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

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

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

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

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

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

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

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

Версия 6.10

Валидация атрибутов типа "Ссылка на справочник"

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

При попытке изменения существующей модели данных, перенесенной из версии 6.9, могут возникать ошибки, которые не позволят опубликовать модель данных.

Пример ошибки: "Атрибут [wrong_atr] справочника [ref_name], на который ссылается атрибут [link] в [entity_name], должен быть обязательным и отображаемым".

В случае невозможности исправления модели через UI необходимо:

Зайти в раздел "Импорт/экспорт" и экспортировать модель данных в формате xml.
Открыть скачанный файл любым редактором, найти элемент реестра register, в котором происходит ошибка (в примере [entity_name]). См. Рисунок 1.
Найти атрибут типа "Ссылка на справочник" из ошибки (в примере [link]) и удалить в элементе атрибута строку с элементом "lookupEntityDisplayAttributes" и именем атрибута справочника из ошибки (в примере [wrong_atr]). См. Рисунок 2.
Проделать шаги 2-3 для всех атрибутов из ошибки. Сохранить файл.
Импортировать файл модели обратно в систему.
После этого можно изменять модель и выбирать новые отображаемые значения, которые пройдут валидацию.

Пример кода для реестра:

<register version="37" name="test" displayName="test" description="" dashboardVisible="false" flyweight="false" hierarchical="false" maxHierarchyLevel="0">
   <simpleAttribute name="dd" displayName="dd" description="" readOnly="false" hidden="false" nullable="false" order="1" searchable="true" displayable="true" mainDisplayable="true" useAttributeNameForDisplay="false" simpleDataType="Integer" enumDataType="" linkDataType="" unique="false" searchMorphologically="false" searchCaseInsensitive="false" searchWithTransliteration="false" lookupEntityType="">
   <customProperties name="DATACARD_ATTRIBUTE_PREVIEW_TYPE" value="default"/>
   <customProperties name="DATACARD_ATTRIBUTE_TYPE" value="default"/>
   <lookupLink xmlns="">false</lookupLink>
   </simpleAttribute>
   <simpleAttribute name="link" displayName="link" description="" readOnly="false" hidden="false" nullable="true" order="5" searchable="false" displayable="true" mainDisplayable="false" useAttributeNameForDisplay="false" enumDataType="" linkDataType="" unique="false" searchMorphologically="false" searchCaseInsensitive="false" searchWithTransliteration="false" lookupEntityType="test_spr" lookupEntityCodeAttributeType="String">
   <customProperties name="DATACARD_ATTRIBUTE_PREVIEW_TYPE" value="default"/>
   <customProperties name="DATACARD_ATTRIBUTE_TYPE" value="default"/>
   <lookupEntityDisplayAttributes>wrong_atr</lookupEntityDisplayAttributes>
   <lookupLink xmlns="">true</lookupLink>
   </simpleAttribute>
</register>

Пример кода для атрибута:

<simpleAttribute name="link" displayName="link" description="" readOnly="false" hidden="false" nullable="true" order="5" searchable="false" displayable="true" mainDisplayable="false" useAttributeNameForDisplay="false" enumDataType="" linkDataType="" unique="false" searchMorphologically="false" searchCaseInsensitive="false" searchWithTransliteration="false" lookupEntityType="test_spr" lookupEntityCodeAttributeType="String">
   <customProperties name="DATACARD_ATTRIBUTE_PREVIEW_TYPE" value="default"/>
   <customProperties name="DATACARD_ATTRIBUTE_TYPE" value="default"/>
   <lookupEntityDisplayAttributes>wrong_atr</lookupEntityDisplayAttributes>
   <lookupLink xmlns="">true</lookupLink>
   </simpleAttribute>

Рисунок 1 - Элемент реестра (register)

Рисунок 2 - Элемент "lookupEntityDisplayAttributes"

Модуль уведомлений org.universe.mdm.notifications

Изменился сегмент отправки уведомлений о вставке записи com.universe.mdm.notifications[SEND_UPSERT_NOTIFICATION].

После обновления для использования старой версии сегмента необходимо установить параметр com.universe.mdm.notifications.notifications.upsert.version=1.

Подробнее см. в журнале тех. изменений.

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

В каталог unidata-deploy добавлены следующие файлы:

docker-compose-cluster.yaml
haproxy.cfg

Обновлен файл .env - добавлен блок настроек для запуска кластерной конфигурации "Settings for cluster", часть переменных из которых содержится в файле платформы backend.properties.

Запуск кластерной конфигурации осуществляется командой:

docker-compose -f docker-compose-cluster.yaml up -d

После запуска будет создан контейнер с балансировщиком haproxy и по два контейнера с BE и FE.

Проверка работы балансировщика haproxy доступна по адресу http://ip:8087/haproxy_stats.

Запросы с http://ip:8087 будут перенаправляться на ui и ui2 в режиме roundrobin.

Связь между контейнерами осуществляется следующим образом: ui - mdm и ui2 - mdm2.

Конфигурация портов:

Frontend Ports (для Standard Edition):
- FRONTEND_PORT=28080
- FRONTEND_PORT_2=28081
Backend Ports (для Standard Edition):
- BACKEND_PORT=29080
- BACKEND_PORT_2=29081
Frontend Ports (для Enterprise Edition):
- FRONTEND_PORT=8082
- FRONTEND_PORT_2=8083
Backend Ports (для Enterprise Edition):
- BACKEND_PORT=9081
- BACKEND_PORT_2=9082

Система доступна по адресу http://ip:8087, а также каждый ui отдельно:

ui http://ip:28080 и ui2 http://ip:28081 (для Standard Edition)

ui http://ip:8082 и ui2 http://ip:8083 (для Enterprise Edition)

Версия 6.9

Устаревшая версия REST API

В релизе 6.9 REST API версия v1 отмечена как устаревшая, поэтому исключена из продуктов Юниверс. Описанные ниже запросы доступны только в версии v2:

Исключены из SE/EE:

org.unidata.mdm.rest.core
org.unidata.mdm.rest.v1.search
org.unidata.mdm.rest.v1.meta
org.unidata.mdm.rest.v1.data
org.unidata.mdm.rest.v1.draft
org.unidata.mdm.rest.v1.dq.core
org.unidata.mdm.rest.v1.dq.data
org.unidata.mdm.rest.v1.bulk.core
org.unidata.mdm.rest.v1.matching.core
org.unidata.mdm.rest.v1.matching.data
com.unidata.mdm.rest.v1.bulk.remove.records
com.unidata.mdm.rest.v1.workflow.core

Исключены из CE:

org.unidata.mdm.rest.core
org.unidata.mdm.rest.v1.data
org.unidata.mdm.rest.v1.meta
org.unidata.mdm.rest.v1.draft
org.unidata.mdm.rest.v1.search
org.unidata.mdm.rest.v1.dq.core
org.unidata.mdm.rest.v1.dq.data
org.unidata.mdm.rest.v1.matching.core
org.unidata.mdm.rest.v1.matching.data
org.unidata.mdm.rest.v1.bulk.core

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

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

В релизе 6.9 Юниверс MDM перешла с 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.

При переходе на OpenSearch необходимо выполнить дополнительные шаги для сохранения данных аудита.

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

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

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

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

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

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

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

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

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

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

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

В параметр системы "Хранилище журнала аудита" org.unidata.mdm.core.audit.enabled.storages добавьте значение "index".
Обновите пути аудита "Маршруты сообщений модуля Core" org.unidata.mdm.system.messaging.domains.core-messaging из core.xml.

Обновление шаблона Excel для импорта / экспорта записей

Было изменено название листа комплексного атрибута в XLSX-файле. Теперь указывается имя самого атрибута и имя вложенного объекта.

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

Версия 6.8

Миграции базы данных

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

В версии 6.8 были произведены архитектурные изменения, связанные с размещением расширений PostgreSQL. Это сделало автоматическую миграцию баз данных с предыдущих версий невозможной.

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

Создайте резервные копии БД и поисковых индексов.
Обновите систему до Юниверс MDM 6.8. Не запускайте систему.

До запуска системы выполните следующий SQL-код вручную:

alter extension "uuid-ossp" set schema public;
alter extension "postgres_fdw" set schema public;
alter extension "hstore" set schema public;

Расширение timescaledb (схема org_unidata_mdm_timelog) при этом не обновляется. Чтобы обновить расширение, пересоздайте его с удалением. Выполните следующий SQL-код вручную:
```
drop schema if exists org_unidata_mdm_timelog_core cascade;
drop extension if exists timescaledb cascade;
```
При запуске системы применятся все изменения, будет создана новая схема org_unidata_mdm_timelog.

Это не затрагивает сценарий первичной установки Юниверс MDM 6.8. При установке на чистый сервер миграции инициализируют базу данных автоматически.

Миграция данных в Docker volumes

В версии 6.8 изменились имена Docker volumes. Изменение влияет на случаи, когда необходимо обновить Юниверс MDM с более ранних версий, и если система была установлена через Docker, а данные при этом хранились в Docker volumes. Чтобы провести миграции volumes вам необходимо обратиться к вендору за инструкцией.

Устаревшая версия REST API

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

В релизе 6.8 запросы REST API v1 отмечены как устаревшие, так как не совместимы с новой моделью безопасности системы. В следующем релизе API v1 будет удален. Рекомендуется переход на v2.

Невозможность обновления прав доступа

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

Переход формата времени на UTC

Начиная с версии 6.7 timestamp перешел на UTC (Zulu time), в связи с этим формат времени должен оканчиваться на букву Z.