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

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

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

Что нужно подготовить перед вызовом

Прежде чем писать код, убедитесь, что веб-сервис действительно опубликован и доступен. На сервере, где развёрнута база-источник, веб-сервис публикуется через конфигуратор (Администрирование → Публикация на веб-сервере) либо вручную через файл default.vrd. Публикация выполняется на веб-сервере IIS или Apache.

Со стороны вызывающей базы вам понадобятся: URL сервиса (для SOAP — адрес вида http://сервер/база/ws/ИмяСервиса.1cws?wsdl, для HTTP-сервиса — базовый URL вида http://сервер/база/hs/имя), а также логин и пароль пользователя той базы, у которого есть права на вызов операций сервиса. Проверить доступность можно прямо из браузера: откройте URL WSDL — если браузер показывает XML-описание сервиса, публикация работает.

Вызов SOAP веб-сервиса через WS-ссылку

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

Порядок действий: в конфигураторе откройте ветку «Общие → WS-ссылки», добавьте новую ссылку и укажите URL WSDL. Платформа загрузит описание и покажет список операций. После этого в коде используйте WSСсылки.ИмяСсылки.СоздатьWSПрокси() с указанием пространства имён, имени сервиса и точки подключения — эти значения берутся из WSDL.

Пример кода вызова операции:

Определение = Новый WSОпределения("http://server/base/ws/Exchange.1cws?wsdl", "user", "password");
Прокси = Новый WSПрокси(Определение,
"http://example.org/exchange",
"Exchange",
"ExchangeSoap");
Прокси.Пользователь = "user";
Прокси.Пароль = "password";

Результат = Прокси.GetDocuments(НачалоДня(ТекущаяДата()));

Обратите внимание: имя точки подключения в WSDL обычно заканчивается на «Soap», и если перепутать её с именем сервиса, платформа выдаст ошибку о невозможности найти точку подключения. Пространство имён URI сервиса задаётся в конфигураторе базы-источника в свойствах веб-сервиса.

Вызов HTTP-сервиса через HTTPСоединение

HTTP-сервисы 1С работают по принципу «запрос — ответ» без жёсткой схемы WSDL, поэтому на стороне клиента используется универсальный механизм HTTPСоединение. Этот же способ подходит для обращения к любым REST API, опубликованным внешними системами.

Пример GET-запроса к HTTP-сервису:

Соединение = Новый HTTPСоединение("server", 80, "user", "password");
Запрос = Новый HTTPЗапрос("/base/hs/orders/list?date=20260101");
Запрос.Заголовки.Вставить("Accept", "application/json");

Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
ТелоОтвета = Ответ.ПолучитьТелоКакСтроку();
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ТелоОтвета);
Данные = ПрочитатьJSON(ЧтениеJSON);
Иначе
ВызватьИсключение "Ошибка сервиса: " + Ответ.КодСостояния;
КонецЕсли;

Для HTTPS-подключений в конструктор HTTPСоединение дополнительно передаётся объект защищённого соединения: Новый ЗащищенноеСоединениеOpenSSL(). Без него попытка обратиться к сервису по https завершится ошибкой установки соединения.

1. 1
   Убедитесь, что WSDL открывается в браузере по URL сервиса
2. 2
   Добавьте WS-ссылку в конфигураторе или создайте WSОпределения программно
3. 3
   Создайте WSПрокси с корректными пространством имён, именем сервиса и точки подключения
4. 4
   Передайте логин и пароль пользователя базы-источника
5. 5
   Вызовите операцию внутри блока Попытка/Исключение
6. 6
   Проверьте результат: тип возвращаемого значения и содержимое ответа

Сравнение двух подходов

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

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

WS-ссылка в конфигурации

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

Программный WSОпределения

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

HTTPСоединение

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

Обработка ошибок и таймауты

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

По коду состояния HTTP можно быстро локализовать проблему: 401 — неверный логин или пароль, 403 — пользователь аутентифицирован, но не имеет прав на сервис, 404 — неверный URL или сервис не опубликован, 500 — исключение в коде сервиса на стороне источника. Для SOAP-вызовов ошибки сервиса приходят в виде исключения с текстом SOAP Fault.

Для длительных операций задайте таймаут в конструкторе HTTPСоединение (параметр в секундах). Без таймаута вызов может «повиснуть» надолго, блокируя сеанс пользователя или фоновое задание. Разумная практика — таймаут на уровне 30–120 секунд в зависимости от ожидаемого объёма данных и повторные попытки с паузой при временных сбоях.

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

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

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

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

Как проверить, что вызов работает

Начинайте проверку с самого простого: откройте URL WSDL или тестовый метод HTTP-сервиса в браузере с теми же учётными данными. Если браузер получает ответ, а код 1С — нет, проблема почти наверняка в параметрах соединения: адресе, порте, протоколе или прокси-сервере на машине, где работает сервер 1С.

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

Признак корректной работы: код состояния 200 (для HTTP), возвращаемое значение ожидаемого типа (для SOAP), данные в ответе соответствуют тестовому набору. Обязательно проверьте граничные случаи: пустой результат, большой объём данных, недоступность сервера — код должен вести себя предсказуемо в каждом из этих сценариев.

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

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

Доступность WSDL в браузере

Норма

Отображается XML-описание сервиса

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

Ошибка 404, 403 или таймаут

Код состояния HTTP-ответа

Норма

200 и тело с ожидаемыми данными

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

401/403 — проблема с правами, 500 — исключение в сервисе

Тип возвращаемого значения SOAP

Норма

Соответствует описанию операции в WSDL

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

Неопределено или ошибка преобразования XDTO

Записи в журнале регистрации

Норма

Отсутствуют ошибки вызова

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

Повторяющиеся ошибки соединения или аутентификации

Альтернативы и смежные сценарии

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

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

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

Чем отличается WSОпределения от WS-ссылки в конфигураторе?

WS-ссылка — объект конфигурации, описание WSDL загружается один раз при добавлении. WSОпределения создаётся программно и загружает WSDL при каждом вызове, что позволяет работать без изменения конфигурации, но добавляет сетевой запрос и замедляет выполнение.

Почему возникает ошибка «Ошибка при вызове конструктора (WSОпределения)»?

Чаще всего WSDL недоступен по указанному адресу: неверный URL, сервис не опубликован, требуется аутентификация, которую не передали, или сервер недоступен из сети, где работает сервер 1С. Проверьте тот же URL в браузере с теми же учётными данными.

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

Да, со стороны клиента веб-сервер не нужен: WSПрокси и HTTPСоединение работают из любой базы, включая файловую. Веб-сервер требуется только на стороне базы, которая публикует сервис.

Как передать в веб-сервис файл или большой объём данных?

Для SOAP — через тип base64Binary или хранилище значения, сериализованное в XDTO. Для HTTP-сервиса — телом POST-запроса методом УстановитьТелоИзДвоичныхДанных. Учитывайте ограничения веб-сервера на размер запроса: при больших объёмах надёжнее передавать данные частями.

Что делать, если вызов работает на тестовой базе, но падает на рабочей?

Сравните версии публикации: часто на рабочем сервере не обновлён файл default.vrd после изменения сервиса. Также проверьте, что на рабочем сервере 1С разрешены исходящие соединения и не блокирует ли трафик прокси или файервол.

Нужно ли закрывать HTTPСоединение после запроса?

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