При проектировании нового функционала в системе «1С:Предприятие» перед разработчиком неизбежно встает архитектурный вопрос: в каком виде реализовать новую обработку? Стоит ли внедрить её в состав расширения конфигурации или же оставить обособленной в виде внешней обработки? Этот выбор напрямую влияет на производительность системы, удобство администрирования, простоту дальнейшей поддержки и стабильность базы данных при обновлениях. В этой статье мы подробно разберем все аспекты взаимодействия платформы с расширениями и внешними обработками, проанализируем исторический контекст их развития и рассмотрим новые возможности современных версий платформы 1С.
Существует распространенное мнение, основанное на ранних методических материалах ИТС, что объекты внутри расширения работают «ощутимо быстрее», чем внешние обработки. Давайте разберем этот вопрос с технической точки зрения и выясним истинную причину разницы в скорости.
Основное различие в производительности между внешней обработкой и обработкой в расширении заключается в этапе компиляции модулей и инициализации объектов:
Однако, как только этап инициализации завершен, скорость выполнения самого программного кода (алгоритмов заполнения, расчетов, запросов к базе данных) в обоих случаях становится абсолютно одинаковой. Платформа выполняет скомпилированный байт-код с одинаковой скоростью, независимо от того, где физически расположен исполняемый модуль.
Таким образом, разница в скорости работы будет критична только в сценарии, когда одна и та же сложная обработка открывается программно тысячи раз в день (например, в рамках регламентного обмена или массовой потоковой загрузки номенклатуры множеством пользователей). Для интерактивной работы обычного пользователя разница в 0.1 секунды при открытии формы неощутима.
Если производительность выполнения кода одинакова, то критерии выбора смещаются в сторону удобства жизненного цикла разработки. Рассмотрим преимущества использования расширений в контексте администрирования:
Интеграция с системой прав доступа (ролями). В расширении мы можем создавать полноценные роли, назначать права на новые объекты и гибко управлять доступом пользователей через стандартные профили групп доступа. Настроить права на запуск конкретной внешней обработки штатными средствами платформы гораздо сложнее — обычно приходится использовать механизмы БСП (Библиотеки Стандартных Подсистем).
Простота отладки. Программный код в расширениях полностью открыт для сквозной отладки. Разработчик может легко устанавливать точки останова, замерять производительность и анализировать стек вызовов. В случае с внешними обработками для полноценной отладки часто приходится предварительно сохранять их на локальный диск или совершать дополнительные манипуляции в Конфигураторе.
Контроль целостности кода (Синтаксический контроль). Это одно из главных преимуществ расширений. Если в основной конфигурации изменится тип реквизита какого-либо справочника или удалится документ, расширение выдаст ошибку при проверке применимости или синтаксическом контроле. Мы сразу увидим, что наш код сломался. Внешняя же обработка никак не связана с конфигурацией статически. О том, что в ней сломался запрос из-за переименования поля в основной конфигурации, разработчик узнает только в момент выполнения кода пользователем (часто уже в продуктивной базе).
На ранних этапах развития технологии расширений (период версий платформы 8.3.11–8.3.15) разработчики сталкивались со значительными рисками при добавлении собственных реквизитов и объектов в расширения. Основные опасения вызывали следующие ситуации:
Из-за этих архитектурных несовершенств долгое время действовало негласное правило: «Добавлять новые справочники, документы и реквизиты в расширение — моветон и неоправданный риск». Разработчики предпочитали использовать внешние обработки или добавлять дополнительные сведения/реквизиты через механизмы БСП (свойства объектов).
Фирма «1С» проделала колоссальную работу по стабилизации механизма расширений. Многие критические проблемы и ограничения, обсуждавшиеся разработчиками ранее, были полностью устранены в современных версиях платформы.
Рассмотрим ключевые изменения, которые кардинально меняют подход к выбору архитектуры решения:
1. Полноценная поддержка регламентных заданий (с версии платформы 8.3.23). Раньше внутри расширений было невозможно создавать собственные регламентные задания, что вынуждало разработчиков использовать внешние обработки, запускаемые через БСП. Теперь регламентные задания в расширениях поддерживаются нативно, могут работать по расписанию и корректно функционируют как в файловом, так и в клиент-серверном вариантах работы (включая разделение данных).
2. Механизм автоматического заимствования объектов (с версии 8.3.23). Процесс разработки в расширениях стал значительно быстрее. При составлении запросов в конструкторе система автоматически определяет, какие объекты основной конфигурации используются в кодовой базе расширения, и заимствует их без ручного вмешательства программиста.
3. Повышение устойчивости расширений к изменениям и безопасность ТиИ (с версии 8.3.28). В современных версиях платформы реализована надежная защита данных расширений. Даже если конфигурация поставщика претерпевает значительные изменения, платформа предотвращает потерю информации в реквизитах расширений. Разработчик может гибко настраивать правила разрешения конфликтов метаданных, а процедуры Тестирования и Исправления больше не угрожают целостности кастомных таблиц.
4. Двусторонняя видимость объектов (с версии 8.3.28). Ранее внешние обработки были изолированы от метаданных, созданных в расширении. Теперь же объекты расширения полноценно видны во внешних отчетах и обработках в режиме Конфигуратора. Вы можете использовать типы данных расширения в качестве параметров, обращаться к его таблицам в запросах внешних обработок и выводить их в динамические списки.
5. Визуализация измененного кода в среде 1C:EDT. Одной из жалоб разработчиков было неудобство поиска модифицированных участков кода (когда методы основной конфигурации перехватываются с помощью аннотаций &Вместо, &Перед или &После). Современная среда разработки 1C:EDT полностью решила эту проблему: она наглядно маркирует расширяемые процедуры в основном коде и предоставляет удобную сквозную навигацию между основной конфигурацией и всеми активными расширениями.
Несмотря на колоссальные плюсы расширений, внешние обработки все еще остаются незаменимым инструментом в определенных сценариях:
Добавление обработки в состав расширения является приоритетным выбором в следующих случаях:
Мы проанализировали особенности работы обоих механизмов. В современных реалиях платформы «1С:Предприятие» расширения стали зрелым, стабильным и рекомендуемым стандартом для кастомизации прикладных решений. Страхи прошлых лет, связанные с потерей данных при тестировании и исправлении или невозможностью использовать регламентные задания, остались в прошлом благодаря обновлениям платформы версий 8.3.23 и 8.3.28.
Используйте внешние обработки для разовых задач, утилит администрирования и часто меняющихся внешних интеграций. Для реализации постоянного бизнес-функционала, требующего надежности, контроля типов данных, разграничения прав и удобства сопровождения, всегда выбирайте расширения конфигурации.