Разработчики 1С часто сталкиваются с ситуацией, когда логика приложения работает исправно, но классические точки останова в конфигураторе упорно игнорируются системой. Особенно часто это происходит в специализированных отраслевых решениях, таких как «ITOB: Центр Спутникового Мониторинга». В подобных системах обработка телематических событий (например, въезд в геозону, превышение скорости или слив топлива) выполняется асинхронно.
В этой статье мы подробно разберем, почему конфигуратор не останавливает выполнение на ваших точках останова, как использовать штатный замер производительности для локализации проблемного кода и как правильно настроить отладку серверных вызовов, фоновых заданий и веб-сервисов.
Прежде чем переходить к активным действиям, проанализируем ситуацию и поймем физику процесса. Когда координаты от ГЛОНАСС/GPS-трекеров поступают в систему, они проходят длинный путь. Данные сначала обрабатываются телематическим сервером, а затем передаются в 1С. Этот процесс практически никогда не происходит в рамках вашего активного клиентского сеанса. Платформа выполняет эту работу в других контекстах:
По умолчанию отладчик вашего конфигуратора подключен только к вашему текущему клиентскому сеансу (тонкому или толстому клиенту). Все остальные процессы происходят в фоновом режиме на сервере, который конфигуратор просто не видит. Именно поэтому ваши точки останова благополучно игнорируются, хотя само событие успешно отрабатывает и выводит результат на форму.
Если вам нужно оперативно понять, какой именно код вызывается при возникновении фонового события, лучшим инструментом станет Замер производительности. Этот инструмент фиксирует абсолютно все выполняемые сервером и клиентом строки кода, даже если отладчик не останавливается на них физически.
Разберем по шагам, как правильно выполнить замер производительности для выявления нужного события:
Анализ полученной таблицы позволит вам быстро определить «точку входа» — тот самый общий модуль или модуль объекта, где происходит обработка события. Это существенно сузит область поиска и поможет понять, куда именно ломится система.
Замер производительности помогает локализовать код, но для полноценной пошаговой отладки нам все же нужны работающие точки останова. Чтобы заставить их срабатывать в фоновых заданиях, необходимо выполнить комплексную настройку.
Во-первых, рассмотрим подробнее настройку самого сервера «1С:Предприятия». Он должен быть запущен в режиме отладки. Для этого в реестре Windows (или в файле конфигурации службы на Linux) в параметрах запуска службы ragent должен присутствовать ключ -debug. Если вы используете современную платформу с HTTP-отладкой, параметры запуска должны содержать указание на протокол отладки, например:
ragent.exe -debug -http
Во-вторых, настройте автоматическое подключение в самом конфигураторе. Разберем по шагам этот процесс:
Часто разработчики выполняют все указанные выше действия, но точки останова в фоновых заданиях все равно не срабатывают. Выясним причину этой неочевидной проблемы.
Дело в том, что механизм автоматического подключения конфигуратора к фоновым заданиям крайне чувствителен к посимвольному совпадению строки подключения к базе данных. Платформа сравнивает строку подключения вашего текущего сеанса конфигуратора со строкой, с которой фоновое задание запускается на сервере.
Если в вашем списке баз (в стартере 1cestart) прописано:
Srvr="server1c";Ref="MyBase";
А сервер запускает фоновое задание, используя имя сервера в верхнем регистре или с указанием доменного имени:
Srvr="SERVER1C";Ref="MyBase";
То автоматического сопоставления сеансов не произойдет, и отладчик проигнорирует выполнение фонового процесса. Чтобы решить эту проблему, убедитесь, что имя сервера и имя базы в параметрах подключения вашего конфигуратора абсолютно идентичны тем параметрам, которые прописаны в консоли администрирования серверов 1С.
Если ваша конфигурация обменивается данными с внешним миром через HTTP-сервисы, обычного включения отладки на сервере недостаточно. Нам потребуется скорректировать публикацию базы на веб-сервере (IIS или Apache).
Проанализируем ситуацию с файлом публикации default.vrd, который находится в каталоге публикации вашей базы на веб-сервере. Чтобы разрешить прохождение отладочного трафика через веб-сервер, в XML-структуру этого файла необходимо добавить параметр отладки. Посмотрим на пример корректной настройки секции:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyBase"
ib="Srvr="server1c";Ref="MyBase";">
<debug enable="true" url="tcp://server1c:1560" />
</point>
В параметре url указывается адрес вашего сервера отладки. После редактирования файла default.vrd обязательно перезапустите службу веб-сервера (IIS или Apache), чтобы изменения вступили в силу.
Если ваша конфигурация разработана с использованием Библиотеки стандартных подсистем (БСП), вам доступен элегантный способ отладки фонового кода без сложных манипуляций с сервером. В БСП заложен механизм синхронного выполнения фоновых задач.
Разберем по шагам, как им воспользоваться:
/C РежимОтладки.При таком запуске платформа перехватывает вызовы фоновых заданий и принудительно выполняет их синхронно, прямо в контексте вашего текущего клиентского сеанса. Это означает, что любой серверный код выполнится в вашем основном потоке, и отладчик гарантированно остановится на установленной точке останова.
Многие разработчики по старой привычке пытаются использовать метод Сообщить() для вывода отладочной информации из фоновых процессов. Это крайне плохая практика. Фоновые задания выполняются на сервере без какого-либо графического интерфейса (UI-контекста).
Использование Сообщить() в серверном коде может привести к тому, что платформа либо проигнорирует вызов метода, либо (в зависимости от версии платформы и режима совместимости) вызовет критическую ошибку выполнения из-за попытки обращения к интерактивным функциям в неинтерактивном сеансе.
Вместо метода Сообщить() используйте запись в журнал регистрации. Посмотрим на пример простого и безопасного шаблона для логирования событий на сервере:
Процедура ЗафиксироватьСобытиеДляОтладки(ИмяСобытия, ДанныеДляАнализа) Экспорт
ТекстЛога = "Отладочные данные: " + СокрЛП(ДанныеДляАнализа);
ЗаписьЖурналаРегистрации(
"ОтладкаСобытий",
УровеньЖурналаРегистрации.Информация,,
,
ТекстЛога
);
КонецПроцедуры
Данный метод можно безопасно вызывать из любой точки конфигурации — будь то фоновое задание, модуль веб-сервиса или подписка на событие. Вы всегда сможете зайти в Журнал регистрации, настроить отбор по событию «ОтладкаСобытий» и детально изучить зафиксированные данные.