При работе с расширениями конфигурации 1С программисты часто сталкиваются с ситуацией, когда созданный HTTP-сервис успешно работает в рамках отладки внутри конфигуратора, но абсолютно «невидим» для внешних запросов после публикации на веб-сервере (Apache или IIS). В стандартном диалоговом окне публикации на вкладке «HTTP-сервисы» такие объекты просто не отображаются в списке. Давайте разберем по шагам, почему так происходит и как правильно опубликовать и отладить сервисы, находящиеся в расширениях.
Первое, что нам необходимо уяснить: платформа 1С:Предприятие по умолчанию не выводит HTTP-сервисы расширений в общий список доступных сервисов в окне «Публикация на веб-сервере». Это поведение является штатным. Вместо выбора конкретных объектов, нам предлагается включить механизм публикации «оптом».
Рассмотрим порядок действий для активации автоматической публикации:
Важно понимать принцип «все или ничего»: включив этот флаг, вы публикуете сразу все HTTP-сервисы из всех активных расширений базы. Выбрать выборочно конкретный сервис из расширения в этом интерфейсе невозможно.
Бывают случаи, когда установка флажка в интерфейсе 1С не приводит к желаемому результату, или же файл конфигурации веб-сервера default.vrd по какой-то причине не обновился корректно. В такой ситуации проанализируем содержимое файла default.vrd, который обычно находится в каталоге публикации (например, C:\inetpub\wwwroot\base_name\ или /var/www/base_name/).
Если автоматика не сработала, мы можем прописать сервис вручную внутри секции <httpServices>. Синтаксис для сервисов из расширений имеет критически важную особенность: имя сервиса должно включать имя самого расширения, отделенное двоеточием.
Разберем пример записи в default.vrd:
<httpServices publishExtensionsByDefault="true">
<service name="ИмяРасширения:ИмяСервиса" rootUrl="my_service_endpoint" enable="true" />
</httpServices>
Где ИмяРасширения — это имя объекта «Расширение» в дереве конфигурации, а ИмяСервиса — имя самого объекта HTTP-сервис внутри этого расширения. Параметр rootUrl определяет, по какому пути сервис будет доступен извне.
Выясним причину, по которой внешние системы могут получать ошибку 404 (Not Found) даже при включенной публикации. Структура URL для расширений может отличаться. Проанализируем стандартную схему:
Для обычного сервиса: http://server/base_name/hs/rootUrl/
Для сервиса из расширения платформа часто ожидает путь в формате: http://server/base_name/hs/ИмяРасширения/rootUrl/. Однако это поведение варьируется в зависимости от версии платформы и настроек в default.vrd. Если вы указали rootUrl вручную в файле конфигурации, используйте именно его. Также помните, что начиная с версии 8.3.15, платформа крайне чувствительна к регистру символов в URL. Если в расширении rootUrl задан как GetData, то обращение по пути getdata может вернуть ошибку. Для отправки тестовых запросов и проверки доступности эндпоинта можно использовать инструмент для тестирования REST API.
Если публикация прошла успешно, но точка останова в коде расширения не срабатывает, необходимо проверить настройки отладки — для этого подойдёт руководство по пошаговой отладке кода в 1С. Рассмотрим алгоритм включения отладки:
-debug -http.<point>:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
debug="true"
debuggerURL="http://your_server:1560">
default.vrd могут просто не записаться из-за ограничений прав доступа в Windows (User Account Control).Проанализируем ситуацию с «Безопасным режимом». Это одна из самых частых причин «молчаливого» отказа сервиса. Если расширение подключено в безопасном режиме (флаг Безопасный режим в списке расширений в режиме Предприятие), доступ к HTTP-сервисам может быть ограничен. Попробуйте снять этот флаг и перезапустить веб-сервер.
Зачастую программист создает HTTP-сервис в расширении, но забывает добавить в это же расширение роль, дающую право Использование для данного сервиса. Посмотрим на ситуацию со стороны сервера: если запрос приходит от пользователя, у которого в основных ролях нет доступа к новому объекту расширения, сервер вернет ошибку авторизации.
Важное правило: Всегда создавайте в расширении роль, включайте в нее право на использование HTTP-сервиса и назначайте эту роль пользователю, под которым выполняется HTTP-запрос.
Если все настройки выполнены, но сервис по-прежнему не виден, выполним «гигиенические» процедуры:
Таким образом, для успешной работы HTTP-сервиса из расширения нам необходимо не только установить флаг в окне публикации, но и убедиться в корректности структуры default.vrd, проверить права доступа (роли) и настройки протокола отладки. Для фиксации входящих запросов и отслеживания ошибок пригодится расширение для логирования HTTP-сервисов.