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 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:
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:
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.
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.
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.
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.
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:
artifact_object_key é o caminho do artefato relativo ao prefixo de armazenamento de relatórios, na forma <templateId>/<reportId>.<format>. Baixar um relatório é a via suportada para obter o arquivo, e ele serve um relatório no estado Finished. 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:
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
API REST do Reporter
As 23 operações, a autenticação, a paginação e os erros.
Referência de API
A operação de manifesto de streaming, com o formato de resposta completo.
Variáveis de ambiente
Cada configuração por trás das superfícies de streaming, exchange e modo de execução.
O que é o Reporter?
Templates, relatórios, prazos e onde eles se encaixam.