Вопрос проектирования системы обмена данными в 1С:Предприятие является одной из наиболее ответственных задач при разработке масштабных систем. Представим ситуацию: у нас есть несколько типов объектов (например, справочники «Контрагенты», «Номенклатура» и документы «Заказы»), которые должны участвовать в пяти различных обменах с разными базами-корреспондентами. Состав объектов в каждом обмене уникален. Возникает закономерный вопрос: создавать ли под каждый обмен отдельный ПланОбмена в метаданных или попытаться объединить их в одну структуру?
В этой статье мы подробно разберем теоретические и практические аспекты построения планов обмена, проанализируем влияние архитектурных решений на производительность базы данных и выясним, какие подходы считаются «лучшими практиками» в современной разработке на платформе 1С.
Рассмотрим подход, при котором для каждого из пяти обменов создается свой собственный объект метаданных ПланОбмена. На первый взгляд, это кажется логичным и удобным с точки зрения настройки состава объектов.
Преимущества этого подхода:
Недостатки и риски:
Основной проблемой здесь становится избыточность метаданных и нагрузка на СУБД. Проанализируем ситуацию на уровне SQL. Для каждого объекта, включенного в состав плана обмена, система создает отдельную таблицу регистрации изменений. Если один и тот же справочник включен в 5 разных планов, в базе данных будет создано 5 физических таблиц регистрации для этого справочника. При каждой записи объекта 1С будет вынуждена записывать данные во все 5 таблиц в рамках одной транзакции, что существенно повышает риск возникновения взаимоблокировок (deadlocks) и замедляет работу пользователей.
Рассмотрим альтернативный, более современный подход: мы создаем один ПланОбмена, включаем в его состав все необходимые объекты, а разделение логики производим на уровне узлов этого плана обмена.
В этом случае каждая база-корреспондент будет представлена отдельным элементом (узлом) в рамках одного плана обмена. Рассмотрим подробнее, как реализовать фильтрацию данных, чтобы первый узел получал только первый справочник, а третий — все три.
Механизм программной регистрации:
Вместо использования стандартной автоматической регистрации (свойство «Авторегистрация» — «Разрешить»), мы можем управлять процессом вручную или через правила регистрации. Разберем пример реализации через подписки на события или в модуле объекта:
Процедура ПередЗаписьюОбъекта(Источник, Отказ)
// Определяем, для каких узлов нужно зарегистрировать изменения
ПланыОбмена.ЗарегистрироватьИзменения(УзелДляОбменаСБухгалтерией, Источник);
Если Источник.ВидОбъектаПодходитДляСайта Тогда
ПланыОбмена.ЗарегистрироватьИзменения(УзелДляОбменаССайтом, Источник);
КонецЕсли;
КонецПроцедуры
Этот подход позволяет гибко управлять составом данных, не создавая лишних объектов в дереве метаданных. Мы прописываем логику один раз, и она эффективно работает для любого количества узлов.
Проанализируем ситуацию с точки зрения высоконагруженных систем. Использование минимального количества планов обмена предпочтительнее по следующим причинам:
Если вы разрабатываете современную конфигурацию, крайне рекомендуется использовать подсистему «Синхронизация данных» из состава БСП. В ней уже реализована концепция универсального плана обмена. Выясним, как это работает:
СинхронизацияДанныхЧерезУниверсальныйФормат).Это позволяет конечному пользователю или администратору системы менять состав обмена вообще без внесения изменений в конфигуратор. Вы можете добавить фильтр «выгружать только документы по конкретной организации для этого узла», и система сама будет управлять регистрацией изменений.
Несмотря на общую рекомендацию минимизировать количество планов, существуют исключения. Рассмотрим ситуации, когда разделение оправдано:
Подводя итог нашему анализу, сформулируем правила выбора архитектуры:
Таким образом, правильнее сделать один универсальный план обмена (если базы имеют схожую природу данных) и настроить в нем пять узлов. Это обеспечит максимальную производительность SQL-сервера и упростит дальнейшее развитие системы синхронизации.