Что такое веб-сервис в 1С и как его использовать

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

Механизм работает в обе стороны. 1С может не только публиковать собственные веб-сервисы (выступать сервером), но и обращаться к чужим сервисам как клиент — например, получать курсы валют, проверять контрагентов или отправлять данные в государственные системы.

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

Зачем нужны веб-сервисы в 1С

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

Типичные сценарии использования:

• выгрузка каталога товаров и остатков на сайт в реальном времени;
• приём заказов с сайта сразу в учётную систему;
• обмен данными между распределёнными базами (центральный офис и филиалы);
• подключение мобильных приложений для торговых представителей;
• интеграция с платёжными системами, службами доставки, онлайн-кассами.

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

Типы веб-сервисов в платформе 1С

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

Выбор зависит от задачи. Если интеграция строится с системой, которая умеет работать только по SOAP и требует WSDL-описание, используют классический веб-сервис. Если разработка ведётся с нуля и важны гибкость и простота отладки — рациональнее HTTP-сервис с JSON.

Сравнение вариантов

SOAP веб-сервис

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

HTTP-сервис (REST)

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

Файловый обмен

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

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

Сам по себе объект в конфигураторе не доступен извне — его нужно опубликовать на веб-сервере. Для этого используется IIS (Windows) или Apache. Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере», где указывается имя публикации, каталог и отмечается флаг публикации веб-сервисов.

После публикации платформа создаёт в каталоге файл default.vrd — это XML-файл настроек, где прописано, какие сервисы опубликованы и как веб-сервер подключается к информационной базе (строка соединения, аутентификация).

1. 1
   Создайте в конфигураторе объект Web-сервис и опишите его операции и параметры
2. 2
   Напишите код обработчиков операций на встроенном языке
3. 3
   Обновите конфигурацию базы данных
4. 4
   Убедитесь, что веб-сервер (IIS или Apache) установлен и настроен модуль расширения 1С
5. 5
   Выполните публикацию через «Администрирование» → «Публикация на веб-сервере»
6. 6
   Проверьте доступность WSDL: откройте в браузере адрес вида http://сервер/база/ws/ИмяСервиса?wsdl

Признак успешной публикации — при открытии URL с параметром ?wsdl браузер показывает XML-описание сервиса. Если вместо этого ошибка 404 или 500, проверяйте права на каталог публикации, регистрацию модуля расширения веб-сервера и корректность строки соединения в default.vrd.

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

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

Распространённая практика — завести отдельного служебного пользователя с минимально необходимыми правами. Если сервис только отдаёт остатки товаров, этому пользователю не нужны права на документы, деньги и справочник сотрудников. При компрометации пароля ущерб будет ограничен.

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

Как 1С обращается к внешним веб-сервисам

Обратная задача — когда 1С сама выступает клиентом — решается двумя способами. Для SOAP-сервисов в конфигурации создаётся объект «WS-ссылка»: платформа загружает WSDL-описание внешнего сервиса и генерирует прокси-объект, через который вызываются операции как обычные методы.

Для произвольных HTTP-запросов используется объект HTTPСоединение и связанные объекты HTTPЗапрос и HTTPОтвет. Такой подход универсален: он подходит для REST API, вебхуков и любых сервисов, возвращающих JSON или XML. Ответ разбирается штатными средствами — ЧтениеJSON или ЧтениеXML.

HTTPСоединение = Новый HTTPСоединение("api.example.com", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/v1/rates");
Ответ = HTTPСоединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
Данные = ПрочитатьJSON(Чтение);
КонецЕсли;

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

Проверка работы и диагностика проблем

Базовая проверка опубликованного сервиса — запрос WSDL в браузере. Для HTTP-сервисов удобно отправлять тестовые запросы через curl или Postman: так видно и код ответа, и тело, и время выполнения. Внутри 1С диагностику помогают журнал регистрации и технологический журнал, где фиксируются ошибки выполнения кода операций.

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

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

Открытие URL сервиса с параметром ?wsdl

Норма

Браузер показывает XML-описание сервиса

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

Ошибка 404, 500 или запрос авторизации, который не проходит

Тестовый вызов операции из внешнего клиента

Норма

Ответ с кодом 200 и корректными данными в теле

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

Код 500, пустой ответ или сообщение об ошибке платформы

Журнал регистрации после вызова

Норма

Нет ошибок, есть записи о выполнении операции

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

Ошибки выполнения кода, отказы в доступе

Права служебного пользователя

Норма

Пользователь видит только нужные для сервиса объекты

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

Пользователь имеет роли администратора или полные права

Если сервис «внезапно» перестал работать после обновления конфигурации, первым делом проверьте, не потерялась ли публикация: при обновлении через конфигуратор файл default.vrd может перезаписываться. Также проверяйте, не изменились ли имена операций и параметры — внешние системы обращаются по старым именам и получают ошибки.

Ограничения и альтернативы

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

Альтернативы, которые стоит рассмотреть: планы обмена для синхронизации между базами 1С, универсальный формат EnterpriseData для обмена с типовыми конфигурациями, брокеры сообщений (RabbitMQ, Kafka) для асинхронной интеграции, а также стандартный OData-интерфейс, который платформа публикует автоматически и который позволяет читать данные без написания кода.

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

Чем веб-сервис отличается от HTTP-сервиса в 1С?

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

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

Нет. Для приёма HTTP-запросов обязательно нужен IIS или Apache с установленным модулем расширения веб-сервера 1С. Это относится и к файловым, и к клиент-серверным базам.

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

Откройте в браузере адрес вида http://сервер/имя_публикации/ws/ИмяСервиса?wsdl. Если отображается XML-описание — публикация успешна. Затем выполните тестовый вызов операции из внешнего клиента и проверьте код ответа и журнал регистрации.

Какие права нужны пользователю для работы веб-сервиса?

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

Что делать, если после обновления конфигурации внешняя система получает ошибки?

Проверьте, не изменились ли имена операций и состав параметров в новой версии конфигурации, и не перезаписался ли файл default.vrd при публикации. Сравните текущее WSDL-описание с тем, что использует внешняя система, и при необходимости обновите публикацию заново.

Когда вместо веб-сервиса лучше использовать другой механизм?

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