Как вызвать веб-сервис 1С: пошаговое руководство

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

Перед вызовом сервис должен быть опубликован на веб-сервере — IIS или Apache. Без публикации объект «Web-сервис» или «HTTP-сервис» существует только в конфигурации и недоступен извне. Публикация создаёт на веб-сервере виртуальный каталог с файлом default.vrd, который связывает URL с конкретной информационной базой.

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

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

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

HTTP-сервис работает иначе: вы задаёте шаблон URL (например, /orders/*) и обрабатываете методы GET, POST, PUT, DELETE в модуле сервиса. Формат данных произвольный — чаще всего JSON. Такой вариант предпочтителен для мобильных приложений, сайтов и обмена с системами, где нет SOAP-клиента.

Публикация сервиса на веб-сервере

Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». Укажите имя публикации (латиницей, без пробелов — оно войдёт в URL), выберите веб-сервер и каталог, а на закладках «Web-сервисы» и «HTTP-сервисы» отметьте нужные объекты. После нажатия «Опубликовать» платформа создаст файл default.vrd и зарегистрирует виртуальный каталог.

Для работы публикации на компьютере с веб-сервером должны быть установлены модули расширения веб-сервера 1С — они ставятся вместе с платформой. На IIS дополнительно проверьте, что пул приложений работает в нужной разрядности и у учётной записи пула есть доступ к каталогу публикации. На Apache требуется подключить модуль wsap24.so (имя зависит от версии платформы) и указать обработчик в конфигурации.

1. 1
   Установите компонент «Модули расширения веб-сервера» дистрибутива 1С
2. 2
   Создайте в конфигураторе Web-сервис или HTTP-сервис с операциями и шаблонами
3. 3
   Откройте «Администрирование → Публикация на веб-сервере», задайте имя и каталог
4. 4
   Отметьте сервисы для публикации и нажмите «Опубликовать»
5. 5
   Перезапустите веб-сервер и проверьте доступность URL в браузере

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

Настройка аутентификации и прав

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

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

Вызов SOAP-сервиса из 1С

Если вызывающая сторона — другая база 1С, удобнее всего использовать WS-ссылку: в конфигураторе добавьте объект «WS-ссылки», укажите URL WSDL-описания, и платформа создаст типизированный прокси. Вызов операции в коде выглядит как обычный вызов функции с параметрами.

Альтернатива без изменения конфигурации — динамическое создание прокси через объект WSОпределения. Этот способ подходит для внешних обработок и случаев, когда адрес сервиса хранится в настройках.

Определение = Новый WSОпределения("http://server/base/ws/Orders?wsdl", "Интеграция", "Пароль");
Прокси = Новый WSПрокси(Определение, "http://example.org/orders", "Orders", "OrdersSoap");
Результат = Прокси.GetOrder("Заказ-001");

Таймаут соединения задаётся параметром конструктора WSПрокси. Если сервис выполняет тяжёлую операцию, увеличьте таймаут явно, иначе длительный вызов завершится исключением раньше, чем сервер вернёт ответ.

Вызов HTTP-сервиса из 1С и внешних приложений

Для вызова HTTP-сервиса из 1С используется объект HTTPСоединение и HTTPЗапрос. Адрес формируется из имени публикации и шаблона сервиса: http://сервер/имя/hs/путь/ресурс. Логин и пароль передаются в конструкторе соединения или в заголовке Authorization.

Соединение = Новый HTTPСоединение("server", 80, "Интеграция", "Пароль");
Запрос = Новый HTTPЗапрос("/base/hs/orders/123");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
Данные = Ответ.ПолучитьТелоКакСтроку();
КонецЕсли;

Из внешних приложений вызов ещё проще — это обычный HTTP-запрос. Например, проверить сервис можно утилитой curl до того, как писать код клиента.

curl -u Интеграция:Пароль -X GET "http://server/base/hs/orders/123" -H "Accept: application/json"

Для POST-запросов с JSON передавайте заголовок Content-Type: application/json, а в модуле HTTP-сервиса читайте тело методом ПолучитьТелоКакСтроку() и разбирайте через ЧтениеJSON. Учтите, что тело запроса доступно для чтения один раз — сохраните его в переменную сразу.

Диагностика ошибок при вызове

Большинство проблем при вызове веб-сервиса 1С диагностируется по коду ответа HTTP. Код 404 означает, что публикация не найдена или не совпал шаблон URL; 401 — не пройдена аутентификация; 403 — пользователь аутентифицирован, но у него нет прав; 500 — исключение в коде операции сервиса, текст ошибки ищите в теле ответа и в журнале регистрации базы.

Если вызов из браузера работает, а из клиентского приложения — нет, сравните заголовки запросов. Частая причина — прокси-сервер в сети клиента, который подменяет или блокирует запрос, либо отсутствие заголовка Authorization, который браузер добавлял автоматически после первого запроса.

Безопасность и ограничения самостоятельной настройки

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

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

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

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