Как проверить работу HTTP-сервиса в 1С

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

Проверка HTTP-сервиса состоит из нескольких уровней: правильность публикации на веб-сервере, доступность URL из сети, корректность обработки запроса кодом 1С и адекватность возвращаемого ответа. Ошибка на любом из этих уровней даёт характерные симптомы — коды 404, 500, таймауты или пустые ответы.

Ниже разобраны практические способы проверки: от простого запроса в браузере до отладки обработчиков в конфигураторе, а также типичные ошибки и способы их диагностики.

Что нужно подготовить перед проверкой

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

Проверьте, какие методы (GET, POST, PUT, DELETE) разрешены в свойствах сервиса и какие из них реализованы в модуле. Если в шаблоне URL предусмотрены параметры, например /hs/orders/{id}, заранее подготовьте тестовое значение параметра, которое точно существует в базе, — это исключит ложные ошибки «не найдено».

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

Проверка публикации HTTP-сервиса на веб-сервере

Публикация выполняется через конфигуратор: меню «Администрирование — Публикация на веб-сервере». В диалоге публикации на вкладке «HTTP-сервисы» должны быть отмечены флажки «Публиковать HTTP-сервисы по умолчанию» либо конкретные сервисы в списке. Если флажок снят, сервис физически не попадёт в файл настроек публикации и будет недоступен.

После публикации убедитесь, что веб-сервер (IIS или Apache) запущен и виртуальный каталог базы существует. Для Apache проверьте, что в файле httpd.conf есть соответствующая секция с путём к файлу default.vrd, а сам файл default.vrd содержит элемент публикации HTTP-сервисов.

Быстрая проверка доступности самой публикации — открыть в браузере базовый URL информационной базы без /hs/. Если открывается веб-клиент или страница публикации, веб-сервер и публикация базы работают, и проблему стоит искать уже на уровне самого сервиса.

1. 1
   Откройте конфигуратор под пользователем с правами администратора
2. 2
   Перейдите: Администрирование — Публикация на веб-сервере
3. 3
   Укажите имя публикации и каталог, отметьте нужные HTTP-сервисы
4. 4
   Нажмите «Опубликовать» и дождитесь сообщения об успехе
5. 5
   Перезапустите веб-сервер (для Apache — перезапуск службы)
6. 6
   Проверьте доступность базового URL публикации в браузере

Проверка сервиса через браузер

Самый простой способ — выполнить GET-запрос прямо из адресной строки браузера. Сформируйте полный URL по шаблону: http://сервер/имя_публикации/hs/корневой_URL/параметры. Корневой URL берётся из свойства «Корневой URL» HTTP-сервиса в конфигураторе.

Если сервис требует аутентификации, браузер покажет диалог ввода логина и пароля — введите данные пользователя 1С, которому разрешён доступ. Логин и пароль также можно передать в URL в формате http://логин:пароль@сервер/..., но делайте это только в тестовой среде: такие адреса сохраняются в истории браузера.

Интерпретируйте результат по коду ответа и содержимому страницы. JSON или XML с данными — сервис работает. Страница ошибки веб-сервера с кодом 404 — проблема публикации или неверный URL. Текст ошибки 1С с кодом 500 — исключение в коде обработчика, и в тексте обычно видно, в какой строке модуля оно произошло.

Проверка через curl и Postman

Браузер подходит только для GET-запросов. Для проверки методов POST, PUT и DELETE, а также для передачи тела запроса и заголовков удобнее curl или Postman. Утилита curl доступна в командной строке Windows и Linux и позволяет зафиксировать точный ответ сервера, включая код и заголовки.

curl -i -u Пользователь:Пароль -X GET "http://server/base/hs/api/status" -H "Content-Type: application/json"

Ключ -i выводит заголовки ответа вместе с кодом состояния — это первое, что нужно смотреть при диагностике. Для POST-запроса добавьте ключ -d с телом: curl -X POST -d "{\"name\":\"test\"}" и заголовок Content-Type: application/json, если обработчик ожидает JSON.

В Postman создайте новый запрос, выберите метод, вставьте URL, на вкладке Authorization выберите Basic Auth и укажите учётные данные 1С. Преимущество Postman — сохранение коллекции тестовых запросов: при каждой доработке сервиса можно повторить весь набор проверок одним запуском.

Отладка обработчиков в конфигураторе

Когда сервис отвечает ошибкой 500 или возвращает неверные данные, нужна отладка кода обработчика. Для этого в конфигураторе включите отладку по HTTP: «Сервис — Параметры», на вкладке отладки установите режим подключения к веб-серверу и убедитесь, что в публикации разрешена отладка (флажок «Разрешить отладку» в диалоге публикации).

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

Обратите внимание, что в модуле HTTP-сервиса недоступны интерактивные возможности: нельзя вызвать Предупреждение() или открыть форму — такие вызовы сами по себе вызовут ошибку 500. Для трассировки используйте запись в журнал регистрации через ЗаписьЖурналаРегистрации() или временный вывод диагностических данных в тело ответа.

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

Наиболее частая причина недоступности сервиса — рассинхронизация публикации: сервис добавили или переименовали в конфигураторе, но публикацию не обновили. Любое изменение состава сервисов, корневых URL и шаблонов требует повторной публикации и перезапуска веб-сервера.

Вторая группа ошибок — несовпадение URL. Шаблон URL в свойствах сервиса чувствителен к структуре: лишний или отсутствующий слеш, другой регистр символов в корневом URL приводят к 404. Сверяйте запрашиваемый адрес посимвольно со свойствами сервиса.

Третья группа — ошибки в коде обработчика: обращение к несуществующим реквизитам, деление на ноль, попытка записи без установки привилегированного режима при недостатке прав у пользователя, под которым выполняется запрос. Диагностируется через текст ошибки в ответе и журнал регистрации (Сервис — Журнал регистрации, отбор по событию с ошибкой).

Проверка результата и контрольные точки

Проверка считается завершённой, когда сервис не просто отвечает кодом 200, а возвращает корректные данные и правильно обрабатывает граничные случаи: несуществующий параметр, пустое тело запроса, неверный формат. Обработчик должен возвращать осмысленные коды (400, 404) вместо падения с ошибкой 500.

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

Часто задаваемые вопросы