Что такое управляемое приложение 1С

Управляемое приложение — это режим работы платформы 1С:Предприятие, при котором интерфейс и логика форм строятся по декларативному описанию, а отрисовкой занимается сама платформа, а не код разработчика. Вместо того чтобы программно размещать каждую кнопку и поле, разработчик описывает структуру формы, а платформа сама решает, как показать её в толстом, тонком или веб-клиенте.

Такой подход появился в платформе 8.2 и стал основой всех современных типовых конфигураций: «1С:Бухгалтерия 8», «Управление торговлей 11», «Зарплата и управление персоналом 3» и других. Старый режим, который называют «обычное приложение», сохраняется только для совместимости с устаревшими решениями и новых проектов на нём практически не ведут.

Понимание разницы между режимами важно не только разработчикам. От режима зависит, какие клиенты можно использовать, будет ли работать база через веб-браузер, как вести себя при доработке форм и почему некоторые старые обработки отказываются запускаться в новых конфигурациях.

Как устроено управляемое приложение

Ключевая идея режима — разделение описания и отображения. Разработчик в конфигураторе создаёт управляемую форму: указывает реквизиты, команды, элементы и их связи с данными. Платформа на основании этого описания самостоятельно строит интерфейс под конкретный клиент: один и тот же документ будет выглядеть по-разному на десктопе, в браузере и на планшете, но останется функционально тем же.

Вторая особенность — чёткое разделение кода на серверный и клиентский. В управляемых формах процедуры и функции явно помечаются директивами компиляции: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста. Это связано с трёхзвенной архитектурой: клиентская часть не имеет прямого доступа к базе данных, все обращения к данным выполняются на сервере.

Третья составляющая — декларативный интерфейс всего приложения. Панели разделов, командный интерфейс подсистем, начальная страница формируются на основе настроек подсистем и прав пользователя. Администратор может скрыть лишние разделы для конкретной роли без изменения кода конфигурации.

Чем управляемое приложение отличается от обычного

Обычное приложение — режим платформы версий 8.0 и 8.1, где формы рисовались разработчиком пиксельно: каждый элемент имел фиксированные координаты и размеры. Такой подход давал полный контроль над внешним видом, но жёстко привязывал интерфейс к толстому клиенту на Windows.

Практическое следствие различий: обработки и отчёты, написанные под обычные формы, в управляемом приложении не откроются либо откроются с ошибкой. Если внешняя обработка содержит только обычную форму, платформа в режиме управляемого приложения просто не сможет её показать.

Клиенты и способы запуска

Главное практическое преимущество управляемого приложения — свобода выбора клиента. Одна и та же база может обслуживать пользователей с разными способами подключения без доработки конфигурации.

Тонкий клиент — лёгкое приложение, которое устанавливается на компьютер пользователя и обменивается с сервером только данными, а не готовым интерфейсом. Он требует заметно меньшей пропускной способности канала, поэтому подходит для филиалов и удалённых сотрудников. Веб-клиент вообще не требует установки: пользователь открывает браузер, вводит адрес публикации на веб-сервере и работает в привычном интерфейсе.

Для мобильных сценариев существует мобильный клиент и мобильная платформа. Мобильный клиент подключается к существующей базе и показывает адаптированный интерфейс, мобильная платформа позволяет собирать автономные приложения с обменом данными. Не всякий функционал конфигурации корректно работает на мобильных устройствах, поэтому для полевых сотрудников обычно делают отдельные упрощённые формы.

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

Работа с кодом в управляемом приложении требует понимания контекста исполнения. Директива &НаКлиенте означает, что процедура выполняется на компьютере пользователя: здесь доступны элементы формы, диалоги, работа с файлами пользователя. Директива &НаСервере запускает код на сервере, где доступны запросы к базе и объектная модель данных.

Типичный шаблон взаимодействия выглядит так: клиентская процедура обрабатывает нажатие кнопки, вызывает серверную процедуру для чтения или записи данных, получает результат и обновляет отображение. Передавать между клиентом и сервером можно только сериализуемые данные — объекты типа «ДокументОбъект» напрямую передать нельзя, используется механизм «ДанныеФормы».

&НаКлиенте
Процедура ЗаполнитьЦены(Команда)
    ЗаполнитьЦеныНаСервере();
    Элементы.Товары.Обновить();
КонецПроцедуры

&НаСервере
Процедура ЗаполнитьЦеныНаСервере()
    // запрос к базе данных, заполнение табличной части
КонецПроцедуры

Ещё одно ограничение — запрет модальных окон. Вместо конструкции «Если Вопрос(...) = КодВозвратаДиалога.Да Тогда» применяется асинхронный вызов ПоказатьВопрос с описанием оповещения. Старый модальный код в управляемом приложении либо не компилируется, либо приводит к ошибкам при работе через веб-клиент.

Как определить режим работы базы и переключить его

Проверить, в каком режиме работает конфигурация, можно в конфигураторе. Откройте свойства корневого узла конфигурации и найдите параметр «Основной режим запуска»: там будет указано «Управляемое приложение», «Обычное приложение» или вариант с выбором. Также признаком служит интерфейс: наличие панели разделов и «плиточного» начального экрана характерно для управляемого режима.

Переключение старой конфигурации на управляемый режим — это не смена одной галочки, а проект. Нужно создать управляемые формы для всех используемых объектов, переписать код с учётом разделения клиент-сервер, убрать модальность и проверить работу всех ролей пользователей. Для больших самописных конфигураций такая миграция занимает недели или месяцы.

1. 1
   Убедитесь, что конфигурация находится на поддержке с возможностью изменения, и сделайте резервную копию базы.
2. 2
   В свойствах объекта (справочника, документа) создайте управляемую форму нужного типа: форму элемента, списка, выбора.
3. 3
   Перенесите реквизиты и табличные части на форму, настройте группировку и видимость элементов.
4. 4
   Перепишите обработчики событий: разделите код на клиентский и серверный, замените модальные вызовы на оповещения.
5. 5
   Протестируйте форму в тонком клиенте и при необходимости в веб-клиенте под учётной записью с реальными правами пользователя.

Когда управляемое приложение не нужно

Несмотря на статус стандарта, управляемый режим не всегда обязателен. Если база работает на старой самописной конфигурации, обслуживает пару пользователей в локальной сети и не планирует развиваться, переводить её на управляемые формы может быть экономически неоправданно. Обычное приложение продолжает запускаться на современных версиях платформы в режиме совместимости.

Обратная ситуация — когда переход неизбежен: требуется доступ через браузер, работа удалённых сотрудников по тонкому каналу, мобильные сценарии или обновление на свежий релиз типовой конфигурации. Типовые решения линейки 8.3 поставляются только с управляемым интерфейсом, и остаться на обычном режиме при обновлении не получится.

Проверка результата после перехода

После перевода конфигурации или отдельных объектов на управляемые формы важно системно проверить работоспособность. Поверхностная проверка «открылось — не открылось» пропускает ошибки, которые проявятся у пользователей с ограниченными правами или в веб-клиенте.

Отдельно проверьте печатные формы и обмены данными: эти механизмы часто завязаны на серверный контекст, и при неправильном переносе кода печать может молча формировать пустые бланки. Контрольный прогон нескольких реальных документов от создания до печати — минимальный приёмочный тест.

Часто задаваемые вопросы