> ## 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. # Eventos do Reporter > Assine os eventos de relatório e de prazo do Reporter: a operação de manifesto de streaming, o topic lógico, o envelope CloudEvents, as políticas de entrega e o que cada payload carrega. O Reporter publica um evento de negócio sempre que um template, um relatório ou um prazo muda de estado. Se você assinar esses eventos, fica sabendo que um relatório terminou sem ficar sondando `GET /v1/reports/{id}` atrás disso. `GET /v1/streaming/events` descreve o contrato em forma legível por máquina. Esta página cobre o lado do consumidor: o que o manifesto informa, o que chega pelo fio e o que cada evento carrega. ## A operação de manifesto *** [Obter eventos de streaming](/pt/reference/reporter/get-streaming-events) retorna o catálogo estático de eventos. Ela é autenticada como qualquer outra operação, responde `Cache-Control: no-store` e é servida quer este deployment publique eventos, quer não. Leia-a na inicialização para conferir que o seu consumidor e o Reporter concordam sobre o contrato. A resposta tem quatro campos: | Campo | O que carrega | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `version` | Versão semântica do formato do manifesto. | | `publisher` | Quem publica: `serviceName` é `reporter`, `sourceBase` é `//lerian.studio/reporter`, `routePath` é esta operação, `outboxSupported` é `true`, além das versões da aplicação e da biblioteca. | | `events` | Uma entrada por definição de evento, com a chave, o tipo de recurso, o tipo de evento, a versão de esquema, a descrição e a política de entrega padrão. | | `routes` | Vazio. O Reporter não publica nenhuma topologia de broker pela API. | ## O topic é uma chave de roteamento *** Cada entrada de evento carrega um `topic`. Ele é uma **chave lógica de roteamento**: um identificador estável para um fluxo de eventos, composto a partir do source do publicador e da definição do evento. Com o source que o Reporter anuncia, `report.requested` compõe: ``` lerian.studio-reporter.report.requested ``` Essa string não é um endereço de broker. Não vincule uma fila a ela e não a trate como destino. Ela existe para que um consumidor identifique um fluxo de eventos entre transportes diferentes. Aquilo a que você de fato se vincula vive na configuração do deployment. O Reporter publica no exchange que `RABBITMQ_REPORT_EVENTS_EXCHANGE` nomeia, e a chave de roteamento de cada mensagem é a chave de definição do evento tal como está — `report.finished`, `deadline.delivery_reverted`, underscores incluídos. ## O catálogo de eventos *** Existem doze definições de evento entre os dois modos de execução. | Evento | Emitido quando | Classe | | ---------------------------- | ----------------------------------------------------------------------- | --------- | | `template.created` | Um template é enviado. | Important | | `template.updated` | O arquivo ou os metadados de um template mudam. | Important | | `template.deleted` | Um template é removido, com a contagem de prazos que caíram em cascata. | Important | | `report.requested` | Uma solicitação de relatório é aceita e enfileirada. | Important | | `report.finished` | Todas as seções de dados deram certo e o artefato está armazenado. | Critical | | `report.partial` | Algumas seções falharam. Existe um artefato. | Critical | | `report.errored` | O relatório terminou em erro. | Critical | | `deadline.created` | Um prazo é criado. | Important | | `deadline.updated` | Um prazo muda. | Important | | `deadline.deleted` | Um prazo é removido. | Important | | `deadline.delivered` | Um prazo é marcado como entregue. | Critical | | `deadline.delivery_reverted` | Uma marca de entrega é limpa. | Critical | Este canal é somente de publicação. O Reporter emite esses eventos e não consome nenhum deles. ## Entrega *** A classe na tabela acima seleciona uma política de entrega. | Classe | Publicação direta | Outbox | Dead letter | | --------- | ----------------- | ---------------------------------------- | ----------------- | | Important | Sim | Recorre ao outbox quando o circuito abre | Em falha roteável | | Critical | Não | Sempre | Em falha roteável | Um evento de classe Critical, portanto, nunca publica direto no broker. Ele cai em um outbox durável dentro da mesma transação, e um despachante o reproduz depois de uma queda do broker. Nada se perde em um reinício do broker. A emissão acontece depois do commit e nunca faz o trabalho falhar. Um problema de publicação não transforma um relatório armazenado em um relatório com erro. A entrega é pelo menos uma vez. Deduplique por `ce-id`. Os eventos de relatório são chaveados pelo identificador do relatório e pelo status terminal dele, no formato `reporter.report..`, então toda reemissão do mesmo fato carrega o mesmo identificador. Os eventos de prazo são chaveados pelo identificador do prazo, pelo tipo de evento e pelo timestamp da transição. ## O envelope CloudEvents *** As mensagens viajam em modo binário do CloudEvents, versão 1.0. Os atributos de contexto viajam como cabeçalhos da mensagem. | Cabeçalho | Valor | | ------------------ | ------------------------------------------------------------------------------- | | `ce-specversion` | `1.0` | | `ce-id` | A chave de deduplicação descrita acima | | `ce-source` | O valor de `STREAMING_CLOUDEVENTS_SOURCE` | | `ce-type` | `studio.lerian..`, por exemplo `studio.lerian.report.finished` | | `ce-time` | Timestamp de emissão em RFC 3339 | | `ce-subject` | O identificador do relatório, do template ou do prazo | | `ce-resourcetype` | `report`, `template` ou `deadline` | | `ce-eventtype` | `finished`, `created`, `delivery_reverted`, e assim por diante | | `ce-schemaversion` | `1.0.0` | | `ce-tenantid` | O tenant dono da mudança | As mensagens são marcadas como persistentes. Um deployment single-tenant também carimba um valor de tenant, então um mesmo consumidor atende as duas formas de deployment com o mesmo código. ## O que um payload carrega *** As chaves do payload são `snake_case`, ao contrário da superfície REST em camelCase. Um corpo de `report.finished`: ```json theme={null} { "report_id": "019826f4-6a9c-7b31-9d40-2f1e8c5a4b77", "template_id": "8f2c1a9e-4b30-4c02-9a1b-2d5e6f7a1c33", "output_format": "pdf", "status": "Finished", "artifact_object_key": "8f2c1a9e-4b30-4c02-9a1b-2d5e6f7a1c33/019826f4-6a9c-7b31-9d40-2f1e8c5a4b77.pdf", "artifact_content_type": "application/pdf", "completed_at": "2026-07-29T14:22:08Z", "duration_ms": 8421, "section_count": 3 } ``` `artifact_object_key` é o caminho do artefato relativo ao prefixo de armazenamento de relatórios, na forma `/.`. [Baixar um relatório](/pt/reference/reporter/download-report) é a via suportada para obter o arquivo, e ele serve um relatório no estado `Finished`. [Deployment](/pt/reporter/reporter-deployment) mostra onde esse prefixo fica dentro do bucket. `report.partial` acrescenta `section_failures` e `failed_section_count` ao lado dos mesmos campos de artefato, para que um consumidor encaminhe um relatório utilizável mas incompleto de forma diferente de um relatório limpo. `report.errored` substitui os campos de artefato por `error_code` e `error_summary`. Os dois vêm de um vocabulário fixo — `report_generation_failed`, `report_generation_timeout` ou `report_generation_canceled` —, cada um emparelhado com um resumo fixo. O texto de erro bruto nunca viaja pelo fio, então um payload não pode vazar uma consulta, uma string de conexão ou dados de tenant. Ramifique a sua lógica por `error_code`. ## Habilitar a publicação de eventos *** A publicação de eventos é uma escolha de deployment, feita com `STREAMING_ENABLED`. Ligue-a e o Reporter passa a exigir mais três configurações na inicialização: | Configuração | Valor | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `RABBITMQ_REPORT_EVENTS_EXCHANGE` | O exchange que carrega os eventos. Configurado pelo operador; o valor de referência é `reporter.events`. | | `STREAMING_BROKERS` | Precisa estar presente e não vazio. | | `STREAMING_CLOUDEVENTS_SOURCE` | Copiado tal como está para `ce-source`. Dê a cada deployment o próprio valor quando vários publicadores compartilham um broker. | O Reporter se recusa a subir quando a publicação está ligada e qualquer uma das três está em branco, então um deployment mal configurado falha na inicialização em vez de descartar eventos em silêncio. ## Próximos passos *** As 23 operações, a autenticação, a paginação e os erros. A operação de manifesto de streaming, com o formato de resposta completo. Cada configuração por trás das superfícies de streaming, exchange e modo de execução. Templates, relatórios, prazos e onde eles se encaixam.