Миграция платформы

Поддерживаемые сегодня платформы-источники: SAP LeanIX. Дополнительные адаптеры (Ardoq, Mega HOPEX, BiZZdesign, Avolution Abacus, …) подключаются к той же конвейерной обработке staging и apply и автоматически появляются в диалоге загрузки, как только они выпущены.

Импортер миграции платформы (Администрирование → Настройки → Миграция) принимает полный workspace LeanIX и за одну ревизуемую поэтапную операцию переводит его в карты, связи, теги, заинтересованные стороны, документы, комментарии и полноценную метамодель Canopy.

Для кого это?

Для клиентов, переходящих с LeanIX (SAP LeanIX) на Canopy. Импортер принимает xlsx-книгу LeanIX Full Snapshot — многолистовой экспорт с по одному листу на каждый тип fact sheet, по одному листу на каждый тип связи, плюс TagGroups, Tags, Documents, Comments, Types и справочный лист ReadMe. Загрузка в других форматах отклоняется уже на этапе загрузки с понятным сообщением об ошибке.

Как получить экспорт

В LeanIX откройте Administration → Export → Full Snapshot. Это создаёт единый XLSX-файл, содержащий все активные fact sheet, их связи, группы тегов, теги, документы (в LeanIX называемые resources) и комментарии.

Архивные fact sheet не включаются в Full Snapshot — сначала восстановите их в LeanIX, если хотите, чтобы они попали в Canopy.

Рабочий процесс

1. Загрузка снимка в Настройки → Миграция → Новая миграция. Файл остаётся на диске сервера; в БД хранятся только метаданные. Парсинг идёт в фоне, статус автоматически переходит из uploaded в parsed.

2. Проверка каждого типа сущностей во вкладочном представлении. Каждая staged-строка несёт действие:

   • create — будет добавлено в Canopy
   • update — уже существует; поля diff будут объединены
   • skip — уже существует без изменений
   • conflict — отсутствует endpoint, тип не сопоставлен, коллизия со встроенным, некорректный email и т. п. — см. колонку Note с полным описанием причины

   Каждая вкладка показывает над таблицей ряд фильтр-пилюль — по одной на тип карты, где применимо, иначе по действию — чтобы сузить длинный список (сотни карт, десятки типов fact sheet) до одного среза за раз. Вкладка Карты показывает разрешённое имя карты рядом с UUID источника. Колонка Note отображает полную причину конфликта; строки update перечисляют изменённые имена полей с подсказкой, раскрывающей переход старое → новое.

   Вкладки Новые типы, Пользовательские поля и Новые связи показывают tenant-кастомизированную метамодель из вашего исходного workspace. По умолчанию принимаются как есть и создают соответствующие не-built-in типы карт / поля / типы связей в Canopy.

3. Сопоставить импортированные поля (опционально, во вкладке Пользовательские поля). Для каждого пользовательского столбца исходной платформы выберите один из трёх вариантов из выпадающего списка рядом со строкой:

   • Импортировать как новое пользовательское поле (по умолчанию) — столбец становится новым атрибутом на целевом типе карты, в синтетической секции Imported from {source}.
   • Сопоставить с существующим полем Canopy — значение направляется в built-in поле целевого типа карты (например, отправить businessCriticality из LeanIX в собственный слот businessCriticality TEA). Строка поля метамодели пропускается при apply, поэтому никакого «осиротевшего» столбца не создаётся.
   • Сопоставить с фазой жизненного цикла — для столбцов с датой значение направляется в стандартный слот plan / phaseIn / active / phaseOut / endOfLife в card.lifecycle. Значения date / datetime автоматически приводятся к YYYY-MM-DD (суффикс T00:00:00, который некоторые платформы пишут для datetime-ячеек, отбрасывается); неразбираемые значения отбрасываются, чтобы не повредить карту lifecycle.
   • Не импортировать это поле — столбец полностью пропускается, ни как атрибут, ни как поле метамодели.

   Сопоставление действует для одной миграции и может редактироваться, пока статус parsed или previewed. Базовые столбцы исходной платформы, которые адаптер направляет напрямую в стандартные слоты Canopy (например, LeanIX name, displayName, description, status, category → subtype, lifecycle:*, qualitySeal, completion), перечислены вверху вкладки в информационном баннере только для чтения — для них решения по сопоставлению не требуется.

