Важные изменения¶
Версия 6.11
Предупреждение
В Юниверс MDM версии 6.11 было осуществлено обновление PostgreSQL до версии 16.3, в связи с этим теперь требуется обязательная установка расширения TimescaleDB для корректной работы с большими объемами данных. В зависимости от вашей ОС, проверьте шаги установки TimescaleDB в руководстве по установке системы. Перед установкой рекомендуется проверить совместимость вашей версии PostgreSQL и версии TimescaleDB.
Важные проблемы версии 6.11¶
Некорректно объединяются записи с удаленными связями/классификациями. Поведение будет исправлено в следующих релизах.
При сопоставлении отсутствующая классификация/связь равнозначна незаполненному атрибуту классификации/связи (т.е. затронуты ситуации, когда матчинг настроен по атрибуту классификации/связи и в правиле включено сопоставление по null). Поведение будет исправлено в следующих релизах.
Запись внутри связи типа "Включение" не участвует в сопоставлении
Запись сможет участвовать в сопоставлении:
При редактировании записи-включения напрямую;
При любом редактировании записи, содержащей включение;
При запуске операции matchingJob.
При редактировании связи-включения запись внутри включения использует свое предыдущее состояние, а не новое (т.е. для сопоставления используются атрибуты записи от предыдущей ревизии записи);
При удалении связи-включения запись внутри включения не исключается из сопоставления. Такие записи удалятся из матчинга только при запуске matchingJob с пересозданием таблиц.
Также при удалении связи-включения классификации и другие связи в записи внутри включения не удаляются из БД/не помечаются неактивными в БД.
При отсоединении/объединении/клонировании/восстановлении частично могут встречаться те же проблемы, что и для создания/удаления записи-включения.
Автоконсолидация не срабатывает, поскольку кластер не создается, т.к. запись внутри включения не участвовала в сопоставлении.
Параметры для индексации поисковых данных записей реестров/справочников в OpenSearch¶
Во время операции реиндекса (reindexDataJob) с отключенной фоновой переиндексацией и операцией переприменения (reapplyDataJob) для затрагиваемых реестров отключается refresh (но не для справочников, т.к. считается, что в них мало данных). Для таких реестров вместо значения WAIT_FOR будет использован TRUE (в случае, если мы обычно используем WAIT_FOR). Существует теоретическое окно, когда одновременно запись сохраняется и запускается операция реиндекса, в результате чего запрос на индексацию данных в OpenSearch уйдет с refresh=WAIT_FOR при отключённом автоматическом refresh'е.
Тип refresh'а при каких-либо операциях над данными (кроме тех, что определены ниже) - org.unidata.mdm.data.indexing.refresh = ${DATA_REFRESH:WAIT_FOR}
Тип refresh'а, используемый при сохранении черновиков записей - org.unidata.mdm.data.indexing.refresh.draft.upsert = ${DATA_REFRESH_DRAFT_UPSERT:WAIT_FOR}
Тип refresh'а, используемый при публикации черновиков записей - org.unidata.mdm.data.indexing.refresh.draft.publish = ${DATA_REFRESH_DRAFT_PUBLISH:WAIT_FOR}
Тип refresh'а при каких-либо операциях над данными имеет доступные значения: FALSE, WAIT_FOR, TRUE.
TRUE - refresh выполняется при каждом запросе на индексацию данных в OpenSearch, что ведёт к деградации производительности при большой нагрузке (ранее это значение использовалось по умолчанию).
WAIT_FOR - каждый запрос на индексацию данных в OpenSearch не возвращает ответ до тех пор, пока не будет выполнен refresh (например, другим запросом с refresh=TRUE или автоматически, который выполняется каждые org.unidata.mdm.data.indexing.refresh.interval миллисекунд), теперь это значение используется по умолчанию (спасает при большой нагрузке за счёт небольшого увеличения времени ответа запросов при малой нагрузке).
FALSE - запрос на индексацию данных в OpenSearch не выполняет refresh, запись в поиске становится доступна не сразу.
Если какой-то из этих параметров не задан, то используется значение параметра org.unidata.mdm.search.refresh.immediate (false -> FALSE, true -> TRUE).
Изменение шаблона бизнес-процесса с проверкой качества¶
Шаблон бизнес-процесса согласования изменений с проверкой качества был изменен. Для корректной работы необходимо пересоздать бизнес-процесс с новым шаблоном.
Изменение формата хранения файловых массив-атрибутов¶
При переходе на версию 6.11 необходимо запустить операцию "Задача миграции файловых атрибутов", иначе при попытке открыть запись с файловым массив-атрибутом будет возникать ошибка.
Валидация входящих связей типа "Включение"¶
Если у реестра есть входящие связи типа "Включение", то при сохранении черновика будет происходить валидация на наличие входящих связи других типов или любые исходящие связи.
Примечание
Реестр может иметь несколько входящих связей типа "Включение" из разных реестров.
Миграция из предыдущих версий:
Если в предыдущих версиях в модели данных у реестра имелись какие-либо связи помимо связей типа "Включение", то такие модели невозможно будет изменить из-за новой валидации.
Чтобы удалить связи, несоответствующие валидации связей "Включение", необходимо выполнить следующие шаги:
В экспортированном xml файле вручную удалите связи, которые несоответствуют валидации связей "Включение".
Связь типа "Включение" имеет параметр relType="Contains".
Импортируйте исправленную модель данных с включенным флагом "Пересоздать".
Обновление Nginx¶
Для устранения уязвимостей необходимо обновить версию Nginx до 1.23.2-alpine.
Перечень уязвимостей:
Отображение доп. параметров¶
Улучшено отображение длинных значений доп. параметров различных объектов системы. Если значение не помещается в ячейку таблицы, то у ячейки появится всплывающая подсказка, отображающая полностью ее содержимое (Рисунок 1).
При редактировании добавлена кнопка переключения в режим многострочного ввода .
Изменения касаются свойств классификаторов и их узлов классификаторов, свойств реестра/справочника, связей реестра, источников данных, перечислений, единиц измерения. Изменения НЕ применялись в дополнительных параметрах разделов "Пользователи" и "Роли".
Рисунок 1 – Отображение длинных значений доп. параметров
Поиск процессов по полям связанных задач¶
В индексы бизнес-процессов добавлены новые поля, поэтому при обновлении системы необходимо выполнение операции переиндексация необходимых бизнес-процессов с обновлением маппингов.
Поиск записей по синонимам значений атрибутов¶
При обновлении системы до последней версии необходимо выполнить операцию переиндексации данных реестров и справочников с очисткой индексов и обновлением маппингов.
Если Opensearch установлен локально, то необходимо добавить файл synonyms.txt в ${OPENSEARCH_HOME}/config/.
Подробнее о настройке синонимов см. в статье.
Версия 6.10.2
Обновление алгоритмов сопоставления
После обновления до версии 6.10.2 для корректной работы правил сопоставления необходимо:
Создать черновик модели правил сопоставления.
Удалить все назначения таблиц и наборов правил на реестры и справочники.
Опубликовать черновик.
Создать новый черновик модели правил сопоставления.
Добавить заново назначения таблиц и наборов правил на реестры и справочники.
Опубликовать новый черновик.
Поскольку все таблицы сопоставления в БД будут удалены и созданы заново, то необходимо выполнить операцию сопоставления данных для пересчета кластеров дубликатов.
Версия 6.10.1
Рекомендации по переиндексации
При переходе на 6.10.1 необходима переиндексация данных (записи, связи, черновики, классификации) с флагами "Очистить индексы" и "Обновить маппинги". Прежде всего это влияет на реестры/справочники, на которых есть назначения классификаторов.
Особенности ограничений на сборках SE и EE редакций
Количество ядер процессора: в EE редакции = 16, в SE = 8, если иное значение не указано напрямую в лицензии.
Количество узлов поискового движка и платформы: в EE редакции - не ограничено, в SE = 2, если иное значение не указано напрямую в лицензии.
Ограничение многопоточности операций переиндексации данных (reindexDataJob) применяется только для редакции SE (по умолчанию reindexDataJob выполняется только на одном узле - в лицензии можно отключить это ограничение). В сборке EE операция выполняется на всех узлах, не зависимо от того, что указано в лицензии.
Версия 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.