Как реализовать проверку доступности сервера (Ping) в мобильном приложении 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В процессе разработки мобильных приложений на платформе 1С часто возникает задача диагностики связи. Типичная ситуация: пользователь сообщает, что приложение «не работает», но причин может быть множество — от включенного режима «в самолете» до падения веб-сервера. На настольных ПК для первичной диагностики мы привыкли использовать команду Ping, однако в мобильной платформе (МП) 1С прямого аналога этой команды не существует из-за ограничений безопасности операционных систем Android и iOS. Рассмотрим, как выстроить эффективную систему диагностики доступности узла, используя доступный инструментарий 1С.

Почему стандартный Ping недоступен и чем его заменить

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

Шаг 0: Проверка локального интернет-соединения на устройстве

Прежде чем пытаться «достучаться» до сервера, нужно выяснить, есть ли у мобильного устройства вообще выход в сеть. Проанализируем ситуацию, когда пользователь случайно выключил Wi-Fi или находится вне зоны действия сети. Для этого в мобильной платформе используется объект СредстваИнформационногоВзаимодействия.

Рассмотрим пример функции, которая возвращает состояние сети:


Функция ПроверитьНаличиеИнтернета() Экспорт
    ТипСоединения = СредстваИнформационногоВзаимодействия.ПолучитьТипИнтернетСоединения();
    
    Если ТипСоединения = ТипИнтернетСоединения.НетСоединения Тогда
        Возврат Ложь;
    Иначе
        // Можно уточнить тип: WiFi, СотовыеДанные или ЛокальнаяСеть
        Возврат Истина;
    КонецЕсли;
КонецФункции

Эта проверка мгновенная и не требует сетевых запросов. Если функция возвращает Ложь, дальнейшая диагностика бессмысленна — нужно просить пользователя проверить настройки связи или режим «Полет».

Шаг 1: Эмуляция Ping через HTTP-запрос с минимальным таймаутом

Чтобы проверить, «жив» ли IP-адрес сервера, не обязательно отправлять ICMP-пакет. Мы можем попытаться установить TCP-соединение с веб-сервером (порт 80 или 443). Основная хитрость заключается в использовании очень короткого таймаута. Если сервер доступен, он ответит практически мгновенно. Если сервер выключен, система будет ждать ответа до истечения времени ожидания.

Разберем программную реализацию такой проверки:


Функция ПроверитьДоступностьIP(АдресСервера) Экспорт
    // Устанавливаем таймаут 1-2 секунды для быстрой проверки
    Таймаут = 2; 
    Попытка
        НТТР = Новый HTTPСоединение(АдресСервера, , , , , Таймаут);
        Запрос = Новый HTTPЗапрос("/");
        Ответ = НТТР.Получить(Запрос);
        // Если мы дошли сюда, сервер ответил (даже если 404 или 500)
        Возврат Истина;
    Исключение
        // Анализируем ошибку. Если сервер совсем недоступен, 
        // мы получим исключение по таймауту или отсутствию узла.
        Возврат Ложь;
    КонецПопытки;
КонецФункции

Важный момент: если вы хотите измерить скорость отклика (имитация времени в мс), замеряйте время выполнения этого кода с помощью функции ТекущаяУниверсальнаяДатаВМиллисекундах() до и после вызова НТТР.Получить().

Шаг 2: Проверка работоспособности веб-сервера и публикации

Даже если IP-адрес откликается, веб-сервер (Apache или IIS) может быть остановлен, либо публикация базы 1С может быть повреждена. Для более глубокой проверки проанализируем использование объекта WSОпределения. Это позволяет понять, видит ли мобильное приложение структуру веб-сервисов вашей базы.


Функция ПроверитьПубликациюБазы(ПутьКWSDL, Логин, Пароль) Экспорт
    Попытка
        // Пытаемся получить определения веб-сервиса
        Определение = Новый WSОпределения(ПутьКWSDL, Логин, Пароль, 5); // Таймаут 5 сек
        Возврат Истина;
    Исключение
        // Веб-сервер работает, но база 1С недоступна или путь неверный
        Возврат Ложь;
    КонецПопытки;
КонецФункции

Шаг 3: Использование FTP для проверки «чистого» IP

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

Использование внешних компонент для реального Ping

Если ваша задача требует получения классической строки ответа Ping (с указанием количества переданных пакетов и TTL), единственным надежным способом будет использование внешней компоненты (Native API).

Выясним, как это работает архитектурно:

  1. Для Android пишется небольшая библиотека на Java/Kotlin, которая вызывает системный метод Runtime.getRuntime().exec("/system/bin/ping -c 1 " + ip).
  2. Результат выполнения (stdout) считывается компонентой и передается обратно в 1С в виде строки.
  3. Для iOS используются низкоуровневые сокеты через Apple SimplePing API.

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

Резюме по диагностической цепочке

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

  1. Проверка №0: СредстваИнформационногоВзаимодействия — проверяем, включен ли интернет на смартфоне.
  2. Проверка №1 (Ping): HTTPСоединение к корню домена с таймаутом 1 сек — проверяем доступность сервера.
  3. Проверка №2: HTTPЗапрос к тестовому HTTP-сервису внутри вашей базы — проверяем, что база «живая» и отвечает на запросы.

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

← На главную