Перейти к содержанию

Утилита переноса конфигурации

Утилита переноса (сквозной механизм)

Утилита переноса — это подсистема переноса конфигурации между площадками и версионирования модулей.

Подсистема работает в двух связанных каналах:

  1. Ручной перенос через админ-интерфейс (/api/migration/*).
  2. Версии модулей через RevisionRepository (/api/admin/revisionrepository/*).

Что переносится

Переносятся конфигурационные сущности:

  • категории, разделы, ДП, статусы, подписи;
  • смарты, смарт-пакеты, смарт-расписания;
  • порталы, блоки, настройки доступа и др.

Не переносятся автоматически:

  • рабочие данные пользовательских задач;
  • пользовательские файлы;
  • часть кастомных DB-объектов (переносятся отдельно).

Канал 1: ручной перенос (экспорт/импорт)

Основные API:

  • GET /api/migration/tree-root
  • GET /api/migration/fetch
  • POST /api/migration/export/config
  • POST /api/migration/export/config/background
  • GET /api/migration/export/config/background/status
  • POST /api/migration/import/preview
  • POST /api/migration/import/config

Экспорт

  1. Администратор выбирает сущности в дереве.
  2. Backend собирает MigrationDto (Config, Data, AdditionalData).
  3. MigrationFileLayoutService.Split() разбивает данные на мультифайловую структуру по scope.
  4. Формируется ZIP с деревом файлов (см. раздел «Формат файлов»).

Важно: параметр includeSubcat работает контринтуитивно. includeSubcat=true означает «частичная выгрузка БЕЗ дочерних зависимостей», includeSubcat=false — полная выгрузка С зависимостями. Для полной выгрузки раздела передавайте GUID'ы подкатегорий явно и используйте includeSubcat=false.

Полная выгрузка:

  • запускается как MigrationExportJob;
  • результат кладется в Диск -> Файлы автоматизации -> Export configurations.

Импорт

  1. preview показывает, что будет Добавить/Обновить/Конфликт/Без изменений/AutoCreate. Статус AutoCreate появляется при включённой опции EnrichWithDefaults и означает зависимости, которые будут созданы автоматически.
  2. import/config выполняет транзакционный импорт.
  3. При ошибках отдаются диагностические файлы Log.txt и Error.txt.

Опции импорта:

  • withDenormalization
  • includeAllResolutions
  • importAsNewData
  • importWithoutKeepIdentity — импорт без сохранения идентификаторов. Сопоставление по GUID, ID приёмника не перезаписываются. Доступна только через CLI (ключ -iowki) и WinForms-утилиту; в веб-интерфейсе (SPA) не поддерживается.
  • importConstraintsAction
  • EnrichWithDefaults — заполняет обязательные поля значениями по умолчанию и автоматически создаёт стабы для отсутствующих зависимостей. По умолчанию выключена. Доступна через интерфейс, API и CLI (ключ -ioed). В канале RevisionRepository (changeversion) включена принудительно.

Важно:

  • в текущем контуре часть операций с constraints в MigrationImportService отключена (исторический код закомментирован), поэтому фактическое поведение определяется текущей реализацией сервиса.

Realtime-лог импорта

  • SignalR hub: /migrationUtilityHub;
  • событие на клиент: notify;
  • сообщения выводятся в нижний лог на странице импорта.

Денормализация в утилите переноса

Денормализация — обязательный операционный блок производительности после импорта (если включен флаг withDenormalization).

Что происходит:

  1. Импорт коммитится.
  2. Отправляется команда обновления кешей (UpdateAllCachesServerCommand).
  3. Выполняется денормализация:
  4. категорий;
  5. ДП «Таблица» при соответствующих условиях;
  6. сводных разделов (перестроение SQL-view).

Ручной контур денормализации (вне импорта):

  • POST /api/system/denormalize-subcats
  • POST /api/system/denormalize-subcats/all
  • SignalR: /denormalizationHub, событие LogMessage.

Подробно: Денормализация и детальный техразбор денормализации.

Канал 2: версии модулей (RevisionRepository)

API:

  • POST /api/admin/revisionrepository/versionconfig
  • POST /api/admin/revisionrepository/versionconfig/changeversion
  • DELETE /api/admin/revisionrepository/versionconfig/{id}

Сервисные API репозитория:

  • POST /api/admin/revisionrepository/reposettings
  • GET /api/admin/revisionrepository/reposettings
  • POST /api/admin/revisionrepository/reposettings/{id}
  • DELETE /api/admin/revisionrepository/reposettings/{id}
  • POST /api/admin/revisionrepository/reposettings/preparerepository

Поток create version:

  1. Создание записи в VersionConfigs.
  2. Сбор текущей конфигурации модуля через экспортный контур.
  3. Push в активный провайдер репозитория (FileSystem/Git).

Поток change version:

  1. Pull версии из репозитория.
  2. Импорт конфигурации в текущую базу.
  3. Обновление Modules.VersionConfigId.
  4. Если импорт упал — откат привязки на предыдущую версию.

Формат файлов

Начиная со сборки 2.267.360 экспорт использует мультифайловую структуру вместо монолитного data.json.

Новый формат (мультифайловый)

ZIP содержит дерево файлов, организованное по scope:

_meta/config.json                              стратегии ассоциаций
_meta/additional-data.json                     Guid→Id маппинги зависимостей
_meta/manifest.json                            версия бэкенда-источника (с 2.268)
_global/ext-params.json                        глобальные ДП
_global/states.json                            глобальные статусы
_global/groups.json                            группы
_global/...
_versions/smart-expression-versions.json       версии смартов
_versions/smart-script-versions.json           версии скриптов
categories/cat-{id}/_category.json             раздел
categories/cat-{id}/subcat-{id}/_subcategory.json  категория
categories/cat-{id}/subcat-{id}/smart-expressions.json
categories/cat-{id}/subcat-{id}/ext-param-in-subcats.json
categories/cat-{id}/subcat-{id}/group-permissions.json
categories/cat-{id}/subcat-{id}/states-routes-in-subcats.json
categories/cat-{id}/subcat-{id}/actions-packs.json
...

Типичная выгрузка раздела с 7 категориями: ~226 файлов, ~440 КБ.

Старый формат (legacy)

Три файла в корне ZIP:

  • data.json — все сущности (может быть 100+ МБ)
  • config.json — стратегии ассоциаций
  • additionalData.json — маппинги зависимостей

Обратная совместимость

Импорт автоматически определяет формат: если в ZIP есть data.json → старый формат, иначе → мультифайловый. Оба формата поддерживаются на всех каналах (ручной перенос, RevisionRepository).

Кросс-версионный импорт

Начиная с версии 2.268 Скульптор, импорт файлов, созданных на другой версии системы, не прерывается из-за неизвестных типов данных. Неизвестные CLR-типы пропускаются с записью предупреждения в лог. ZIP экспорта теперь содержит файл _meta/manifest.json с версией системы-источника.

Компоненты реализации

Компонент Что делает
MigrationFileLayoutService Split (MigrationDto → файлы) и Merge (файлы → MigrationDto)
VersionConfigFileHelper Атомарная запись/чтение на ФС (temp → rename → rollback)
MigrationFileService ZIP-канал: пакует/распаковывает мультифайловую структуру

Подробно: multifile-export.md.

Диагностика

Проверять по слоям:

  1. API:
  2. статусы export/import;

  3. корректность preview.

  4. UI:

  5. SignalR-лог на странице импорта.

  6. Backend:

  7. сообщения импорт/экспорт сервисов;

  8. результат фонового MigrationExportJob.

  9. Data:

  10. наличие обязательных зависимостей (AdditionalData);
  11. факт денормализации категорий/сводных;
  12. факт обновления кешей.

Связанные страницы