Como registar com segurança o controlo periódico sem internet?

Resposta breve: como manter o registo de controlo sem internet?

Guarde o formulário de controlo numa base de dados local transacional no dispositivo; dê a cada registo uma identidade de transação única, mantenha visível o estado de envio e, quando a ligação regressar, reconcilie com o servidor sem produzir duplicações.

No trabalho offline, “guardado” não é um único estado. Ao utilizador devem ser apresentados separadamente os estados guardado no dispositivo, a aguardar envio, aceite pelo servidor e requer revisão . Assim, com ligação fraca, o facto de o formulário aparecer no ecrã não leva a supor que chegou ao centro.

Que dados devem ser levados para o dispositivo antes de sair para o campo?

Resposta breve: apenas o pacote de dados atual e autorizado necessário para concluir o trabalho atribuído.

• Ordem de trabalho e identidade imutável do equipamento
• Versão fixada do formulário de controlo associado ao tipo de equipamento
• Critérios de controlo necessários e listas de seleção
• Âmbito de tarefa e referências de dispositivo do pessoal atribuído
• Hora da última sincronização e versão do pacote

A especificação W3C Service Workers explica que é possível construir aplicações web offline com um worker que interceta pedidos e um repositório local de pedidos/respostas. A contrapartida no fluxo de trabalho da VizyonTech não é apenas colocar a estrutura da página em cache, mas preparar, validada antes do campo, um pacote com os formulários e dados de referência do trabalho atribuído.

Se o pacote não estiver atualizado, a aplicação não deve abrir silenciosamente o formulário antigo. A hora da última sincronização, a versão do formulário e o limite de utilização sem ligação à Internet devem estar visíveis; se faltarem dados mestres críticos, o sistema deve bloquear a criação do registo (fail-closed). A relação entre a ordem de trabalho, o equipamento e o formulário é explicada no guia do plano de controlos periódicos , que pode consultar.

Como deve ser guardado o formulário no dispositivo?

Resposta breve: escreva cada alteração de campo não numa memória temporária de ecrã, mas numa transação local curta e atómica.

O projeto W3C IndexedDB 3.0 define, para requisitos web offline, a conservação local de objetos estruturados e transações que são escritas na totalidade ou revertidas em caso de erro. No formulário de campo, isto significa escrever o valor de medição, unidade, descrição, ligação a fotografia e hora de registo numa versão de rascunho consistente.

O botão guardar só deve mostrar sucesso quando a transação local estiver concluída. O fecho da aplicação, o esgotar da bateria ou o regresso momentâneo da rede não devem levar um formulário incompleto ao estado “enviado”.

Como deve ser feita a sincronização quando a ligação regressa?

Resposta breve: envie a fila por ordem, repita cada elemento com a mesma identidade de transação e marque como concluído apenas após a resposta de aceitação explícita do servidor.

1. Verifique não apenas a existência da ligação, mas o acesso ao servidor de aplicações.
2. Reverifique a integridade local do registo na fila e os campos obrigatórios.
3. Envie o registo e os anexos com identidade de transação imutável e versão local.
4. Execute no servidor os controlos de autorização, ordem de trabalho, versão de formulário e versão atual do registo.
5. Na aceitação bem-sucedida, escreva no dispositivo a identidade do registo no servidor e a hora de aceitação.
6. Separe o erro transitório para nova tentativa controlada e o erro permanente de validação para revisão humana.

O RFC 9110 explica que um pedido idempotente pode ser repetido após uma falha de ligação com o mesmo efeito pretendido. No registo de controlo periódico, o nome do método não é suficiente por si só: o servidor não deve acrescentar como novo relatório um segundo pedido com a mesma chave de transação; deve devolver o resultado da aceitação anterior.

A Background Synchronization API pode adiar o trabalho para um service worker quando a ligação regressa; contudo, a MDN assinala-a como uma funcionalidade sem amplo suporte de navegadores. Por isso, a fila não deve depender apenas do evento em segundo plano; deve funcionar com segurança também na abertura da aplicação e na ação “enviar agora” do utilizador.

O que acontece se o mesmo registo for alterado em dois dispositivos?

Resposta breve: não utilize a abordagem de “o último a escrever ganha” nos campos de medição e conformidade; pare o conflito de versões e mostre as duas alterações ao utilizador autorizado.

Se a versão no servidor estiver à frente da versão base que o dispositivo recebeu ao iniciar o trabalho, a sobreposição automática pode causar perda de dados. Os campos sem conflito podem ser fundidos de forma controlada; se a mesma medição, resultado ou descrição crítica mudou em ambos os lados, o estado requer revisão deve ser atribuído ao registo.

• Compare a versão do servidor com a versão base do dispositivo.
• Preserve no rasto de operações os campos alterados e os autores.
• Não substitua silenciosamente o relatório publicado por um rascunho offline.
• Registe a resolução do conflito como nova revisão com justificação.
• Mostre claramente ao utilizador em que dispositivo está o registo pendente.

Como proteger os dados offline no dispositivo?

Resposta breve: descarregue apenas os dados necessários, proteja os dados locais com o armazenamento seguro da plataforma e aplique uma limpeza controlada ligada ao ciclo de vida do dispositivo/sessão.

A OWASP MASVS-STORAGE-1 exige o armazenamento seguro de dados sensíveis independentemente da sua localização no dispositivo. A MASWE-0006 recomenda não manter localmente dados sensíveis desnecessários, proteger as chaves no cofre de chaves seguro da plataforma e usar encriptação adequada.

• Leve para o pacote offline apenas o trabalho atribuído, não todo o arquivo do cliente.
• Proteja a chave de sessão, os dados pessoais, fotografias e anexos de medição conforme a classe de dados.
• Não guarde a chave de encriptação junto ao ficheiro de dados nem no código fonte.
• Teste os cenários de perda do dispositivo, mudança de utilizador e revogação de autorização.
• Limpe de forma segura os anexos locais enviados, segundo a política de retenção.
• Não escreva registos sensíveis em áreas de ficheiro partilhadas ou cópias de segurança não controladas.

O trabalho offline não elimina o controlo de autorização. Mesmo que o dispositivo tenha sido previamente autorizado, o servidor deve reverificar, durante a sincronização, o utilizador, a organização, a ordem de trabalho e a versão do formulário.

Que cenários devem ser testados antes da publicação?

Resposta breve: o teste em modo de voo não chega; deve demonstrar-se que a interrupção ocorre em cada fase do registo e que a nova tentativa não produz duplicações.

1. A aplicação abre pela primeira vez em modo offline, ou reporta corretamente a falta de preparação?
2. Se a aplicação fechar durante o preenchimento de um campo, a última transação local concluída é preservada?
3. Se a ligação falhar durante o carregamento de uma fotografia, a ligação entre formulário e anexo parte-se?
4. Se o servidor aceitar o registo mas a resposta não chegar ao dispositivo, o reenvio abre um segundo registo?
5. Quando a versão do formulário muda no centro, como é resolvido o trabalho offline antigo?
6. Quando o mesmo trabalho é editado em dois dispositivos, o conflito de campos críticos para?
7. Quando um utilizador com autorização revogada volta a ligar-se, o envio é recusado e o registo preservado?
8. Quando a fila espera durante dias, o utilizador consegue perceber que registos não estão no centro?

Vizyon Periyodik na avaliação, a funcionalidade offline deve ser testada não apenas com a demonstração de “o formulário abre”, mas em conjunto: commit local, fila visível, aceitação idempotente, gestão de conflitos e segurança do dispositivo. Para outras barreiras fail-closed na seleção de software, consulte o guia de escolha de software de controlos periódicos , que pode consultar.