В современной разработке на платформе 1С:Предприятие 8.3 использование расширений стало стандартом. Однако часто возникает ситуация, когда функционал разрастается, и нам требуется обратиться из одного расширения к объектам (справочникам, регистрам), созданным в другом расширении. Рассмотрим подробнее, как решить задачу подписки на события и доступа к данным в такой многослойной структуре.
Разберем наиболее современный и технологичный способ, который появился в платформе, начиная с версии 8.3.15. До этого момента расширения были изолированы друг от друга, но теперь мы можем явно указать системе, что одно расширение «знает» о существовании другого.
Проанализируем шаги по настройке зависимостей:
РегистрСведений.Важный нюанс: при настройке зависимостей платформа начинает строго контролировать порядок применения. Расширение-донор должно располагаться в списке выше, чем расширение-потребитель. Если мы попытаемся нарушить этот порядок или создать циклическую зависимость (А зависит от Б, а Б от А), система выдаст ошибку при попытке обновления конфигурации базы данных.
После установки связи мы сможем выбирать объекты из другого расширения в качестве источника для подписки на события, как если бы они находились в основной конфигурации.
Иногда, как отмечали участники обсуждения, проще и надежнее объединить связанные объекты в одном расширении. Если расширение для согласования документов и расширение с новыми статусами логически дополняют друг друга, разделение их на два отдельных контейнера может только усложнить поддержку.
Рассмотрим процесс объединения:
.cfe.Этот путь избавляет нас от необходимости контролировать зависимости и порядок загрузки, однако делает расширение более «тяжелым».
Проанализируем ситуацию, описанную в сообщениях форума. Часто добавление новых объектов хранения данных (справочников и регистров) в расширения является архитектурной ошибкой, если эти данные критически важны для бизнеса. Разберем, почему опытные разработчики рекомендуют хранить структуру данных в основной конфигурации.
Риски хранения в расширениях: если кто-то случайно удалит расширение из базы, все данные таблиц, созданных в нем (включая записи вашего регистра сведений), будут безвозвратно удалены из СУБД. При обновлении типовых конфигураций неопытные администраторы могут совершить ошибку, которая приведет к потере данных.
Рассмотрим алгоритм правильного переноса («приземления») объектов:
Пример кода для миграции данных регистра сведений:
Выборка = РегистрыСведений.НашРегистрВРасширении.Выбрать();
Пока Выборка.Следующий() Цикл
МенеджерЗаписи = РегистрыСведений.НовыйРегистрВКонфе.СоздатьМенеджерЗаписи();
ЗаполнитьЗначенияСвойств(МенеджерЗаписи, Выборка);
МенеджерЗаписи.Записать();
КонецЦикла;
После успешного переноса данных и проверки работоспособности кода, объекты в расширении можно удалить, а в расширение добавить уже объекты основной конфигурации для их обработки или изменения логики.
Выясним причину, по которой подписки на события в расширениях иногда ведут себя не так, как ожидается. Подписка в расширении может быть создана для:
Если нам нужно программно реагировать на запись в регистр, мы создаем объект ОбщаяКоманда.ПодпискаНаСобытие в расширении. При этом важно соблюдать стандарты при разработке подписок на события, особенно в высоконагруженных системах. В качестве источника указываем тип нашего регистра, а в качестве обработчика — процедуру в общем модуле расширения. Убедитесь, что у общего модуля установлены флаги Сервер и Внешнее соединение.
Посмотрим на возможности последних версий платформы (8.3.17+). Теперь в контекстном меню объекта, созданного в расширении, доступна команда Перенести в основную конфигурацию. Это значительно ускоряет процесс рефакторинга структуры, о котором мы говорили выше.
Важно: данная команда переносит только структуру метаданных (поля, типы, свойства). Сами данные (записи в таблицах БД) этой командой не переносятся. После выполнения этой операции вам все равно придется воспользоваться обработкой миграции данных, чтобы не потерять историю согласования документов.
При работе с несколькими расширениями крайне важно соблюдать уникальность префиксов имен. Проанализируем типичную проблему: если в Расширении 1 создан объект пр_СтатусСогласования и в Расширении 2 создан объект с точно таким же именем, возникнет конфликт.
Всегда используйте уникальные префиксы для своих разработок (например, Корп_, Dev_, Спец_). Это гарантирует, что при подключении новых расширений или обновлении основной конфигурации вы не столкнетесь с ошибкой дублирования имен в пространстве имен платформы. Для комплексного анализа конфигураций и расширений на наличие ошибок рекомендуется использовать специализированные инструменты — для этого подойдёт архитектурный анализ конфигураций и визуализация зависимостей.
Подводя итог, можно сказать: если ваша задача — быстро настроить связь, используйте механизм зависимостей. Если же вы планируете долгосрочную эксплуатацию системы с большими объемами данных, лучше рассмотреть вариант переноса структуры в основную конфигурацию.