Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Команда интеграции передаёт серверы и диски из внутренней системы в Assets. Один разработчик отвечает за JSON, другой — за схему объектов. После небольшого переименования поля диски перестали связываться с серверами. Чтобы подобные изменения не проходили незаметно, нужен проверяемый контракт между двумя сторонами.
Начните с потребителя данных: какие связи действительно нужны агенту и какие изменения он должен замечать. Контракт между системами описывает не только формат JSON, но и смысл сущностей. Если сервер переустановлен или диск перемещён, обе стороны должны одинаково понимать, остаётся ли это прежний объект.
Модель и договорённости
Зафиксируйте внешние идентификаторы типов, атрибутов и самих объектов. Опишите структуру входного JSON и значение каждого селектора. Для связей укажите, по какому ключу находится целевой объект и кто отвечает за отсутствующую ссылку. Разделите версию источника и версию отображения: это разные причины изменения результата импорта.
Для внешних ключей задайте пространство имён, особенно если данные приходят от нескольких поставщиков. Совпадающий локальный номер не гарантирует одинаковую сущность. В контракте зафиксируйте допустимые изменения полей, правила удаления и действия при временной недоступности родительских записей, чтобы ошибка порядка загрузки не выглядела списанием.
Порядок внедрения
Создайте маленький эталонный набор с одним сервером и несколькими дисками. Подготовьте схему и сопоставление по официальному формату, затем проверьте передачу данных на ограниченной схеме. Сохраните контракт и примеры рядом с кодом интеграции. Любое переименование входного атрибута сопровождайте изменением тестового набора и явным решением о совместимости.
Закрепите эталонный набор данных и ожидаемый результат за версией интеграции. При изменении схемы сначала проверяйте совместимость со старым входом, затем с новым. В журнале партии сохраняйте идентификатор используемого отображения. Если несколько команд выпускают изменения независимо, согласуйте переходный период, когда источник и потребитель понимают оба допустимых формата.
Проверки на реальных сценариях
Прогоните отсутствующий обязательный ключ, неизвестный родительский объект, повторный идентификатор и пустой массив дочерних элементов. Проверьте обновление сервера без изменения его дисков. Сравните реальные связи после импорта с ожидаемым графом. Успешный HTTP-ответ не доказывает, что все дочерние объекты получили правильного родителя.
В тестовом наборе сохраните эталонный граф объектов и ожидаемые атрибуты после каждой партии. Сравнение только входного JSON не обнаружит неверную ссылку в целевой схеме. Проверьте изменение порядка массивов: результат должен зависеть от идентификаторов и сопоставления, а не от позиции элемента.
Ошибки и диагностика
Частая ошибка — считать путь JSON косметической деталью. Изменение вложенности может разорвать выборку по селектору. Также опасно использовать позицию элемента массива как идентификатор: порядок меняется между выгрузками. Ошибки контракта лучше обнаруживать до отправки, выдавая понятный отчёт по записи, а не пытаясь угадывать структуру на рабочем импорте.
При разрыве ссылок сравните версии селекторов и реальную вложенность данных. Не исправляйте каждую связь вручную до устранения причины, иначе следующий импорт снова перезапишет результат ручной работы.
Возврат и восстановление
Поддерживайте предыдущую совместимую версию сопоставления и исходные данные последней принятой партии. При неудаче остановите новые запуски и выясните, какие записи уже изменены. Возвращайте конфигурацию вместе с соответствующим форматом данных. Простое восстановление старого JSON при новом сопоставлении может повторить ту же ошибку в другом направлении.
При возврате отображения убедитесь, что уже созданные новые типы и атрибуты не используются рабочими обращениями. Их немедленное удаление способно повредить полезные ссылки. Остановите дальнейшую загрузку несовместимых данных и составьте план восстановления конкретных связей. Возврат интеграционного кода завершён только после сверки целевого графа объектов и его идентификаторов.
Приёмка и дальнейший контроль
Отслеживайте несопоставленные ссылки, изменение числа объектов по типам и ошибки валидации контракта. После каждой поставки интеграции выполняйте эталонный импорт и сравнение связей. Результат — возможность объяснить происхождение любого объекта и доказать, что изменение источника не сломало идентичность и отношения в CMDB.
Для каждой поставки записывайте версии источника, схемы и отображения, а также идентификатор партии. Тогда неожиданную связь можно проследить до конкретного изменения контракта. Добавление поля должно сопровождаться решением, кто владеет его значением и как старый источник работает с новой конфигурацией.
Механизм продукта и применимость
Документация External Imports описывает схему и отображение данных, включая внешние идентификаторы. Структура передаваемых данных должна соответствовать селекторам, определённым в сопоставлении.
Источник относится к External Imports в Assets Cloud и описывает формат схемы и mapping. Он не заменяет бизнес-контракт между владельцами систем. Идентичность сервера, порядок миграции полей и реакцию на отсутствующий объект определяют заранее, отдельно от технической успешности передачи JSON.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу