При настройке обмена данными между конфигурациями на платформе 1С:Предприятие с использованием Конвертации данных 2.1 (КД 2.1) часто возникает специфическая задача: необходимо ограничить выгрузку объектов таким образом, чтобы в базу-приемник попадали изменения только по тем элементам (например, контрагентам, организациям или документам), которые уже были сопоставлены ранее. Это позволяет избежать "замусоривания" приемника новыми объектами, которые должны создаваться только по определенному регламенту или вручную.
В этой статье мы подробно разберем, как реализовать механизм регистрации к синхронизации только сопоставленных объектов, проанализируем различные архитектурные подходы — от простых флагов до использования HTTP-сервисов и зеркалирования регистров.
Рассмотрим вариант, предложенный в обсуждении: проверку наличия связи в реальном времени. Основная сложность заключается в том, что информация о сопоставлении (связь между уникальными идентификаторами источника и приемника) хранится в базе-приемнике в регистре сведений СоответствияОбъектовИнформационныхБаз. База-источник "не знает", сопоставлен объект или нет.
Проанализируем алгоритм реализации через HTTP-сервис:
GET, который принимает GUID объекта источника.СоответствияОбъектовИнформационныхБаз и проверяет наличие записи.ПриРегистрацииИзменения (или в правилах регистрации объектов в КД) выполняется вызов этого сервиса.Пример логики в обработчике регистрации (база-источник):
// Обработчик ПриРегистрацииИзменения
Если ТипЗнч(Данные) = Тип("СправочникСсылка.Контрагенты") Тогда
УИД_Источника = Строка(Данные.УникальныйИдентификатор());
// Выполняем HTTP-запрос к приемнику
РезультатПроверки = ПроверитьСопоставлениеНаСторонеПриемника(УИД_Источника);
Если Не РезультатПроверки Тогда
Отказ = Истина; // Отменяем регистрацию, так как объект не сопоставлен
КонецЕсли;
КонецЕсли;
Важное замечание: Выполнение HTTP-запроса на каждый объект при массовой записи может критически замедлить работу системы. Выясним, как это оптимизировать: используйте кэширование результатов в параметрах сеанса или передавайте массив идентификаторов (Batching), если регистрация происходит пакетно.
Разберем более надежный с точки зрения производительности способ. Вместо того чтобы каждый раз опрашивать приемник, мы можем передать информацию о связях обратно в источник. Это исключает зависимость от доступности сети в момент записи объекта пользователем.
Пошаговый план реализации:
ЛокальныеСоответствияОбъектов) с измерениями СобственныйОбъект и УИД_Приемника.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ЛокальныеСоответствия.СобственныйОбъект
|ИЗ
| РегистрСведений.ЛокальныеСоответствияОбъектов КАК ЛокальныеСоответствия
|ГДЕ
| ЛокальныеСоответствия.СобственныйОбъект = &Объект";
Запрос.УстановитьПараметр("Объект", Данные);
Если Запрос.Выполнить().Пустой() Тогда
Отказ = Истина;
КонецЕсли;
Если нам не важен конкретный GUID в приемнике, а нужно просто знать, что объект уже однажды "ушел" в синхронизацию, можно использовать дополнительный реквизит или запись в простом регистре сведений на стороне источника.
Рассмотрим ситуацию: при первой (ручной) выгрузке объекта мы устанавливаем флаг Синхронизирован = Истина. В правилах регистрации (ПВД) прописываем условие: регистрировать изменения только если этот флаг установлен. Это гарантирует, что новые (черновые) объекты не попадут в обмен автоматически до тех пор, пока ответственный сотрудник не инициирует их первичную выгрузку.
Иногда целесообразно позволить объектам регистрироваться в плане обмена, но отсекать их непосредственно в момент формирования файла выгрузки. В КД 2.1 для этого используется обработчик ПередОбработкой в ПВД.
Посмотрим на пример кода в ПВД:
// Обработчик ПередОбработкой
// Проверяем, нужно ли выгружать данный конкретный объект
Если ТипЗнч(Объект) = Тип("СправочникСсылка.Организации") Тогда
// Здесь может быть логика проверки наличия связи
Если Не ОбъектДолженБытьВыгружен(Объект) Тогда
Отказ = Истина;
КонецЕсли;
КонецЕсли;
Этот метод более гибок, так как позволяет управлять выгрузкой без очистки таблицы регистраций. Однако стоит помнить, что если объектов много, а выгружаться будут единицы, "хвост" невыгруженных регистраций в плане обмена будет расти, что потребует периодической очистки.
Проанализируем возможности современных конфигураций. Если ваш обмен построен на базе БСП, вы можете использовать типовой функционал фильтрации данных. В настройках синхронизации (в пользовательском интерфейсе) часто доступны фильтры по организациям или складам.
Для реализации проверки сопоставления на уровне БСП можно переопределить программный интерфейс ПланыОбмена.ДанныеДляОтправки или использовать подписки на события, которые штатно встроены в подсистему обмена данными. БСП умеет разделять "первичный" образ данных и "изменения", что позволяет более тонко настроить сценарии синхронизации.
Выясним еще один вариант: асинхронный анализ. Чтобы не тормозить работу пользователя при записи объекта (особенно если проверка сопоставления долгая), можно реализовать регламентное задание.
COM или Web-сервис).ПланыОбмена.УдалитьРегистрациюИзменений().Подведем итог. Выбор метода зависит от требований к скорости работы и архитектуры систем:
ВыгружалсяРанее в самой базе-источнике.Помните, что любая логика в обработчиках регистрации напрямую влияет на отзывчивость интерфейса для конечного пользователя. Старайтесь минимизировать количество тяжелых запросов внутри транзакции записи объекта.