Как организовать периодическую проверку связи между тонким клиентом и сервером 1С

В процессе эксплуатации систем на базе платформы 1С:Предприятие 8.3 (например, «Управление торговлей 11») разработчики часто сталкиваются с жалобами пользователей на нестабильное соединение. Тонкий клиент может внезапно завершать работу, «отваливаться» или зависать в моменты кратковременного разрыва сетевого соединения. Чтобы своевременно диагностировать подобные проблемы, возникает задача: организовать регулярную проверку связи (так называемый пинг) непосредственно со стороны клиента к серверу 1С.

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

Почему классический ICMP-пинг через внешние компоненты — это плохой выбор?

На первый взгляд самым простым решением кажется запуск стандартной системной утилиты ping.exe или использование VBS-скриптов через COM-объект WScript.Shell. Однако при детальном анализе этот подход сталкивается со следующими критическими проблемами:

1. Предупреждение безопасности платформы. Современные версии платформы 1С:Предприятие 8.3 при любой попытке запуска внешнего приложения или создания COM-объекта на клиенте выдают интерактивное предупреждение безопасности («Программа пытается запустить внешнюю команду...»). Если ваш фоновый пинг будет срабатывать каждые 5 минут, пользователь будет постоянно видеть всплывающие окна блокировки, что сделает работу в системе невозможной. Отключение этой защиты в файле conf.cfg или через профили безопасности крайне не рекомендуется по соображениям безопасности.
2. Сетевые экраны (брандмауэры) и NAT. Классический пинг работает по протоколу ICMP. В реальных инфраструктурах (особенно когда клиенты работают удаленно через VPN или мобильный интернет) ICMP-пакеты часто блокируются маршрутизаторами и межсетевыми экранами. При этом сам тонкий клиент 1С может успешно продолжать работу по протоколам TCP или HTTP/HTTPS. Таким образом, отсутствие ответа на ICMP-запрос не будет означать реального отсутствия связи с базой.
3. Зависимость от операционной системы. Использование системных утилит Windows делает код несовместимым с клиентами, работающими на macOS или Linux.

Оптимальная альтернатива: Проверять связь нужно именно по тому каналу, по которому работает сама 1С. Если база опубликована на веб-сервере (IIS или Apache), наиболее надежным решением будет отправка легких асинхронных HTTP-запросов к веб-серверу или выполнение сверхлегкого вызова серверного метода 1С.

Проблема зависания интерфейса (синхронность против асинхронности)

Если мы настроим периодический вызов сервера или синхронный HTTP-запрос в обработчике ожидания, то при реальной потере связи или «затухании» интернет-канала сеанс пользователя гарантированно зависнет на время таймаута (по умолчанию это около 20–30 секунд). В этот момент пользователь будет видеть крутящийся курсор ожидания и не сможет совершать никаких действий в интерфейсе. Это сильно раздражает персонал.

Чтобы избежать микрофризов и зависаний, мы должны соблюдать два правила:

• Устанавливать минимально возможный таймаут для соединения (не более 2–3 секунд).
• По возможности выполнять проверку асинхронно, чтобы сетевой запрос не блокировал основной поток интерфейса.

Пошаговая реализация проверки связи через Расширение конфигурации

Чтобы не вносить изменения в типовую конфигурацию «Управление торговлей 11» и не усложнять последующие обновления системы, всю логику проверки мы реализуем с помощью расширения конфигурации.

Шаг 1. Создание расширения и подключение обработчика ожидания

Создадим новое расширение конфигурации. Добавим в него модуль управляемого приложения и переопределим процедуру ПриНачалеРаботыСистемы с аннотацией &После. Это позволит нам запустить периодический таймер сразу при старте сеанса пользователя.

&После("ПриНачалеРаботыСистемы")
Процедура Пинг_ПриНачалеРаботыСистемы()
    // Настраиваем проверку каждые 5 минут (300 секунд)
    // Метод ПодключитьОбработчикОжидания работает на стороне клиента
    ПодключитьОбработчикОжидания("Пинг_ВыполнитьПроверкуСвязи", 300, Ложь);
КонецПроцедуры

Шаг 2. Создание глобального модуля на клиенте

Создадим в расширении новый общий модуль с именем ПингКлиент. В свойствах модуля обязательно установим флаги Клиент (управляемое приложение) и Глобальный. Это необходимо, чтобы платформа могла вызвать процедуру-обработчик ожидания по ее имени.

