WebSocket'ы – это не больно

Часто для того, чтобы начать применять новую технологию на практике, недостаточно одной статьи – приходится самостоятельно изучать множество дополнительных материалов, потому что «не зная букв, читать сложно». И моя задача сейчас – сэкономить вам время и рассказать о веб-сокетах так, чтобы вы сразу смогли применять эти знания в своих проектах.

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

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

С чего начнем?

Для начала предлагаю вам обратить внимание на две мои статьи, опубликованные на Инфостарте:

• Поинтегрируем: WebSocket’ы в платформе 1С. Часть 1
  //infostart.ru/1c/articles/2280032/. Статья о том, как развернуть WebSocket-сервер на Node.js, создать WebSocket-клиент на 1С и получить простую систему обмена сообщениями. В этом случае все сообщения сохраняются в оперативной памяти сервера и передаются всем клиентам, включая тех, кто подключается позднее.

• Поинтегрируем: WebSocket’ы в платформе 1С. Часть 2
  //infostart.ru/1c/articles/2293957/. Во второй статье я развил первый пример и показал, как отправлять сообщения не всем подключенным пользователям, а конкретной сессии. Фактически это уже основа полноценного чата, опираясь на который можно создать собственный аналог Telegram или ВКонтакте.

Это то, с чего можно начать.

Ограничение HTTP-сервисов – однонаправленная связь

Прежде чем говорить о WebSocket, давайте вспомним, как задача обмена данными между клиентом и сервером решалась в 1С раньше.

Раньше для такого обмена использовались HTTP-сервисы. Их основной недостаток – однонаправленная связь.

Чтобы узнавать на клиенте об изменениях на сервере, приходилось отправлять запрос и только по ответу понимать, что что-то изменилось. Для обменов в реальном времени это неудобно.

Люди стали думать – как сделать так, чтобы получать информацию в онлайне. И первое, что пришло в голову – это «короткие опросы» или Short Polling, когда HTTP-запрос отправляется на сервер в цикле с некоторой периодичностью.

Вы мучаете сервер и все время спрашиваете: «Есть ли для меня что-нибудь?», «А сейчас?», «А теперь?».

В какой-то момент он вам отвечает: «Да, пожалуйста, данные есть», но в результате получается DDoS-атака своими руками.

Тогда люди стали думать, что еще можно придумать. И придумали «длинный опрос» или Long Polling.

Суть этого метода в том, что запрос отправляется на сервер, но сам сервер не отвечает мгновенно, а вместо этого держит соединение открытым и ждет новых данных в течение определенного промежутка времени – например, 30 секунд. Если изменения появляются, сервер отдает их на клиент – тот забирает результат и сразу же отправляет сообщение снова.

Это похоже на рыбалку – вы забрасываете удочку, ждете, и если поплавок дергается, значит, рыба клюнула: вытаскиваете улов и снова забрасываете. А если долгое время ничего не происходит, значит, наживку съели, ее нужно обновить и опять закинуть.

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

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

• Использование WebSocket часто блокируют безопасники, объясняя это ограничениями корпоративной инфраструктуры и внутренними требованиями организации. В таких ситуациях Long Polling до сих пор must-have.

• На поддержание сессий требуется выделение ресурсов. Для работы WebSocket-сервера необходим хороший канал связи и отдельная инфраструктура – виртуальные машины или физические серверы, способные надежно сохранять информацию об активных сеансах. Такие возможности доступны далеко не всем.

Двунаправленная связь. Протокол WebSocket и его сфера применения

А теперь все-таки поговорим про вебсокеты.

Официальная спецификация протокола WebSocket (RFC 6455) опубликована в декабре 2011 года, а возможность работать с WebSocket средствами платформы 1С у нас появилась только в 2025 году, в платформе 8.3.27. Представляете, сколько времени потребовалось, чтобы эта технология добралась до мира 1С?

Главное отличие WebSocket от традиционного HTTP-запроса – это двунаправленная связь в рамках одного постоянного соединения.

Работает это следующим образом:

• Клиент отправляет на сервер небольшой HTTP-запрос со специальными заголовками – этот процесс называется рукопожатием или Handshake.

• В результате рукопожатия сервер переключается на протокол WebSocket и устанавливает постоянное WebSocket-соединение.

• После этого клиент и сервер могут использовать это соединение независимо друг от друга – отправлять по нему сообщения в любой момент времени.

Где обмен по протоколу WebSocket наиболее востребован?

• Первое, что приходит в голову – это биржевые приложения и торговые площадки. На изменения стоимости акций нужно оперативно реагировать, а реализовать это нормально через обычные HTTP-запросы не получится.

