Разработка и поддержка веб-сервисов в экосистеме 1С — задача ответственная, а отладка этого процесса часто превращается в настоящий квест для разработчика. Бывают ситуации, когда веб-сервис успешно функционирует, возвращает корректные данные, но при этом игнорирует все расставленные точки останова в Конфигураторе. Проблема отладки веб-сервисов часто кроется в тонких настройках взаимодействия между веб-сервером (IIS или Apache) и сервером отладки 1С.
В этой статье мы подробно разберем, как заставить отладчик «видеть» ваш веб-сервис, проанализируем необходимые изменения в конфигурационных файлах и рассмотрим неочевидные нюансы системного администрирования.
Прежде всего, нам необходимо убедиться, что при публикации информационной базы были установлены правильные параметры. Перейдем в меню «Администрирование» — «Публикация на веб-сервере». На закладке «Прочее» крайне важно обратить внимание на поле «Отладка». Здесь следует выбрать значение «Разрешена (протокол HTTP)» или «Разрешена (протокол TCP/IP)».
Разберем подробнее разницу. Современные версии платформы (начиная с 8.3.7) отдают приоритет протоколу HTTP. Он считается более стабильным при работе через веб-серверы, так как использует стандартные механизмы передачи данных. При выборе этого протокола система будет использовать специальный «Сервер отладки» (процесс dbgs). Если вы используете файловый вариант базы, платформа может запустить его автоматически, но для серверных решений это требует отдельной настройки в строке запуска службы агента 1С (флаг -debug -http).
Файл default.vrd — это сердце вашей публикации. Он находится в каталоге, который вы указали при публикации (например, в wwwroot вашего веб-сервера). Нам нужно убедиться, что секция отладки прописана корректно. Проанализируем типичную структуру этого файла:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/MyBase"
ib="Srvr=MyServer;Ref=MyBase;">
<debug enable="true" url="http://localhost:1560" />
<standardOdata enable="true"/>
</point>
Обратим внимание на атрибут enable="true". Без него отладка не взлетит, даже если в Конфигураторе все включено. Атрибут url указывает адрес сервера отладки. Если отладчик и веб-сервер находятся на одной машине, часто достаточно просто enable="true", но явное указание адреса с портом (по умолчанию 1560 для HTTP-отладки) снимает множество вопросов с маршрутизацией трафика.
Важный момент: после любого изменения в default.vrd рекомендуется выполнить команду iisreset в командной строке от имени администратора, чтобы веб-сервер гарантированно перечитал настройки и сбросил кешированные сессии.
Даже если веб-сервер готов отдавать данные для отладки, Конфигуратор должен «захотеть» их принять. Рассмотрим настройки самого Конфигуратора. Перейдем в меню «Отладка» — «Подключение». В открывшемся окне нажмем кнопку «Автоматическое подключение».
В появившемся списке необходимо установить флажки напротив пунктов:
Если в момент вызова веб-сервиса сеанс не подхватывается автоматически, попробуйте во время выполнения запроса (пока он «висит») заглянуть в список «Доступные сеансы» в этом же окне. Если вы видите там сеанс типа «Web-сервис», попробуйте подключить его вручную. Если сеанс не появляется — проблема в связи между веб-сервером и платформой.
Иногда стандартных настроек публикации недостаточно. В таких случаях мы прибегаем к созданию специальных файлов конфигурации в папке conf установленной платформы (например, C:\Program Files\1cv8\8.3.X.XXXX\bin\conf).
Рассмотрим использование файла webservicecfg.xml. Этот файл помогает платформе определить параметры отладки именно для веб-компонентов. Однако существует еще более универсальный способ — файл debug.cfg. Если создать его в папке conf и прописать в нем адрес сервера отладки, это принудительно направит все отладочные сообщения по нужному адресу:
CommonDebugServer=http://localhost:1560
Проанализируем ситуацию: если на сервере установлено несколько версий платформы, убедитесь, что вы правите файлы в каталоге именно той версии, которая используется веб-сервером. Это можно проверить в настройках «Обработчиков сопоставления» (Handler Mappings) в консоли управления IIS.
Выясним одну из самых частых «невидимых» причин отказа отладки — права доступа. Веб-сервис исполняется от имени пользователя, под которым запущен пул приложений IIS (обычно это IIS AppPool\DefaultAppPool). Этот пользователь должен иметь:
bin установленной платформы 1С.Если Конфигуратор запущен от имени администратора «Иванова», а процесс w3wp.exe (IIS) работает под системной учетной записью, они могут не «увидеть» друг друга в контексте сетевых подключений. Попробуйте запустить Конфигуратор от имени администратора, если это еще не сделано.
Также проанализируем влияние брандмауэра. Отладка — это двустороннее сетевое соединение. Для TCP/IP отладки должны быть открыты порты 1560–1591. Для HTTP-отладки должен быть открыт порт 1560 (или тот, который вы указали). Антивирусное ПО часто блокирует входящие соединения к Конфигуратору, считая их подозрительной активностью.
Посмотрим на пример кода, который инициирует вызов веб-сервиса со стороны клиента (например, из внешней обработки):
Определение = Новый WSОпределения(АдресWSDL, Логин, Пароль);
Прокси = Новый WSПрокси(Определение, "http://www.uri.com/data", "DocumentsData", "DocumentsDataSoap");
Данные = Прокси.GetData(ПараметрКлиент);
Если точка останова внутри метода GetData не срабатывает, попробуйте следующий прием: добавьте в самом начале метода веб-сервиса запись в журнал регистрации.
ЗаписьЖурналаРегистрации("ОтладкаВебСервиса", УровеньЖурналаРегистрации.Информация, , , "Метод GetData вызван успешно");
Если после вызова в журнале регистрации запись появилась, значит, код выполняется, и мы локализовали проблему — она на 100% в настройках «транспорта» отладки. Если записи нет — запрос вообще не дошел до выполнения кода 1С, и нужно проверять настройки IIS или авторизацию.
Разберем последовательность действий, если ничего не помогает:
debug enable="true" в default.vrd.iisreset.Следуя этим шагам, мы создаем контролируемую среду для разработки, где каждый вызов веб-сервиса будет прозрачен и доступен для анализа в привычном интерфейсе 1С.