Архитектура мобильных приложений с поддержкой автономной работы для полевых команд

Введение и архитектурные требования

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

Локальная база данных и хранение данных

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

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

Стратегии синхронизации на основе очередей

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

Создание очереди операций

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

Фоновые службы

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

Разрешение конфликтов (Conflict Resolution)

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

• Победитель получает все / Последняя запись побеждает (Last Write Wins): Принятие в качестве действительного последнего изменения на основе временной метки.
• Приоритет сервера: Актуальные данные на сервере всегда являются доминирующими.
• Ручное разрешение: Предоставление интерфейсов, позволяющих пользователю или администратору вмешаться при обнаружении конфликта.

Заключение

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

Гипотетический сценарий: Обслуживание сети энергоснабжения

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

Подробный контрольный список реализации

При создании надежной мобильной архитектуры с поддержкой автономной работы необходимо полностью выполнить определенные шаги для минимизации технических рисков и управления сценариями сбоев. Во-первых, следует убедиться, что ключи шифрования локальной базы данных хранятся в защищенном аппаратном слоте устройства (Keychain или Keystore). Во-вторых, при проектировании механизма очереди операций следует отдавать предпочтение идемпотентным структурам (возвращающим тот же результат при повторных вызовах); таким образом предотвращается загрязнение данных, вызванное дублированием отправки одного и того же запроса при слабом соединении. В-третьих, показатели заполненности памяти и диска должны периодически проверяться, а старые синхронизированные данные — очищаться в рамках политики безопасности. В-четвертых, в случае сетевых ошибок (HTTP 5xx, таймаут или обрыв соединения) должна применяться стратегия экспоненциальной задержки (exponential backoff) для балансировки нагрузки на сервер. В-пятых, пользователю должны предоставляться четкие и понятные визуальные индикаторы, сообщающие о состоянии сети и синхронизации. Наконец, все сценарии ошибок должны быть протестированы сквозным образом, чтобы приложение переходило в безопасный режим в ситуациях, когда целостность данных оказывается под угрозой.

Источники

• Веб- и мобильные приложения — Cy Logic Software