Веб-сервисы 1С: как они работают и как их настроить

Веб-сервисы в 1С — это механизм, который позволяет платформе принимать запросы от внешних систем и отдавать данные или выполнять действия в базе. Сайт, мобильное приложение, складская программа или банковский клиент обращаются к опубликованному адресу, а 1С выполняет код и возвращает ответ. Платформа поддерживает два подхода: классические SOAP-сервисы (объект «Web-сервис») и более гибкие HTTP-сервисы, появившиеся в версии 8.3.

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

Ниже разобрано, как устроены оба типа сервисов, как происходит обработка запроса, как опубликовать и проверить сервис, а также какие ошибки встречаются чаще всего при интеграциях.

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

Первый тип — SOAP web-сервисы. Они описываются в конфигураторе в ветке «Общие → Web-сервисы» и работают по протоколу SOAP: запросы и ответы передаются в XML-конвертах, а структура сервиса описывается WSDL-файлом. Это старый, формально строгий стандарт: клиент может автоматически сгенерировать код обращения по WSDL-описанию. Минус — громоздкость XML, сложность отладки и меньшая гибкость.

Второй тип — HTTP-сервисы (ветка «Общие → HTTP-сервисы»). Здесь разработчик сам определяет URL-шаблоны (например, /orders/{id}), методы (GET, POST, PUT, DELETE) и формат данных — чаще всего JSON. Это фактически REST-подход: легче отлаживать, меньше накладных расходов, удобнее для мобильных приложений и современных интеграций.

SOAP или HTTP-сервис

SOAP (Web-сервис)

Подходит, если внешняя система требует WSDL-описание или уже работает по SOAP. Ограничение: тяжёлый XML, сложнее отладка.

HTTP-сервис (REST/JSON)

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

Стандартный OData-интерфейс

Подходит для чтения и простого изменения данных без написания кода. Ограничение: нельзя встроить произвольную бизнес-логику.

Как платформа обрабатывает входящий запрос

Цепочка обработки выглядит так. Внешняя система отправляет HTTP-запрос на адрес вида http://server/base/hs/api/orders. Веб-сервер (Apache или IIS) по настройкам публикации понимает, что запрос относится к 1С, и передаёт его расширению веб-сервера платформы. Далее запрос попадает в кластер серверов 1С (или в файловую базу через веб-расширение), где запускается сеанс и выполняется код обработчика.

Внутри обработчика HTTP-сервиса разработчик получает объект HTTPСервисЗапрос, из которого читает параметры URL, заголовки и тело запроса, выполняет нужную логику (запись документа, выборку данных) и формирует объект HTTPСервисОтвет с кодом состояния и телом. Коды ответа — стандартные HTTP: 200 при успехе, 400 при ошибке в данных, 401 при отказе в аутентификации, 500 при внутренней ошибке.

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

Публикация выполняется из конфигуратора: меню «Администрирование → Публикация на веб-сервере». Предварительно на машине должен быть установлен и запущен Apache или IIS, а также компоненты веб-доступа платформы 1С. В диалоге публикации указывают имя публикации (оно войдёт в URL), каталог и отмечают флажки: «Публиковать HTTP-сервисы» и/или «Публиковать Web-сервисы», при необходимости — стандартный интерфейс OData.

После публикации платформа создаёт в каталоге файлы настройки (в том числе default.vrd) и регистрирует обработчик в конфигурации веб-сервера. Проверка простая: для SOAP-сервиса откройте в браузере адрес вида http://server/base/ws/ИмяСервиса?wsdl — должно вернуться XML-описание. Для HTTP-сервиса отправьте тестовый запрос на его URL-шаблон.

1. 1
   Установите веб-сервер (Apache или IIS) и компоненты веб-доступа платформы 1С
2. 2
   Создайте в конфигураторе HTTP-сервис с URL-шаблоном и обработчиками методов
