Como processar uma alteração em lote com retomada e conferência por item

O que você vai levar deste guia

• Fixe a regra e o conjunto de trabalho de forma verificável.
• Avance o progresso apenas quando o efeito correspondente estiver confirmado.
• Separe itens rejeitados de itens ainda pendentes e produza uma conferência final.

Defina o resultado antes de selecionar os registros

Uma operação em massa deve começar com a regra que será aplicada e com o motivo da mudança. “Atualizar todos os equipamentos” é amplo demais para conferir. Escreva quais equipamentos entram, qual campo muda, quais condições impedem a alteração e o que deve permanecer igual. Essa descrição permite preparar uma simulação e avaliar o impacto antes de executar. Também ajuda a reconhecer quando uma falha representa um problema do item ou um erro na própria regra.

No exemplo fictício da empresa Parque Técnico, equipamentos de uma família receberão uma nova classificação de manutenção depois de revisão interna. A operação deve alterar apenas os que ainda usam a classificação antiga e pertencem às unidades selecionadas. Equipamentos desativados ficam fora. A mudança não deve apagar histórico nem alterar a próxima visita já confirmada. Esses limites tornam o trabalho verificável e evitam que uma atualização ampla alcance registros que apenas compartilham um nome semelhante.

Crie uma identidade para a operação e registre a versão da regra. Ela será usada para relacionar seleção, tentativas e resultados. Não trate cada reinício como um novo trabalho sem vínculo, porque isso dificulta saber se um equipamento foi modificado pela execução original ou por uma repetição. A operação lógica pode ter várias tentativas, mas deve manter uma intenção reconhecível durante todo o processo.

Escolha como fixar o conjunto de trabalho

Determine se o lote processa os registros existentes no momento da solicitação ou um conjunto que continua mudando. Para uma alteração administrativa, fixar os identificadores elegíveis pode facilitar a conferência. Em outros casos, uma condição estável com marco temporal pode ser suficiente. A escolha depende do volume e das capacidades do sistema, mas precisa impedir que novos registros entrem acidentalmente ou que itens desapareçam da varredura por mudança de ordenação.

Evite usar o número da página como única evidência de progresso quando o conjunto pode mudar. Se registros são inseridos ou deixam de atender ao filtro, a próxima página pode pular itens ou repetir outros. Uma estratégia baseada em chaves estáveis, seleção materializada ou marcação explícita pode ser mais adequada. O tutorial não impõe uma implementação universal; exige que a equipe demonstre como cada item do conjunto será alcançado mesmo após interrupção.

Na Parque Técnico fictícia, a seleção registra a identidade e a versão observada dos equipamentos. Isso permite conferir no processamento se alguém alterou o item desde a preparação. A seleção não é autorização eterna para sobrescrever qualquer estado futuro. Se a condição deixou de valer, o item pode ser separado para revisão. Defina esse comportamento antes de executar, porque a operação pode levar tempo suficiente para encontrar mudanças legítimas da equipe.

Faça uma simulação com resultados classificados

Execute a regra em modo de avaliação, sem confirmar alterações, sobre o conjunto ou uma amostra apropriada conforme o risco e o volume. Mostre quantos itens seriam alterados, ignorados ou rejeitados e por quê. Inclua exemplos de cada classe. Um total geral não revela que uma unidade inteira foi selecionada por um filtro incorreto. A revisão precisa permitir que a pessoa responsável reconheça o alcance e o significado da mudança.

Separe ausência de dado de condição não atendida. Um equipamento desativado pode ser corretamente excluído; um equipamento sem identificação de família pode exigir correção. Não some ambos como “não processado”. Essa classificação ajuda a decidir se o lote pode avançar com pendências ou se a qualidade dos dados impede a execução. Registre a versão da simulação para relacioná-la à regra que será aplicada de fato.

