При работе с распределенными информационными базами (РИБ) в среде 1С:Предприятие 8.3 администраторы и разработчики часто сталкиваются с неприятной ситуацией: обмен данными (документами, справочниками, ценами) функционирует абсолютно корректно и регулярно, однако измененная в центральной базе конфигурация упорно отказывается «лететь» в подчиненные (периферийные) узлы. Особенно часто эта проблема проявляется при тонких настройках прав доступа — например, когда в конфигураторе изменяются права существующих стандартных ролей для конкретных документов.
В данной статье мы подробно разберем, почему возникает эта проблема, проанализируем механизмы регистрации изменений платформы 1С и рассмотрим несколько надежных практических способов ее решения — от обходных маневров без снятия с поддержки до современных стандартов с использованием расширений конфигурации и классического метода пересоздания связи узлов.
Выясняем причину: почему изменения конфигурации «застревают» при обмене по РИБ?
Чтобы понять, как решить проблему, давайте проанализируем внутреннее устройство механизмов обмена 1С. Когда в главном узле РИБ происходит изменение метаданных (свойств объектов, модулей или прав доступа в ролях) и выполняется обновление конфигурации базы данных (клавиша F7), платформа должна автоматически зарегистрировать это изменение для всех существующих подчиненных узлов.
Однако на практике этот механизм имеет определенную «гранулярность» и может давать сбои по следующим причинам:
Особенности регистрации изменений стандартных ролей. Если конфигурация находится на поддержке, изменение галочек прав доступа внутри стандартных ролей иногда классифицируется платформой как «незначительное» изменение. В результате компилятор метаданных не выставляет флаг регистрации изменения конфигурации для плана обмена РИБ. Изменения применились локально в центральной базе, но пакет обновления конфигурации для подчиненных узлов просто не сформировался.
Динамическое обновление («демоническое обновление»). Постоянное применение обновлений конфигурации в режиме «на лету» (без выгона пользователей) очень часто ломает последовательность номеров сообщений обмена конфигурацией. Платформа теряет информацию о том, в какой момент подчиненный узел должен принять изменения, и передача конфигурации блокируется, при этом обычный обмен данными продолжает ходить.
Блокировка фоновыми заданиями или активными сеансами в подчиненном узле. Файл обмена с обновлением конфигурации может успешно дойти до подчиненного узла, но база не сможет применить его, если в этот момент в ней работают пользователи или выполняются регламентные задания. Узел «зависает» в ожидании монопольного обновления конфигурации базы данных.
Ниже мы подробно рассмотрим три практических метода решения этой проблемы.
Способ 1. Искусственная инициация регистрации изменений (Метод новой роли)
Это самый простой способ, который обнаружил автор темы экспериментальным путем. Он позволяет решить проблему прямо из конфигуратора центральной базы без необходимости отвязывать подчиненные узлы и прерывать рабочий процесс.
Суть метода заключается в том, что добавление в конфигурацию абсолютно нового объекта (в данном случае новой роли) заставляет платформу гарантированно перестроить структуру таблиц и зафиксировать глобальное изменение конфигурации для планов обмена. «Прицепом» к новой роли улетают и все ранее сделанные изменения в правах существующих объектов.
Рассмотрим этот процесс по шагам:
Откроем конфигуратор центральной информационной базы.
Перейдем в ветку Общие -> Роли и добавим новую роль (например, с именем ОграничениеПроведенияДокументов).
Для необходимых документов (в нашем примере это документы оприходования, списания и пересортицы товаров) настроим в новой роли все права, кроме права Проведение.
Обновим конфигурацию базы данных центрального узла (нажатием клавиши F7). Крайне важно выполнять обновление монопольно, убедившись, что все пользователи вышли из системы. Не используйте динамическое обновление!
Выполним сеанс синхронизации данных в центральном узле.
Платформа обнаружит появление нового объекта метаданных и гарантированно зарегистрирует изменение конфигурации. При следующем обмене файл с обновлением конфигурации улетит в подчиненный узел.
В подчиненном узле принимаем файл обмена, завершаем работу всех пользователей, заходим в конфигуратор и обновляем конфигурацию базы данных (F7).
Теперь новая роль появилась в подчиненном узле. Переходим в режим «1С:Предприятие» в подчиненном узле и в профилях групп доступа заменяем старую стандартную роль (которая позволяла проводить документы) на нашу новую созданную роль.
Способ 2. Отключение подчиненного узла от РИБ, ручное обновление и обратное подключение
Если конфигурация в подчиненном узле настолько сильно рассинхронизировалась с центральной базой, что автоматический обмен файлами обновлений заблокирован, придется использовать классический метод ручной «перепривязки» базы.
Рассмотрим детальный алгоритм этого процесса:
В конфигураторе центральной базы выгрузим конфигурацию в файл. Для этого выберем пункт меню Конфигурация -> Сохранить конфигурацию в файл... и сохраним файл с расширением .cf (например, cb_main.cf).
Перейдем к подчиненному узлу. Нам необходимо временно «отвязать» базу от главного узла, чтобы получить возможность вносить изменения в конфигурацию на месте.
Запустим подчиненную базу в режиме «1С:Предприятие». Снять признак подчиненности можно программно с помощью короткого скрипта на встроенном языке 1С. Откроем консоль кода или внешнюю обработку и выполним следующую команду:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Также отключить узел можно при запуске платформы из командной строки с использованием специального ключа /ResetMasterNode.
После выполнения этой команды подчиненная база становится полностью самостоятельной, а замок редактирования метаданных в конфигураторе снимается.
Откроем конфигуратор теперь уже «отвязанной» подчиненной базы. Выберем пункт меню Конфигурация -> Сравнить, объединить с конфигурацией из файла... (или воспользуемся полной загрузкой через Загрузить конфигурацию из файла...) и укажем ранее сохраненный файл cb_main.cf.
Применим изменения конфигурации базы данных (клавиша F7). Теперь конфигурации центрального и подчиненного узлов стали абсолютно идентичными.
Возвращаем базу обратно в структуру РИБ. Для этого в режиме «1С:Предприятие» подчиненного узла нам нужно выполнить код, который снова назначит центральную базу главным узлом:
// Находим ссылку на узел главного узла в плане обмена РИБ
ИмяПланаОбмена = "Полный"; // Укажите имя вашего плана обмена РИБ
КодГлавногоУзла = "ЦБ"; // Укажите код центральной базы
ГлавныйУзел = ПланыОбмена[ИмяПланаОбмена].НайтиПоКоду(КодГлавногоУзла);
Если ЗначениеЗаполнено(ГлавныйУзел) Тогда
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
ПоказатьПредупреждение(,"Связь с главным узлом успешно восстановлена!");
Иначе
ПоказатьПредупреждение(,"Ошибка: Главный узел не найден. Проверьте имя плана обмена и код!");
КонецЕсли;
Запускаем обмен данными и проверяем, что синхронизация снова работает в штатном режиме без ошибок метаданных.
Способ 3. Использование расширений конфигурации (Современный стандарт разработки)
Редактирование стандартной конфигурации напрямую (даже с сохранением поддержки) — это устаревший подход, создающий массу сложностей при последующих обновлениях «1С:Управление торговлей». Современный и безопасный стандарт решения подобных задач — использование механизмов Расширений конфигурации.
Проанализируем преимущества этого подхода и шаги по его реализации:
В центральной базе создаем новое расширение конфигурации (тип расширения — «Адаптация»).
Добавляем в расширение нужные документы (оприходование, списание, пересортица) и заимствуем необходимые роли.
Внутри расширения деактивируем права на проведение документов для требуемых ролей. Основная конфигурация при этом остается полностью типовой и находится на поддержке без каких-либо изменений.
Начиная с версии платформы 8.3.12, расширения умеют автоматически передаваться по каналам РИБ. Для этого в свойствах вашего плана обмена в конфигураторе должна быть установлена галочка Включать расширения конфигурации.
Если данная опция включена, при очередной синхронизации расширение само прилетит на все подчиненные узлы и применится к ним без зависаний обмена.
Как проверить, зарегистрировано ли обновление конфигурации к отправке?
Чтобы не гадать, «улетело» обновление в РИБ или нет, мы можем воспользоваться штатным инструментом платформы 1С:
В режиме «1С:Предприятие» в центральной базе перейдем в меню Функции для технического специалиста (ранее — «Все функции»).
Найдем и откроем стандартную обработку Регистрация изменений для обмена.
В появившемся окне выберем наш план обмена РИБ и выделим строку конкретного подчиненного узла.
В верхней части дерева зарегистрированных объектов обратите внимание на узел Конфигурация.
Если напротив него стоит маркер регистрации (цифра 1 или иконка), это означает, что платформа зафиксировала изменения и отправит их с ближайшим файлом обмена. Если в этой строке пусто, то сколько бы сеансов синхронизации вы ни запускали, конфигурация на периферии не обновится — в этом случае используйте искусственное изменение метаданных, описанное в Способе 1.