Что нужно, чтобы опубликовать web-сервис и HTTP-сервис в 1С

Для публикации web-сервиса или HTTP-сервиса 1С недостаточно просто описать его в конфигураторе — платформа сама по себе не умеет принимать входящие HTTP-запросы извне. Нужен внешний веб-сервер (IIS или Apache), установленное расширение веб-сервера 1С, корректный файл публикации и права доступа к информационной базе. Только после настройки всей цепочки внешние системы смогут обращаться к сервисам по URL.

Web-сервисы и HTTP-сервисы решают схожую задачу — приём и обработка запросов из других систем, но работают по-разному. Web-сервис использует протокол SOAP и описывается через WSDL, что удобно для интеграций с корпоративными системами, где важна строгая типизация. HTTP-сервис работает с произвольными HTTP-запросами (GET, POST, PUT, DELETE) и чаще применяется для REST-подобных API, обмена с сайтами, мобильными приложениями и весовым оборудованием.

Оба типа сервисов публикуются через один механизм: диалог публикации в конфигураторе формирует файлы настройки веб-сервера (default.vrd и связанные с ним), после чего веб-сервер начинает перенаправлять запросы в платформу 1С. Ниже разобраны все необходимые компоненты, порядок публикации, проверка результата и типичные ошибки.

Какие компоненты нужны до начала публикации

Первое обязательное условие — установленный и работающий веб-сервер. На Windows чаще используют IIS (включается через компоненты Windows), на Linux — Apache 2.4. Без веб-сервера публикация невозможна в принципе: кнопка «Опубликовать» в конфигураторе будет недоступна или завершится ошибкой.

Второй компонент — «Расширение веб-сервера 1С:Предприятия». Оно ставится вместе с платформой, но по умолчанию может быть не выбрано в установщике. Проверить наличие можно по файлам wsisapi.dll (для IIS) или модулю wsap24.so (для Apache) в каталоге установки платформы. Если расширения нет, запустите установщик платформы повторно и отметьте соответствующий компонент.

Третье условие — сам сервис должен быть создан в конфигурации. Для web-сервиса в ветке «Общие → Web-сервисы» описываются операции и параметры, в модуле пишется код обработчиков. Для HTTP-сервиса в ветке «Общие → HTTP-сервисы» создаются шаблоны URL и методы, в модуле реализуются функции обработки запросов. Публиковать «пустышку» бессмысленно — сервис должен отвечать на запросы.

Чем web-сервис отличается от HTTP-сервиса и что выбрать

Web-сервис 1С работает по протоколу SOAP: структура сообщений строго описана в WSDL-файле, который платформа генерирует автоматически. Клиентская система получает WSDL по специальному URL и строит запросы по этой схеме. Это удобно, когда интегрирующаяся система умеет работать с SOAP «из коробки» — например, при обмене между двумя базами 1С или с корпоративными ERP.

HTTP-сервис даёт полную свободу: вы сами определяете шаблон URL, метод запроса, формат тела (JSON, XML, произвольный текст) и код ответа. Это стандартный подход для REST API. Минус — нет автоматического описания интерфейса, документацию для интегрирующей стороны придётся писать вручную.

Пошаговая публикация через конфигуратор

Основной способ публикации — диалог в конфигураторе. Откройте меню «Администрирование → Публикация на веб-сервере». Если пункт неактивен, конфигуратор запущен без достаточных прав или веб-сервер не обнаружен.

В диалоге укажите имя публикации (латиница, без пробелов — оно станет частью URL), каталог на диске, куда будут записаны файлы настройки, и тип веб-сервера. На закладках отметьте, что именно публиковать: web-сервисы, HTTP-сервисы, а при необходимости — стандартный интерфейс OData и тонкий клиент через веб.

1. 1
   Убедитесь, что веб-сервер запущен, а расширение веб-сервера 1С установлено
2. 2
   Запустите конфигуратор от имени администратора (важно для записи настроек IIS)
3. 3
   Откройте «Администрирование → Публикация на веб-сервере»
4. 4
   Задайте имя публикации и каталог, выберите тип веб-сервера
5. 5
   Отметьте нужные сервисы на закладках «Web-сервисы» и «HTTP-сервисы»
6. 6
   Нажмите «Опубликовать» и дождитесь сообщения об успешной публикации
7. 7
   При необходимости перезапустите веб-сервер (iisreset или restart Apache)

После публикации в указанном каталоге появятся файлы default.vrd и (для web-сервисов) ws-публикации. Файл default.vrd — главный: именно он указывает расширению веб-сервера, к какой информационной базе подключаться и какие сервисы доступны. Для клиент-серверной базы в нём прописывается строка подключения к серверу 1С, для файловой — путь к каталогу базы.

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

Публикация через файл default.vrd вручную

В сценариях автоматизации удобнее создавать или править default.vrd напрямую, а публикацию выполнять утилитой webinst из комплекта платформы. Это позволяет включить публикацию в скрипты развёртывания и не открывать конфигуратор на сервере.

Минимальный default.vrd для HTTP-сервиса содержит точку подключения к базе и элемент httpServices с указанием имени сервиса и пула соединений. Для web-сервиса добавляется элемент ws с именем публикации. Синтаксис файла описан в документации платформы; проще всего взять за основу файл, сгенерированный конфигуратором, и адаптировать его.

<?xml version="1.0" encoding="UTF-8"?>
<point name="MyBase" ib="Srvr=&quot;server&quot;;Ref=&quot;base&quot;;">
  <httpServices>
    <service name="MyHttpService" rootUrl="api" poolSize="10" poolTimeout="60"/>
  </httpServices>
  <ws pointEnable="true"/>
</point>

Ручной способ требует аккуратности: ошибка в XML или неверная строка подключения приведут к тому, что все запросы будут возвращать ошибку 500, а диагностировать причину придётся по журналам веб-сервера и технологическому журналу 1С.

Как проверить, что сервис опубликован и работает

Первичная проверка web-сервиса — запрос WSDL в браузере. Откройте адрес вида http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Если в ответ пришёл XML с описанием сервиса — публикация работает. Ошибка 404 означает, что публикация не создана или имя указано неверно, ошибка 500 — проблема с подключением к базе или правами.

HTTP-сервис проверяется прямым запросом по шаблону URL, например http://сервер/ИмяПубликации/hs/api/ping. Удобно использовать Postman, curl или браузер для GET-запросов. В ответе должен прийти результат, который формирует ваш код в модуле сервиса.

Безопасность и права доступа

Опубликованный сервис — это точка входа в базу извне, поэтому вопрос аутентификации критичен. По умолчанию используется аутентификация 1С: логин и пароль передаются в заголовке запроса (Basic-аутентификация). Создайте отдельного пользователя с минимально необходимыми правами — только на те объекты, к которым обращается сервис. Никогда не публикуйте сервисы под пользователем с полными правами.

При доступе из интернета обязательно настройте HTTPS на веб-сервере: логин и пароль в Basic-аутентификации передаются в открытом виде и без шифрования легко перехватываются. Дополнительно можно ограничить доступ по IP-адресам средствами веб-сервера.

Отдельный риск — код обработчиков. Входные параметры запроса нельзя использовать в запросах к базе без проверки: конкатенация строк в тексте запроса 1С открывает путь к инъекциям. Используйте параметры запроса и валидируйте все входные данные.

Типичные ошибки и их решение

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

FAQ