WS-соединение в 1С: что это и как его использовать

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

Термин «WS» в 1С-среде иногда понимают двояко: как WebSocket и как сокращение от Web Service (веб-сервисы 1С, публикуемые на веб-сервере). Это разные механизмы. Веб-сервисы 1С работают по модели «запрос — ответ» поверх HTTP/SOAP, а WebSocket — это отдельный протокол для обмена в реальном времени. Ниже разберём оба значения и покажем, какие задачи каждый из них решает.

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

Что такое WebSocket и чем он отличается от HTTP

WebSocket — это протокол поверх TCP, который начинается с обычного HTTP-запроса с заголовком Upgrade, после чего соединение «переключается» в постоянный двусторонний канал. Дальше обе стороны могут отправлять сообщения в любой момент с минимальными накладными расходами — без повторной передачи заголовков на каждое сообщение.

HTTP работает иначе: каждый запрос — отдельное соединение (или переиспользуемое, но всё равно по модели «запрос — ответ»). Сервер не может сам инициировать отправку данных клиенту. Если 1С-сеансу нужно узнать о событии во внешней системе, при классическом HTTP ему приходится периодически опрашивать сервер.

HTTP-запросы против WebSocket

HTTP (веб-сервисы, HTTP-сервисы 1С)

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

WebSocket

Подходит для мгновенных уведомлений: чаты, онлайн-статусы заказов, мониторинг датчиков. Ограничение — в 1С нет штатной поддержки, нужна внешняя компонента или промежуточный сервер.

Long polling (длинные запросы)

Компромисс: клиент отправляет HTTP-запрос, сервер «держит» его до появления данных. Реализуется штатными средствами, но создаёт висящие соединения и нагрузку на сервер.

Два значения термина «WS» в 1С

Первое значение — WebSocket, описанный выше. Второе, более распространённое в документации и настройках, — веб-сервисы 1С. В конфигураторе в дереве метаданных есть ветка «Web-сервисы»: это объекты, которые публикуются на веб-сервере (IIS или Apache) и принимают SOAP-вызовы от внешних систем. Файл публикации обычно имеет расширение .1cws, а точка подключения выглядит как http://сервер/база/ws/ИмяСервиса.

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

Какие задачи решает WS-соединение на практике

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

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

Маршрут решения

Как выбрать механизм обмена

Внешняя система сама обращается к 1С по событию или расписаниюОпубликуйте HTTP-сервис или веб-сервис 1С — штатное и поддерживаемое решение

1С должна мгновенно узнавать о событиях во внешней системеИспользуйте промежуточный брокер (очередь сообщений) с регламентным заданием-получателем или внешнюю компоненту с WebSocket

Нужны уведомления пользователей внутри 1СРассмотрите штатную систему взаимодействия 1С — она уже реализует обмен сообщениями между сеансами

Обмен редкий и некритичный ко времениДостаточно файлового обмена или периодических HTTP-запросов регламентным заданием

Способы реализовать обмен в реальном времени в 1С

Промежуточный брокер сообщений

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

Внешняя компонента с WebSocket

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

Система взаимодействия 1С

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

Прежде чем внедрять WebSocket-компоненту, замерьте реальную требуемую задержку. На практике регламентное задание с интервалом 10–30 секунд закрывает большинство бизнес-сценариев «в реальном времени» и обходится без сторонних зависимостей.

Настройка веб-сервиса 1С: базовый порядок

Если под WS понимается классический веб-сервис, настройка выглядит так. В конфигураторе создаётся объект «Web-сервис» с операциями и параметрами, в модуле описывается код обработчиков. Затем база публикуется на веб-сервере (Apache или IIS) с отмеченным флагом публикации веб-сервисов.

После публикации проверьте доступность WSDL-описания: откройте в браузере адрес вида http://сервер/база/ws/ИмяСервиса?wsdl. Если отдаётся XML-описание — сервис опубликован. Ошибка 404 означает проблему с публикацией, 401/403 — с аутентификацией, 500 — ошибку в коде операции.

1. 1
   Создайте объект Web-сервис в конфигураторе, опишите операции и их параметры
2. 2
   Напишите код операций в модуле веб-сервиса, обновите конфигурацию базы данных
3. 3
   Выполните публикацию на веб-сервере с включённой опцией «Публиковать Web-сервисы»
4. 4
   Откройте URL сервиса с ?wsdl в браузере и убедитесь, что возвращается XML-описание
5. 5
   Вызовите операцию тестовым клиентом (например, SoapUI или из другой базы 1С через WS-ссылку) и проверьте ответ

Безопасность и типичные риски

Любой опубликованный сервис — это точка входа в базу. Минимальный набор мер: HTTPS вместо HTTP, отдельный пользователь с минимально необходимыми правами, отсутствие анонимного доступа, ограничение по IP на уровне веб-сервера, если системы находятся в одной сети. Для WebSocket-подключений из внешних компонент действуют те же правила: шифрованный канал (wss://), проверка токена, защита от повторного подключения с чужими учётными данными.

Отдельный риск — висящие соединения. Long polling и WebSocket держат потоки на сервере; при росте числа клиентов можно упереться в лимиты веб-сервера и рабочих процессов 1С. Перед промышленным запуском оцените пиковое число одновременных подключений и проведите нагрузочную проверку.

Частые ошибки при работе с WS-соединениями

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

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

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

Доступность сервиса

Норма

URL сервиса возвращает WSDL или корректный ответ на тестовый запрос

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

Ошибки 404, 500, таймаут — проверяйте публикацию, права и журнал регистрации

Скорость доставки событий

Норма

Событие из внешней системы появляется в 1С в пределах согласованной задержки

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

События теряются или приходят пачками с большим опозданием

Нагрузка на сервер

Норма

Число висящих соединений и время отклика стабильны при росте клиентов

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

Растёт число потоков, рабочие процессы 1С перегружены

Устойчивость к обрыву

Норма

После перезапуска сервера соединение восстанавливается автоматически

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

Требуется ручной перезапуск клиента или задания

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

Есть ли в 1С встроенный WebSocket-клиент?

Нет, во встроенном языке платформы нет штатных объектов для работы с WebSocket. Доступные варианты: внешние компоненты по технологии Native API, промежуточные сервисы (брокеры сообщений) с опросом из 1С или long polling через HTTP-сервисы. Для внутренних уведомлений между сеансами подходит штатная система взаимодействия.

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

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

Как организовать мгновенные уведомления из 1С на сайт?

Из 1С при событии отправляйте HTTP-запрос на сторону сайта (вебхук) — это проще и надёжнее, чем держать постоянное соединение из базы. Если событий много, ставьте между 1С и сайтом очередь сообщений, чтобы не потерять данные при недоступности сайта.

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

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

Что делать, если WebSocket-соединение через компоненту постоянно рвётся?

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

Можно ли обойтись без WebSocket для онлайн-статусов заказов?

Да. Клиентское приложение может опрашивать HTTP-сервис 1С каждые 10–30 секунд либо получать push-уведомления через внешний сервис доставки. Для большинства сценариев статусов заказов такой задержки достаточно, а решение получается проще и устойчивее.