• Второй пример – чаты и мессенджеры. Я уже приводил в пример свои статьи, где на технологии WebSocket был реализован чат. Тоже можно использовать.

• И третий пример – интеграции между системами. Чуть позже мы рассмотрим возможные сценарии подробнее.

Варианты работы с WebSocket до 8.3.27

До появления встроенной поддержки WebSocket в платформе 8.3.27 разработчикам приходилось искать обходные решения.

• Например, использовать внешние компоненты – одну из таких компонент можно найти на Инфостарте.

• Второй вариант – использовать поле HTML-документа. Многие используют его в 1С не только по прямому назначению, но и делают на его основе красивые дизайны, приспосабливают для обработки событий, и, в том числе, реализуют работу с WebSocket.

• Третий вариант – реализовывать собственные «велосипеды» для обмена данными. Например, в платформе 8.3.26 появилась возможность оповещать клиент с сервера. А еще раньше – с платформы 8.3.20 – такую возможность можно было реализовать при помощи Системы взаимодействия. Это позволяло разработчикам на основе тех же самых HTTP-сервисов строить механизмы, частично напоминающие взаимодействие через WebSocket.

Новый механизм и его проблемы

Теперь ситуация изменилась, и в платформе 8.3.27 появились веб-сокеты.

Правда поначалу в этом механизме было очень много ошибок. И хотя сейчас (прим. ред. доклад от 11 октября 2025 года) большинство из них уже исправлены, на багборде до сих пор появляются новые записи об ошибках веб-сокетов.

В частности, до сих пор в платформе 8.3.27 есть ошибки в документации к обработчику ПередПодключением().

• В описании синтаксиса указан параметр «Клиент» – ПередПодключением(<Клиент>).

• А в примере кода почему-то используется параметр «Соединение», хотя на момент выполнения обработчика «ПередПодключением» процедура рукопожатия еще не завершена, и полноценного WebSocket-соединения там нет. Очевидно, что этот код работать не будет.

Кроме этого, мне удалось обнаружить еще одну интересную ошибку.

Многие знают, что в платформе 8.3.27 появилась встроенная обработка «Управление WebSocket-клиентами», и возможность объявлять WebSocket-клиенты предопределенными (устанавливать для них флажок «Предопределенный»).

Очевидно, что удалять предопределенные объекты нельзя, а значит, кнопка «Удалить» для предопределенного WebSocket-клиента в обработке будет не активна. Но:

• Нам доступно нажатие «Удалить» в контекстном меню.

• Либо мы можем выделить предопределенный WebSocketКлиент и нажать на клавиатуре клавишу Del.

В результате возникает замечательная ошибка, предлагающая перезапустить 1С.

Так что проблемы, конечно, есть. И в наших силах это все находить и отправлять в фирму «1С», чтобы когда-нибудь, возможно, увидеть идеальную работу этого механизма.

Механизм WebSocket – что нового в платформе 8.3.27

А теперь давайте последовательно разберем все возможности по работе с веб-сокетами, которые у нас появились в платформе 8.3.27.

Прежде всего, появилась специальная встроенная обработка, которая может управлять WebSocket-клиентами.

Появилась отладка для WebSocket по TCP.

Также расширились возможности отладки по HTTP – появилась опция отладки для WebSocket.

Объект WebSocketКлиент можно добавлять в дерево метаданных непосредственно в конфигурацию и в расширение.

Добавленный объект WebSocketКлиент имеет перечисленные на слайде свойства, большинство из которых рассчитаны на авторизацию. Сейчас мы поговорим о них подробнее.

Свойство «Предопределенный». При выставлении для WebSocket-клиента флага «Предопределенный» его нельзя удалить программно. По крайней мере, не нужно пытаться это делать, потому что такая попытка приводит к ошибке – вы это уже видели.

Обратите внимание, что созданные в конфигурации и расширении предопределенные WebSocket-клиенты сразу сохраняются в таблице websocketclients базы данных – для того, чтобы их отличить от программно созданных экземпляров, используется поле _predefined.

Еще у WebSocketКлиента появилось свойство «Подключать автоматически».

Когда этот флаг установлен, сразу же при запуске приложения будет происходить попытка подключения к WebSocket-серверу:

• Если соединение установить невозможно – например, у вас нет интернета или не работает WebSocket-сервер – статус будет «Открывается».

• Как только успешное подключение произойдет, появится статус «Открыто».

В модуле WebSocket-клиента появилась возможность добавлять обработчики. Их всего пять, и мы сейчас их рассмотрим подробнее.

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

