O caminho de ponta a ponta
1
Requisição
Você chama Criar um relatório com um identificador de template e os filtros de linha que quiser. O Reporter valida a requisição e armazena o relatório como
Processing.2
Extração
O worker consulta cada fonte de dados que o template nomeia, uma seção por fonte de dados, e mantém apenas os campos no mapa de campos do template.
3
Renderização
As linhas extraídas se tornam o contexto do template. O Reporter renderiza o documento no formato de saída do template.
4
Armazenamento
O Reporter grava o arquivo renderizado no bucket de armazenamento de objetos configurado e registra o status final do relatório.
5
Download
Você chama Baixar um relatório e recebe o arquivo com o tipo de conteúdo e o nome dele.
O que o manager faz
O manager é responsável por tudo o que acontece antes da fila. Ele executa quatro verificações em ordem, e qualquer uma delas pode rejeitar a requisição imediatamente. Ele aplica idempotência. Envie um header
X-Idempotency para nomear a requisição você mesmo. Sem um, o Reporter deriva a chave a partir do corpo da requisição. O Reporter rejeita a repetição de uma requisição em andamento como duplicata. A repetição de uma requisição concluída retorna 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 do template. Um identificador desconhecido falha aqui.
Ele valida os seus filtros. Cada campo em que você filtra é verificado contra o schema ativo da fonte de dados dele. Um nome de campo incorreto faz a requisição falhar em vez de gerar um relatório vazio.
Ele registra o relatório e enfileira o trabalho. O relatório é armazenado como Processing e a resposta retorna imediatamente com esse status. O Reporter então publica o comando de geração para o worker.
O relatório mantém sua 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 muda.
O que o worker faz
O worker consome o comando e é responsável pelo restante do caminho. Uma fila pode entregar o mesmo comando duas vezes. Por isso, o worker lê o relatório antes de iniciar uma execução: um relatório que já se consolidou como
Finished ou Error é deixado como está, em vez de ser gerado novamente.
Em seguida, ele carrega o arquivo de template do armazenamento de objetos 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 apenas então decide o status do relatório.
Quando todas as seções falham, o Reporter registra a falha e pula a renderização. Nenhum arquivo enganoso chega ao bucket.
A etapa de renderização transforma as seções que restaram no documento. Quando o formato de saída é PDF, o Reporter renderiza HTML primeiro e o converte por meio de um pool de navegadores headless. Os bytes finalizados vão para o bucket, o status final vai para o registro do relatório, e um evento final vai para o event stream.
Estados do relatório
Um relatório atinge um de quatro estados.
Faça polling em Verificar status do relatório ou consuma o evento final. Um relatório
Partial carrega um resultado por seção nos seus metadados, que nomeia as fontes de dados que não responderam: corrija essas fontes de dados e gere o relatório novamente. Baixar um relatório entrega o artefato assim que o relatório está Finished.
Limites de tempo no caminho
Cada etapa carrega seu próprio limite, e um operador os define por deploy.
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 para as configurações por trás de cada um.
Onde os prazos se encaixam
Um prazo é uma data de vencimento com uma regra de recorrência, e pode nomear o template que o satisfaz. Ele fica ao lado do caminho de geração, e 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 uma marca de entrega avança para sua próxima data de vencimento na primeira leitura depois que a data atual passa, e esse avanço limpa a marca. A operação de notificações retorna os prazos dentro da janela de alerta deles quando você os solicita. Veja Gerenciando prazos.
Armazenamento e download
Os arquivos renderizados vivem em um bucket compatível com S3, sob o prefixo
reports/. O Reporter armazena cada arquivo sob o identificador do template e o nomeia a partir do relatório, então os arquivos ficam agrupados pelo template que os produziu.
O download retorna 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 mantém seu 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.
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
Motor de templates do Reporter
O mapa de campos, o contexto de dados e os dois tipos de filtro.
Usando o Reporter
Faça upload de um template, gere um relatório e baixe o resultado.
Gerenciando prazos
Acompanhe uma obrigação regulatória e marque-a como entregue.
Arquitetura do Reporter
Um binário, duas superfícies e os armazenamentos que elas compartilham.