Проблема, когда отладка успешно работает в клиентском коде, но «пролетает» мимо серверных процедур, является одной из самых частых при работе с клиент-серверной архитектурой 1С. Ситуация осложняется, когда на самом сервере приложений отладка работает, а с удаленного рабочего места разработчика — нет. Проанализируем причины этой проблемы и разберем пошагово методы её решения для платформы 8.3.10 и выше.
Прежде всего, нам необходимо убедиться, что сервер 1С:Предприятия запущен в режиме отладки. Разберем, как это проверить. В реестре Windows на машине, где установлен сервер 1С (Srv1), в ветке службы ragent должен быть прописан параметр -debug.
Путь в реестре обычно выглядит так:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64)
В параметре ImagePath должна присутствовать строка следующего вида:
"C:\Program Files\1cv8\8.3.10.2753\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
Если параметра -debug нет, его нужно добавить и перезапустить службу 1C:Enterprise 8.3 Server Agent. Без этого флага сервер в принципе не будет предоставлять информацию о предметах отладки.
Выясним причину, по которой отладка может работать локально на Srv1, но не работать с Srv2. При использовании стандартного протокола TCP сервер 1С должен иметь возможность инициировать обратное соединение с компьютером разработчика.
Рассмотрим важные нюансы настройки портов:
1cv8.exe. Часто администраторы забывают про это, блокируя входящий трафик на рабочей станции разработчика.ping Srv2, запущенной непосредственно с сервера приложений. При необходимости можно жестко прописать соответствие IP и имени в файле hosts.В версиях платформы 8.3.10 существует специфический баг, связанный с механизмом подключения к предметам отладки. Если все настройки верны, но отладка все равно не заходит в серверные процедуры, попробуем применить следующий алгоритм прямо во время сеанса:
Этот простой маневр часто заставляет платформу «увидеть» контекст, который был потерян из-за внутренних ошибок кеширования соединений.
Если классическая отладка по TCP продолжает работать нестабильно, перейдем к использованию протокола HTTP. Этот режим появился в 8.3.7 и в версии 8.3.10 работает вполне зрело. Его главное преимущество — использование одного порта и отсутствие необходимости в обратном соединении от сервера к клиенту, что снимает большинство проблем с брандмауэрами.
Разберем по шагам, как включить HTTP-отладку:
1. Настройка сервера 1С:
В строке запуска службы сервера в реестре замените флаг -debug на флаг -http. Если вы хотите использовать конкретный порт для сервера отладки (по умолчанию 1550), это можно настроить, но обычно достаточно простого включения режима.
Пример строки запуска:
"C:\Program Files\1cv8\8.3.10.2753\bin\ragent.exe" -srvc -agent ... -debug -http
2. Настройка Конфигуратора:
В «Конфигураторе» на машине разработчика (Srv2) выполните следующие действия:
http://Srv1:1550).После этого перезапустите «Конфигуратор» и сеанс отладки. Как правило, после перехода на HTTP проблемы с «незаходом» в серверные процедуры исчезают.
Посмотрим на ситуацию шире. Иногда отладка не работает только для определенных вызовов.
Если ваш код исполняется в фоновом задании, проверьте настройки в окне Отладка — Подключение — Настройка автоматического подключения. Должна стоять галочка напротив пункта Фоновые задания. В противном случае отладчик будет игнорировать серверные вызовы, выполняемые в отдельных потоках.
Также проанализируем сетевой протокол IPv6. Платформа 8.3.10 иногда некорректно обрабатывает приоритеты протоколов. Если в вашей сети включен IPv6, но настроен не полностью, отладчик может пытаться использовать пустые или некорректные адреса. Попробуйте временно отключить IPv6 в свойствах сетевого адаптера на обеих машинах (Srv1 и Srv2), чтобы исключить этот фактор.
Резюме: Если отладка на сервере не работает, сначала проверьте флаг -debug и настройки брандмауэра на клиенте. Если это не помогает — попробуйте переподключить предметы отладки вручную или переведите систему на протокол HTTP, который является более устойчивым к сетевым ограничениям.