Как настроить синхронизацию данных между базами 1С, если одна из них существенно дорабатывается?

← На главную

При сопровождении систем на базе 1С часто возникает ситуация, когда необходимо настроить регулярный обмен данными между двумя изначально идентичными конфигурациями. Однако стандартный механизм распределенных информационных баз (РИБ) накладывает жесткие ограничения: конфигурации должны оставаться идентичными, и любое изменение в «главном» узле должно быть передано в «подчиненный». Если одна из баз начинает активно дорабатываться (меняются алгоритмы, добавляются новые реквизиты, отчеты или документы), классический РИБ становится обузой, блокирующей развитие системы.

В этой статье мы подробно разберем, как реализовать надежную синхронизацию данных, которая позволит базам «разойтись» по коду и структуре метаданных, сохранив при этом целостность обмена документами и справочниками.

Метод 1. Реализация механизма «РИБ без РИБ»

Проанализируем самый гибкий подход, который часто называют «РИБ без РИБ». Этот метод объединяет в себе мощь механизмов регистрации изменений и гибкость настройки правил обмена. Суть заключается в использовании объекта метаданных ПланОбмена, но без включения признака Распределенная информационная база.

Разберем реализацию по шагам:

Создание Плана обмена: В конфигураторе создадим новый ПланОбмена. В свойствах убедимся, что флаг «Распределенная информационная база» снят. В состав плана обмена включим все документы и справочники, которые должны участвовать в синхронизации. У каждого объекта установим режим авторегистрации «Разрешить».
Регистрация изменений: Теперь система будет автоматически фиксировать изменения объектов в специальной таблице. Чтобы получить список измененных данных программно, мы можем использовать метод ПланыОбмена.ВыбратьИзменения().
Использование Конвертации данных 2.0: Поскольку структуры баз могут начать отличаться (например, в одной базе добавили реквизит ЦветИзделия, а в другой его нет), нам потребуются правила обмена (XML). Создадим их в конфигурации «Конвертация данных 2.0». Это позволит нам гибко сопоставлять поля и игнорировать отсутствующие реквизиты.

Пример кода для выгрузки только измененных данных через созданный план обмена:


// Создаем узел, для которого будем выгружать данные
УзелСсылка = ПланыОбмена.НайтиПоКоду("Узел_001");

// Инициализируем запись XML и обработку обмена
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл("C:\Exchange\data.xml");

// Используем типовую обработку "УниверсальныйОбменДаннымиВФорматеXML"
ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиВФорматеXML.Создать();
ОбработкаОбмена.ИмяФайлаПравил = "C:\Exchange\Rules.xml";
ОбработкаОбмена.УзелОбменаДляРегистрацииИзменений = УзелСсылка;
ОбработкаОбмена.РежимОбмена = "Выгрузка";
ОбработкаОбмена.ВыполнитьВыгрузку();

Метод 2. Расширение «Универсального формата» (EnterpriseData)

Если ваши конфигурации построены на базе БСП (Библиотеки Стандартных Подсистем), рассмотрим использование синхронизации через Универсальный формат (EnterpriseData). Многие пользователи жалуются на «скудный» состав этого обмена, но его можно и нужно расширять.

Выясним, как добавить новые документы в этот формат:

Основная ошибка новичков — попытка вручную править XDTO-пакеты в конфигураторе. Правильный путь — использование конфигурации «Конвертация данных 3.0». В ней описывается маппинг между объектами базы и объектами формата. Если же стандартного объекта формата (например, Документ.ЗаказКлиента) вам недостаточно или его нет в пакете, следует создать Расширение конфигурации.

В расширение добавляется собственный XDTO-пакет, который дополняет стандартный. Это позволяет сохранить основную конфигурацию на поддержке. После описания правил в КД 3.0, вы выгружаете их и подключаете в настройках синхронизации в пользовательском режиме.

Метод 3. Автоматизация обмена через планировщик

Вернемся к вопросу автора о том, как запускать «Универсальный обмен данными в формате XML» по расписанию. Рассмотрим подробнее два варианта решения этой задачи.

Вариант А: Использование параметров командной строки.
Мы можем настроить запуск 1С через планировщик Windows, передавая в параметре /Execute путь к внешней обработке, а в параметре /C — строку с настройками выгрузки.

Вариант Б: Встраивание в Регламентные задания.
Это более профессиональный путь. Создадим в конфигурации обработку, которая будет вызывать процедуру выгрузки. Пример программного вызова выгрузки данных:


Процедура ВыполнитьОбменПоРасписанию() Экспорт
    ПутьКПравилам = "C:\Exchange\Rules.xml";
    ПутьКДанным = "C:\Exchange\Export.xml";
    
    Обмен = Обработки.УниверсальныйОбменДаннымиВФорматеXML.Создать();
    Обмен.ИмяФайлаПравил = ПутьКПравилам;
    Обмен.ИмяФайлаДанных = ПутьКДанным;
    Обмен.РежимОбмена = "Выгрузка";
    
    // Указываем узел плана обмена для выгрузки изменений
    Обмен.УзелОбменаДляРегистрацииИзменений = ПланыОбмена.СинхронизацияБаз.НайтиПоКоду("Б2");
    
    Обмен.ВыполнитьВыгрузку();
    
    // После успешной выгрузки можно очистить регистрацию
    // (обычно это делается после подтверждения приема на стороне получателя)
КонецПроцедуры

Метод 4. Синхронизация через HTTP-сервисы (On-line режим)

Если конфигурации сильно расходятся или требуется мгновенная передача данных, проанализируем архитектуру с использованием HTTPСервисы. Это современный стандарт интеграции.

Разберем по шагам логику работы:

На стороне приемника: Создаем HTTP-сервис с методом POST. Этот метод будет принимать JSON или XML, парсить его и записывать объект в базу.
На стороне источника: В модуле объекта (например, документа) в событии ПриЗаписи добавляем код, который отправляет данные на сервер-приемник.

Важно! Чтобы избежать бесконечного цикла обмена, всегда проверяйте свойство ОбменДанными.Загрузка. Посмотрим на пример кода:


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    // Если данные загружаются из обмена, не инициируем новую отправку
    Если ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    // Логика формирования JSON и отправки через HTTPСоединение
КонецПроцедуры

Важные нюансы при работе с «неидентичными» базами

При реализации любого из перечисленных методов необходимо учитывать следующие технические моменты:

Уникальные идентификаторы (GUID):
Главная проблема синхронизации — дублирование данных. Всегда синхронизируйте объекты по их внутреннему идентификатору (GUID). В правилах обмена (КД 2.0 или 3.0) установите флаг «Искать по уникальному идентификатору». Это гарантирует, что при изменении названия контрагента в одной базе, во второй базе обновится тот же самый объект, а не создастся новый.

Свойство ОбменДанными.Загрузка:
При программной записи объектов, полученных из другой базы, обязательно устанавливайте ОбменДанными.Загрузка = Истина. Это отключает проверки в модулях объектов (например, контроль остатков), которые могут помешать загрузке данных, и предотвращает зацикливание обмена.

Контроль структуры данных:
Если в базе-приемнике были добавлены обязательные для заполнения реквизиты, которых нет в базе-источнике, обязательно пропишите алгоритмы их заполнения «по умолчанию» в правилах конвертации или в коде загрузки. В противном случае объект не пройдет валидацию и не будет записан.

Таким образом, для решения задачи автора наиболее оптимальным будет использование Планов обмена без признака РИБ в сочетании с Универсальным обменом в формате XML. Это позволит автоматизировать выгрузку только измененных данных и обеспечит гибкость при дальнейшем развитии конфигураций.