Как запустить отладку на сервере 1С

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

Главное условие — сервер 1С должен быть запущен в режиме отладки. Без этого флага рабочие процессы не открывают отладочные порты, и предметы отладки в конфигураторе останутся пустыми, сколько бы вы ни обновляли список. Ниже разобраны оба протокола отладки (TCP и HTTP), настройка агента сервера, подключение конфигуратора и разбор типичных проблем.

Какие протоколы отладки существуют и что выбрать

В платформе 1С поддерживаются два протокола отладки: классический TCP и более современный HTTP. TCP-протокол исторически использовался по умолчанию: конфигуратор подключается напрямую к рабочим процессам по диапазону портов (по умолчанию 1560–1591). Он прост в настройке, но требует сетевой доступности этих портов между машиной разработчика и сервером, что в корпоративных сетях с файрволами часто становится проблемой.

HTTP-протокол отладки работает через веб-сервер (IIS или Apache), на котором опубликована информационная база. Трафик отладки идёт по стандартным портам 80/443 вместе с обычными запросами, поэтому проблем с межсетевыми экранами практически не возникает. Именно HTTP-протокол рекомендуется для новых установок и для отладки через интернет или изоляцию DMZ.

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

Включение режима отладки на агенте сервера

Режим отладки включается параметром командной строки агента сервера 1С (ragent). В Windows агент обычно работает как служба, поэтому параметр прописывается в реестре. Откройте ветку HKLM\SYSTEM\CurrentControlSet\Services, найдите службу агента сервера нужной версии (например, «1C:Enterprise 8.3 Server Agent») и в параметре ImagePath добавьте к строке запуска ключ -debug. Для HTTP-протокола дополнительно укажите -debug -http.

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

"C:\Program Files\1cv8\8.3.x.xxxx\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http

В Linux агент обычно запускается скриптом или юнитом systemd. Параметр -debug добавляется в строку вызова ragent в соответствующем файле службы, после чего выполняется перезапуск юнита. Логика та же: пока процесс не перечитает параметры, отладочные порты не откроются.

Подключение конфигуратора к серверным предметам отладки

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

Если конфигуратор и сервер находятся на разных машинах и используется TCP-протокол, в настройках подключения нужно указать имя или IP-адрес сервера и убедиться, что порты диапазона 1560–1591 доступны. Проверить доступность можно простым подключением telnet или через Test-NetConnection в PowerShell.

1. 1
   Добавьте ключ -debug (и -http при необходимости) в строку запуска агента сервера
2. 2
   Перезапустите службу агента сервера 1С
3. 3
   Откройте конфигуратор и включите автоматическое подключение серверных предметов отладки
4. 4
   Поставьте точку останова в серверной процедуре
5. 5
   Запустите клиентское приложение или действие, вызывающее серверный код
6. 6
   Убедитесь, что выполнение остановилось на точке останова в конфигураторе

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

Отладка фоновых заданий и веб-сервисов

Фоновые задания — частый источник проблем, потому что их код стартует не из клиентского сеанса, а по расписанию или программно. Чтобы отладить фоновое задание, включите автоматическое подключение предмета отладки «Фоновое задание» и запустите задание. Конфигуратор подхватит его сразу после старта. Если задание выполняется очень быстро и завершается раньше, чем конфигуратор успевает подключиться, временно добавьте в начало обработчика ожидание или точку останова на первой же строке.

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

Отладка веб-сервисов и HTTP-сервисов требует, чтобы вызов пришёл в момент активной отладки. Включите соответствующий тип предмета отладки, поставьте точку останова в обработчике и выполните запрос к сервису — например, из браузера, Postman или вызывающей системы. Если используется HTTP-протокол отладки, убедитесь, что публикация на веб-сервере обновлена после включения отладки.

Отладка по HTTP через веб-сервер

Для HTTP-протокола отладки, помимо ключа -http у агента, требуется корректная публикация базы. При публикации через диалог конфигуратора («Администрирование → Публикация на веб-сервере») убедитесь, что включена поддержка отладки — в настройках публикации есть соответствующий флаг. После изменения настроек публикации веб-сервер нужно перезапустить (для IIS — перезапуск пула приложений или самого IIS).

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

Типичные проблемы и их диагностика

Самая частая ситуация — точка останова не срабатывает, а список предметов отладки пуст. Почти всегда это означает, что агент сервера запущен без ключа -debug, либо службу не перезапустили после его добавления. Второй по частоте сценарий — конфигуратор подключён к другой базе или к другому кластеру (например, к тестовому вместо рабочего).

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

Отдельная категория проблем — отладка на сервере с несколькими рабочими процессами. Серверный вызов может попасть в любой из rphost, и если отладочные порты открыты только у части процессов (например, после неполного перезапуска кластера), отладка будет срабатывать «через раз». Лечится полным перезапуском службы агента, который пересоздаёт рабочие процессы.

Частые вопросы