Часто при планомерном переходе со старых конфигураций возникает потребность перевести на новый интерфейс только часть сотрудников. Например, у вас есть историческая конфигурация на обычных формах, но вы хотите внедрить управляемое приложение для склада, чтобы адаптировать интерфейс для работы с отгрузкой и другими документами. Разберем подробнее, возможно ли использовать обычное приложение у одних пользователей и управляемое у других, и выясним причину возможных технических сложностей.
Да, платформа 1С:Предприятие позволяет запускать в одной конфигурации и обычного, и управляемого клиента в нужном режиме. Ничего не мешает совмещать обычные и управляемые формы в любом из режимов запуска. Рассмотрим по шагам, как это правильно реализовать и на что обратить внимание.
Для того чтобы разделить запуск интерфейсов по пользователям, проанализируем ситуацию с настройками в Конфигураторе. Мы можем жестко привязать режим запуска к конкретному профилю:
Чтобы переход был более плавным и формы могли открываться кросс-режимно, посмотрим на корневые свойства самой конфигурации. Рекомендуется установить флажки:
Если требуется открывать управляемую форму только для определенных ролей или режимов (когда по умолчанию для объекта задана обычная форма), мы можем программно перехватывать процесс открытия. Для этого используем событие ОбработкаПолученияФормы в модуле менеджера конкретного справочника или документа.
В этом обработчике можно переопределить параметр ВыбраннаяФорма, указав путь к нужной управляемой форме:
Процедура ОбработкаПолученияФормы(ВидФормы, Параметры, ВыбраннаяФорма, ДополнительнаяИнформация, СтандартнаяОбработка)
// Пример переопределения формы для тонкого клиента
#Если ТонкийКлиент Тогда
ВыбраннаяФорма = "УправляемаяФормаДокумента";
СтандартнаяОбработка = Ложь;
#КонецЕсли
КонецПроцедуры
Несмотря на техническую возможность смешанного режима, возможны сюрпризы, если старые объекты написаны "в стиле" обычного приложения без разбора контекста. Разберем эту проблему подробнее.
Главное ограничение связано с тем, что обычное приложение требует запуска ресурсоемкого «Толстого клиента», тогда как управляемое приложение должно работать через «Тонкий клиент». При их совместном использовании начинают параллельно работать разные модули старта системы: «Модуль обычного приложения» и «Модуль управляемого приложения».
В управляемых формах код жестко разделен на контексты с помощью директив &НаКлиенте и &НаСервере. Обычные формы исторически позволяли выполнять серверные вызовы (например, запросы к базе данных) прямо из клиентского кода. Из-за этого общие модули конфигурации становятся уязвимым местом: если не разделить контекст вызовов, при запуске управляемого приложения база начнет выдавать ошибки компиляции.
Чтобы скрыть несовместимые куски кода от разных клиентов, разработчику придется оборачивать участки инструкциями препроцессора. Посмотрим на пример того, как это должно выглядеть:
#Если ТолстыйКлиентОбычноеПриложение Тогда
// Здесь размещается старый код, который может делать запросы напрямую с клиента
Запрос = Новый Запрос;
#ИначеЕсли ТонкийКлиент Тогда
// Здесь размещается вызов серверной процедуры для управляемого приложения
ВыполнитьДействиеНаСервере();
#КонецЕсли
Перевод складского контура на управляемые формы стоит рассматривать как стратегический шаг, который открывает новые технические возможности, недоступные на обычных формах. Проанализируем два полезных сценария:
Подводя итог: запускать разные виды клиентов в одной базе можно. Однако перед переводом части пользователей в управляемый режим, обязательно проведите ревизию общих модулей и модулей объектов, чтобы грамотно разделить контекст исполнения кода.