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