В практике 1С-программиста нередко возникают ситуации, когда нам приходится работать с базами, размещенными на "чужих" серверах. Часто это сопровождается жесткими ограничениями: у нас нет доступа к консоли администрирования серверов 1С, нет прав на просмотр реестра Windows, нет доступа к файловой системе сервера, а запуск внешних обработок заблокирован политиками безопасности. При этом нам критически важно понимать: запущен ли сервер 1С в режиме отладки (с ключом -debug) или нет? Без этого мы не сможем проанализировать сложные серверные ошибки.
В этой статье мы подробно разберем, как, имея доступ только к Конфигуратору (и часто только в режиме "Обычное приложение"), выяснить статус отладки на сервере. Мы рассмотрим несколько методов — от использования встроенных инструментов платформы до "хитростей" с пошаговым выполнением кода.
Первый и наиболее правильный инструмент, который предоставляет нам платформа, — это механизм подключения отладчика к работающим процессам. Многие забывают, что список доступных для отладки процессов формируется не только локально, но и с учетом настроек подключения.
Давайте разберем алгоритм действий по шагам:
Здесь есть важный нюанс. Если сервер 1С находится на другой физической машине (а в условии задачи сказано, что сервер "чужой-пречужой"), вы по умолчанию увидите только свои локальные клиентские процессы. Чтобы "увидеть" сервер, нам необходимо указать платформе, где его искать.
Настройка поиска удаленных предметов отладки:
После того как адрес сервера прописан, снова откройте Отладка -> Подключение. Проанализируем список:
rphost), значит, отладка на сервере включена. Ключ -debug работает, и вы можете подключаться.Важное примечание про протоколы (TCP vs HTTP):
В современных версиях платформы (8.3.х) отладка может работать по протоколу HTTP (ключ -debug -http). Если сервер настроен на HTTP-отладку, а ваш Конфигуратор пытается подключиться по TCP (стандартный режим), вы не увидите серверный процесс. В настройках отладки (Сервис -> Параметры) попробуйте переключить протокол отладки и перезапустить Конфигуратор.
Если возиться с настройками IP-адресов не хочется или есть подозрение, что порты закрыты админами, мы можем использовать поведенческий анализ платформы. Поскольку мы работаем в режиме "Обычное приложение" (Толстый клиент), у нас есть преимущество: код выполняется и на клиенте, и на сервере, и мы можем явно отследить переход управления.
Суть метода заключается в том, чтобы попытаться "провалиться" отладчиком из клиентского кода в серверный.
Алгоритм действий:
Сервер и Вызов сервера (или Клиент (обычное приложение) и Сервер).Когда выполнение остановится на клиенте, нажмите клавишу F11 (Шаг внутрь). Здесь нас ждет момент истины:
Иногда в чужой конфигурации сложно сходу найти место, где вызывается серверный код, чтобы поставить там точку останова. Мы можем помочь себе, написав небольшой скрипт для поиска подходящих общих модулей. Поскольку запускать внешние обработки нельзя, мы можем использовать этот код, например, в какой-нибудь временной процедуре формы, которую можно менять (если конфигурация находится на поддержке с возможностью изменения), или просто визуально проанализировать дерево метаданных.
В теме предложен отличный вариант перебора метаданных, чтобы найти чисто серверные модули, исключая те, что компилируются и на клиенте (так как заход в гибридный модуль может сбить с толку — вы можете остаться на клиенте, думая, что попали на сервер).
Рассмотрим код, который помогает найти чисто серверные модули:
Для Каждого ОбщийМодуль Из Метаданные.ОбщиеМодули Цикл
// Ищем модули, которые компилируются ТОЛЬКО на сервере
Если ОбщийМодуль.Сервер
И НЕ (ОбщийМодуль.КлиентОбычноеПриложение
Или ОбщийМодуль.КлиентУправляемоеПриложение) Тогда
Сообщить(ОбщийМодуль.Имя);
КонецЕсли;
КонецЦикла;
Получив список таких модулей, мы можем воспользоваться глобальным поиском по конфигурации, чтобы найти места их вызова в клиентских формах. Найдя такое место, применяем Метод 2 (шаг внутрь по F11).
Еще один остроумный способ проверки — спровоцировать ошибку на сервере. Если отладка включена и настроена, отладчик должен перехватить исключение.
ВызватьИсключение "Тест").Если Конфигуратор "выпрыгнет" на передний план и покажет строку с ошибкой в серверном модуле — отладка работает. Если же вы просто увидите стандартное окно сообщения об ошибке в режиме Предприятия, а Конфигуратор промолчит — отладки нет.
Даже если на сервере запущен процесс с ключом -debug, вы можете столкнуться с ситуацией, когда отладка не подключается. Причина может крыться в правах доступа Windows.
Для корректной работы отладки (особенно по протоколу TCP) пользователь, от имени которого запущен ваш Конфигуратор, и пользователь, от имени которого работает служба агента сервера 1С (обычно USR1CV8), должны иметь возможность взаимодействовать.
Если вы находитесь в другом домене или не имеете соответствующих прав DCOM на сервере, список предметов отладки может быть пустым. В таких случаях системные администраторы часто добавляют пользователей в группу Debugger Users (если она настроена) или настраивают права доступа к процессам. Но для первичной диагностики описанных выше методов (особенно метода с F11) обычно достаточно, чтобы понять принципиальную возможность отладки.
Подводя итог, если вы оказались перед "закрытым" сервером, действуйте в таком порядке:
Сервер.Эти действия позволят вам со 100% вероятностью определить, доступна ли отладка, не прибегая к помощи администраторов и не взламывая систему.