Definir o conjunto esperado
Um batch só pode ser reconciliado quando se sabe o que era esperado para aquele ciclo. No exercício, o manifesto exige os eventos a, b e c, com 600 unidades no total. O ficheiro incorreto contém a:100, b:200 e b:300. A contagem de três linhas e a soma de 600 passam, mas só existem duas identidades distintas. O laboratório lê o CSV e calcula estes controlos; não aceita o conjunto. Antes da escrita, confirma também estrutura e tipos previstos pelo contrato. Não renomeies o segundo b para c sem evidência do produtor. Uma correção inventada pode conservar os totais e continuar a representar o evento errado.
Separar identidade, conteúdo e tentativa
O contrato local identifica um batch por origem, data de negócio e batch_id. Guarda também um digest do conteúdo associado. A primeira aplicação insere três eventos e um recibo na mesma transação; repetir a mesma identidade e intenção mantém três eventos e 600 unidades. Mudar o nome do ficheiro ou o operador não cria necessariamente outra operação de negócio. Por outro lado, a mesma etiqueta batch-7 noutra data pode identificar um ciclo diferente segundo este contrato. Regista sempre o âmbito usado. Este desenho de exercício não estabelece uma regra universal de chaves para serviços externos, cuja semântica e janela de retenção precisam de ser confirmadas.
Comparar interrupção antes e depois do commit
O laboratório cria duas bases descartáveis e termina deliberadamente um processo filho com código 17 em cada uma. Na primeira, a saída acontece depois das escritas mas antes do COMMIT; reabrir a base mostra zero eventos e zero recibos. Na segunda, a saída acontece depois do COMMIT e antes de qualquer confirmação ao chamador; reabrir mostra três eventos, 600 unidades e um recibo. O mesmo código de saída acompanha estados persistentes diferentes. A recuperação da primeira aplica o batch; a da segunda reconhece a repetição sem novo efeito. Foram testadas terminações de processos locais, não perda elétrica, falha de disco, rede ou recuperação distribuída.
Tratar conflito de intenção e falha parcial
Uma repetição com a mesma chave muda a primeira linha de 100 para 999 unidades. O código compara o conteúdo com o recibo e rejeita identity-conflict, conservando o resultado anterior. Noutro ensaio, um novo batch insere d e depois colide com a identidade a já existente. O tratamento faz rollback explícito da transação, incluindo o novo recibo e d. Ficam apenas os três eventos anteriores. O suporte não deve presumir que o prefixo persistiu nem que qualquer erro SQL desfaz automaticamente tudo. Confirma a fronteira transacional e o tratamento implementado. A repetição deve partir desse estado, com a intenção reconciliada, sem mudar identificadores apenas para passar uma restrição.
Comunicar o limite do resultado conhecido
Um recibo nesta base demonstra o efeito local definido pelo exercício. Não confirma que outro sistema recebeu, aceitou ou publicou o resultado. Numa passagem para a equipa seguinte, escreve separadamente o ciclo, o commit observado, os consumidores confirmados e os estados ainda desconhecidos. Se a janela de retenção da chave de um serviço externo terminou, não prometas que reenviar a mesma chave continua a impedir duplicação. Pede reconciliação pelo procedimento aplicável. Para uma correção após commit, avalia uma operação compensatória apropriada; ROLLBACK numa nova ligação não desfaz automaticamente a transação anterior. Mantém a decisão e o impacto no cut-off visíveis ao responsável do serviço.
Produzir um plano de recuperação verificável
Termina a oficina com um plano que outro operador autorizado consiga avaliar. Identifica origem, data, batch, conteúdo, resultado persistente, restrições de repetição e evidência de validação final. Classifica cada afirmação como observada, inferida ou ainda desconhecida. O laboratório guarda versões e hash do script; utiliza ficheiros temporários e não toca na base da aplicação dr.pt. A execução registada usou CPython 3.13.1 e SQLite 3.53.4 em Darwin. Não houve scheduler, transferência externa ou dados bancários reais. O plano criado é um exercício original e precisa de adaptação ao contrato e aos mecanismos reais antes de servir numa operação de produção.
python3 content/labs/aps-evidence/run.py
# Uses temporary SQLite databases only; no network or application database
# The recorded run used CPython 3.13.1 with SQLite 3.53.4
# Two disposable child processes deliberately exit with status 17
# One exits before COMMIT and the other after COMMIT
# Reopened state and replay outcome are checked explicitly.Um batch fictício apresenta três linhas e 600 unidades, mas só duas identidades distintas. Outro termina depois do commit sem enviar confirmação ao chamador.
Armadilhas comuns
Aceitar totais sem identidades, mudar uma chave para contornar conflito ou tratar um código de saída diferente de zero como prova de ausência de commit.
Tópicos relacionados: SQL · SFTP · Suporte L3
Reconcilia a intenção com o estado persistente. Uma repetição válida conserva identidade e parâmetros; efeitos externos exigem evidência própria.
Referência: Data Processing Pipelines · DR APS professional curriculum 2026-09; vendor-neutral operational guidance reviewed 2026-09-30