¿Cómo se registran con seguridad los controles periódicos sin conexión a internet?

Respuesta breve: ¿cómo se registra el control cuando no hay internet?

Guarde el formulario de control en una base de datos local transaccional del dispositivo; asigne a cada registro una identidad de transacción única, mantenga visible el estado de envío y, al restablecerse la conexión, concilie con el servidor sin generar duplicados.

En el trabajo sin conexión, “guardado” no es un único estado. Al usuario se le deben mostrar por separado los estados guardado en el dispositivo, pendiente de envío, aceptado por el servidor y requiere revisión . Así, con una conexión débil, que el formulario aparezca en pantalla no hace suponer que llegó a la central.

¿Qué datos deben cargarse en el dispositivo antes de salir al campo?

Respuesta breve: solo debe cargarse el paquete de datos actual y autorizado necesario para completar el trabajo asignado.

• Orden de trabajo e identidad inmutable del equipo
• Versión fijada del formulario de control asociado al tipo de equipo
• Criterios de control requeridos y listas de selección
• Alcance del encargo del personal asignado y referencias de dispositivos
• Hora de la última sincronización y versión del paquete

La especificación W3C Service Workers explica que pueden construirse aplicaciones web sin conexión mediante un worker que intercepta las peticiones y un almacén local de peticiones/respuestas. Su equivalente en el flujo de VizyonTech no es solo cachear la estructura de la página, sino preparar, verificados antes de la salida al campo, los formularios y datos de referencia del trabajo asignado como un paquete.

Si el paquete no está actualizado, la aplicación no debe abrir silenciosamente el formulario antiguo. La fecha y hora de la última sincronización, la versión del formulario y el límite de uso sin conexión deben ser visibles; si faltan datos maestros críticos, el sistema debe bloquear el inicio del registro (fail-closed). La relación entre la orden de trabajo, el equipo y el formulario se detalla en la guía del plan de controles periódicos , que puede consultar.

¿Cómo debe guardarse el formulario en el dispositivo?

Respuesta breve: escriba cada cambio de campo no en una memoria de pantalla temporal, sino en una operación breve y atómica de la base de datos local.

El borrador W3C IndexedDB 3.0 define, para requisitos web sin conexión, el almacenamiento local de objetos estructurados y que las transacciones se escriban en su totalidad o se reviertan en caso de error. En el formulario de campo, esto significa escribir el valor medido, la unidad, la descripción, el vínculo de la foto y la hora del registro en una versión de borrador coherente.

El botón de guardar solo debe mostrar éxito cuando se completa la operación local. El cierre de la aplicación, el agotamiento de la batería o una conexión momentánea no deben llevar un formulario incompleto al estado “enviado”.

¿Cómo debe realizarse la sincronización al volver la conexión?

Respuesta breve: envíe la cola en orden, reintente cada elemento con la misma identidad de transacción y marque como completado solo tras la respuesta de aceptación explícita del servidor.

1. Verifique no solo la existencia de la conexión, sino el acceso al servidor de aplicaciones.
2. Vuelva a comprobar la integridad local del registro de la cola y sus campos obligatorios.
3. Envíe el registro y sus adjuntos con la identidad de transacción inmutable y la versión local.
4. Ejecute en el servidor los controles de autorización, orden de trabajo, versión del formulario y versión actual del registro.
5. Tras una aceptación correcta, el servidor escribe en el dispositivo la identidad del registro y la hora de aceptación.
6. Distinga el error transitorio, con reintento controlado, del error de validación permanente, con revisión humana.

El RFC 9110 explica que una petición idempotente puede repetirse tras un error de conexión con el mismo efecto pretendido. En el registro de control periódico, el nombre del método no basta por sí solo: el servidor no debe añadir como informe nuevo una segunda petición que llegue con la misma clave de transacción; debe devolver el resultado de la aceptación previa.

