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

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

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

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

Какие виды веб-сервисов существуют в 1С

В дереве конфигурации в ветке «Общие» присутствуют два разных объекта: «Web-сервисы» и «HTTP-сервисы». Объект «Web-сервис» реализует классический SOAP-подход: вы описываете операции, их параметры и типы данных, платформа автоматически формирует WSDL-описание, а клиенты вызывают операции по протоколу SOAP. Этот вариант исторически применялся для интеграции с корпоративными системами, где WSDL-контракт важен для строгой типизации.

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

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

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

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

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

Публикация означает, что запросы внешних систем будет принимать веб-сервер (Apache или IIS), который через модуль расширения платформы передаёт их в информационную базу. Без веб-сервера опубликованный сервис работать не будет — файловый или клиент-серверный вариант базы сам по себе HTTP-запросы не принимает.

Порядок действий в конфигураторе: откройте меню «Администрирование» → «Публикация на веб-сервере», укажите имя публикации (латиницей, без пробелов), каталог для файлов публикации, установите флажки «Публиковать HTTP-сервисы» и/или «Публиковать Web-сервисы», затем нажмите «Опубликовать». После этого сервис станет доступен по адресу вида http://сервер/ИмяПубликации/hs/КорневойURL/... для HTTP-сервисов или .../ws/ИмяСервиса?wsdl для SOAP.

На рабочем сервере убедитесь, что установлены модули расширения веб-сервера из дистрибутива платформы и что версия разрядности модуля совпадает с разрядностью веб-сервера — несовпадение 32/64 бит является одной из самых частых причин ошибки «сервис недоступен» сразу после публикации.

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

Как написать обработчик HTTP-сервиса

В свойствах HTTP-сервиса задаётся корневой URL, а внутри создаются шаблоны URL с методами. Для каждого метода платформа формирует функцию-обработчик, в которую передаётся объект HTTPСервисЗапрос. Из него вы читаете параметры строки запроса, заголовки и тело, выполняете бизнес-логику и возвращаете объект HTTPСервисОтвет с кодом состояния и телом.

Функция ПолучитьОстатокGET(Запрос)
    Артикул = Запрос.ПараметрыЗапроса.Получить("article");
    Если Артикул = Неопределено Тогда
        Ответ = Новый HTTPСервисОтвет(400);
        Ответ.УстановитьТелоИзСтроки("Не указан параметр article");
        Возврат Ответ;
    КонецЕсли;
    // ... запрос остатка из базы ...
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(СтрокаJSON);
    Возврат Ответ;
КонецФункции

Обращайте внимание на три вещи. Во-первых, всегда возвращайте осмысленные HTTP-коды: 200 при успехе, 400 при ошибке в параметрах, 401 при отказе в доступе, 500 при внутренней ошибке — это упрощает диагностику на стороне клиента. Во-вторых, явно устанавливайте заголовок Content-Type с кодировкой UTF-8, иначе кириллица в ответе может отображаться некорректно. В-третьих, проверяйте все входные параметры до обращения к базе: непроверенные данные из внешнего запроса — источник ошибок и уязвимостей.

Как вызвать внешний веб-сервис из 1С

Для обращения к чужим API из кода используется связка объектов HTTPСоединение и HTTPЗапрос. Соединение описывает сервер, порт, защищённость (SSL) и при необходимости прокси, а запрос — конкретный ресурс, метод, заголовки и тело. Ответ приходит как объект HTTPОтвет, из которого читаются код состояния и тело.

Для SOAP-сервисов существует альтернатива: объект WSСсылка, который по адресу WSDL-описания автоматически создаёт прокси с типизированными методами. Это удобно, когда у внешнего сервиса сложная структура данных, но требует, чтобы WSDL был доступен в момент вызова. Для большинства современных REST API с JSON проще и прозрачнее работать через HTTPСоединение.

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

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

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

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

Как проверить работу сервиса и найти ошибку

Первичная проверка выполняется без всякого кода: для HTTP-сервиса с методом GET достаточно открыть URL в браузере, для SOAP — запросить WSDL по адресу ?wsdl. Если страница открывается и возвращает данные или XML-описание, публикация работает. Для методов POST/PUT используйте инструменты вроде Postman или curl, где можно задать заголовки, тело и авторизацию.

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

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