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

← На главную

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

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

Способ 1. Использование мобильного клиента с автономным режимом (МКАР)

Это современный и наиболее рекомендуемый фирмой «1С» способ решения проблемы. Разберем по шагам, в чем заключается суть этой технологии. Мобильный клиент с автономным режимом — это гибридная технология, которая объединяет в себе тонкую работу с сервером и наличие локальной базы данных на мобильном устройстве.

Проанализируем основные принципы его работы:

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

Для реализации этого режима нам необходимо в свойствах конфигурации установить режим использования мобильного приложения как МобильныйКлиентСАвтономнымРежимом. После этого для необходимых объектов метаданных нужно настроить состав автономных данных.

Способ 2. Реализация логики «Offline-first» в мобильном приложении

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

Разберем алгоритм работы такой системы:

Пользователь вводит данные в формы мобильного приложения.
Данные сохраняются в локальную информационную базу (НаСервере в контексте мобильного приложения означает выполнение кода на самом мобильном устройстве).
Объекты регистрируются к обмену (например, через планы обмена или в специальном регистре сведений).
Асинхронно, при наличии связи, приложение пытается отправить накопленные изменения на центральный сервер через HTTP или Web-сервисы.

Выясним причину, почему это надежнее: даже если связь пропадет в момент записи, данные никуда не исчезнут, так как они уже зафиксированы в локальной SQLite-базе устройства. Посмотрим на пример упрощенного кода для проверки доступности сервера перед отправкой:


&НаКлиенте
Процедура ОтправитьДанныеНаСервер()
    
    Попытка
        Соединение = Новый HTTPСоединение("myserver.com", 443, , , , Истина);
        Ответ = Соединение.Получить(Новый HTTPЗапрос("/hs/ping"));
        Если Ответ.КодСостояния = 200 Тогда
            // Выполняем выгрузку накопленных данных
            ВыгрузитьЛокальныеИзменения();
        КонецЕсли;
    Исключение
        // Связи нет, данные остаются в локальной базе до следующей попытки
        СообщитьПользователюОПроблемахСвязи();
    КонецПопытки;
    
КонецПроцедуры

Способ 3. Программный контроль связи и фоновые задания

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

Чтобы приложение продолжало попытки синхронизации, даже когда пользователь свернул его, можно использовать механизмы фонового выполнения. Однако стоит помнить об ограничениях операционных систем (Android и iOS) в части энергосбережения. Чтобы фоновое задание не «умерло» через несколько минут, в настройках мобильного устройства для приложения 1С должно быть разрешено использование батареи без ограничений.

Для программного определения статуса подключения в современных версиях платформы можно использовать проверку свойств подключения. Но самым надежным способом остается обработка исключений при вызове серверного метода:


&НаКлиенте
Процедура ЗаписатьДокумент()
    
    Попытка
        // Пытаемся вызвать серверную процедуру основного сервера
        ЗаписатьНаСервереОсновнойБазы();
    Исключение
        // Если сервер недоступен, сработает этот блок
        Если ЭтоМобильныйКлиент Тогда
            СохранитьВоВременноеХранилищеЛокально();
            // Или записываем в локальные файлы (JSON/XML)
        КонецЕсли;
    КонецПопытки;
    
КонецПроцедуры

Сложности, которые необходимо учитывать

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

При разработке системы синхронизации («ручками» или через автономный режим) необходимо заранее определить правила разрешения конфликтов:

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

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

Резюме

Подводя итог, можно сказать: наиболее эффективный путь сегодня — это использование Мобильного клиента с автономным режимом. Он минимизирует количество «ручного» кода для синхронизации и использует встроенную мощь платформы для управления локальной базой данных. Если же требуется полный контроль над процессом или работа на старых версиях платформы, следует выбирать архитектуру мобильного приложения с асинхронным обменом через HTTP-сервисы.