Как инициировать синхронизацию данных со стороны сервера в мобильном приложении 1С?

← На главную

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

Причина проблемы: Почему сервер не может «достучаться» до клиента

Разберем ситуацию: центральный сервер опубликован как веб-сервер и имеет статический адрес. Мобильный же клиент часто находится за NAT оператора связи, имеет динамический IP-адрес или вовсе временно теряет сеть. Таким образом, инициировать TCP-соединение со стороны сервера к мобильному устройству технически невозможно. Все запросы должны исходить от клиента.

Тем не менее, существует несколько проверенных способов реализовать «реактивность» приложения, чтобы оно начинало синхронизацию сразу после внесения изменений на сервере. Рассмотрим их подробно.

Решение 1: Периодический опрос сервера (Polling)

Проанализируем самый простой в реализации метод, который выбрал автор темы. Суть заключается в том, что мобильное приложение регулярно «спрашивает» сервер: «Есть ли для меня новые данные?». Если сервер отвечает «Да», запускается полноценная процедура обмена.

Для реализации этого подхода выполним следующие шаги:

На стороне сервера: Создадим легкий метод в составе Web-сервиса или HTTP-сервиса. Этот метод не должен передавать сами данные, его задача — максимально быстро вернуть булево значение (Истина/Ложь), сигнализирующее о наличии изменений для конкретного устройства.
На стороне мобильного приложения: В модуле управляемого приложения или в основной форме настроим ПодключитьОбработчикОжидания.

Рассмотрим пример кода для мобильного приложения:


&НаКлиенте
Процедура ПриОткрытии(Отказ)
    // Запускаем проверку каждые 30 секунд
    ПодключитьОбработчикОжидания("ПроверитьНаличиеОбновленийНаСервере", 30);
КонецПроцедуры

&НаКлиенте
Процедура ПроверитьНаличиеОбновленийНаСервере()
    // Вызываем легкую функцию через WS-ссылку или HTTP-запрос
    ЕстьИзменения = ПроверитьИзмененияНаСервереНаСервере();
    
    Если ЕстьИзменения Тогда
        // Вызываем основную процедуру обмена
        ВыполнитьСинхронизациюДанных();
    КонецЕсли;
КонецПроцедуры

Важный нюанс: Чтобы не раздражать пользователя и не блокировать интерфейс, процедуру ВыполнитьСинхронизациюДанных рекомендуется выполнять в фоновом режиме, используя ФоновыеЗадания мобильной платформы, если это позволяет логика вашего приложения.

Решение 2: Использование Push-уведомлений

Разберем более продвинутый и энергоэффективный метод — Push-уведомления. В отличие от постоянных запросов, этот метод позволяет мобильному приложению «спать» и активироваться только по сигналу от сервисов уведомлений (Google FCM или Apple APNs).

В платформе 1С реализован механизм ДоставляемыеУведомления. Проанализируем цепочку действий:

На сервере при изменении данных срабатывает код, который отправляет Push-сообщение через специальный сервис 1С.
Мобильное устройство получает уведомление.
В мобильном приложении срабатывает обработчик ПриПолученииДоставляемогоУведомления.

Существует два типа пуш-уведомлений, которые мы можем использовать:

Информационные: Пользователь видит текст на экране, нажимает на него, приложение открывается и запускает обмен.
Тихие (Data messages): Уведомление не отображается визуально, но пробуждает обработчик в коде приложения. Это позволяет инициировать обмен незаметно для пользователя.

Пример обработки уведомления в модуле мобильного приложения:


Процедура ПриПолученииДоставляемогоУведомления(Уведомление, Локальное, Показано)
    // Проверяем содержимое уведомления
    Если Уведомление.Данные.Свойство("ТипСобытия") И Уведомление.Данные.ТипСобытия = "ТребуетсяОбмен" Тогда
        // Инициируем синхронизацию
        ВыполнитьСинхронизациюДанных();
    КонецЕсли;
КонецПроцедуры

Решение 3: Система взаимодействия

Рассмотрим современный инструмент — Систему взаимодействия. Она работает на протоколе WebSockets, который поддерживает постоянное открытое соединение между сервером и клиентом. Это позволяет серверу мгновенно «толкнуть» сообщение клиенту.

Выясним преимущества этого метода:

Минимальные задержки (реальное время).
Экономия трафика по сравнению с постоянными HTTP-запросами.
Возможность передавать небольшие порции данных прямо в теле сообщения.

Для реализации необходимо зарегистрировать информационную базу в сервисе взаимодействия и подписать мобильное приложение на соответствующий канал или обсуждение. Когда на сервере происходит событие (например, проведение документа ЗаказПокупателя), сервер отправляет сообщение, которое перехватывается мобильным клиентом через обработчик оповещений.

Решение 4: Использование HTTP-сервисов и Long Polling

Если по условиям безопасности использование внешних Push-сервисов невозможно (закрытый контур), проанализируем архитектуру Long Polling. Это модификация обычного опроса.

Выясним суть метода: мобильное приложение делает запрос к серверу (используя HTTPЗапрос), а сервер не отвечает сразу, если данных нет. Он «удерживает» соединение открытым в течение длительного времени (например, 30–60 секунд). Как только данные появляются или время истекает, сервер отправляет ответ. При получении ответа клиент тут же отправляет новый «длинный» запрос.

Почему HTTP лучше WS для мобильных? HTTPСервисы работают быстрее, так как используют легковесный JSON вместо тяжелого SOAP/XML, который используется в Web-сервисах. Это критично для мобильных процессоров и экономии заряда батареи.

Сравнительный анализ и рекомендации

Проанализируем, какой метод выбрать в зависимости от задач:

Если нужна простота и надежность: Выбираем опрос по таймеру (Polling) через HTTP-сервис. Интервал в 30-60 секунд обычно не критичен для батареи, но обеспечивает приемлемую актуальность данных.
Если критична мгновенная доставка: Используем Push-уведомления. Это стандарт индустрии для мобильной разработки.
Если работа идет в корпоративной сети без интернета: Оптимальным выбором будет Система взаимодействия (с локальным сервером взаимодействия) или Long Polling.

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