4. Применение при готовности. Пайплайн apply исполняет 12 проходов, упорядоченных по зависимостям (типы метамодели → поля метамодели → типы связей метамодели → пользователи → карты → группы тегов → теги → связки карта-тег → связи → подписки → документы → комментарии), каждый в собственном savepoint — одна неудачная строка не отравит остальной импорт. Статус переходит из applying в applied (или failed, если ошибки превысят порог безопасности).

   Если разобранный снимок содержит строки в conflict, над staging-вкладками появляется предупреждающий баннер (с кликабельными пилюлями, переходящими на соответствующую вкладку), а нажатие Применить открывает диалог подтверждения, в котором перечислены типы с конфликтами. Перед запуском apply необходимо явно подтвердить, что строки с конфликтами будут пропущены. В последующем Результате применения рядом с создано / обновлено / пропущено / ошибки отображается отдельная пилюля конфликты — конфликты не являются молчаливыми пропусками, это первоклассный результат, видимый в истории миграций.

Что импортируется

LeanIX	Canopy
Application, ITComponent, Business Capability, Business Context, Process, DataObject, Interface, Provider, TechCategory, Platform, Objective, Project / Initiative	Прямое 1:1 сопоставление типа карты
User Group	Organization с подтипом team, с тегом leanix_origin=UserGroup
Фазы жизненного цикла (plan / phaseIn / active / phaseOut / endOfLife)	Дословно переносятся в cards.lifecycle
Иерархия (childParentRelation)	Сворачивается в Card.parent_id
Рёбра Successor/Predecessor (*SuccessorRelation)	Сохраняются как связи; направление переворачивается при импорте, чтобы конвенция Canopy «source следует за target» совпала с семантикой LeanIX «у X есть преемник Y». У новых tenant-типов карт has_successors=true, поэтому отображается представление lineage.
Связи (50+ типов рёбер LeanIX по умолчанию, и xlsx-нотация applicationITComponentRelation, и GraphQL-нотация relApplicationToITComponent)	Нативные связи Canopy с атрибутами рёбер
Tenant-определённые типы связей (Server↔Application, lxSystem*, lxDora*, microservice*, ESG* и т. д.)	Новые не-built-in строки relation_types, создаются автоматически в том же проходе импорта, чтобы каждое ребро реально приземлилось
Теги (группы single/multi)	Группы тегов + теги + связи по картам
Подписки (по одной на роль RESPONSIBLE/OBSERVER)	Строки stakeholders; пользователи автоматически создаются деактивированными (is_active=false)
Документы (URL)	Документы-вложения
Комментарии (верхний уровень + ответы, в плоском виде)	Строки комментариев
Tenant-кастомизированные типы fact sheet (например, ESGCapability, Server, System, TechPlatform, TechnicalStack)	Новые не-built-in типы карт с has_hierarchy=true, has_successors=true и предзаполненной секцией Imported from LeanIX
Tenant-кастомизированные поля	Добавляются в fields_schema целевого типа в синтетической секции Imported from LeanIX. Тип поля и полный список значений enum извлекаются из листа ReadMe книги — currentMaturity приземляется как single-select со всеми 5 значениями (adHoc, repeatable, defined, managed, optimized), даже если в данных используется только одно
Tenant-кастомизированные типы связей	Новые не-built-in типы связей, типы endpoint'ов транслируются через карту LX↔TEA (UserGroup → Organization и т. д.)

Почему важен лист ReadMe

Первый лист xlsx (ReadMe) — авторитетный справочник полей LeanIX: каждая колонка задокументирована с типом (String, Integer, Percent, Datetime, Boolean, String list) и, где применимо, с полным enum-ограничением (Possible values: one of A, B, C.). Импортер читает этот лист первым и использует как основной источник истины для метаданных поля — к листу Types (внутри данных) обращается лишь когда ReadMe не покрывает колонку. Это разница между импортированным полем как свободным текстом и полноценным выпадающим списком с правильными опциями.

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

