При реализации механизмов интеграции 1С с внешними базами данных на уровне SQL программисты часто сталкиваются с проблемой нарушения ссылочной целостности. Типичная ситуация: выгружается характеристика товара, но в базе-приемнике еще нет записи о самой номенклатуре-владельце. Если в SQL-базе настроены жесткие связи (Foreign Keys), транзакция записи прерывается с ошибкой, и обмен «клинит».
В этой статье мы подробно рассмотрим, почему возникают такие ситуации, как работает механизм регистрации изменений и какие архитектурные подходы позволяют гарантировать успешную синхронизацию связанных данных.
Разберем внутреннюю логику работы планов обмена. Когда мы регистрируем объект для выгрузки (например, СправочникОбъект.Номенклатура), платформа добавляет запись в таблицу регистрации изменений. Однако, если у этой номенклатуры есть связанные объекты (характеристики, единицы измерения), они автоматически не регистрируются, если только это не предусмотрено логикой конфигурации или подсистемы обмена данными.
Ситуация осложняется тем, что при использовании метода ПланыОбмена.ВыбратьИзменения() данные извлекаются в порядке их регистрации. Если вы сначала изменили характеристику, а затем номенклатуру, в пакет обмена они могут попасть именно в такой последовательности. Если приемник (SQL) ожидает сначала владельца, а затем подчиненного, возникнет ошибка Foreign Key Constraint Violation.
Самый надежный способ гарантировать наличие всех данных в одном пакете — принудительно регистрировать владельцев и связанные справочники при записи основного объекта. Рассмотрим, как это можно реализовать в модуле объекта или через подписки на события.
Проанализируем пример кода для регистрации характеристик при изменении номенклатуры:
Процедура ПриЗаписи(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Определяем узел обмена, для которого нужно зарегистрировать изменения
УзелОбмена = ПланыОбмена.ИнтеграцияСSQL.НайтиПоНаименованию("ОсновнойSQL");
// Регистрируем саму номенклатуру
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ЭтотОбъект.Ссылка);
// Находим и регистрируем все связанные характеристики
ВыборкаХарактеристик = Справочники.ХарактеристикиНоменклатуры.Выбрать(, ЭтотОбъект.Ссылка);
Пока ВыборкаХарактеристик.Следующий() Цикл
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ВыборкаХарактеристик.Ссылка);
КонецЦикла;
КонецПроцедуры
Этот подход гарантирует, что если номенклатура попала в план обмена, то и все её характеристики будут перевыгружены. Однако стоит учитывать нагрузку на систему при больших объемах данных.
В профессиональных интеграциях считается плохим тоном записывать данные из 1С напрямую в рабочие таблицы SQL с включенными ограничениями. Рассмотрим схему с промежуточными таблицами.
Foreign Keys.Если в промежуточную таблицу попала характеристика без номенклатуры, процедура на стороне SQL может либо создать временную «пустую» запись для номенклатуры, либо отложить обработку этой характеристики до появления владельца. Это исключает остановку всего процесса обмена из-за одной ошибки.
Если изменить структуру SQL-базы невозможно, применим тактику «битых ссылок», которая часто используется в стандартных обменах 1С. Выясним, как это работает по шагам:
Шаг 1: Создание заглушек. При получении объекта, ссылающегося на неизвестного владельца, мы не выбрасываем ошибку. Мы проверяем наличие владельца в SQL. Если его нет — создаем в таблице Номенклатура запись, где заполнен только GUID (и, возможно, техническое наименование «Объект не найден»).
Шаг 2: Актуализация данных. Когда в следующем пакете или позже придет полная информация о номенклатуре, мы обновляем уже существующую запись-заглушку всеми реквизитами.
Такой подход позволяет загружать данные в любом порядке, сохраняя целостность связей в базе данных.
Проанализируем ситуацию, когда объем данных велик и мы уверены, что в рамках одного сеанса обмена придут все связанные части. В этом случае на стороне SQL можно временно отключить проверку ограничений.
Перед началом выгрузки 1С может выполнить команду через ADOConnection или External Connection:
ALTER TABLE ТаблицаХарактеристик NOCHECK CONSTRAINT ALL;
После завершения цикла загрузки всех таблиц (Номенклатура, Характеристики, Цены) необходимо включить проверку обратно:
ALTER TABLE ТаблицаХарактеристик WITH CHECK CHECK CONSTRAINT ALL;
Важно: этот метод требует монопольного доступа к таблицам или очень осторожного использования, так как на время загрузки целостность данных в базе SQL не гарантируется для других пользователей.
Если ваш обмен базируется на правилах конвертации данных (КД 2.0 или 3.0), обратим внимание на настройки ПКО (Правил конвертации объектов). Часто ошибка возникает из-за установленного флага «Не выгружать объекты свойств источника по ссылкам».
Посмотрим, как правильно настроить правила:
Владелец в характеристиках) убедитесь, что включена полная выгрузка объекта, а не только передача ссылки.ПередВыгрузкой, чтобы программно проверить наличие владельца в очереди на регистрацию: ПланыОбмена.ИзмененияЗарегистрированы(Узел, Объект.Владелец).Мы рассмотрели несколько стратегий борьбы с «рассинхроном» связанных данных. Выбор конкретного метода зависит от архитектуры вашей системы:
Помните, что порядок выборки из плана обмена не гарантирован, поэтому ваша система-приемник всегда должна быть готова к тому, что «ребенок» (подчиненный объект) может прийти раньше «родителя» (владельца).