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

← На главную

При разработке мобильного приложения на платформе 1С перед разработчиком встает ключевая архитектурная задача: как правильно и надежно связать мобильное устройство с центральной информационной базой. Рассмотрим основные подходы к проектированию обмена данными, проанализируем выбор протоколов и разберем правила работы с изменениями объектов.

Выбор архитектуры: сервисы и планы обмена

Использование файловых выгрузок или резервных копий (выгрузок dt) через облачные диски не подходит для промышленной эксплуатации из-за высоких накладных расходов, отсутствия гибкости и невозможности гранулярного контроля ошибок. Классическая и наиболее надежная схема строится на взаимодействии по принципу клиент-сервер:

Мобильное приложение выступает инициатором соединения. Так как мобильное устройство находится за NAT оператора связи и не имеет статического публичного IP-адреса, оно не может функционировать как сервер, принимающий входящие подключения. Все запросы на синхронизацию отправляются с мобильного клиента на сторону центральной базы.
Центральная база публикует интерфейс взаимодействия. Для приема и передачи данных в основной конфигурации настраивается и публикуется на веб-сервере соответствующий сервис.
Фиксация изменений через план обмена. На стороне мобильного приложения создается объект метаданных ПланОбмена, в состав которого включаются справочники, документы или регистры, подлежащие выгрузке. При модификации объектов платформа автоматически регистрирует изменения для узла обмена.

HTTP-сервисы против SOAP и формат данных

Выясним, какие протоколы и форматы наиболее эффективны в мобильной среде. Традиционные веб-сервисы (SOAP) и универсальный формат EnterpriseData на базе XML создают значительную избыточную нагрузку на мобильный процессор и оперативную память из-за сложной валидации XML-схем. Для мобильной разработки предпочтительны следующие решения:

HTTP-сервисы платформы. Они обеспечивают минимальный служебный трафик и быстро обрабатываются даже в условиях слабого мобильного интернета.
Формат JSON. Сериализация и десериализация данных с помощью встроенных объектов ЗаписьJSON и ЧтениеJSON выполняются значительно быстрее парсинга XML и требуют меньше оперативной памяти устройства.

Механизм квитирования и снятия с регистрации изменений

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

Разберем правильный алгоритм взаимодействия по шагам:

Мобильное приложение считывает зарегистрированные изменения из плана обмена и упаковывает их в пакет JSON. Каждому пакету присваивается номер сообщения (например, через механизм номеров сообщений плана обмена).
Мобильное устройство отправляет сформированный пакет на HTTP-сервис центральной базы.
Центральная база в единой транзакции записывает полученные данные и возвращает мобильному клиенту ответ со статусом успешного завершения и идентификатором (номером) принятого пакета.
Получив подтверждение от сервера, мобильное приложение программно удаляет регистрацию изменений для переданных объектов с помощью метода ПланыОбмена.УдалитьРегистрациюИзменений().
Если во время отправки или обработки возникла ошибка сети, мобильное приложение не подтверждает отправку, и при следующем сеансе связи те же самые объекты будут выгружены повторно.

Пример кода: выгрузка данных и очистка регистрации

Посмотрим на пример процедуры формирования пакета изменений на стороне мобильного приложения с использованием потоковой записи JSON:


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

Ограничения мобильной платформы и обработка коллизий

При проектировании синхронизации важно учитывать специфику работы мобильных операционных систем (Android, iOS):

Контроль расхода памяти. Мобильная платформа чувствительна к нехватке оперативной памяти (OOM-ошибки). Формирование больших массивов структур в памяти целиком недопустимо. Рекомендуется использовать потоковое чтение/запись во временные файлы либо разбивать обмен на порции (пагинация по 50–100 объектов в одном запросе).
Идентификация объектов. Чтобы избежать дублирования ссылочных данных при двустороннем обмене, мобильное приложение генерирует стандартный УникальныйИдентификатор (UUID). Центральная база при создании нового объекта принимает этот UUID в качестве базового идентификатора.
Разрешение коллизий. При одновременном изменении объекта на мобильном устройстве и в центральной базе необходимо заранее определить правила разрешения конфликтов: например, по дате последней модификации или с безусловным приоритетом сервера.
Альтернативный вариант: мобильный клиент с автономным режимом. Если нет жесткой необходимости писать собственное мобильное приложение с нуля, можно воспользоваться технологией автономного мобильного клиента (доступна в современных версиях платформы 8.3). В этом случае синхронизацию данных, кэширование и разрешение базовых коллизий платформа берет на себя без написания дополнительного кода транспортных сервисов.