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