Как надёжно вести запись периодического контроля при отсутствии интернета?

Краткий ответ: как вести записи контроля без интернета?

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

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

Какие данные нужно загрузить на устройство перед выездом?

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

• Наряд и неизменный идентификатор оборудования
• Зафиксированная версия формы контроля для соответствующего типа оборудования
• Необходимые критерии контроля и списки выбора
• Область задач назначенного сотрудника и ссылки на приборы
• Время последней синхронизации и версия пакета

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

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

Как сохранять форму на устройстве?

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

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

Кнопка сохранения должна показывать успех только после завершения локальной транзакции. Закрытие приложения, разряд батареи или кратковременное появление сети не должны переводить незавершённую форму в статус «отправлено».

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

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

1. Проверяйте не только наличие соединения, но и доступность сервера приложения.
2. Повторно проверяйте локальную целостность записи в очереди и обязательные поля.
3. Отправляйте запись и её вложения с неизменным идентификатором операции и локальной версией.
4. Выполняйте на сервере проверки полномочий, наряда, версии формы и текущей версии записи.
5. После успешного приёма сохраняйте на устройстве серверный идентификатор записи и время приёма.
6. Направляйте временные ошибки на контролируемый повтор, а постоянные ошибки валидации — на рассмотрение человеком.

RFC 9110 объясняет, что идемпотентный запрос можно повторить после ошибки соединения с тем же предполагаемым эффектом. Для записи периодического контроля одного названия метода недостаточно: сервер не должен добавлять второй запрос с тем же ключом операции как новый отчёт, а должен вернуть результат прежнего приёма.

Background Synchronization API может отложить выполнение задачи до восстановления связи и передать её service worker, но MDN отмечает, что эта возможность не имеет широкой поддержки браузерами. Поэтому очередь не должна зависеть только от фонового события; она также должна безопасно обрабатываться при открытии приложения и нажатии пользователем «отправить сейчас».

Что произойдёт, если одну запись изменили на двух устройствах?

Краткий ответ: не применяйте принцип «последняя запись побеждает» к измерениям и полям соответствия; при конфликте версий остановите операцию и покажите оба изменения уполномоченному пользователю.

Если серверная версия новее базовой версии, полученной устройством в начале работы, автоматическая перезапись может привести к потере данных. Неконфликтующие поля можно объединить под контролем; если одно и то же измерение, результат или критически важное пояснение изменены с обеих сторон, для записи статус требуется рассмотрение должен быть установлен.

• Сравните серверную версию с базовой версией устройства.
• Сохраните изменённые поля и участников изменений в журнале действий.
• Не заменяйте опубликованный отчёт автономным черновиком без явного контроля.
• Зафиксируйте разрешение конфликта новой редакцией с обоснованием.
• Ясно покажите пользователю, на каком устройстве запись ожидает обработки.

Как защитить автономные данные на устройстве?

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

OWASP MASVS-STORAGE-1 требует безопасного хранения чувствительных данных независимо от их расположения на устройстве. MASWE-0006 рекомендует не хранить ненужные чувствительные данные локально, защищать ключи в безопасном хранилище ключей платформы и использовать подходящее шифрование.

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

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

Какие сценарии проверить перед вводом в эксплуатацию?

Краткий ответ: проверки в авиарежиме недостаточно; нужно доказать корректность при прерывании на каждом этапе записи и отсутствие дублей при повторе.

1. Открывается ли приложение впервые без сети или правильно сообщает о недостаточной подготовке?
2. Сохраняется ли последняя завершённая локальная транзакция, если приложение закрывается во время сохранения поля?
3. Сохраняется ли связь формы и вложения, если соединение обрывается при загрузке фотографии?
4. Создаёт ли повторная отправка вторую запись, если сервер принял первую, но ответ не дошёл до устройства?
5. Как отделяется старая автономная работа, если версия формы в центральной системе изменилась?
6. Блокируется ли операция при конфликте критических полей, если одну работу редактируют на двух устройствах?
7. Отклоняется ли отправка с сохранением записи, когда пользователь с отозванными полномочиями снова подключается?
8. Понимает ли пользователь, каких записей ещё нет в центральной системе, если очередь ждёт несколько дней?

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