3. 3
   Откройте «Администрирование → Публикация на веб-сервере», укажите имя и отметьте публикацию HTTP-сервисов
4. 4
   Перезапустите веб-сервер, чтобы изменения применились
5. 5
   Отправьте тестовый запрос (например, через браузер для GET или Postman/curl для POST) и проверьте код ответа

Аутентификация и безопасность

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

Передавать логин и пароль по открытому HTTP недопустимо: данные в заголовке легко перехватываются. Настройте HTTPS на веб-сервере (SSL-сертификат) и ограничьте доступ по IP-адресам, если интеграция идёт с фиксированных серверов. Дополнительный уровень — проверка токена или подписи внутри самого обработчика: сервис сверяет переданный ключ с хранящимся в базе и отклоняет чужие запросы.

Отладка и проверка результата

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

Проверять результат удобнее всего внешними инструментами: curl, Postman или даже браузером для GET-запросов. Смотрите не только на тело ответа, но и на HTTP-код: сервис, который всегда возвращает 200 с текстом ошибки внутри, затрудняет мониторинг со стороны внешней системы. Полезно вести журнал обращений — записывать в регистр сведений входящий запрос, результат и время выполнения.

Контрольные точки

Как проверить результат

WSDL SOAP-сервиса

Норма

По адресу ?wsdl возвращается XML-описание

Тревожный признак

Ошибка 404 (сервис не опубликован) или 500 (ошибка в коде)

Ответ HTTP-сервиса

Норма

Код 200 и корректное тело в ожидаемом формате

Тревожный признак

Код 401 (проблема аутентификации), 500 (исключение в обработчике)

Права пользователя

Норма

Технический пользователь имеет доступ только к нужным объектам

Тревожный признак

Сервис работает под администратором или полными правами

Типичные ошибки и ограничения

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

Важное ограничение: каждый вызов веб-сервиса — это отдельный сеанс 1С, который расходует лицензии и ресурсы сервера. Частые тяжёлые запросы способны исчерпать пул сеансов и замедлить работу пользователей. Для массовых выгрузок лучше проектировать пакетные методы (один запрос — много записей) и ограничивать время выполнения обработчика.

Когда веб-сервис не нужен: альтернативы

Не каждая интеграция требует собственного сервиса. Если внешней системе нужно только читать и простым образом изменять данные, достаточно включить стандартный интерфейс OData при публикации — он автоматически предоставляет доступ к объектам конфигурации без написания кода. Для обмена между двумя базами 1С часто проще использовать планы обмена или формат EnterpriseData через регламентные задания.

Обратная ситуация — когда 1С сама выступает клиентом: тогда используются объекты HTTPСоединение и HTTPЗапрос для обращения к внешним API. Это отдельная тема, но важно не путать направление: публикация веб-сервиса открывает доступ внутрь базы, а HTTPСоединение работает наружу.

Частые вопросы

Чем HTTP-сервис отличается от Web-сервиса (SOAP) в 1С?

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

Почему веб-сервис возвращает ошибку 404, хотя он создан в конфигураторе?

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

Нужен ли отдельный пользователь 1С для веб-сервиса?

Да, это обязательная практика. Создайте технического пользователя с ролями, дающими доступ только к объектам, которые обрабатывает сервис. Работа под административной учётной записью означает, что компрометация одного пароля открывает полный доступ ко всей базе.

Как отладить код обработчика веб-сервиса?

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

Сколько одновременных запросов выдержит веб-сервис 1С?

Точного универсального числа нет: каждый запрос создаёт сеанс, который расходует лицензии и ресурсы сервера. Предел зависит от мощности сервера, количества лицензий и тяжести обработчиков. Практическая рекомендация — делать обработчики быстрыми, объединять данные в пакеты и при высокой нагрузке рассматривать очереди сообщений вместо прямых синхронных вызовов.

Можно ли опубликовать веб-сервис файловой базы?

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