Первым способом доработки типовых конфигураций 1С были внешние обработки. Они появились еще в версиях 7.7 и позволяли добавлять функционал, не трогая основной программный код. С выходом платформы 8.3.6 (и особенно 8.3.10) появился механизм расширений, который перевернул представление о модификации. Теперь разработчик может встраивать изменения на уровне метаданных, оставаясь в парадигме поддерживаемости.
Данная статья — глубокое погружение в оба механизма, их внутреннее устройство, критерии выбора и стратегии совместного использования.
Внешние обработки: детальный разбор
Внешняя обработка — это файл с расширением .epf или .erf (для отчетов), который существует независимо от основной конфигурации базы данных. Это обособленный модуль, способный выполнять практически любые действия с данными, но ограниченный в возможностях модификации интерфейса и логики работы существующих объектов.
Архитектура внешней обработки
Внешняя обработка имеет ту же структуру, что и объект конфигурации «Обработка»:
|
Формы |
Для взаимодействия с пользователем |
|
Макеты |
Для хранения шаблонов печатных форм и отчетов |
|
Реквизиты |
Данные, которые обработка хранит в своем контексте |
|
Команды |
Действия, которые пользователь может выполнить |
Её модули (модуль объекта, модули форм) существуют в изоляции. Они не видят экспортные процедуры типовых объектов напрямую (только через общие модули конфигурации или через создание объекта типа Документы.ИмяДокумента). Это создает эффект «песочницы»: ошибка во внешней обработке вряд ли приведет к фатальному сбою всей системы, но и возможности по интеграции ограничены.
Регистрация внешних обработок в системе
Для того чтобы внешняя обработка интегрировалась в интерфейс (например, появилась в разделе «Дополнительные отчеты и обработки» или в списке печатных форм документа), она должна экспортировать функцию СведенияОВнешнейОбработке().
После регистрации в справочнике «Дополнительные отчеты и обработки» такая внешняя обработка появляется в соответствующих разделах интерфейса и может быть назначена конкретным пользователям через роли.
Производительность и безопасность внешних обработок
Важный нюанс: При открытии внешней обработки её модули компилируются заново. Если 50 пользователей одновременно откроют одну и ту же обработку, она будет скомпилирована в памяти 50 раз (в отличие от объекта конфигурации, который компилируется один раз и кэшируется). Это создает нагрузку на сервер. На практике это заметно только для очень больших и сложных обработок с тысячами строк кода, но забывать об этом не стоит.
Ограничения внешних обработок
Несмотря на всю мощь, внешние обработки имеют принципиальные ограничения:
- Не могут добавлять новые реквизиты в существующие объекты метаданных.
- Не могут переопределять поведение типовых форм и модулей (кроме случая с "Заполнением объектов", где обработка вызывается из формы документа).
- Не могут создавать новые документы, справочники или регистры (только работать с существующими).
- Не могут влиять на командный интерфейс и подсистемы.
Расширения: глубокая интеграция
Расширение — это самостоятельный слой конфигурации, который как бы "накладывается" на основной. Все изменения, сделанные в расширении, для платформы выглядят так, будто они всегда были частью основной конфигурации. При этом оригинальная конфигурация остается нетронутой и полностью поддерживаемой.
Что можно делать в расширении?
- Платформа постоянно расширяет возможности расширений. На сегодняшний день можно:
- Добавлять новые объекты метаданных: подсистемы, роли, общие формы, общие модули, константы, регистры сведений (ограниченно).
- Модифицировать существующие объекты:
- Добавлять реквизиты и табличные части в документы, справочники, регистры.
- Добавлять формы и макеты.
- Добавлять команды и кнопки на формы.
- Изменять модули существующих объектов с помощью аннотаций (см. ниже).
- Переопределять элементы интерфейса: изменять командный интерфейс, настраивать видимость кнопок в зависимости от ролей.
Жизненный цикл и обновление
Расширения хранятся в базе данных отдельно, в собственной таблице. При обновлении основной конфигурации происходит проверка расширений на совместимость. Платформа анализирует, не изменились ли объекты и методы, которые использует расширение.
Если в основной конфигурации процедура, которую мы переопределили через&Вместо, была удалена или изменила набор параметров, расширение будет помечено как "Требует проверки" и автоматически отключено до вмешательства разработчика.
Если изменения не затрагивают используемые расширением объекты, обновление проходит незаметно для пользователя.
Этот механизм гарантирует, что некорректное расширение не сможет "положить" систему после обновления — оно просто перестанет применяться, а администратор получит уведомление.
Сравнительная таблица и глубокий анализ
Для наглядности сведем ключевые различия в таблицу, а затем разберем нюансы.
|
Критерий |
Внешняя обработка |
Расширение конфигурации |
|
Тип изменений |
Работа с данными, алгоритмы |
Изменение структуры метаданных, логики, интерфейса |
|
Влияние на поддержку |
Не требует снятия с поддержки |
Не требует снятия с поддержки |
|
Интеграция в интерфейс |
Через объекты |
Нативная, как часть конфигурации |
|
Производительность |
Компиляция на каждый запуск, выше нагрузка |
Кэшируется как основной код, высокая |
|
Сложность разработки |
Низкая |
|
|
Риск при обновлении |
Минимальный |
Средний |
Критическое различие: контекст выполнения
Внешняя обработка работает в своем собственном контексте. Ей недоступны экспортные процедуры модуля объекта документа, если она не создаст этот документ как объект. Она не может просто так вызвать внутренние служебные процедуры типовой конфигурации.
Расширение работает в контексте основной конфигурации. Для него все экспортные процедуры и функции типовых объектов доступны так же, как если бы они были написаны в самой конфигурации. Это дает огромную гибкость, но и требует от разработчика глубокого понимания внутренней логики типового решения.
Критерии выбора: чек-лист для разработчика
Предлагаю использовать следующий алгоритм при принятии решения.
Определите цель изменения:
- Это просто работа с данными? (массовое изменение реквизитов, разовые операции) -> Внешняя обработка. Пользователь откроет её, сделает дело и закроет. Незачем "засорять" конфигурацию.
- Это изменение бизнес-логики? (новые условия проведения, перерасчет сумм, дополнительные проверки при записи) -> Расширение. Только оно позволяет внедриться в существующие алгоритмы.
- Это добавление нового реквизита или колонки? -> Расширение. Без расширения новый реквизит не появится ни в формах, ни в запросах.
- Это новый отчет? -> Любой вариант.
Если отчет простой, не использует сложных общих модулей и его будут часто дорабатывать под требования конкретного пользователя — выбирайте внешний отчет. Его легко заменить без обновления конфигурации.
Если отчет должен быть глубоко интегрирован, использовать общие модули конфигурации, располагаться в определенном разделе интерфейса и быть доступным по ролям — выбирайте расширение.
Оцените сложность обновления и сопровождения:
- Внешние обработки: Обновление сводится к замене файла на сервере или в базе данных (если они хранятся в справочнике). Никаких конфликтов с обновлением платформы не возникает, если только разработчики не переименовали используемые обработкой объекты.
- Расширения: Требуют проверки при каждом обновлении типовой конфигурации. Необходимо иметь тестовый стенд, где можно проверить работоспособность расширения с новым релизом. Это увеличивает стоимость сопровождения, но дает взамен более глубокую интеграцию.
Стратегии совместного использования
На практике эти два инструмента не исключают, а дополняют друг друга. Существует несколько эффективных стратегий их совместного применения:
1. Прототипирование с миграцией
Начинайте разработку нового функционала как внешней обработки. Это позволяет быстро проверить гипотезу, отладить алгоритмы в изолированной среде, не рискуя нарушить работу основного интерфейса.
Когда логика отлажена и требуется глубокая интеграция (например, добавление реквизита или кнопки на форму), переносите код в расширение. Многие разработчики так и делают: внешняя обработка служит "полигоном", а затем превращается в часть расширения.
2. Модульное расширение с «тяжелым» функционалом
Хорошей практикой является вынесение сложных алгоритмов во внешние обработки, которые вызываются из расширения. Например, расширение добавляет кнопку на форму документа. При нажатии на кнопку создается и открывается внешняя обработка, которой в параметры передается текущий документ.
Это разгружает расширение (его проще обновлять) и сохраняет гибкость: внешнюю обработку можно дорабатывать независимо.
3. Типичные ошибки
Когда в компании накапливаются десятки внешних обработок, разбросанных по разным папкам, начинается хаос. Пользователи путаются, обработки теряются, появляются дубли.
Решение:
Все внешние обработки должны храниться централизованно в справочнике «Дополнительные отчеты и обработки» в самой базе данных, с четким распределением по ролям.
4. Превращение расширения в «хаос»
Стремление решить все задачи через одно расширение приводит к тому, что оно разрастается, становится трудносопровождаемым и начинает конфликтовать само с собой.
Решение:
Разбивайте функционал на тематические расширения (например, "Расширение для продаж", "Расширение для склада", "Административные инструменты"). Это облегчает тестирование и отключение проблемных частей.
Прогнозы и будущее механизмов
Платформа 1С развивается в сторону расширения возможностей расширений. Скорее всего, в будущих версиях:
- Упростится механизм проверки совместимости при обновлении.
- Появятся инструменты для визуального сравнения расширений с основной конфигурацией.
- Внешние обработки, вероятно, останутся инструментом для разовых и узкоспециализированных задач, а также для быстрого прототипирования.
Заключение
Выбор между внешней обработкой и расширением — это не вопрос «что лучше», а вопрос «что целесообразнее в данной ситуации».
Внешние обработки незаменимы для автономных, разовых или узкоспециализированных задач.
Расширения — это выбор для глубокой, системной интеграции нового функционала в типовую конфигурацию.
Владение обоими инструментами и понимание их архитектурных особенностей — признак высокой квалификации разработчика 1С. Это позволяет создавать гибкие, поддерживаемые и безопасные решения, которые сохраняют возможность автоматического обновления и радуют пользователей новой функциональностью.