При использовании расширений конфигурации в 1С, которые вносят изменения в структуру данных, например, добавляют новые реквизиты, справочники или регистры сведений, в Распределенной Информационной Базе (РИБ) мы можем столкнуться с определенными сложностями. Основная проблема, как правило, проявляется в виде ошибки: "В текущем сеансе существуют изменяющие данные расширения конфигурации, неиспользуемые в распределенной информационной базе". Давайте подробнее разберем, почему возникает эта ошибка и как ее эффективно устранить.
Основной принцип работы РИБ заключается в обеспечении идентичности структуры данных во всех узлах – как в центральной, так и в периферийных базах. Это фундаментальное требование платформы 1С. Если расширение конфигурации добавляет или изменяет метаданные, оно, по сути, меняет структуру базы данных. Если такое расширение подключено только в центральной базе, но не распространяется на подчиненные узлы, платформа 1С воспринимает это как нарушение принципа идентичности структуры.
Даже если мы предполагаем, что новые объекты, добавленные расширением, не должны участвовать в обмене данными, или функциональность расширения не нужна на периферийных узлах, платформа 1С все равно требует, чтобы любое расширение, изменяющее метаданные, было включено в состав обмена РИБ. Игнорирование этого требования приводит к вышеупомянутой ошибке при попытке создания начального образа или выполнении очередного обмена данными.
Рассмотрим эту ситуацию более детально. Мы хотим запустить расширение, которое содержит свои дополнительные данные, но только в центральном узле РИБ. Например, это расширение для обмена с сайтом, и оно добавляет новые справочники или реквизиты. Если мы устанавливаем его без флага "Используется в распределенной ИБ", платформа фиксирует, что структура данных центральной базы отличается от того, что будет в периферийных узлах после обмена. Это несовпадение метаданных и вызывает ошибку. Система ожидает, что если расширение изменяет данные, оно должно быть доступно во всех узлах, чтобы структура данных оставалась единой.
Самое прямое и рекомендуемое решение, которое предлагает платформа 1С, заключается в том, чтобы включить расширение, изменяющее структуру данных, в состав обмена РИБ. Разберем по шагам, как это сделать:
Это первый и самый важный шаг. Откройте расширение в конфигураторе (или через интерфейс в режиме 1С:Предприятие, в разделе "Администрирование" - "Печатные формы, отчеты и обработки" - "Расширения"). В свойствах расширения обязательно установите флажок "Используется в распределенной ИБ". Этот флаг сигнализирует платформе, что данное расширение должно распространяться на все узлы РИБ.
После установки флага у расширения, необходимо убедиться, что ваш план обмена настроен на распространение расширений. Откройте нужный план обмена в конфигураторе, перейдите на вкладку "Прочие" (или аналогичную, в зависимости от версии платформы) и убедитесь, что опция "Включать расширения конфигурации" активна. Это гарантирует, что при выполнении обмена данные расширения будут передаваться в подчиненные узлы.
После выполнения этих двух шагов, при следующем обмене данными или создании начального образа, расширение будет успешно распространено на все подчиненные узлы, и ошибка "В текущем сеансе существуют изменяющие данные расширения конфигурации, неиспользуемые в распределенной информационной базе" исчезнет. Платформа будет считать, что структура данных всех узлов соответствует, поскольку расширение присутствует везде.
Мы выяснили, что расширение, изменяющее метаданные, должно быть во всех узлах РИБ. Однако, часто возникает ситуация, когда функциональность расширения действительно нужна только в центральном узле (например, обмен с сайтом). В этом случае мы не хотим, чтобы код расширения выполнялся в периферийных базах. Для решения этой задачи мы можем использовать проверку на принадлежность узла:
Внутри кода расширения, где сосредоточена его основная функциональность, необходимо вставить проверку, которая будет определять, является ли текущий узел главным (центральным). Для этого используем стандартную функцию 1С ПланыОбмена.ГлавныйУзел().
Например, если у вас есть процедура или функция, которая выполняет обмен с сайтом, ее можно обернуть в такую проверку:
// Процедура, отвечающая за выполнение обмена с сайтом
Процедура ВыполнитьОбменСайт() Экспорт
// Проверяем, является ли текущая база главным узлом РИБ
Если ПланыОбмена.ГлавныйУзел() Тогда
// Если это главный узел, выполняем функциональность расширения
// Например, запускаем обмен с сайтом
Сообщить("Выполняем обмен с сайтом из Главного узла.");
// ... Здесь ваш код обмена с сайтом ...
Иначе
// Если это периферийный узел, ничего не делаем или выводим сообщение
Сообщить("Обмен с сайтом не выполняется, так как это периферийный узел.");
КонецЕсли;
КонецПроцедуры
Таким образом, расширение физически будет присутствовать во всех узлах, поддерживая идентичность структуры данных, но его бизнес-логика будет активироваться только в центральной базе. Это позволяет нам соблюсти требования платформы и при этом не перегружать периферийные узлы ненужной функциональностью.
Механизм работы с расширениями в РИБ постоянно совершенствуется. С версии платформы 8.3.12 обмен расширениями реализован на уровне платформы, что значительно упрощает их распространение. Однако, могут возникнуть и другие нюансы, которые нам необходимо учитывать:
Если в расширении добавляются новые объекты, иногда могут возникнуть проблемы с корректностью записей в системном справочнике "Идентификаторы объектов расширений" в центральном узле. Этот справочник хранит уникальные идентификаторы для объектов, добавленных расширениями. Для актуализации этих данных мы можем использовать специальную процедуру:
Справочники.ИдентификаторыОбъектовРасширений.ОбновитьДанныеСправочника();
Выполнение этой процедуры поможет синхронизировать данные справочника с фактическим составом объектов, добавленных расширениями, и избежать потенциальных ошибок.
Иногда после подключения расширения с новыми объектами мы можем столкнуться с ошибками нарушения прав доступа, даже если все настройки кажутся верными. В таких случаях часто помогает простая очистка кэша 1С. Закройте все сеансы 1С, удалите файлы кэша (обычно находятся в папках AppData) и перезапустите платформу. Это может решить проблему, связанную с некорректно сохраненными данными о правах.
В более сложных сценариях, когда требуется более детальный контроль над тем, какие именно объекты расширения должны участвовать в обмене РИБ, мы можем тонко настраивать это. Это достигается путем явного добавления объектов расширения в состав плана обмена. Более того, при необходимости регистрации изменений для этих объектов (в этом поможет обработка управления регистрацией изменений в РИБ), мы можем создавать в расширении клоны стандартных подписок на события регистрации изменений. Например, для документов это могут быть ПолныйРегистрацияДокумента или ПолныйРегистрацияУдаления. Это позволяет нам добиться гибкого управления поведением расширения в распределенной среде.
Если, по каким-либо причинам, мы совершенно не хотим распространять расширение, изменяющее структуру данных, на узлы РИБ, существуют альтернативные, хотя и более трудоемкие, варианты:
Мы можем перенести все доработки, которые меняют структуру данных (добавление реквизитов, справочников и т.д.), непосредственно в основную конфигурацию. Это решение требует снятия конфигурации с поддержки или работы в режиме частичной поддержки, что может значительно усложнить процесс обновления типовой конфигурации в будущем. Этот путь часто считается менее предпочтительным из-за высоких затрат на поддержку.
Вместо расширений, мы можем реализовать функциональность, требующую дополнительных данных, с помощью внешних механизмов. Например, использовать обмен данными по правилам (с помощью универсального обмена данными) или создать собственные веб-сервисы для взаимодействия с внешними системами или даже между узлами РИБ — для автоматизации такой синхронизации подойдёт настройка регулярного обмена по правилам конвертации. Этот подход дает максимальную гибкость, но требует значительных доработок и разработки собственных правил обмена, что значительно увеличивает сложность проекта.
Для точечного внесения изменений в код и упрощения контроля над обновлением расширений при изменении типовой конфигурации, можно использовать аннотацию &ИзменениеИКонтроль. Она позволяет разработчикам более явно указывать места изменений и контролировать их влияние при обновлении.
В заключение, мы можем сказать, что требование платформы 1С о распространении расширений, изменяющих структуру данных, на все узлы РИБ не является "приговором". Это фундаментальный принцип, обеспечивающий целостность и согласованность данных в распределенной системе. Следуя рекомендациям по включению расширения в обмен РИБ и, при необходимости, ограничивая его функциональность в периферийных узлах с помощью проверки ПланыОбмена.ГлавныйУзел(), мы можем успешно реализовать наши задачи, соблюдая все требования платформы. В более сложных случаях нам доступны и альтернативные, но более трудоемкие, подходы.