Внутри общего модуля напишем процедуру, которая будет выполнять легкий тестовый запрос. Рассмотрим вариант с использованием HTTP-соединения к веб-серверу, где опубликована база 1С. Этот метод наиболее безопасен и стабилен.

Процедура Пинг_ВыполнитьПроверкуСвязи() Экспорт
    
    // Определяем адрес сервера публикации из параметров строки соединения
    СтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
    // Извлекаем адрес веб-сервера (в реальном коде можно использовать регулярные выражения или функции парсинга БСП)
    АдресВебСервера = ПингКлиентСервер.ПолучитьАдресСервераИзСтрокиСоединения(СтрокаСоединения);
    
    Если ПустаяСтрока(АдресВебСервера) Тогда
        Возврат; // Если база файловая или запущена не через веб-сервер
    КонецЕсли;
    
    // Создаем соединение с минимальным таймаутом, чтобы избежать зависания интерфейса
    ТаймаутПроверки = 3; // 3 секунды
    
    Попытка
        Соединение = Новый HTTPСоединение(АдресВебСервера, , , , , ТаймаутПроверки);
        // Запрашиваем легкий статический файл (например, ping.html, предварительно созданный в корне веб-сервера)
        // или обращаемся к легкому HTTP-сервису базы 1С
        Запрос = Новый HTTPЗапрос("ping.html"); 
        
        Ответ = Соединение.Получить(Запрос);
        
        Если Ответ.КодСостояния = 200 Тогда
            // Связь стабильна. При необходимости фиксируем успешную проверку
        Иначе
            ЗаписатьИнформациюОСбое("Код ответа сервера: " + Ответ.КодСостояния);
        КонецЕсли;
    Исключение
        // Сюда мы попадем, если связь полностью оборвалась или таймаут 3 секунды истек
        ЗаписатьИнформациюОСбое("Сбой сети: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
    КонецПопытки;
    
КонецПроцедуры

Как логировать результаты, если связь потеряна?

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

Для решения этой проблемы мы можем использовать запись логов в локальный файл на компьютере пользователя. Локальные права тонкого клиента обычно позволяют выполнять запись в каталог временных файлов:

Процедура ЗаписатьИнформациюОСбое(ТекстОшибки)
    
    ИмяФайлаЛога = КаталогВременныхФайлов() + "1c_network_ping_log.txt";
    СтрокаЛога = Строка(ТекущаяДата()) + " | " + ИмяПользователя() + " | " + ТекстОшибки + Символы.ПС;
    
    Попытка
        ЗаписьТекста = Новый ЗаписьТекста(ИмяФайлаЛога, КодировкаТекста.UTF8, , Истина);
        ЗаписьТекста.ЗаписатьСтроку(СтрокаЛога);
        ЗаписьТекста.Закрыть();
    Исключение
        // Если даже локальный диск недоступен, то просто игнорируем ошибку
    КонецПопытки;
    
КонецПроцедуры

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

Использование стандартных механизмов БСП

Если ваша конфигурация построена на базе БСП (как «Управление торговлей 11»), вам не обязательно писать парсеры адресов и обработчики сетевых соединений вручную. В библиотеке есть готовые служебные модули. Например, функция ПроверитьДоступностьСервера() из общего модуля ПолучениеФайловИзИнтернетаСлужебный берет на себя рутину по кроссплатформенной проверке доступности сетевых ресурсов.

Нагрузка на сервер 1С и альтернативные решения

Проанализируем нагрузку на информационную систему. Если в вашей базе одновременно работают более 100 активных пользователей, и каждый из них каждые 5 минут отправляет запросы к серверу 1С, это создает дополнительно десятки тысяч транзакций в день. Каждый такой запрос дергает рабочий процесс сервера 1С (rphost), отвлекая его вычислительные ресурсы от выполнения бизнес-задач пользователей.

Если вашей главной целью является детальный аудит качества каналов связи удаленных пользователей, правильнее использовать специализированные системы мониторинга (например, Zabbix Agent или Prometheus Node Exporter), установленные на рабочих станциях сотрудников. Они выполняют сбор сетевой статистики в фоновом режиме операционной системы, не задействуя платформу 1С и гарантируя стопроцентную точность данных без создания паразитной нагрузки на сервер приложений.