> ## 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 de Reporter > Suscríbete a los eventos de informes y plazos de Reporter: la operación de manifiesto de streaming, el topic lógico, el sobre CloudEvents, las políticas de entrega y lo que lleva cada payload. Reporter publica un evento de negocio cada vez que una plantilla, un informe o un plazo cambia de estado. Si te suscribes a esos eventos, te enteras de que un informe terminó sin sondear `GET /v1/reports/{id}` para averiguarlo. `GET /v1/streaming/events` describe el contrato en forma legible por máquina. Esta página cubre el lado del consumidor: qué te dice el manifiesto, qué llega por el cable y qué lleva cada evento. ## La operación de manifiesto *** [Obtener eventos de streaming](/es/reference/reporter/get-streaming-events) devuelve el catálogo estático de eventos. Está autenticada como cualquier otra operación, responde `Cache-Control: no-store` y se sirve tanto si este despliegue publica eventos como si no. Léela al arrancar para comprobar que tu consumidor y Reporter coinciden en el contrato. La respuesta tiene cuatro campos: | Campo | Qué lleva | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `version` | Versión semántica del formato del manifiesto. | | `publisher` | Quién publica: `serviceName` es `reporter`, `sourceBase` es `//lerian.studio/reporter`, `routePath` es esta operación, `outboxSupported` es `true`, más las versiones de la aplicación y de la biblioteca. | | `events` | Una entrada por definición de evento, con su clave, tipo de recurso, tipo de evento, versión de esquema, descripción y política de entrega por defecto. | | `routes` | Vacío. Reporter no publica ninguna topología de broker a través de la API. | ## El topic es una clave de enrutamiento *** Cada entrada de evento lleva un `topic`. Es una **clave lógica de enrutamiento**: un identificador estable para un flujo de eventos, compuesto a partir del source del publicador y de la definición del evento. Con el source que Reporter anuncia, `report.requested` se compone así: ``` lerian.studio-reporter.report.requested ``` Esa cadena no es una dirección de broker. No enlaces una cola a ella ni la trates como un destino. Existe para que un consumidor pueda identificar un flujo de eventos a través de distintos transportes. Aquello a lo que sí te enlazas vive en la configuración del despliegue. Reporter publica en el exchange que nombra `RABBITMQ_REPORT_EVENTS_EXCHANGE`, y la clave de enrutamiento de cada mensaje es la clave de definición del evento tal cual — `report.finished`, `deadline.delivery_reverted`, guiones bajos incluidos. ## El catálogo de eventos *** Existen doce definiciones de evento repartidas entre los dos modos de ejecución. | Evento | Se emite cuando | Clase | | ---------------------------- | --------------------------------------------------------------------------- | --------- | | `template.created` | Se sube una plantilla. | Important | | `template.updated` | Cambia el archivo o los metadatos de una plantilla. | Important | | `template.deleted` | Se elimina una plantilla, con el recuento de plazos que cayeron en cascada. | Important | | `report.requested` | Se acepta y se encola una solicitud de informe. | Important | | `report.finished` | Todas las secciones de datos salieron bien y el artefacto está almacenado. | Critical | | `report.partial` | Algunas secciones fallaron. Existe un artefacto. | Critical | | `report.errored` | El informe terminó con error. | Critical | | `deadline.created` | Se crea un plazo. | Important | | `deadline.updated` | Cambia un plazo. | Important | | `deadline.deleted` | Se elimina un plazo. | Important | | `deadline.delivered` | Se marca un plazo como entregado. | Critical | | `deadline.delivery_reverted` | Se borra una marca de entrega. | Critical | Este canal es solo de publicación. Reporter emite estos eventos y no consume ninguno. ## Entrega *** La clase de la tabla anterior selecciona una política de entrega. | Clase | Publicación directa | Outbox | Cola de mensajes fallidos | | --------- | ------------------- | -------------------------------------------- | ------------------------- | | Important | Sí | Recurre al outbox cuando el circuito se abre | Ante un fallo enrutable | | Critical | No | Siempre | Ante un fallo enrutable | Un evento de clase Critical, por tanto, nunca publica directamente al broker. Aterriza en un outbox duradero dentro de la misma transacción, y un despachador lo reproduce después de una caída del broker. Nada se pierde por un reinicio del broker. 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. La entrega es al menos una vez. Deduplica por `ce-id`. Los eventos de informe se identifican por el identificador del informe y su estado terminal, con la forma `reporter.report..`, así que cada reemisión del mismo hecho lleva el mismo identificador. Los eventos de plazo se identifican por el identificador del plazo, el tipo de evento y la marca de tiempo de la transición. ## El sobre CloudEvents *** Los mensajes viajan en modo binario de CloudEvents, versión 1.0. Los atributos de contexto viajan como cabeceras del mensaje. | Cabecera | Valor | | ------------------ | ------------------------------------------------------------------------------- | | `ce-specversion` | `1.0` | | `ce-id` | La clave de deduplicación descrita arriba | | `ce-source` | El valor de `STREAMING_CLOUDEVENTS_SOURCE` | | `ce-type` | `studio.lerian..`, por ejemplo `studio.lerian.report.finished` | | `ce-time` | Marca de tiempo de emisión en RFC 3339 | | `ce-subject` | El identificador del informe, la plantilla o el plazo | | `ce-resourcetype` | `report`, `template` o `deadline` | | `ce-eventtype` | `finished`, `created`, `delivery_reverted`, y así sucesivamente | | `ce-schemaversion` | `1.0.0` | | `ce-tenantid` | El tenant dueño del cambio | Los mensajes se marcan como persistentes. Un despliegue de tenant único también estampa un valor de tenant, así que un mismo consumidor atiende las dos formas de despliegue con el mismo código. ## Qué lleva un payload *** Las claves del payload son `snake_case`, a diferencia de la superficie REST en camelCase. Un cuerpo 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` es la ruta del artefacto relativa al prefijo de almacenamiento de informes, con la forma `/.`. [Descargar un informe](/es/reference/reporter/download-report) es la vía admitida para obtener el archivo, y sirve un informe en estado `Finished`. [Despliegue](/es/reporter/reporter-deployment) muestra dónde queda ese prefijo dentro del bucket. `report.partial` añade `section_failures` y `failed_section_count` junto a los mismos campos de artefacto, para que un consumidor pueda encaminar un informe utilizable pero incompleto de forma distinta a uno limpio. `report.errored` sustituye los campos de artefacto por `error_code` y `error_summary`. Ambos vienen de un vocabulario fijo — `report_generation_failed`, `report_generation_timeout` o `report_generation_canceled` —, cada uno emparejado con un resumen fijo. El texto de error en bruto nunca viaja por el cable, así que un payload no puede filtrar una consulta, una cadena de conexión ni datos de tenant. Ramifica tu 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 toma con `STREAMING_ENABLED`. Enciéndela y Reporter exige tres ajustes más al arrancar: | Ajuste | Valor | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | `RABBITMQ_REPORT_EVENTS_EXCHANGE` | El exchange que transporta los eventos. Lo configura el operador; el valor de referencia es `reporter.events`. | | `STREAMING_BROKERS` | Debe estar presente y no vacío. | | `STREAMING_CLOUDEVENTS_SOURCE` | Se copia tal cual en `ce-source`. Dale a cada despliegue su propio valor cuando varios publicadores comparten un mismo broker. | Reporter se niega a arrancar cuando la publicación está encendida y cualquiera de los tres está en blanco, así que un despliegue mal configurado falla al arrancar en lugar de perder eventos en silencio. ## Próximos pasos *** Las 23 operaciones, la autenticación, la paginación y los errores. La operación de manifiesto de streaming, con su formato de respuesta completo. Cada ajuste detrás de las superficies de streaming, exchange y modo de ejecución. Plantillas, informes, plazos y dónde encajan.