← На главную

Часто при разработке интеграций с внешними системами, например, с IP-телефонией (АТС), возникает задача: как только на веб-сервер поступает входящий пакет (например, JSON с данными о звонке), нужно мгновенно открыть карточку клиента на экране конкретного пользователя в 1С. Проанализируем типичную ситуацию: разработчики принимают пакет на сервере, записывают его в регистр сведений, а на клиенте запускают ПодключитьОбработчикОжидания с интервалом в 1 секунду, который проверяет этот регистр.

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

Почему стандартный обработчик ожидания не подходит?

Механизм ПодключитьОбработчикОжидания работает по принципу постоянного опроса (short polling). Разберем причины, по которым этот подход ограничивает скорость и производительность:

1. Задержки соединения: Время уходит не только на ожидание самого интервала, но и на установку контекстного соединения с сервером 1С.
2. Нагрузка на СУБД: Если в колл-центре работает множество операторов, и каждый клиент 1С ежесекундно обращается к регистру, это создает лавинообразную нагрузку на базу данных сотнями пустых запросов.
3. Фризы интерфейса: Частые серверные вызовы блокируют клиентский интерфейс, вызывая визуальные подтормаживания.

Попытки уменьшить интервал (например, до 1/10 секунды) путем вызова вложенных обработчиков только усугубят проблему производительности. Рассмотрим более современные и быстрые варианты.

Способ 1: Использование Системы взаимодействия (СВ)

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

Посмотрим на алгоритм работы:

1. Сервер 1С (HTTP-сервис) получает JSON-пакет от телефонии.
2. Вместо записи в регистр, сервер генерирует невидимое сообщение Системы взаимодействия.
3. Сообщение адресно отправляется конкретному пользователю (идентификатору сеанса).
4. На стороне клиента событие перехватывается моментально, и код открывает нужное окно (документ или карточку клиента).

Способ 2: Менеджер уведомлений клиента (Платформа 8.3.26+)

Если разворачивать сервер Системы взаимодействия избыточно или невозможно, в новых версиях платформы появился специализированный объект МенеджерУведомленийКлиента. Он создан именно для push-оповещений с сервера на клиент без установки дополнительных компонент.

Разберем по шагам логику его использования:

1. На стороне клиента при старте системы регистрируем процедуру-обработчик через метод УведомленияКлиента.ПодключитьОбработчик(...).
2. При получении звонка веб-сервером вызывается серверный метод УведомленияКлиента.ОтправитьУведомление(...).
3. В параметрах метода указывается номер сеанса нужного оператора. Доставка происходит мгновенно, минуя базу данных.

Способ 3: Использование внешних очередей сообщений (Message Queue)

Если вы ограничены старыми версиями платформы, рассмотрим классический вариант избавления от опросов БД — использование внешней компоненты (ВК) и брокеров сообщений (MSMQ, RabbitMQ, различные реализации сокетов).

Как это работает:

1. Вы настраиваете сервер очередей (например, MSMQ, работающий в Windows "из коробки").
2. На клиентах устанавливается Внешняя Компонента (или используются COM-объекты), которая умеет подписываться на события очереди.
3. Веб-сервер при получении звонка кладет сообщение в очередь конкретного пользователя.
4. ВК на клиенте мгновенно генерирует внешнее событие в 1С (ОбработкаВнешнегоСобытия), и открывается форма. Скорость реакции возрастает в разы, а СУБД полностью освобождается от паразитной нагрузки.

Способ 4: Long Polling и локальные микросервисы

Если внешние компоненты использовать нельзя, проанализируем вариант с "длинными опросами" (Long Polling) или локальными утилитами.

Long Polling: Клиент 1С отправляет асинхронный HTTP-запрос к интеграционному веб-серверу. Сервер не отвечает сразу, а удерживает соединение открытым. Как только поступает входящий звонок, сервер мгновенно отдает ответ в это открытое соединение. 1С обрабатывает его, открывает окно и сразу же инициирует новый "длинный" запрос. Это радикально снижает количество запросов по сравнению с ежесекундным опросом.

Локальный микросервис: На рабочей станции оператора запускается легковесная фоновая программа, которая держит постоянное WebSocket-соединение с АТС. Клиент 1С общается не с центральным сервером, а с этим локальным микросервисом через быстрые локальные HTTP-вызовы (localhost). Центральный сервер 1С при этом вообще не участвует в маршрутизации событий о звонках.

Подведем итог: Для обеспечения реакции интерфейса "быстрее секунды", откажитесь от паттерна постоянного чтения базы данных через обработчик ожидания. Используйте штатную Систему взаимодействия или Менеджер уведомлений клиента для новых платформ, либо внедряйте событийную архитектуру через Message Queue или Long Polling для более старых систем.