1С веб-сервис: как обращаться и вызывать его методы

Веб-сервис в 1С — это механизм, который позволяет одной информационной базе отдавать данные и выполнять операции по запросу других систем через протокол SOAP. Обращаться к такому сервису можно двумя способами: из другой базы 1С через WS-ссылку либо из внешнего приложения (например, на C#, Python или PHP), формируя SOAP-запросы напрямую. В обоих случаях предварительно сервис нужно опубликовать на веб-сервере.

Типичный сценарий выглядит так: разработчик создаёт объект «Web-сервис» в конфигураторе, описывает операции и их параметры, публикует базу на IIS или Apache, после чего потребители получают WSDL-описание по URL и вызывают нужные методы. Ошибки чаще всего возникают не в коде, а на этапе публикации и настройки прав доступа.

Ниже разобран полный цикл: от публикации сервиса до вызова его методов и диагностики проблем. Материал ориентирован на платформу 1С:Предприятие 8.3, но общие принципы справедливы и для более ранних версий.

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

Обращаться к веб-сервису можно только после его публикации. В конфигураторе откройте «Администрирование → Публикация на веб-сервере», укажите имя публикации (латиницей, без пробелов), каталог для файлов публикации и обязательно отметьте флаг «Публиковать Web-сервисы». На вкладке «Web-сервисы» проверьте, что нужный сервис отмечен.

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

Проверка публикации выполняется простым запросом из браузера: откройте адрес вида http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Если в ответ приходит XML-описание сервиса (WSDL), публикация выполнена корректно. Если браузер запрашивает логин и пароль — это нормально: введите учётные данные пользователя информационной базы.

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

Как проверить публикацию

Запрос WSDL в браузере

Норма

Возвращается XML с описанием сервиса

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

Ошибка 404 — сервис не опубликован или неверный URL

Аутентификация

Норма

После ввода логина/пароля WSDL открывается

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

Ошибка 401/403 — нет прав у пользователя или неверные учётные данные

Модуль расширения веб-сервера

Норма

Запросы обрабатываются

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

Ошибка 500 — проверьте установку компоненты и разрядность платформы

Получение WSDL-описания сервиса

WSDL (Web Services Description Language) — это XML-документ, который описывает операции сервиса, их параметры и типы данных. Именно по WSDL потребитель понимает, как обращаться к сервису: какие методы существуют, какие параметры принимает каждый из них и что возвращается в ответ.

Адрес WSDL формируется по шаблону: http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Имя сервиса должно точно совпадать с именем объекта «Web-сервис» в конфигураторе, включая регистр символов. Также работает вариант без суффикса ?wsdl — тот же адрес отдаёт описание при запросе с соответствующим заголовком.

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

Обращение к веб-сервису из другой базы 1С

Основной способ вызова веб-сервиса из 1С — WS-ссылка. Это объект конфигурации, который хранит адрес WSDL и автоматически создаёт прокси для вызова операций. Добавьте WS-ссылку через ветку «Общие → WS-ссылки» в конфигураторе, указав URL WSDL и, при необходимости, логин и пароль.

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

Определение = WSСсылки.ОбменДанными.СоздатьWSПрокси(
"http://example.org", "DataExchange", "DataExchangeSoap");
Определение.Пользователь = "ws_user";
Определение.Пароль = "secret";
Результат = Определение.GetCounterparty(ИНН);

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

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

Обращение к веб-сервису из внешних приложений

Из приложений на других языках к веб-сервису 1С обращаются как к обычному SOAP-сервису. В C# достаточно добавить Service Reference по URL WSDL — Visual Studio сгенерирует клиентский класс. В Python используют библиотеку zeep, в PHP — встроенный класс SoapClient.

Аутентификация в подавляющем большинстве случаев — базовая (Basic): логин и пароль пользователя информационной базы передаются в HTTP-заголовке Authorization. Пример на Python:

from zeep import Client
from zeep.transports import Transport
from requests import Session
from requests.auth import HTTPBasicAuth

session = Session()
session.auth = HTTPBasicAuth("ws_user", "secret")
client = Client("http://server/base/ws/DataExchange?wsdl",
transport=Transport(session=session))
result = client.service.GetCounterparty("7707083893")

Учитывайте ограничения: 1С по умолчанию использует кодировку UTF-8 и стиль документарных SOAP-сообщений. Если клиент формирует запросы вручную, убедитесь, что пространства имён в XML совпадают с указанными в WSDL, иначе сервер вернёт ошибку разбора.

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

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

Код веб-сервиса выполняется от имени пользователя, под которым прошла аутентификация. Поэтому для интеграций создавайте отдельного технического пользователя с минимально необходимыми правами: доступ только к тем объектам, которые реально читает или изменяет сервис. Никогда не публикуйте сервис под административной учётной записью.

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

Типичные ошибки при обращении к веб-сервису

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

Если сервер возвращает SOAP Fault, читайте текст ошибки внимательно: 1С обычно возвращает содержательное описание, включая имя операции и причину отказа. Ошибки вида «Операция не найдена» почти всегда означают, что клиент использует устаревшее описание сервиса после изменения конфигурации.

Проверка результата и отладка

Для отладки вызовов полезны три инструмента: журнал регистрации информационной базы (фиксирует ошибки выполнения кода сервиса), логи веб-сервера (показывают HTTP-ошибки до входа в 1С) и SOAP-клиенты с отображением сырого запроса и ответа, например SoapUI.

Признак корректной работы — метод возвращает ожидаемый тип данных, а изменения (если операция их предполагает) видны в базе. Если ответ приходит пустым, проверьте, не отлавливает ли код сервиса исключения молча: конструкция «Попытка...Исключение» без записи в журнал — частая причина «тихих» сбоев.

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

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

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

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

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

Почему WS-ссылка выдаёт ошибку после обновления конфигурации поставщика?

При изменении состава операций или типов параметров WSDL меняется, а кэшированное описание в WS-ссылке устаревает. Обновите ссылку в конфигураторе или пересоздайте динамическое определение.

Как передать в веб-сервис сложный объект, например документ?

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

Работает ли веб-сервис в файловой базе без сервера 1С?

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

Как ограничить время выполнения операции веб-сервиса?

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