В обработчике «ПередПодключением» мы можем переопределять параметры подключения – устанавливать заголовки для авторизации на сервере и дополнительные параметры для отладки.

Если у нас проходит рукопожатие, то срабатывает следующий обработчик – «ПриОткрытииСоединения».

После открытия соединения начинает работать обработчик «ПриПолученииСообщения». Это самый главный для нас обработчик – именно здесь мы получаем сообщения от WebSocket-сервера и выполняем с ними необходимые действия. Сообщения могут пересылаться в формате JSON или двоичными данными – в зависимости от того, какая задача решается.

Следующий обработчик – «ПриОшибке». В нем мы можем получить информацию об ошибке в виде ее кода. Значение кода и его расшифровка зависят от того, какая ошибка возникла, и какой сервер используется.

С возможными кодами ошибок и их описанием можно ознакомиться в соответствующем разделе спецификации WebSocket.

И последний обработчик WebSocket-клиента, который тоже возвращает коды – «ПриЗакрытииСоединения». Когда соединение закрывается, мы можем получить код закрытия, по которому можно определить причину завершения работы. Например, код 1000 означает, что соединение закрылось штатно, все отработало как надо. Другие коды могут означать, что соединение завершилось из-за определенных проблем – несколько примеров я привел на слайде. Все коды закрытия описаны в том же разделе спецификации.

Еще одно свойство объекта WebSocketКлиент – «Заголовки».

У нас появилась возможность добавлять заголовки для соединений прямо в конфигураторе. Было бы неплохо увидеть что-то подобное и у HTTP-сервисов.

Кроме этого, появилась возможность переопределять те же самые заголовки программно – например, через встроенную обработку «Управление WebSocket-клиентом».

И еще у нас появилась возможность переопределять заголовки в обработчике «ПередПодключением».

На слайде как раз показано, что я переопределяю тот же самый заголовок программно, и потом в обработчике «ПередПодключением».

Здесь важно понимать, какие настройки будут применяться, если один и тот же заголовок указан в нескольких местах.

• Самый высокий приоритет – у обработчика «ПередПодключением». Если заголовок переопределен здесь, будет использоваться именно это значение.

• Второй по приоритету идет программная настройка – например, можно переопределить заголовок через встроенную обработку «Управление WebSocket-клиентом».

• И последний приоритет – тот заголовок, который определен в конфигураторе.

Практическая часть. Три варианта работы с WebSocket-соединениями

Согласно ИТС, создавать WebSocket-соединения в 1С можно тремя способами:

• Программно на стороне клиентского приложения.

• Программно на стороне кластера серверов,

• Через работу с WebSocket-клиентами, созданными непосредственно в конфигурации или расширении – соединения от таких WebSocket-клиентов тоже будут работать на стороне кластера серверов.

Все эти три варианта мы сейчас рассмотрим на практических примерах.

Для доклада я специально подготовил конфигурацию, WebSocket-сервер и несколько обработок, которые выложил на GitHub.

Поэтому все примеры, которые мы будем разбирать дальше, можно скачать и самостоятельно проверить у себя.

Пример 1. WebSocket-клиент предопределенный

Начнем с самого простого варианта – мы создадим WebSocket-клиент, не написав ни единой строчки кода.

Для этого в конфигураторе добавляем новый WebSocket клиент:

• устанавливаем ему два флага – «Предопределенный» и «Подключать автоматически»;

• в поле «URL сервера» указываем адрес в сети, где у нас развернут WebSocket-сервер;

• указываем пользователя и пароль – в моем примере будет проверяться пароль «123».

Что будет происходить?

При запуске 1С платформа попытается установить соединение автоматически.

Если мы посмотрим на параметры соединения в отладчике, то увидим, что:

• Логин и пароль лежат в открытом виде.

• При этом самих заголовков в настройках клиента мы не увидим, потому что заголовок «Authorization» платформа формирует самостоятельно, используя Basic-авторизацию.

• Хотя на стороне WebSocket-сервера я заголовок «Authorization» отлавливал – он там действительно приходит.

•  

Если авторизация прошла успешно, мой тестовый WebSocket-сервер, который я приложил в репозитории, отправит сообщение: {"type": "auth_success"}

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

В результате пользователь с базовыми правами сможет программно прочитать логин и пароль, указанные в настройках WebSocket-клиента, а потом продублировать себе и как бы работать под вами.

В связи с этим я не рекомендую использовать этот типовой механизм, поскольку он подразумевает хранение логина и пароля непосредственно в конфигураторе и расширении.