Снимок не содержит следующего — импортер помечает отсутствующее в колонке Note по каждой строке:

• Бинарные файлы документов — в снимке только URL; импортер создаёт документы-ссылки. Перезагрузите бинарные файлы вручную.
• Threading комментариев — ответы уплощаются в комментарии верхнего уровня, чтобы сохранить текст; родители тредов потребовали бы метаданных UI LeanIX, которых нет в снимке.
• Пароли пользователей и привязки SSO — автоматически созданные пользователи приземляются деактивированными. Пригласите их или привяжите к SSO позже.
• История аудита до момента импорта — история Canopy начинается с timestamp применения.
• Диаграммы / постерные представления / дашборды / сохранённые поиски / настройки уведомлений / API-токены / вебхуки — нет эквивалента в Canopy или нет аналога в снимке.

Повторный запуск импорта

Идемпотентность встроена. Таблица migration_identity_map хранит соответствие UUID LeanIX → Canopy для каждой импортированной сущности. Повторная загрузка того же снимка (или обновлённого снимка того же workspace) обнаруживает существующие сущности и пишет staged-строки update/skip, а не дублирует create. Поле external_id карты несёт factSheetId LeanIX, поэтому связь сохраняется даже при очистке identity map.

Если нужно переделать импорт (например, вы массово удалили импортированные карты в UI и хотите перезагрузить их), нажмите значок корзины в строке миграции, чтобы удалить её, и затем повторно загрузите файл. Миграции в состоянии applied можно удалять; это снимает блокировку идемпотентности по хешу файла, позволяя повторно загрузить тот же снимок. Осиротевшие строки в migration_identity_map, указывающие на несуществующие карты, автоматически очищаются на следующем проходе staging — ручная чистка identity map никогда не требуется.

Разрешение

Эта страница защищена разрешением admin.migrate. По умолчанию им обладает только роль admin; явно выдайте его другим ролям в Настройки → Роли, если хотите, чтобы миграцию проводил не-администратор.

Ограничения, которые стоит учесть

• Одна активная миграция на хеш файла. Повторная загрузка тех же байтов, когда миграция по этому хешу ещё активна, возвращает существующую запись миграции (хеш SHA-256 — естественный ключ идемпотентности). Если действительно нужен повторный приём того же файла, сначала удалите запись миграции.
• Большие workspace'ы (10k+ fact sheet): парсер потоковый, но пайплайн apply пишет строки одной транзакцией на проход. Для очень больших импортов запланируйте ~15 минут.
• Пользовательские поля, значения и теги допускаются, не предмаппятся. Любая колонка LeanIX, которой нет во встроенной метамодели Canopy, попадает в карту attributes импортированной карты дословно и появляется во вкладке Пользовательские поля, чтобы администратор мог её обработать (направить в существующее поле TEA, в фазу жизненного цикла или пропустить — см. Сопоставить импортированные поля в потоке выше). Так же — для tenant-определённых групп тегов и типов связей, добавленных исходными платформами (например, lxSystemSystem*, *Lx*Dora*, microservice*, eSGCapability*) — они без изменений появляются во вкладках Новые типы / Новые связи, ожидая решения администратора.
• Email подписок принимает оба разделителя. Экспорт «Full Snapshot» LeanIX разделяет email в ячейках subscriptions:<RoleType>[:<RoleName>] через ;; экспорт GraphQL CSV использует ,. Парсер принимает оба. Строки с некорректным email (нет @, или неразделённый разделитель) staged как conflict с понятной причиной, а не создаются как фиктивные пользователи — исправьте исходный экспорт и загрузите заново.

Очистка

Удаление записи миграции (Настройки → Миграция → значок корзины) убирает и строки БД для этой миграции (staged-записи каскадно), и файл снимка на диске. Миграции в статусах uploaded, parsed, previewed, failed, aborted и applied все удаляемы; миграция в статусе applying должна сначала завершиться (или упасть), прежде чем её можно будет удалить.