Как постепенно перевести конфигурацию 1С с обычного приложения на управляемое

← На главную

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

Ограничения совмещения режимов и особенности платформы

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

Обычные формы не поддерживаются в тонком и веб-клиенте. Если в свойствах конфигурации включена опция Использовать обычные формы в управляемом приложении, пользователи обязаны запускать базу исключительно через толстый клиент (в режиме запуска управляемого приложения), пока абсолютно все формы не будут заменены.
Особенности отображения старых интерфейсов. В командном интерфейсе управляемого приложения обычные формы открываются только в виде свободных всплывающих окон. Они не встраиваются в рабочую панель вкладок и не подчиняются общим настройкам масштабирования интерфейса «Такси».
Инициализация модулей приложения. При смене основного режима запуска код из МодуляОбычногоПриложения перестает отрабатывать. Логику входа в систему и инициализации окружения необходимо переносить в МодульУправляемогоПриложения и МодульСеанса.
Глобальные переменные. Переменные, объявленные с директивой Экспорт в модуле обычного приложения, недоступны в контексте тонкого клиента и серверных вызовах управляемых форм. Их необходимо заменять на ПараметрыСеанса либо выносить в повторно используемые общие модули.

Стратегия 1: Постепенное внедрение управляемых форм в обычном приложении

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

Разберем по шагам реализацию этого подхода:

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

Стратегия 2: Переключение на управляемый режим с поддержкой обычных форм

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

Такой вариант требует более тщательной предварительной подготовки, так как при старте сразу начинает исполняться МодульУправляемогоПриложения. Посмотрим, как корректно инициализировать пользовательские сеансы без сбоев:

Все переменные сессии (текущий пользователь, основной склад, организация по умолчанию) переносятся в модуль сеанса в предопределенную процедуру УстановкаПараметровСеанса.
Анализируются обработчики ПриНачалеРаботыСистемы и ПередНачаломРаботыСистемы: из них исключаются любые модальные диалоги и несовместимые с тонким клиентом вызовы.
Настраиваются права доступа: проверяется доступность подсистем по ролям пользователей.

Архитектурная подготовка кода: разделение контекста Клиент/Сервер

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

Чтобы код можно было использовать повторно как в старых, так и в новых формах, бизнес-логику необходимо выносить в общие модули с серверным контекстом. Разберем пример адаптации процедур с использованием директив компиляции препроцессора:


#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда

Процедура РассчитатьИтогиТабличнойЧасти(ДокументОбъект) Экспорт
    // Серверная логика пересчета сумм и налогов
    Для Каждого Стр Из ДокументОбъект.Товары Цикл
        Стр.Сумма = Стр.Количество * Стр.Цена;
    КонецЦикла;
КонецПроцедуры

#КонецЕсли

Посмотрим на пример вызова серверной логики из модуля управляемой формы. На клиенте мы оперируем объектом формы, затем трансформируем его в прикладной объект на сервере:


&НаКлиенте
Процедура КоличествоПриИзменении(Элемент)
    ПересчитатьДанныеНаСервере();
КонецПроцедуры

&НаСервере
Процедура ПересчитатьДанныеНаСервере()
    ДокОбъект = ДанныеФормыВЗначение(Объект, Тип("ДокументОбъект.ЗаказКлиента"));
    РассчитатьИтогиТабличнойЧасти(ДокОбъект);
    ЗначениеВДанныеФормы(ДокОбъект, Объект);
КонецПроцедуры

Ревизия общих модулей и выявление проблем

Для стабильной работы базы в переходный период необходимо выполнить аудит всех общих модулей конфигурации:

Флаги общих модулей. Большинство старых общих модулей имеют признак Клиент (обычное приложение). Чтобы процедуры модуля стали доступны из управляемых форм, требуется взвести флаг Сервер или Клиент (управляемое приложение). Перед этим обязательно удалите из модуля вызовы элементов экранных форм, диалогов и методов работы с файлами, которые не поддерживаются на сервере.
Отказ от модальности. В управляемом приложении модальные вызовы (ОткрытьФормуМодально, Вопрос, Предупреждение) блокируют работу веб-клиента и снижают отзывчивость интерфейса. Заменяйте их на асинхронные методы: ПоказатьВопрос, ПоказатьПредупреждение с процедурами оповещения.
Автоматизированная проверка конфигурации. Используйте штатный механизм платформы «Конфигурация» — «Проверка конфигурации». В окне настройки отметьте проверки для тонкого клиента, сервера и внешнего соединения. Платформа сформирует исчерпывающий список мест, где нарушено контекстное разделение или используются недопустимые типы.

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