Considere o intervalo entre simulação e execução. Se o conjunto ou a regra mudou, a aprovação operacional de uma prévia antiga pode não representar o trabalho atual. Defina quais mudanças exigem nova avaliação e como o sistema identifica essa diferença. Uma simulação útil reduz incerteza, mas não elimina a necessidade de verificar condições no momento da gravação, especialmente quando outras pessoas continuam usando o sistema.

Confirme progresso em unidades recuperáveis

Divida o processamento em partes que caibam na capacidade e no tempo de recuperação desejado. A documentação do Spring Batch apresenta processamento orientado a chunks, com leitura e escrita organizadas em unidades. A ideia útil para este caso é escolher uma unidade de confirmação e retomada; as garantias concretas dependem da implementação e dos recursos externos envolvidos. Um contador de itens lidos não substitui a confirmação do efeito.

Registre o checkpoint somente quando o trabalho correspondente estiver confirmado de forma compatível com o armazenamento. Se o progresso avança antes da alteração, uma falha pode fazer a retomada pular itens que nunca foram modificados. Se a alteração confirma e o progresso não, a retomada pode repetir o item. Essa segunda situação precisa de proteção apropriada para reconhecer o efeito anterior. Desenhe ambas as janelas e teste o comportamento, em vez de confiar na ordem aparente das linhas de código.

Escolha tamanho de parte por medição. Partes grandes podem reduzir alguma sobrecarga, mas aumentam duração de transação, memória e quantidade de trabalho a rever após falha. Partes pequenas podem facilitar retomada e aumentar custo de coordenação. Use o volume realista e observe o impacto na aplicação em uso. A operação administrativa não deve tornar o atendimento cotidiano inviável apenas porque seu trabalhador consegue consumir todos os recursos disponíveis.

Trate cada resultado sem esconder falhas sistêmicas

Defina estados por item, como pendente, confirmado, ignorado por regra e rejeitado para revisão. Registre uma razão estruturada e referências suficientes para investigar, evitando copiar todo o registro sem necessidade. Um erro de validação conhecido pode permitir continuar, mas uma falha que indica regra quebrada ou conexão indisponível pode exigir pausar o lote. Não classifique qualquer exceção como item inválido para manter o contador avançando.

No exemplo fictício, um equipamento que já recebeu a classificação nova por uma ação anterior pode ser reconhecido como sem alteração necessária. Um equipamento cuja família mudou desde a seleção exige revisão. Uma falha de banco em todos os itens seguintes indica um problema sistêmico e deve interromper tentativas em massa. Essa distinção evita produzir milhares de rejeições artificiais que depois parecem problemas de cadastro.

Defina limites de erro com significado operacional. Uma quantidade de rejeições acima do esperado pode sinalizar que a simulação não representava os dados atuais. O limite deve ser escolhido para o caso e acompanhado de uma ação, não um número universal copiado de outro projeto. Quando pausar, preserve o conjunto e os resultados já confirmados. A equipe precisa continuar de um estado conhecido, sem refazer tudo por falta de informação.

Planeje retomada, versão da regra e concorrência

Uma retomada deve carregar a mesma intenção e verificar o estado atual dos itens pendentes. Se o código da regra mudou durante a interrupção, decida se a versão original ainda pode executar ou se será necessária uma nova operação. Misturar parte dos resultados com uma regra e parte com outra sem registro dificulta a conferência. A versão não é apenas um detalhe técnico: explica por que dois itens semelhantes podem ter recebido tratamentos diferentes.

Evite que duas tentativas assumam o mesmo trabalho sem coordenação. Pode haver paralelismo por partição, mas a propriedade de cada item precisa ser clara e recuperável. Teste reinício de trabalhadores e perda de posse durante uma execução. Um trabalhador atrasado não deve confirmar efeitos depois que outro assumiu com uma visão diferente sem a proteção necessária. A estratégia exata depende do banco e da arquitetura, mas deve preservar a identidade do trabalho e a condição de alteração.