La API Background Synchronization puede aplazar el trabajo a un service worker cuando vuelve la conexión; pero MDN la señala como una característica sin amplio soporte de navegadores. Por ello, la cola no debe depender solo de un evento en segundo plano; debe funcionar con seguridad también al abrir la aplicación y en la acción del usuario de “enviar ahora”.

¿Qué ocurre si el mismo registro se modifica en dos dispositivos?

Respuesta breve: no utilice el enfoque de “el último que escribe gana” en los campos de medición y conformidad; detenga el conflicto de versiones y muestre ambos cambios al usuario autorizado.

Si la versión del servidor es posterior a la versión base que recibió el dispositivo al iniciar el trabajo, la sobrescritura automática puede provocar pérdida de datos. Los campos sin conflicto pueden combinarse de forma controlada; si la misma medición, resultado o descripción crítica se ha modificado en ambos lados, el estado requiere revisión debe asignarse al registro.

• Compare la versión del servidor con la versión base del dispositivo.
• Conserve en la pista de auditoría los campos modificados y los actores.
• No sustituya silenciosamente el informe publicado por un borrador sin conexión.
• Registre la resolución del conflicto como una nueva revisión con su justificación.
• Muestre claramente al usuario en qué dispositivo hay un registro pendiente.

¿Cómo deben protegerse los datos sin conexión en el dispositivo?

Respuesta breve: descargue solo los datos imprescindibles, proteja los datos locales con el almacén seguro de la plataforma y aplique una limpieza controlada ligada al ciclo de vida del dispositivo y de la sesión.

OWASP MASVS-STORAGE-1 exige el almacenamiento seguro de los datos sensibles con independencia de su ubicación en el dispositivo. MASWE-0006 recomienda no conservar localmente datos sensibles innecesarios, proteger las claves en el almacén seguro de la plataforma y usar cifrado adecuado.

• Incluya en el paquete sin conexión solo el trabajo asignado, no todo el archivo del cliente.
• Proteja la clave de sesión, los datos personales, las fotos y los adjuntos de medición según su clase de datos.
• No guarde la clave de cifrado junto al archivo de datos ni en el código fuente.
• Pruebe los escenarios de pérdida del dispositivo, cambio de usuario y revocación de autorizaciones.
• Limpie de forma segura los adjuntos locales ya enviados conforme a la política de retención.
• No escriba registros sensibles en carpetas compartidas ni en copias de seguridad no controladas.

El trabajo sin conexión no elimina el control de autorización. Aunque el dispositivo haya recibido autorización antes, el servidor debe reverificar durante la sincronización al usuario, la organización, la orden de trabajo y la versión del formulario.

¿Qué escenarios deben probarse antes de la puesta en producción?

Respuesta breve: la prueba en modo avión no basta; debe demostrarse que el corte se produce en cada fase del registro y que el reintento no genera duplicados.

1. ¿Se abre la aplicación estando por primera vez sin conexión, o informa correctamente de la falta de preparación?
2. Si la aplicación se cierra durante el registro de un campo, ¿se conserva la última operación local completada?
3. Si la conexión se corta durante la carga de una foto, ¿se mantiene el vínculo entre el formulario y el adjunto?
4. Si el servidor acepta el registro pero la respuesta no llega al dispositivo, ¿el reenvío abre un segundo registro?
5. Cuando la versión del formulario cambia en la central, ¿cómo se resuelve el trabajo sin conexión antiguo?
6. Cuando el mismo trabajo se edita en dos dispositivos, ¿se detiene el conflicto en los campos críticos?
7. Cuando un usuario con la autorización revocada vuelve a conectarse, ¿se rechaza el envío y se conserva el registro?
8. Cuando la cola espera durante días, ¿puede el usuario entender qué registros no están en la central?

Vizyon Periyodik En la evaluación, la función sin conexión no debe probarse solo con una demo de “el formulario se abre”; deben probarse conjuntamente el commit local, la cola visible, la aceptación idempotente, la gestión de conflictos y la seguridad del dispositivo. Para otras puertas fail-closed en la selección de software, consulte la guía para elegir software de control periódico , que puede consultar.