Каждый разработчик 1С рано или поздно сталкивается с ситуацией: создается внешняя обработка, в ее модуле расставляются точки останова, запускается отладка в Конфигураторе, но при выполнении кода программа упорно игнорирует эти точки. Особенно часто эта проблема проявляется в клиент-серверных базах, работающих под управлением Библиотеки Стандартных Подсистем (БСП), и на боевых серверах, где включение режима отладки по умолчанию запрещено администраторами.
В этой статье мы подробно разберем, почему точки останова во внешних обработках могут не работать, как функционируют механизмы отладки в 1С и какие существуют безопасные и эффективные альтернативы для отладки серверного кода без угрозы стабильности рабочей системы.
Для начала проанализируем ситуацию и выделим три основные причины, по которым конфигуратор не может перехватить управление на точке останова во внешней обработке:
.epf, открытый у нас в Конфигураторе, никак не связан с тем кодом, который фактически исполняется на сервере. Конфигуратор просто «не знает», что исполняемый на сервере временный файл — это наш исходник.---
Если на вашем сервере (тестовом или локальном) отладка включена, но точки останова во внешней обработке все равно не срабатывают из-за механизмов БСП, не нужно переписывать общие модули. В БСП встроен штатный и очень удобный механизм отладки внешних отчетов и обработок.
Разберем по шагам, как его использовать:
.epf на локальном диске или в сетевом каталоге, который доступен серверу приложений 1С.После выполнения этой настройки БСП при вызове обработки будет брать код не из хранилища значений в СУБД, а напрямую считывать файл по указанному пути. В результате этого точки останова в вашем Конфигураторе начнут стабильно срабатывать.
---
Если внешняя обработка выполняет длительные операции в фоновом режиме (через фоновые задания), отладить их стандартным способом бывает крайне сложно, особенно если серверная отладка отключена. Для обхода этой проблемы в БСП предусмотрен специальный параметр запуска.
Рассмотрим подробнее этот способ:
/C РежимОтладки
При запуске системы с этим флагом БСП принудительно отключает асинхронное выполнение фоновых заданий для дополнительных обработок. Все серверные процедуры, которые должны были уйти в фоновое задание, будут выполнены синхронно непосредственно в вашем текущем клиентском сеансе. Это позволяет перехватить выполнение кода обычным клиентским отладчиком, даже без глобального включения отладки на сервере.
---
Это самый популярный, надежный и безопасный метод, к которому прибегает большинство разработчиков. Если боевой сервер находится под высокой нагрузкой и администраторы категорически запрещают включать на нем дебаг (так как это может снизить производительность системы), мы должны перенести процесс разработки на локальный ПК.
Выполним следующие действия:
.dt) или создадим файловую копию базы на своем рабочем компьютере.Важный нюанс: Помните, что файловый и клиент-серверный режимы имеют различия. Например, в файловом режиме серверные вызовы выполняются в контексте того же процесса, что и клиент, и имеют доступ к файловой системе вашего компьютера. При переносе обработки на клиент-сервер пути к файлам могут стать недоступны для сервера приложений 1С (так как сервер будет искать их на своем локальном диске, а не на вашем ПК). Всегда учитывайте это при написании кода экспорта/импорта файлов.
---
Если у вас есть доступ к серверу приложений (например, это тестовый сервер или сервер разработки) и вы хотите настроить полноценную серверную отладку, разберем, как правильно включить параметр -debug для операционных систем Windows и Linux.
regedit в строке «Выполнить»).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64)
ImagePath. Его значение выглядит примерно так:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
-debug через пробел:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
services.msc), найдем службу Агент сервера 1С:Предприятия 8.3 и перезапустим ее.Начиная с современных версий платформы 1С, управление службами в Linux полностью переведено на системные юниты systemd. Проанализируем, как включить отладку в этом случае:
nano /opt/1cv8/x86_64/8.3.22.1709/srv1cv8-8.3.22.1709@.service
[Service] и добавим (или раскомментируем, если она уже есть) строку с переменной окружения SRV1CV8_DEBUG:
[Service]
...
Environment=SRV1CV8_DEBUG=-debug
...
systemctl daemon-reload
systemctl restart srv1cv8-8.3.22.1709@default.service
---
Начиная с версии платформы 8.3.7, фирма 1С добавила новый, современный и безопасный механизм отладки по протоколу HTTP взамен устаревшего TCP. При HTTP-отладке используется промежуточное звено — служба Сервер отладки (dbgs).
В чем ее ключевое преимущество для работы на удаленных или корпоративных серверах? При TCP-отладке сервер приложений 1С пытается сам инициировать TCP-сессию к компьютеру разработчика, что почти всегда блокируется сетевыми экранами и брандмауэрами. При HTTP-отладке и Конфигуратор разработчика, и сервер приложений 1С сами подключаются к единому серверу отладки по стандартному веб-протоколу. Такой трафик легко проходит через NAT, прокси-серверы и маршрутизаторы.
Для активации HTTP-отладки на сервере приложений вместо ключа -debug прописывается ключ -http. На стороне Конфигуратора в меню Сервис — Параметры — Запуск 1С:Предприятия — Отладка необходимо переключить способ отладки на HTTP и указать адрес сервера отладки.
---
Это продвинутый метод для тех случаев, когда перезапускать основную службу сервера на боевой базе нельзя, но у вас есть доступ к самому серверу и СУБД (например, PostgreSQL), и вам критически важно отладить код именно на реальных данных.
Мы можем поднять на том же физическом сервере вторую службу сервера 1С (того же релиза платформы), но настроить ее на другие порты работы (например, порты управления 2540 и 2541 вместо стандартных 1540 и 1541).
Алгоритм действий выглядит следующим образом:
-debug.ServerName:2541).---
Если все вышеперечисленные методы по каким-то причинам недоступны (нет прав администратора, нет возможности создать файловую копию, сервер закрыт "наглухо"), нам остается проверенный временем классический способ — вывод отладочной информации вручную.
Для этого мы можем использовать встроенные механизмы вывода сообщений и записи в системный журнал регистрации. Разберем пример кода, который помогает отслеживать состояние переменных в серверных процедурах без использования точек останова:
// Пример вывода информации пользователю
Сообщить("Значение переменной СуммаДокумента = " + ТекущийДокумент.СуммаДокумента);
// Пример безопасной записи в Журнал регистрации для анализа на сервере
ЗаписьЖурналаРегистрации(
"ОтладкаВнешнейОбработки",
УровеньЖурналаРегистрации.Информация,
,
,
"Текущий статус обработки контрагента: " + КонтрагентСсылка.Наименование
);
Также хорошей практикой является использование готовых внешних обработок класса Консоль кода или Консоль запросов. Они позволяют динамически исполнять произвольные куски серверного кода через вызовы функций Выполнить() и Вычислить(), выводя результаты вычислений в удобные таблицы прямо на клиенте, минуя необходимость перезапускать конфигуратор и ловить точки останова.