Отладка на сервере 1С: как включить и пользоваться

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

Причина в архитектуре: по умолчанию сервер 1С запускается без поддержки отладки, и конфигуратор не может подключиться к рабочему процессу rphost. Чтобы это изменить, сервер нужно перезапустить со специальным параметром, а затем правильно настроить подключение в конфигураторе. Ниже разобран полный порядок действий для Windows и Linux, особенности отладки фоновых заданий и типичные проблемы.

Как работает серверная отладка и когда она нужна

В клиент-серверном режиме код делится на клиентский и серверный. Директивы компиляции &НаСервере, &НаСервереБезКонтекста, серверные общие модули и код бизнес-логики выполняются внутри рабочих процессов сервера 1С (rphost). Конфигуратор по умолчанию «видит» только клиентский процесс, поэтому серверные точки останова игнорируются.

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

Отладка на сервере необходима в таких ситуациях:

• ошибка воспроизводится только в клиент-серверной базе, а в файловой копии не повторяется;
• нужно пошагово проверить фоновое или регламентное задание;
• требуется отладить обработчик веб-сервиса или HTTP-сервиса;
• падает обмен данными, который выполняется на сервере;
• нужно понять, какие запросы и данные обрабатывает серверная процедура.

Включение отладки на сервере приложений Windows

На Windows сервер 1С обычно работает как служба «Агент сервера 1С:Предприятия». Чтобы включить отладку, в параметры запуска службы нужно добавить ключ -debug. Сделать это можно двумя способами.

Первый способ — через реестр. Откройте редактор реестра и найдите ветку службы агента сервера, обычно это HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (имя может отличаться в зависимости от версии и разрядности). В параметре ImagePath добавьте в конец строки запуска ключ -debug, не ломая существующие параметры. После изменения перезапустите службу.

Второй способ — перерегистрировать службу утилитой ragent с нужными параметрами. Этот вариант удобен, если служб несколько или требуется точно контролировать строку запуска. Команда выполняется от имени администратора.

sc stop "1C:Enterprise 8.3 Server Agent (x86-64)" && sc start "1C:Enterprise 8.3 Server Agent (x86-64)" -- -debug

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

1. 1
   Откройте реестр и найдите параметр ImagePath службы агента сервера 1С
2. 2
   Добавьте в конец строки запуска ключ -debug
3. 3
   Перезапустите службу агента сервера 1С
4. 4
   В конфигураторе включите протокол отладки TCP/IP (Отладка → Параметры)
5. 5
   Подключите серверный сеанс через Отладка → Подключение
6. 6
   Поставьте точку останова в серверном коде и воспроизведите действие

Включение отладки на сервере Linux

На Linux агент сервера 1С запускается скриптом или юнитом systemd. Принцип тот же: в строку запуска процесса ragent нужно добавить параметр -debug. Для этого отредактируйте unit-файл службы (обычно в /etc/systemd/system/ или в каталоге, созданном при установке) и дополните директиву ExecStart ключом отладки.

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

systemctl daemon-reload && systemctl restart srv1cv83 && ps aux | grep ragent

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

Настройка конфигуратора: протокол и подключение сеанса

После перезапуска сервера нужно настроить сам конфигуратор. Откройте меню «Отладка → Параметры» и убедитесь, что выбран протокол отладки по TCP/IP — именно он поддерживает отладку серверного кода. Режим HTTP используется в основном для отладки через веб-сервер и мобильных клиентов.

Дальше откройте «Отладка → Подключение». В окне подключения отображаются доступные предметы отладки: клиентские и серверные сеансы информационной базы. Найдите нужный сеанс (его можно опознать по пользователю и типу приложения) и нажмите «Подключить». Если список пуст, включите флажок показа сеансов всех пользователей и проверьте, что отладка на сервере действительно включена.

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

Отладка фоновых и регламентных заданий

Фоновые задания выполняются в отдельных сеансах, которые создаются в момент запуска задания и исчезают после завершения. Поэтому подключиться к ним заранее нельзя — сеанс появляется только на время выполнения. Для отладки в окне подключения включите автоматическое подключение к фоновым заданиям: в параметрах отладки есть соответствующая настройка, либо используйте отбор по типу сеанса в окне подключения.

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

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

Отладка веб-сервисов и HTTP-сервисов

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

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

Типичные ошибки и их устранение

Чаще всего отладка не работает из-за того, что службу не перезапустили после добавления ключа, либо ключ добавили не туда — например, в ярлык клиента вместо параметров агента сервера. Проверка строки запуска процесса ragent — первое действие при любой проблеме.

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

Безопасность и отключение режима отладки

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

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

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