Веб-сервисы 1С: что это и как их использовать

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

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

Работает схема так: в конфигураторе разработчик описывает сервис, его операции и параметры, пишет код обработки запросов на встроенном языке. Затем сервис публикуется на веб-сервере (IIS или Apache), после чего внешние системы могут обращаться к нему по URL. Каждый запрос проходит аутентификацию, выполняется код 1С, и результат возвращается вызывающей стороне в формате XML или JSON.

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

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

Важно понимать разницу между двумя ролями. 1С может быть поставщиком веб-сервиса — тогда она отвечает на входящие запросы. А может быть потребителем — тогда сама вызывает сервисы сторонних систем, например проверяет контрагента по ИНН через сервис ФНС или получает курсы валют. В этой статье речь в основном о первом сценарии, когда 1С открывает доступ к своим данным.

Чем SOAP-сервисы отличаются от HTTP-сервисов

SOAP-сервисы (объект «Web-сервисы» в конфигураторе) работают по строгому стандарту: запросы и ответы оборачиваются в XML-конверты, типы данных описываются в WSDL, поддерживаются сложные структуры через XDTO-пакеты. Это надёжный, но тяжеловесный вариант — сообщения получаются объёмными, а разработка требует аккуратного описания типов.

HTTP-сервисы (объект «HTTP-сервисы») дают полную свободу: разработчик сам определяет шаблоны URL, методы (GET, POST, PUT, DELETE) и формат тела запроса. Обычно данные передаются в JSON, что делает такие сервисы удобными для веб-разработчиков. Платформа всего лишь передаёт запрос в обработчик, а всю логику разбора и формирования ответа пишет разработчик.

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

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

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

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

Как опубликовать веб-сервис: порядок действий

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

В диалоге публикации указывается имя публикации (оно войдёт в URL), каталог веб-сервера и флажки «Публиковать веб-сервисы» и «Публиковать HTTP-сервисы». После нажатия «Опубликовать» платформа создаёт файл настроек default.vrd, в котором перечислены опубликованные сервисы.

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

После публикации проверьте результат: для SOAP-сервиса откройте в браузере адрес вида http://сервер/имя_базы/ws/ИмяСервиса?wsdl — должно вернуться XML-описание. Для HTTP-сервиса выполните запрос к шаблону URL, который вы задали в конфигураторе. Ошибка «404» обычно означает проблему с публикацией, «401» — с аутентификацией, «500» — ошибку в коде обработчика.

Пример простого HTTP-сервиса

Допустим, нужно отдавать остаток товара по артикулу. В конфигураторе создаётся HTTP-сервис, в нём — шаблон URL вида /stock/{article} с методом GET, а в обработчике пишется код, который находит номенклатуру, считает остаток и формирует JSON-ответ.

Функция stockGET(Запрос)
Артикул = Запрос.ПараметрыURL["article"];
Ответ = Новый HTTPСервисОтвет(200);

Товар = Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", Артикул);
Если Товар.Пустая() Тогда
Ответ.КодСостояния = 404;
Ответ.УстановитьТелоИзСтроки("{""error"":""Товар не найден""}");
Возврат Ответ;
КонецЕсли;

// ... запрос остатка и формирование JSON ...
Ответ.Заголовки.Вставить("Content-Type", "application/json");
Возврат Ответ;
КонецФункции

Обратите внимание на обработку ошибок: сервис обязан возвращать осмысленный HTTP-код (404, если объект не найден, 400 при неверных параметрах, 500 при внутренней ошибке), а не просто падать с исключением. Это сильно упрощает диагностику на стороне вызывающей системы.

curl -u Пользователь:Пароль "http://server/base/hs/api/stock/Т-001"

Безопасность и ограничения

Опубликованный веб-сервис — это точка входа в вашу базу извне, поэтому безопасность здесь критична. Минимальный набор мер: использовать HTTPS, а не открытый HTTP; завести отдельного пользователя 1С только для интеграции; выдать ему права ровно на те объекты, которые нужны сервису, без административных прав.

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

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

Как проверить, что интеграция работает правильно

После настройки проверьте сервис не только «в холостую», но и под нагрузкой, близкой к реальной. Убедитесь, что ответы приходят за приемлемое время, ошибки возвращают корректные коды, а данные в ответе совпадают с тем, что видно в самой 1С.

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