Пример 2. WebSocket-клиент с программной авторизацией

Второй пример – поинтереснее. Для него я подготовил обработку «wsАвторизация», которая входит в состав конфигурации, выложенной в репозитории с примерами.

В рамках второго примера мы:

• Создадим WebSocket-клиент в расширении.

• Настроим авторизацию через заголовки.

• Настроим логирование в журнал регистрации.

• И отправим сообщение в двух форматах – текстом и через двоичные данные.

Смотрите: мы также добавляем WebSocket-клиент, но уже в расширении, и указываем только URL сервера, пользователя и пароль не указываем.

Заголовок мы будем генерировать программно.

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

Перейдем непосредственно к самой обработке «wsАвторизация».

Ее код я разбил на три блока, чтобы его было удобнее показывать на слайдах.

В первом блоке мы ищем объект метаданных WebSocket-клиента по наименованию.

Потом попытаемся найти предопределенный WebSocket-клиент – этот код у нас вернет Неопределено, потому что WebSocket-клиент у нас непредопределенный. Это значит, что новый WebSocket-клиент мы будем создавать программно, на основе существующего объекта метаданных.

Здесь очень важно: для каждого создаваемого WebSocket-клиента необходимо задать уникальный ключ соединения. В моем примере все просто – создаем новый уникальный идентификатор и преобразуем его в строку.

Далее, используя объект метаданных и полученный ключ, создаем WebSocket-клиент и записываем его.

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

Во втором блоке WebSocket-клиент у нас уже существует, но соединение с сервером еще не установлено.

Поэтому сначала получаем текущее состояние соединения. Поскольку мы еще не подключались, оно будет закрыто.

Теперь подготовим заголовок авторизации: для этого берем логин и пароль, кодируем их в Base64, добавляем префикс Basic и формируем заголовок Authorization.

После этого передаем заголовок WebSocket-клиенту и вызываем метод подключения.

В этот момент начинается установка соединения с сервером.

Но теперь нам понадобится еще одна вещь – ключ клиента. Именно его мы будем использовать дальше для отправки сообщений.

Чтобы его получить, вызываем:

Соединение = ВебсокетКлиент.ПолучитьТекущееСоединение();
КлючКлиента = Соединение.Ключ;

Именно этот ключ мы будем использовать далее.

Обратите внимание, что в обработке есть возможность выставить галочку «Удалить», чтобы сразу последовательно выполнить весь цикл: создать клиента, подключиться, завершить соединение и удалить клиента. Но сейчас мы эту галочку выставлять не будем, потому что соединение нам понадобится для следующих примеров.

Нажмем в обработке кнопку «Авторизоваться» и посмотрим, какие логи появились в журнале регистрации.

• Сначала вызывается обработчик «ПередПодключением».

• Далее у нас произошло рукопожатие, выполняется авторизация и вызывается обработчик «ПриОткрытииСоединения».

• И после успешного подключения сервер присылает сообщение, которое мы тоже увидим в журнале.

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

Теперь попробуем отправить сообщение через WebSocket.

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

С двоичными данными все практически так же.

Сначала преобразуем сообщение в двоичные данные, а затем передаем их через тот же метод ОтправитьСообщение().

Посмотрим логи в журнале регистрации.

Мой тестовый WebSocket сервер, который приложен к материалам, работает по принципу эха: получает сообщение и отправляет ответ с информацией о том, что именно было получено.

Поэтому после отправки мы увидим ответы и на текстовое сообщение, и на двоичные данные.

Пример 3. Программное создание соединений на клиенте и сервере

Теперь перейдем к последнему примеру.

До этого мы работали с WebSocket-клиентами, созданными в конфигураторе и расширении.

А теперь попробуем создавать соединения полностью программно. Причем рассмотрим сразу два варианта – на стороне клиента и на стороне сервера. Для этого я подготовил в конфигурации два общих модуля – клиентский и серверный.

• Модуль, который работает на клиенте, будет вызывать методы серверного модуля.

• А в серверном модуле у нас будут происходить все основные действия по отражению событий в журнале регистрации.

Обратите внимание, в клиентском модуле мы не можем передать соединение с клиента на сервер, поэтому вместо него я передаю заглушку – строку «Клиент».

А код в модуле на сервере отвечает за запись в журнал регистрации и очень похож на то, что было описано в предыдущих примерах.

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

Для иллюстрации этого примера я подготовил отдельную обработку «wsДинамический», которая также входит в состав выложенной конфигурации.

