GET /v1/reports/{id} para averiguarlo.
GET /v1/streaming/manifest describe el contrato en formato legible por máquina. Esta página cubre el lado del consumidor: qué te dice el manifiesto, qué llega por el cable y qué transporta cada evento.
La operación de manifiesto
Streaming events devuelve el catálogo estático de eventos. Requiere autenticación como cualquier otra operación. Responde con
Cache-Control: no-store, y responde independientemente de si este despliegue publica eventos o no. Léelo al arrancar para confirmar que tu consumidor y Reporter coinciden en el contrato.
La respuesta expone la identidad de la aplicación y el catálogo:
Recibir los eventos
El manifiesto indica el tema, pero no el broker. Los eventos de Reporter te llegan por el Streaming Hub, nunca por el RabbitMQ propio de Reporter. Crea una suscripción con
origin definido como reporter y las claves de evento que necesitas, como report.finished o deadline.delivery_reverted, guiones bajos incluidos. El Hub entrega cada evento al destino de webhook, de cola o de pull que elijas.
RabbitMQ lleva solo la cola interna de informes de Reporter. No lleva ningún evento de negocio.
El catálogo de eventos
Existen diecisiete definiciones de evento entre los dos modos de ejecución.
Este canal es solo de publicación. Reporter emite estos eventos y no consume ninguno de ellos.
Entrega
Todo evento del manifiesto tiene la clase
fact. Reporter envía todo evento, por el outbox de streaming durable de Mongo después del commit del estado de negocio, y un dispatcher lo reproduce tras una interrupción del broker. Nunca publica directo al broker.
La escritura del estado y la inserción en el outbox son operaciones separadas, no una única transacción atómica de aplicación. Ese hueco es una ventana de falla: una caída o una inserción fallida en el outbox después del commit del estado pierde el evento. Ninguna conciliación lo recupera. La pérdida deja solo un registro de error y una métrica. Una vez que la fila está en el outbox, el dispatcher reintenta hasta lograr la entrega.
La emisión ocurre después del commit y nunca hace fallar el trabajo. Un problema de publicación no convierte un informe almacenado en uno con error.
El envelope de CloudEvents
Los mensajes viajan en modo binario de CloudEvents, versión 1.0. Los atributos de contexto viajan como headers del mensaje. El Streaming Hub reentrega el mensaje: un consumidor de webhook lee
X-Lerian-Event-Id y X-Lerian-Tenant-Id, y un consumidor de pull lee ceId. Consulta consumir eventos. La tabla siguiente es el envelope del productor.
Reporter siempre estampa un valor de tenant.
Qué transporta un payload
Las claves del payload son
snake_case, a diferencia de la superficie REST en camelCase. Un cuerpo de report.finished:
artifact_object_key es la clave de objeto exacta que informa el almacenamiento después de la escritura, no una ruta que los consumidores deban reconstruir. Usa el valor tal cual.
Si validas su segmento de tenant, compáralo con el tenant vinculado a tu suscripción autenticada, no con otro campo del mismo mensaje. Una clave vacía en report.finished o report.partial es una violación del contrato. Descargar un informe sigue siendo la forma admitida de obtener un informe en estado Finished.
report.partial agrega section_failures y failed_section_count junto a los mismos campos de artefacto. Una clave resoluble no significa que el informe esté completo. Entrega un informe de plantilla solo desde report.finished, y una presentación regulatoria solo desde regulatory.filing_approved. Decodifica estrictamente el campo status en lugar de usar la presencia de la clave como discriminador. regulatory.filing_approved nombra el archivo aprobado en artifact_object_key y lleva artifact_sha256, artifact_size_bytes, delivery_attempt y approved_by.
document_type lleva la categoría de la plantilla. report.errored reemplaza los campos de artefacto por error_code y error_summary, y agrega document_id y document_version, que nombran el documento regulatorio cuando una suscripción generó el informe. Que le falte un campo de artefacto no demuestra que no se escribió ningún objeto: el almacenamiento puede tener éxito antes de que falle la persistencia del estado terminal, dejando un objeto que ningún evento nombra. Ambos campos de error provienen de un vocabulario fijo: report_generation_failed, report_generation_timeout, report_generation_canceled o report_worker_lost. Cada código tiene un resumen fijo. El texto de error crudo nunca viaja por el cable, de modo que un payload no puede filtrar una consulta, una cadena de conexión ni datos de tenant. Ramifica la lógica según error_code.
Habilitar la publicación de eventos
La publicación de eventos es una decisión de despliegue, que se configura con
STREAMING_ENABLED. Actívala y Reporter valida estos ajustes al arrancar:
Cuando la publicación está apagada,
STREAMING_CLOUDEVENTS_SOURCE puede quedar sin definir. Si está definido, igual debe ser exactamente reporter. Reporter rechaza cualquier otro valor no vacío al arrancar aun con la publicación apagada. Cuando la publicación está encendida, Reporter también se niega a arrancar si un ajuste obligatorio está en blanco, de modo que un despliegue mal configurado falla al arrancar en lugar de descartar eventos en silencio.
Próximos pasos
API REST de Reporter
Las 69 operaciones, la autenticación, la paginación y los errores.
Referencia de API
La operación de manifiesto de streaming, con la forma completa de su respuesta.
Variables de entorno
Cada ajuste detrás de las superficies de streaming y modo de ejecución.
¿Qué es Reporter?
Plantillas, informes, plazos y dónde encajan.