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

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

Для кого это?

Для клиентов, переходящих с LeanIX (SAP LeanIX) на Turbo EA. Импортер принимает 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, если хотите, чтобы они попали в Turbo EA.

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

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

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

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

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

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

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

LeanIX	Turbo EA
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)	Сохраняются как связи; направление переворачивается при импорте, чтобы конвенция Turbo EA «source следует за target» совпала с семантикой LeanIX «у X есть преемник Y». У новых tenant-типов карт has_successors=true, поэтому отображается представление lineage.
Связи (50+ типов рёбер LeanIX по умолчанию, и xlsx-нотация applicationITComponentRelation, и GraphQL-нотация relApplicationToITComponent)	Нативные связи Turbo EA с атрибутами рёбер
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 позже.
• История аудита до момента импорта — история Turbo EA начинается с timestamp применения.
• Диаграммы / постерные представления / дашборды / сохранённые поиски / настройки уведомлений / API-токены / вебхуки — нет эквивалента в Turbo EA или нет аналога в снимке.

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

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

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

Разрешение

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

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

• Одна активная миграция на хеш файла. Повторная загрузка тех же байтов, когда миграция по этому хешу ещё активна, возвращает существующую запись миграции (хеш SHA-256 — естественный ключ идемпотентности). Если действительно нужен повторный приём того же файла, сначала удалите запись миграции.
• Большие workspace'ы (10k+ fact sheet): парсер потоковый, но пайплайн apply пишет строки одной транзакцией на проход. Для очень больших импортов запланируйте ~15 минут.
• Пользовательские поля, значения и теги допускаются, не предмаппятся. Любая колонка LeanIX, которой нет во встроенной метамодели Turbo EA, попадает в карту attributes импортированной карты дословно и появляется во вкладке Пользовательские поля, чтобы администратор мог продвинуть её в первоклассное поле. Так же — для tenant-определённых групп тегов и типов связей, добавленных клиентами LeanIX (например, lxSystemSystem*, *Lx*Dora*, microservice*, eSGCapability*) — они без изменений появляются во вкладках Новые типы / Новые связи, ожидая решения администратора.

Очистка

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