> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Como funciona a geração de relatórios > O caminho que um relatório do Reporter percorre: a requisição, a extração contra as fontes de dados configuradas, o render, o arquivo em object storage e o download. A geração de relatórios tem duas metades. O **manager** aceita a sua requisição, confere e a entrega a uma fila. O **worker** extrai os dados, renderiza o template e grava o arquivo. O Reporter responde à sua requisição assim que a primeira metade termina, então a segunda você acompanha por consulta ou por eventos. As duas metades são distribuídas em um único binário. Uma implantação roda a superfície de API, a superfície de worker ou as duas, e uma fila leva o trabalho entre elas. Esta página segue um relatório ao longo desse caminho. ## O caminho de ponta a ponta *** Você chama [Criar um relatório](/pt/reference/reporter/create-report) com um identificador de template e os filtros de linha que quer. O Reporter valida a requisição e guarda o relatório como `Processing`. O worker consulta cada fonte de dados que o template nomeia, uma seção por fonte de dados, e mantém apenas os campos do mapa de campos do template. As linhas extraídas viram o contexto do template. O Reporter renderiza o documento no formato de saída do template. O Reporter grava o arquivo renderizado no bucket de object storage configurado e registra o status terminal do relatório. Você chama [Baixar um relatório](/pt/reference/reporter/download-report) e recebe o arquivo com o tipo de conteúdo e o nome dele. ## O que o manager faz *** O manager é dono de tudo que acontece antes da fila. Ele roda quatro conferências em ordem, e qualquer uma delas pode recusar a requisição de imediato. **Ele aplica idempotência.** Envie um cabeçalho `X-Idempotency` para nomear a requisição você mesmo. Sem ele, o Reporter deriva a chave do corpo da requisição. Uma repetição de uma requisição em voo é recusada como duplicada. Uma repetição de uma requisição concluída devolve o relatório original e marca a resposta com `X-Idempotency-Replayed: true`. A janela é de 30 segundos. **Ele resolve o template.** O Reporter carrega o mapa de campos, o formato de saída e a descrição que pertencem ao identificador de template. Um identificador desconhecido falha aqui. **Ele valida os seus filtros.** Cada campo pelo qual você filtra é conferido contra o esquema ao vivo da fonte de dados dele. Um nome de campo errado faz a requisição falhar em vez de produzir um relatório vazio. **Ele registra o relatório e enfileira o trabalho.** O relatório é guardado como `Processing` e a resposta retorna de imediato com esse status. O Reporter então publica o comando de geração para o worker. O relatório guarda a própria cópia do formato de saída e da descrição do template. Esse snapshot é o que torna um relatório antigo reproduzível depois que o template segue adiante. ## O que o worker faz *** O worker consome o comando e é dono do resto do caminho. Uma fila pode entregar o mesmo comando duas vezes. Por isso o worker lê o relatório antes de começar uma execução: um relatório que já ficou em `Finished` ou `Error` é deixado como está, em vez de gerado de novo. Em seguida ele carrega o arquivo de template do object storage e extrai os dados. **Cada fonte de dados é uma seção.** Uma seção que falha não interrompe as outras. O worker reúne o resultado de cada seção e só então decide o status do relatório. Quando todas as seções falham, o Reporter registra a falha e pula o render. Nenhum arquivo enganoso chega ao bucket. O passo de render transforma as seções sobreviventes no documento. Quando o formato de saída é PDF, o Reporter renderiza HTML primeiro e converte por um pool de navegadores headless. Os bytes prontos vão para o bucket, o status terminal vai para o registro do relatório e um evento terminal vai para o fluxo de eventos. ## Estados de um relatório *** Um relatório alcança um de quatro estados. | Estado | Significado | Artefato | | ------------ | ---------------------------------------------------------------- | -------------------- | | `Processing` | Aceito e enfileirado, ou em extração | Ainda não | | `Finished` | Todas as seções devolveram dados | Pronto para download | | `Partial` | Algumas seções falharam, outras devolveram dados | Incompleto | | `Error` | Todas as seções falharam, ou a requisição nunca chegou ao worker | Nenhum | Consulte [Verificar status do relatório](/pt/reference/reporter/check-report-status) periodicamente ou consuma o evento terminal. Um relatório `Partial` carrega nos metadados dele o resultado por seção, que nomeia as fontes de dados que não responderam: corrija essas fontes de dados e gere o relatório de novo. [Baixar um relatório](/pt/reference/reporter/download-report) serve o artefato quando o relatório está em `Finished`. ## Limites de tempo no caminho *** Cada etapa carrega o próprio limite, e um operador os define por implantação. | Limite | Valor padrão | Aplica-se a | | -------------------------------- | ------------ | -------------------------------------------- | | Janela de idempotência | 30 segundos | A detecção de repetição na requisição | | Tempo limite de extração | 300 segundos | Uma execução de extração | | Concorrência de extração | 4 | Consultas em paralelo dentro de uma execução | | Tempo limite de conversão em PDF | 90 segundos | Uma conversão de HTML para PDF | | Pool de workers de PDF | 2 | Conversões simultâneas por worker | Limites de volume delimitam a mesma execução: 10 fontes de dados, 50 tabelas por fonte de dados, 200 campos por tabela e 100 MiB de resultado extraído. Veja [Variáveis de ambiente](/pt/reporter/reporter-environment-variables) para os ajustes por trás de cada um. ## Onde os prazos entram *** Um prazo é uma data de vencimento com uma regra de recorrência, e ele pode nomear o template que o cumpre. Ele fica ao lado do caminho de geração, não sobre ele. Um prazo nunca inicia um relatório. Você gera o relatório pelo caminho de requisição acima e depois marca o prazo como entregue. O Reporter recalcula um prazo na leitura. Uma obrigação recorrente que carrega marca de entrega avança para a próxima data de vencimento na primeira leitura depois de a data atual passar, e esse avanço limpa a marca. A operação de notificações devolve os prazos que estão dentro da janela de alerta deles quando você a chama. Veja [Gerenciando prazos](/pt/reporter/managing-deadlines). ## Armazenamento e download *** Os arquivos renderizados vivem em um único bucket compatível com S3, sob o prefixo `reports/`. O Reporter guarda cada arquivo sob o identificador do template e o nomeia conforme o relatório, então os arquivos ficam agrupados pelo template que os produziu. O download devolve os bytes com o tipo de conteúdo do formato de saída e um nome de arquivo construído a partir do identificador do relatório. O download funciona depois que o template é excluído, porque o relatório carrega o próprio snapshot de formato. Um relatório é criado uma vez e depois retido. Os filtros dele, o status dele e o arquivo dele descrevem exatamente a requisição que os produziu, que é o que faz de um relatório antigo a evidência do que você reportou na época. O Reporter mantém os arquivos renderizados no bucket. Defina a retenção com uma política de ciclo de vida no próprio bucket. ## Próximos passos *** O mapa de campos, o contexto de dados e as duas espécies de filtro. Envie um template, gere um relatório e baixe o resultado. Acompanhe uma obrigação regulatória e marque-a como entregue. Um binário, duas superfícies e os armazenamentos que elas compartilham.