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

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

При разработке мобильных решений на платформе 1С программисты часто сталкиваются с архитектурным тупиком. Типичный сценарий: на складе работают сотрудники с терминалами сбора данных (ТСД) на базе мобильной платформы 1С. Менеджер в центральной базе (КИС) проводит новый заказ на сборку и хочет, чтобы этот заказ мгновенно появился на экране ТСД конкретного кладовщика. Логичное первое желание разработчика — поднять HTTP-сервис внутри мобильного приложения и отправлять данные напрямую из КИС. Однако здесь мы сталкиваемся с суровой реальностью сетевых технологий.

Мобильное устройство физически не может выступать в роли классического веб-сервера, готового в любой момент принять входящее соединение от КИС. Мобильный интернет использует динамические IP-адреса, устройства находятся за NAT операторов связи, а сама мобильная операционная система (Android или iOS) жестко экономит заряд батареи, «усыпляя» фоновые процессы. Прямой вызов мобильного устройства со стороны сервера невозможен.

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

Архитектурный шаблон Push-Pull: детальный разбор схемы

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

  1. В центральной базе 1С происходят изменения (например, создан новый документ ЗаказПокупателя).
  2. Система регистрирует изменения для конкретного мобильного устройства (узла плана обмена).
  3. Центральная база отправляет специальный сигнал — Push-уведомление — через службу уведомлений (Google FCM, Apple APNs или собственный сервис 1С) на конкретное мобильное устройство.
  4. Мобильное устройство принимает это уведомление (даже если само приложение в этот момент закрыто или свернуто).
  5. Операционная система мобильного устройства передает управление мобильной платформе 1С, которая обрабатывает входящий push-пакет.
  6. Мобильное приложение «понимает», что на сервере появились новые данные, и в фоновом режиме отправляет встречный HTTP-запрос к HTTP-сервису центральной базы.
  7. HTTP-сервис центральной базы упаковывает изменившиеся данные в формат JSON или XML и отдает их в теле ответа.
  8. Мобильное приложение принимает данные, записывает их в свою локальную базу данных и отправляет серверу подтверждение успешного приема.

Рассмотрим по шагам, как реализовать каждый элемент этой цепочки.

Шаг 1. Регистрация изменений на стороне сервера 1С

Чтобы не гонять весь объем информации при каждом сеансе связи, мы должны передавать только измененные или новые данные. Для этого в центральной базе создадим специализированный объект метаданных — ПланОбмена (назовем его ОбменСМобильнымиУстройствами).

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

Проанализируем пример кода программной регистрации изменений на сервере:


// Процедура регистрирует изменения документа для конкретного ТСД
Процедура ЗарегистрироватьДокументДляМобильного(СсылкаНаДокумент, АдресатКладовщик) Экспорт
    
    // Ищем узел плана обмена, соответствующий конкретному ТСД кладовщика
    УзелОбмена = ПланыОбмена.ОбменСМобильнымиУстройствами.НайтиПоРеквизиту("Кладовщик", АдресатКладовщик);
    
    Если ЗначениеЗаполнено(УзелОбмена) Тогда
        // Регистрируем изменение конкретного объекта для выбранного узла
        ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, СсылкаНаДокумент);
    КонецЕсли;
    
КонецПроцедуры

Шаг 2. Настройка и отправка Push-уведомлений

Для отправки уведомлений платформа 1С предоставляет встроенный механизм работы с доставляемыми уведомлениями. Отправка может выполняться через систему взаимодействия 1С или напрямую через сторонние API (например, Firebase Cloud Messaging). Самый простой и надежный способ в экосистеме 1С — использование встроенного сервиса доставляемых уведомлений.

Разберем пример отправки push-сигнала из центральной базы 1С на мобильное устройство:


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

Шаг 3. Обработка Push-уведомления в мобильном приложении

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

Посмотрим на пример обработки входящего push-события на мобильном устройстве:


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

Шаг 4. Реализация HTTP-сервиса на стороне сервера и забор данных

В центральной базе 1С мы публикуем HTTP-сервис (например, MobileExchange) с шаблоном URL /v1/get_data. Мобильное устройство обращается к этому сервису, передавая свой уникальный код узла. Сервер считывает зарегистрированные изменения по этому узлу, сериализует их в JSON и отправляет обратно мобильному клиенту.

