Важные изменения¶
Примечание
Ниже представлены важные изменения вышедших релизов, влияющие на функциональность системы. Краткий перечень изменений релизов отражен в новых функциях. Подробную техническую информацию см. в журнале технических изменений.
Версия 2.7 (Enterprise Edition)¶
1. Сортировка без выбранного актива¶
Добавлена индексация отображаемых имен активов и их типов (поля $display_name, $type_display_name). После индексации в поиске по активам доступен поиск и сортировка по отображаемым именам.
Выполнена доработка сервиса для вычисления отображаемых имен активов. Добавлена возможность вычислять отображаемое имя для исторических данных (отображаемое имя актива на определенную дату).
Добавлена предварительна проверка черновиков модели DG на необходимость переиндексации данных после публикации черновика.
Проверка доступна по rest-запросу /v1/meta/model/draft-warnings.
2. Обновление OrientDB с версии 3.2.4 до 3.2.23¶
Варианты обновления:
Примечание
В любом из вариантов рекомендуется выполнить экспорт БД перед обновлением
С помощью Docker / Локальная установка с выделенной директорией для хранения данных
С помощью Docker - действий при обновлении не требуется.
Локальная установка - при установке новой версии необходимо указать в
${ORIENTDB_HOME}/config/orientdb-server-config.xml
путь к директории с данными.
<properties>
<entry name="server.database.path" value="/opt/homebrew/var/db/orientdb" />
</properties>
Локальная установка без выделенной директории для хранения данных
Если OrientDB установлен локально без выделенной директории для хранения данных (данные хранятся в ${ORIENTDB_HOME}/databases
), то возможны два варианта обновления:
Восстановление данных через операцию переиндексации данных со следующими параметрами:
Экспорт и импорт БД:
Перед обновлением необходимо выполнить экспорт БД через консоль OrientDB. Пример:
Запустите консоль OrientDB:
${ORIENTDB_HOME}/bin/orientdb-console.sh
Выполните подключение к БД:
connect remote:{host}:{port}/{db_name} {user} {password}
Пример:
connect remote:localhost:2424/dg root root
Запустите экспорт БД:
export database {path_to_export_file}
Пример:
export database dg.export
После установки новой версии OrientDB необходимо создать новую БД и выполнить импорт. Пример:
Запустите консоль OrientDB:
${ORIENTDB_HOME}/bin/orientdb-console.sh
Выполнить подключение к БД:
connect remote:{host}:{port}/{db_name} {user} {password}
Пример:
connect remote:localhost:2424/dg root root
Запустить импорт БД:
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)
4. Валидация атрибутов типа "Ссылка на справочник"¶
Добавлена валидация, запрещающая у атрибутов с типом "Ссылка на справочник" указывать в качестве отображаемых атрибуты справочника, которые не являются обязательными и отображаемыми.
При попытке изменения существующей модели данных, перенесенной из версии 2.6, могут возникать ошибки, которые не позволят опубликовать модель данных.
Пример ошибки: "Атрибут [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"
Версия 2.6 (Enterprise Edition)¶
1. Обновление прав пользователя без выхода из системы¶
Обновление прав пользователя, его ролей и групп происходит без необходимости выходить из системы и повторной авторизации:
Если пользователь обновляет собственные настройки, то изменения автоматически обновятся на UI.
Если пользователь обновляет настройки другого аккаунта, то на экране пользователя, имеющего активную сессию, отобразится модальное окно с возможностью принять обновления (Рисунок 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.