Na Parque Técnico fictícia, uma correção manual continua possível durante o lote. O processamento verifica a versão ou a condição relevante antes de aplicar a classificação, separando alterações concorrentes para revisão. A Tironi Tech pode desenvolver esse controle e a experiência de acompanhamento para que a operação em massa conviva com o uso cotidiano, sem transformar uma lista preparada no passado em uma ordem de sobrescrita incondicional.

Ofereça progresso e intervenção com significado

Mostre total selecionado, confirmado, ignorado, rejeitado e pendente, explicando quando o total ainda é estimado. Não apresente percentual baseado apenas em itens lidos. Se uma etapa posterior pode falhar, a pessoa precisa saber que o resultado ainda não foi confirmado. Exiba a última atividade e o estado do trabalhador para distinguir processamento lento de execução parada. Evite uma animação contínua como única evidência de progresso.

Permita consultar exemplos e exportar um relatório de pendências quando isso fizer parte do fluxo, respeitando as permissões dos dados. A ação de retomar deve indicar qual operação continua e qual regra será usada. A ação de corrigir itens rejeitados deve preservar o histórico anterior, sem reclassificá-los silenciosamente como se tivessem sido bem-sucedidos desde o início. O suporte precisa conseguir explicar o caminho de cada registro relevante.

Defina interrupção solicitada pela equipe e seu efeito. O lote pode parar após concluir a parte atual, mantendo os resultados confirmados. Não chame isso de reversão completa. Se existe uma operação de desfazer, ela precisa avaliar o estado atual e os efeitos posteriores, pois outros processos podem ter usado a classificação nova. Uma alteração em massa exige transparência sobre o que é recuperável, repetível e reversível.

Reconcilie o resultado e teste falhas deliberadas

Ao concluir, confira o conjunto selecionado contra os estados finais. Todo item deve ter um destino explicável, e os confirmados devem atender à regra esperada. Verifique amostras materiais e totais por unidade ou categoria, conforme o negócio. A igualdade entre contador processado e total não comprova correção se os itens errados foram selecionados ou se o efeito gravado é inadequado. A reconciliação precisa alcançar identidade e conteúdo relevante.

Teste interrupção antes e depois do checkpoint, falha em um item, falha geral, mudança concorrente e retomada com tentativa repetida. Confira que não há itens perdidos nem efeitos duplicados. Use um conjunto pequeno conhecido para validar a lógica e um volume representativo para observar capacidade. Não substitua os testes de integridade por um teste de velocidade; uma rotina rápida que pula registros não atende ao objetivo.

Encerre com o relatório da operação, versão da regra, resultados e pendências que exigem decisão. Defina retenção dos registros de execução conforme a necessidade de suporte e auditoria. O resultado desejado é uma alteração extensa que pode ser explicada por item e retomada a partir de confirmações reais. Essa organização transforma uma tarefa arriscada e opaca em um processo administrável, com limites claros para falhas, concorrência e intervenção humana.

Perguntas frequentes

Basta salvar o número da última página?

Não necessariamente. Se o conjunto muda ou a ordenação não é estável, páginas podem deslocar registros. O progresso deve usar uma identidade e uma estratégia adequadas ao conjunto processado.

Um item inválido deve parar o lote inteiro?

Depende da regra. Defina quais erros permitem separar o item e continuar, quais indicam falha sistêmica e quais exigem interromper para evitar alterações incorretas.

Posso retomar com uma versão nova da regra?

Isso precisa ser uma decisão explícita. Misturar regras na mesma execução pode produzir resultados inconsistentes; preserve a versão ou crie uma operação de correção identificada.

Execute alterações extensas com acompanhamento

A Tironi Tech pode desenvolver operações em lote com simulação, retomada e relatórios de resultado alinhados às regras do seu sistema.

Artigos relacionados

• Como cancelar uma tarefa assíncrona sem esconder efeitos que já aconteceram
• Como revisar um formulário interno para uso por teclado e correção de erros
• Como modernizar um sistema legado substituindo um módulo de cada vez

Fontes consultadas

• Spring Batch — Chunk-oriented Processing