Что такое WS-соединение в 1С и как его настроить

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

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

Материал разбирает оба варианта WS-соединений: как они устроены, чем отличаются, как настроить подключение из конфигуратора и кода, какие ошибки встречаются чаще всего и как проверить, что соединение действительно работает.

Что скрывается за аббревиатурой WS в контексте 1С

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

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

Когда пользователь или разработчик говорит «настроить WS-соединение», в большинстве случаев речь идёт именно о SOAP-варианте: создать WS-ссылку в дереве конфигурации или сформировать прокси программно и вызвать нужную операцию. Дальнейшие разделы рассматривают оба сценария.

Как работает SOAP-подключение через WS-прокси

Механика вызова внешнего веб-сервиса из 1С выглядит так. Платформа обращается по указанному URL и скачивает WSDL-описание. На его основе создаётся объект прокси, в котором доступны операции сервиса как методы, а типы данных сервиса преобразуются в объекты XDTO. Далее код вызывает нужную операцию, передаёт параметры, платформа формирует SOAP-конверт, отправляет его по HTTP(S) и разбирает ответ.

Есть два способа создать прокси. Первый — статический, через объект конфигурации «WS-ссылка»: WSDL импортируется в конфигурацию один раз, и в коде используется короткое обращение по имени ссылки. Второй — динамический, когда WSDL загружается в момент выполнения через объект WSОпределения (WSDefinitions). Динамический способ гибче, но каждый вызов тратит время на загрузку описания, поэтому при частых обращениях определение кэшируют.

Определение = Новый WSОпределения("https://example.com/service?wsdl", "user", "password");
Прокси = Новый WSПрокси(Определение, "http://example.com/", "MyService", "MyServiceSoap");
Результат = Прокси.GetData(Параметр);

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

WebSocket-соединения: когда нужен постоянный канал

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

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

Настройка WS-ссылки и подключения: порядок действий

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

Для динамического подключения конфигуратор не нужен: достаточно кода с созданием WSОпределения и WSПрокси. Этот способ удобен, когда адрес сервиса хранится в настройках базы и может меняться без обновления конфигурации. Учитывайте, что создание определения — сетевая операция, поэтому задавайте таймаут и обрабатывайте исключения, иначе при недоступном сервисе сеанс пользователя будет «висеть».

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

Если сервис работает по HTTPS, сервер 1С должен доверять сертификату. Проблемы с самоподписанными сертификатами и устаревшими цепочками — одна из самых частых причин отказа соединения при внешне корректных настройках. Проверить это можно, открыв адрес сервиса в браузере на сервере и посмотрев, нет ли предупреждения о сертификате.

Типичные ошибки и как их диагностировать

Наиболее частая ошибка — «Ошибка при вызове конструктора WSОпределения» или «Ошибка загрузки WSDL». Она означает, что описание не скачалось: неверный адрес, закрыт порт, прокси-сервер не пропускает запрос или требуется аутентификация, которую не передали. Диагностика начинается с проверки доступности URL именно с той машины и под той учётной записью, где выполняется код.

Вторая группа ошибок — «Ошибка вызова операции сервиса» с SOAP-фолтом внутри. Здесь соединение установлено, но сервис отверг запрос: не хватает прав, неверный формат параметра, изменилась версия API. Текст fault-строки обычно содержит причину, поэтому его обязательно нужно выводить в журнал, а не проглатывать в пустом обработчике исключения.

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

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

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

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

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

Как проверить, что соединение работает

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

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

Частые вопросы о WS-соединениях в 1С