При разработке мобильных решений на платформе 1С часто возникает задача оперативной доставки изменений из центральной информационной системы на мобильные устройства. Классический сценарий, когда клиент периодически опрашивает сервер каждые несколько секунд, создает избыточную паразитную нагрузку на сетевую инфраструктуру и серверную базу данных. Разберем возможные пути решения этой задачи как при наличии доступа в интернет, так и в изолированном контуре локальной сети Wi-Fi.
Штатный механизм push-уведомлений платформы 1С
Рассмотрим стандартный сценарий, заложенный разработчиками платформы 1С. Начиная с версии 8.3.6 мобильной платформы, реализован встроенный сервис доставки push-уведомлений. Этот подход идеально подходит, если планшеты или смартфоны имеют постоянный выход в глобальную сеть интернет.
Схема взаимодействия выглядит следующим образом:
Мобильное устройство при первом запуске регистрируется в сервисе доставки уведомлений и получает уникальный идентификатор подписчика.
Этот идентификатор мобильное приложение передает в основную базу через HTTP- или Web-сервис, где он сохраняется в специальном регистре сведений.
При возникновении события в центральной базе (например, изменились остатки товаров или назначен новый заказ) серверная база формирует и отправляет push-уведомление через облачный сервис рассылки 1С или инфраструктуру Google FCM.
Push-уведомление служит для мобильного клиента легким сигналом к действию. Получив оповещение, мобильное приложение самостоятельно инициирует обращение к HTTP-сервису центральной базы и забирает свежую порцию данных.
Главное ограничение: штатные механизмы push-уведомлений жестко завязаны на внешние облачные шлюзы. Если планшеты работают строго внутри корпоративной сети Wi-Fi без доступа в интернет, мобильное устройство не сможет зарегистрироваться в облаке и принять входящее сообщение.
Организация работы в изолированной сети без доступа в интернет
Проанализируем ситуацию, когда мобильные устройства работают в пределах предприятия и отрезаны от внешней сети. В таких условиях мобильная платформа 1С функционирует исключительно как клиент: поднять собственный слушающий HTTP-сервис или открыть входящий TCP-порт штатными средствами встроенного языка на мобильном устройстве невозможно. Рассмотрим альтернативные архитектурные решения.
Решение 1. Механизм Long Polling (длинный опрос) средствами 1С
Чтобы избежать частого таймерного опроса (раз в 5–15 секунд), применим технику длинного опроса через стандартные объекты HTTPСоединение и HTTPЗапрос.
Разберем логику работы по шагам:
Мобильное приложение отправляет HTTP-запрос к центральной базе с увеличенным таймаутом ожидания ответа (например, 30–60 секунд).
HTTP-сервис на стороне центральной базы не отдает ответ мгновенно. Он проверяет наличие изменений для конкретного мобильного узла. Если новых данных нет, сервер приостанавливает выполнение и ожидает появления события (например, проверяет флаг изменения в цикле с небольшой паузой).
Как только в основной базе регистрируется событие, сервер немедленно возвращает HTTP-ответ с полезными данными, и соединение корректно закрывается.
Если таймаут истек, а изменений не произошло, сервер отдает пустой ответ («нет данных»). Мобильное приложение перехватывает завершение запроса и сразу же открывает следующий длинный запрос.
Такой подход кардинально уменьшает количество сетевых пакетов, освобождает канал связи и обеспечивает реакцию интерфейса практически в реальном времени без применения сторонних библиотек.
Решение 2. Использование локального брокера сообщений и внешних компонент
Если требуется мгновенная доставка без циклического ожидания на сервере, рассмотрим архитектуру на базе брокера сообщений внутри локальной сети предприятия (например, работающего по протоколу MQTT или WebSocket).
Посмотрим на схему взаимодействия:
В закрытой корпоративной сети разворачивается локальный сервис очередей сообщений.
Для мобильного приложения 1С используется внешняя компонента (разработанная по технологии Native API для Android), которая умеет держать постоянный сокет с локальным брокером.
При фиксации изменений центральная база 1С публикует событие в брокер сообщений.
Брокер передает сигнал компоненте на планшете, а внешняя компонента генерирует в мобильной платформе 1С стандартное внешнее событие.
Событие обрабатывается встроенным языком в предопределенной процедуре модуля управляемого приложения:
Процедура ОбработкаВнешнегоСобытия(Источник, Событие, Данные)
Если Источник = "LocalMessageBroker" И Событие = "NeedDataUpdate" Тогда
// Запускаем обновление необходимых справочников или остатков с сервера
ВыполнитьОбновлениеДанных();
КонецЕсли;
КонецПроцедуры
Решение 3. Широковещательные UDP-пакеты (Broadcast)
Выясним еще один эффективный сценарий для закрытой Wi-Fi сети — рассылку широковещательных сообщений. Центральный сервер отправляет UDP-пакет на широковещательный адрес локальной подсети. Внешняя компонента на мобильном устройстве перехватывает сетевой пакет и инициирует событие в коде 1С. Преимущество данного метода заключается в том, что центральной базе не требуется вести реестр IP-адресов каждого мобильного устройства.
Системные настройки Android для стабильной работы
Проанализируем системные ограничения мобильной операционной системы Android, которые могут повлиять на доставку уведомлений:
Режим энергосбережения (Doze Mode): при выключении экрана или длительном отсутствии действий пользователя система Android переводит процессы в режим гибернации и блокирует сетевой трафик. Для стабильного приема сообщений необходимо в настройках планшета отключить оптимизацию расхода аккумулятора для приложения 1С.
Политика работы Wi-Fi: в параметрах беспроводной сети устройства необходимо отключить переход Wi-Fi модуля в спящий режим при блокировке экрана.
Таймауты сетевого оборудования: при использовании постоянных TCP-соединений или длинных HTTP-опросов убедитесь, что интервалы сетевой активности не превышают время разрыва неактивных сессий на локальных маршрутизаторах предприятия.