Разработка в экосистеме 1С:Предприятие непрерывно развивается, и механизм расширений конфигурации давно перестал быть просто инструментом для быстрого перехвата процедур. Сегодня расширения позволяют полноценно кастомизировать прикладные решения, добавляя новые справочники, документы, регистры и даже изменяя существующую структуру базы данных. Однако работа с данными в расширениях имеет множество скрытых нюансов, связанных с версиями платформы, производительностью СУБД и жесткими правилами публикации в облачных сервисах, таких как 1С:Фреш.
В этой статье мы подробно разберем, как эволюционировал механизм добавления объектов через расширения, как изменения структуры данных влияют на СУБД, а также детально рассмотрим современные требования к разработке под облачные решения.
Для того чтобы понять, почему в сети встречается противоречивая информация о возможности добавления документов через расширения, проанализируем хронологию развития этого функционала в платформе 1С:
ЗаказПокупателя в расширении и фиксировать движения по собственному регистру накопления).Разберем по шагам, как правильно создать документ в расширении, чтобы избежать конфликтов и ошибок компиляции:
РежимСовместимости установлено в значение, поддерживающее расширение данных (рекомендуется использовать режим без совместимости или версию не ниже 8.3.12).Расширение1_ПоступлениеТоваровУслуг).Контрагенты или Номенклатура), мы должны найти эти справочники в дереве основной конфигурации, нажать по ним правой кнопкой мыши и выбрать пункт "Добавить в расширение". Важно: мы не переносим сами объекты, мы лишь создаем в расширении информацию об их типах, чтобы платформа могла ссылаться на них.Многие разработчики не задумываются о том, что происходит под капотом СУБД (MS SQL, PostgreSQL), когда мы добавляем новые реквизиты к существующим документам через расширение. Проанализируем эту ситуацию с точки зрения производительности HighLoad-систем:
Когда мы заимствуем типовой документ и добавляем в него новый реквизит или новую табличную часть в расширении, платформа 1С не выполняет прямую команду ALTER TABLE для основной таблицы СУБД. Вместо этого в базе данных создается вспомогательная физическая таблица с суффиксом _x1 (например, если основная таблица документа была _Document150, то для расширенных реквизитов будет создана таблица _Document150_x1).
При любой выборке данных этого документа, формировании динамических списков или проведении платформа выполняет неявное соединение (оператор LEFT OUTER JOIN) основной таблицы с таблицей расширения по уникальному идентификатору ссылки (RefID). В высоконагруженных системах (HighLoad) обилие таких соединений способно критически снизить скорость работы СУБД и вызвать взаимоблокировки.
Альтернативный паттерн проектирования: Чтобы избежать деградации производительности СУБД, опытные архитекторы рекомендуют вместо добавления реквизитов непосредственно в заимствованный документ создавать в расширении собственный независимый Регистр Сведений. В качестве измерения этого регистра мы устанавливаем ссылку на заимствованный документ, а в ресурсах храним все необходимые дополнительные реквизиты. Рассмотрим пример программной записи дополнительных данных в такой регистр при проведении документа:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Подготовим набор записей нашего расширенного регистра сведений
НаборЗаписей = РегистрыСведений.Расш1_ДопРеквизитыДокументов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ДокументСсылка.Установить(ЭтотОбъект.Ссылка);
НоваяСтрока = НаборЗаписей.Добавить();
НоваяСтрока.ДокументСсылка = ЭтотОбъект.Ссылка;
НоваяСтрока.ДополнительноеСвойство = ЭтотОбъект.Расш1_ВременныйРеквизитФормы;
Попытка
НаборЗаписей.Записать(Истина);
Исключение
ЗаписатьЛогТранзакции("Ошибка записи дополнительных реквизитов: " + ОписаниеОшибки());
Отказ = Истина;
КонецПопытки;
КонецПроцедуры
В прошлом сервис 1С:Фреш не принимал к публикации расширения, которые создавали собственные таблицы в СУБД (справочники, документы, табличные части), из-за сложности их администрирования и рисков нарушения целостности мультиарендной базы данных. Сейчас ситуация кардинально изменилась. Проанализируем современные правила публикации таких расширений:
1. Каркасные версии (Frame-версии): Для безопасного обновления структуры метаданных в облаке сервис автоматически генерирует каркасную версию расширения (файл с расширением .frame.cfe). Эта версия содержит исключительно структуру данных (метаданные документов, справочников и регистров) и полностью лишена исполняемого кода. Каркасная версия устанавливается на уровне всей облачной ноды, позволяя СУБД безопасно провести реструктуризацию таблиц, в то время как программный код расширения работает изолированно для конкретного арендатора.
2. Жесткие требования аудита безопасности: Любое расширение, содержащее свои объекты данных, проходит обязательный детальный ручной аудит специалистами фирмы 1С. Выясним основные причины, по которым расширение может отклонить аудит:
COMОбъект или обращение к файловой системе сервера напрямую).3. Риски потери данных при удалении расширений: Это один из наиболее критичных аспектов для администраторов облачных баз. Рассмотрим механизм удаления расширения. Если пользователь удаляет расширение, создавшее новые документы или реквизиты, платформа физически удаляет соответствующие таблицы _x1 из СУБД. Все накопленные пользователями данные в этих полях будут безвозвратно утеряны. Поэтому перед любым изменением, отключением или удалением расширений, влияющих на структуру данных, необходимо в обязательном порядке создавать резервную копию информационной базы.