Крайне важно использовать сериализацию XDTO или специализированные функции работы с JSON для корректного преобразования объектов 1С. Рассмотрим упрощенный пример кода обработчика GET-запроса на стороне сервера:


Функция ПолучитьДанныеДляМобильного(Запрос)
    
    КодУзла = Запрос.ПараметрыЗапроса.Получить("node");
    УзелОбмена = ПланыОбмена.ОбменСМобильнымиУстройствами.НайтиПоКоду(КодУзла);
    
    Если УзелОбмена.Пустая() Тогда
        Ответ = Новый HTTPСервисОтвет(404);
        Возврат Ответ;
    КонецЕсли;
    
    // Инициализируем запись JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписьJSON.ЗаписатьНачалоОбъекта();
    ЗаписьJSON.ЗаписатьИмяСвойства("Заказы");
    ЗаписьJSON.ЗаписатьНачалоМассива();
    
    // Выбираем зарегистрированные изменения документов
    ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелОбмена, 1); // 1 - номер сообщения
    Пока ВыборкаИзменений.Следующий() Цикл
        
        Если ТипЗнч(ВыборкаИзменений.Выборка) = Тип("ДокументСсылка.ЗаказНаСборку") Тогда
            ДокументОбъект = ВыборкаИзменений.Выборка.ПолучитьОбъект();
            
            // Сериализуем данные документа в JSON-структуру
            ЗаписатьJSON(ЗаписьJSON, Новый Структура("Номер, Дата, Склад", ДокументОбъект.Номер, ДокументОбъект.Дата, Строка(ДокументОбъект.Склад)));
        КонецЕсли;
        
    КонецЦикла;
    
    ЗаписьJSON.ЗаписатьКонецМассива();
    ЗаписьJSON.ЗаписатьКонецОбъекта();
    
    СтрокаJSON = ЗаписьJSON.Закрыть();
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
    Ответ.Заголовки.Вставить("Content-Type", "application/json");
    
    Возврат Ответ;
    
КонецФункции

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

Описанный выше классический паттерн с Push-уведомлениями идеален для глобальных сетей (интернет), но имеет ограничения в корпоративных инфраструктурах. Что делать, если склад находится в подвале без доступа к интернету, а ТСД работают в изолированной локальной Wi-Fi сети? Глобальные Push-сервисы (FCM/APNs) работать не будут. Рассмотрим альтернативные варианты архитектуры.

1. Протокол MQTT вместо Push-уведомлений

В закрытой локальной сети вы можете развернуть легковесный брокер сообщений (например, бесплатный Mosquitto). Мобильные устройства при запуске подключаются к брокеру по протоколу MQTT и держат постоянное «дешевое» TCP-соединение.

Когда в центральной базе 1С проводится документ, сервер отправляет короткое текстовое сообщение в топик MQTT-брокера (например, warehouse/tsd_01/sync). Мобильное устройство мгновенно получает это сообщение через открытое соединение и запускает стандартный обмен через HTTP-сервис 1С.

2. Регламентный опрос сервера (Short Polling)

В мобильной базе 1С настраивается регламентное задание, которое запускается с высокой периодичностью (например, каждые 30 или 60 секунд). Задание отправляет быстрый и очень «легкий» HTTP-запрос (ping) на сервер 1С: «Есть ли новые данные для моего ТСД?».

Если сервер возвращает отрицательный ответ, соединение закрывается. Если на сервере зарегистрированы изменения, мобильное устройство начинает полноценный процесс синхронизации. Оверхед от таких легковесных запросов минимален, зато обеспечивается полная автономность от внешних интернет-сервисов.

3. Мобильный клиент с автономным режимом (МКАР)

Если вы не хотите вручную проектировать API, создавать планы обмена на JSON и писать код сериализации, обратите внимание на современную технологию платформы 1С — «Мобильный клиент с автономным режимом». Она кардинально отличается от разработки классического «Мобильного приложения».

Подведение итогов

Реализация обмена, инициируемого сервером, всегда сводится к переворачиванию вектора инициации. Мы не «стучимся» с сервера в мобильный телефон напрямую, а отправляем ему легкий сигнал-команду (через push-уведомление, MQTT или короткий опрос), после чего мобильный клиент сам забирает данные через стандартные HTTP-сервисы. Выбор конкретного инструмента (собственная разработка на JSON + Push, локальный брокер MQTT или использование готовой технологии автономного мобильного клиента 1С) зависит от ландшафта вашей сети и требований к безопасности проекта.

← На главную