Почему тормозит клиент 1С при интеграции с телефонией и как это исправить

← На главную

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

Почему возникают тормоза: технический анализ

Выясним основную причину «вязкости» интерфейса. Платформа 1С:Предприятие в части клиентского приложения работает в преимущественно однопоточном режиме для графического интерфейса (UI). Когда срабатывает ПодключитьОбработчикОжидания, выполнение любого пользовательского действия (ввод текста, прокрутка списка) приостанавливается. Рассмотрим подробнее факторы влияния:

Блокировка основного потока: Даже если запрос к серверу телефонии занимает 100–200 мс, при частоте опроса раз в 1–2 секунды пользователь постоянно попадает в «микро-паузы». Это создает эффект медленного отклика всей системы.
Сетевые задержки и VPN: Работа через VPN накладывает дополнительные расходы на установку TCP-соединений. Если код каждый раз инициализирует новый объект HTTPСоединение, это вызывает процедуру рукопожатия (handshake), которая может длиться дольше, чем сам обмен данными.
Перерисовка формы: При получении АОН (автоматического определителя номера) программа часто вызывает обновление элементов формы. Метод ОповеститьОбИзменении() или программное изменение свойств видимости заставляет платформу полностью пересчитывать макет формы, что является ресурсоемкой операцией.

Решение 1: Использование Системы взаимодействия

Наиболее современный и правильный способ избежать постоянных опросов (polling) — это переход на событийную модель (push). Рассмотрим подробнее использование Системы взаимодействия. Схема выглядит так: внешний сервис телефонии при поступлении звонка сам отправляет сигнал в 1С.

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


// Код на стороне сервера (в HTTP-сервисе)
ПользовательСсылка = Справочники.Пользователи.НайтиПоНаименованию(ИмяПользователя);
ПараметрыСообщения = Новый Структура("НомерТелефона, ИмяКлиента", АОН, ИмяКлиента);

НовоеСообщение = СистемаВзаимодействия.СоздатьСообщение(ОбсуждениеСсылка);
НовоеСообщение.Текст = "Входящий звонок";
НовоеСообщение.Данные = ПараметрыСообщения;
НовоеСообщение.Записать();

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

Решение 2: Асинхронный обмен через поле HTML-документа

Если Система взаимодействия недоступна, проанализируем вариант с использованием поля HTML-документа. Это позволяет реализовать технологию WebSockets или Long Polling внутри 1С. Суть метода заключается в том, что JavaScript-код внутри HTML-поля работает в отдельном процессе (или потоке браузерного движка) и не блокирует основной интерфейс 1С.

Разберем по шагам реализацию этого метода:

Размещаем на форме скрытое поле HTML-документа.
Загружаем в него JS-скрипт, который открывает WebSocket-соединение с сервером телефонии.
При получении данных JS вызывает событие 1С через команду window.external.MessageFromObject.

Пример получения данных в 1С:


&НаКлиенте
Процедура ПолеHTMLДокументаПриНажатии(Элемент, ДанныеСобытия, СтандартнаяОбработка)
    // Обработка данных, пришедших из JavaScript
    Если ДанныеСобытия.ИмяСобытия = "IncomingCall" Тогда
        ОткрытьКарточкуЗвонка(ДанныеСобытия.Номер);
    КонецЕсли;
КонецПроцедуры

Решение 3: Оптимизация классического опроса («Легкий запрос»)

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

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

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

Посмотрим на пример оптимизированного обработчика:


&НаКлиенте
Процедура ОбработчикОжидания_ПроверитьЗвонок()
    // Проверка флага в памяти сервера (очень быстро)
    Если ЕстьНовыеСобытияТелефонии() Тогда 
        // Только теперь выполняем тяжелую работу
        ОбновитьДанныеЗвонкаНаФорме();
    КонецЕсли;
КонецПроцедуры

Решение 4: Внешние компоненты (Native API)

Для максимально производительной работы следует использовать внешние компоненты. Компонента, написанная на C++ или C#, может работать в собственном потоке операционной системы. Она поддерживает постоянное соединение с АТС (например, по протоколу TAPI или через прямое TCP-взаимодействие) и генерирует ВнешнееСобытие в 1С только в момент реального поступления звонка.

Преимущества этого метода:

Нулевая нагрузка на клиент в режиме ожидания.
Мгновенная реакция на событие без задержек, связанных с интервалом опроса.
Стабильность соединения, так как компонента может автоматически переподключаться при разрывах VPN.