← На главную

При внедрении и сопровождении крупных типовых конфигураций (например, 1С:ERP Управление предприятием или 1С:Комплексная автоматизация) перед разработчиком встает важный архитектурный выбор: поместить весь проектный функционал в единое расширение конфигурации или создавать отдельное расширение под каждую задачу. Разберем ключевые критерии проектирования, влияние на производительность системы, нюансы динамического обновления и особенности разграничения прав доступа.

Влияние количества расширений на производительность и ресурсы сервера

Рассмотрим, как платформа 1С:Предприятие 8.3 обрабатывает расширения и почему неограниченное их дробление («одно расширение на каждую мелкую задачу») приводит к техническим проблемам:

1. Инициализация пользовательского сеанса: При подключении каждого пользователя к базе данных платформа выполняет компиляцию виртуальной конфигурации — объединение дерева метаданных основной конфигурации со всеми активными расширениями, а также проверку контрольных сумм заимствованных объектов. Если в базе подключены десятки расширений, время старта тонкого и веб-клиента заметно увеличивается.
2. Потребление оперативной памяти: Кеш скомпилированных модулей на сервере 1С строится с учетом всех подключенных расширений. При большом количестве расширений с перекрестным заимствованием одних и тех же объектов возрастает расход памяти рабочими процессами кластера rphost.
3. Скорость выполнения бизнес-логики: Если расширения не конфликтуют и не перехватывают одни и те же процедуры многократно через цепочки директив, сама скорость выполнения вычислений в сеансе практически не меняется. Основная нагрузка ложится именно на старт сеанса и компиляцию метаданных.

Конфликты заимствования и перехвата методов

Проанализируем технические риски разделения функционала по изолированным расширениям, когда разные задачи затрагивают один и тот же типовой объект (например, документ ПоступлениеТоваровУслуг или справочник Номенклатура):

1. Конфликт директивы &Вместо: Если в двух разных расширениях переопределяется одна и та же экспортная процедура общего модуля с помощью директивы &Вместо, платформа выдаст ошибку применения расширений, так как невозможно однозначно определить финальное тело метода без жесткого задания порядка применения.
2. Использование &ИзменениеИКонтроля: Данный механизм требует точного совпадения заимствованного исходного текста с кодом в основной конфигурации. При регулярных обновлениях типовой ERP адаптацию участков кода придется выполнять во всех расширениях параллельно.
3. Последовательность выполнения &Перед и &После: Очередность выполнения логики в разных расширениях определяется свойством Порядок (приоритет применения расширений). Чем больше расширений затрагивают один алгоритм проведения или проверки, тем сложнее отлаживать побочные эффекты и непредвиденное поведение.

Оптимальный подход: разделение по жизненному циклу и назначению

Наиболее надежной практикой в среде 1С является деление расширений не по отдельным техническим заданиям, а по их назначению и жизненному циклу:

1. Патчи и срочные исправления (Назначение: «Исправление»): Локальные исправления ошибок типовой конфигурации. Такие расширения удаляются по мере выхода официальных обновлений от фирмы «1С».
2. Модули интеграций: Обмены по протоколам HTTP/SOAP, интеграции с внешними сервисами, интеграционные регламентные задания. Их вынесение в отдельное расширение позволяет тестировать транспортную логику изолированно от интерфейсных доработок пользователей.
3. Индивидуальные бизнес-доработки (Назначение: «Адаптация»): Основное проектное расширение заказчика, содержащее изменения форм, добавление реквизитов, макетов печати и отчетов. Объединение взаимосвязанных доработок в одно расширение минимизирует дублирование заимствованных объектов.
4. Подсистемы с хранением данных (Назначение: «Дополнение»): Крупные обособленные модули, содержащие собственные справочники, документы и регистры сведений.

Важно учитывать ограничение динамического обновления: расширения, не меняющие структуры таблиц базы данных (без новых реквизитов и собственных объектов данных), можно применять и обновлять на сервере без отключения пользователей. Если же расширение добавляет физические поля в базу, потребуется монопольный доступ или завершение сеансов для реструктуризации.

Работа с ролями и разграничением прав в расширениях

Выясним, как правильно организовывать права доступа в расширениях с учетом архитектуры подсистемы Управление доступом БСП:

1. Принцип аддитивности прав: В платформе 1С права доступа объединяются по логическому условию «ИЛИ». Роль, созданная в расширении, может только добавить новые разрешения, но не может отнять права, уже выданные пользователю типовой ролью основной конфигурации.
2. Создание атомарных ролей: Вместо попыток модифицировать тяжелые типовые роли (например, ПолныеПрава или ДобавлениеИзменениеДокументовПоступления), в расширении создаются компактные роли, дающие доступ только к объектам самого расширения (новым формам, регистрам, командам).
3. Настройка через Профили групп доступа: В конфигурации ERP права пользователям назначаются не напрямую через роли, а через справочники ПрофилиГруппДоступа и ГруппыДоступа. Для изменения объема прав сотрудника создается новый профиль, в который включаются необходимые типовые роли и добавленные проектные роли из расширения.

Таким образом, для большинства проектов автоматизации одного заказчика оптимально использовать одно основное расширение для бизнес-логики и при необходимости дополнять его изолированными расширениями для интеграций или официальными патчами-исправлениями.