Обратите внимание, в ней есть флажок «Клиент». Если он установлен, WebSocket-соединение создается на клиенте. Если снят – на сервере.

От этого же флажка зависит, где будет выполняться отправка сообщений.

На слайде показан код, который будет выполняться при нажатии кнопки «Авторизоваться».

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

Далее описываем обработчики сокета. Обратите внимание, что для обработчиков в качестве модуля мы вызываем именно WebSocketКлиент – то есть клиентский.

Дальше перечисляем все наши обработчики – так, как они у нас названы.

Программно задаем параметры – логин и пароль.

И при открытии сессии указываем ключ, адрес сервера, обработчики и параметры.

После чего происходит создание соединения.

На сервере – все то же самое, только мы префикс добавляем «Сервер» и используем серверный модуль – WebSocketСервер.

Особенности создания соединений

Далее – самое интересное.

Допустим, мы создали два соединения: одно на клиенте, другое на сервере.

Если на клиенте запросить список всех доступных соединений, мы увидим только клиентское. Серверное в этом списке не появится.

И наоборот: при запросе на сервере мы получим серверные соединения, но не увидим клиентские.

Это важно учитывать при разработке.

Есть и другие особенности:

• Если мы создали соединение на сервере и вдруг решили обновить конфигурацию, соединение не отпадает – я проверял состояние соединения в момент обновления конфигурации.

• Если мы создали соединение на сервере, то другие пользователи могут с ним работать, обращаясь к нему на сервере по ключу.

• Если мы создали соединение на клиенте, то оно доступно только текущему пользователю в текущем сеансе – другие пользователи с ним не могут работать.

• Если пользователь завершает свой сеанс, то все соединения, которые были запущены под ним на клиенте, завершаются не с ошибкой, а с кодом 1000.

Как посмотреть активные WebSocket-соединения

Мы научились создавать соединения, отправлять сообщения, получать ответы. Но как узнать, какие соединения сейчас вообще запущены?

Я поискал такой инструмент среди стандартных и ничего подходящего не нашел. Поэтому пришлось написать собственную обработку – «СоединенияВебсокетов». Ее вы тоже можете найти в составе конфигурации, выложенной на GitHub.

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

Причем, пока я ее делал, обнаружился еще один интересный момент.

Обратите внимание на картинку снизу на слайде – здесь показаны серверное и клиентское соединение, ключи у которых абсолютно одинаковые.

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

Как тестировать WebSocket?

Ну и последний вопрос – как все это тестировать?

На самом деле здесь можно использовать практически те же подходы, что и при тестировании HTTP-сервисов.

Например, создать тестовый или мок-сервер, который будет возвращать заранее подготовленные данные. Именно такой сервер я и использовал для своих примеров.

А если вам нужно проверить работу WebSocket-клиента, можно воспользоваться готовыми инструментами.

Например, Postman.

Или Insomnia. Они позволяют устанавливать WebSocket-соединения, отправлять сообщения и смотреть ответы сервера.

Выше показаны примеры подключения к веб-сокетам через оба инструмента.

Где еще можно использовать веб-сокеты?

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

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

Многопользовательские онлайн-игры. С веб-сокетами можно синхронизировать действия игроков в реальном времени.

Статусы и уведомления. Изменился статус заказа, появилась новая задача, завершилась обработка документа – отправили сообщение заинтересованным пользователям или системам. Это удобно и для интеграции с корпоративными мессенджерами.

Блокировка документов в разных базах 1С. Например, у нас есть несколько баз для разных организаций. В одной базе – «Заказ клиента», в другой – связанный с ним «Заказ поставщику». Когда пользователь открывает документ в одной базе, нужно заблокировать его редактирование в другой.

Через веб-сокеты можно передавать такие уведомления между базами. Но здесь есть нюанс: если WebSocket-сервер недоступен, сообщение о блокировке не дойдёт. Поэтому необходимо предусматреть дополнительные механизмы контроля.

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

Интеграция с искусственным интеллектом. Например, медицинская система передает снимок после эндоскопии в модель распознавания, а после через веб-сокет получает результат обработки.

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

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

Инвентаризация на ТСД. Несколько сотрудников одновременно сканируют товары, и каждому нужно видеть, какие позиции уже обработаны. Один сотрудник отсканировал товар – сервер отправил сообщение остальным терминалам, и информация обновилась у всех. Причём сами терминалы необязательно должны работать на платформе 1С. Например, обновление информации в реальном времени через WebSocket-протокол уже реализовано в мобильном клиенте SimpleUI – при работе на мобильных устройствах на складах или производственных рабочих местах.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.