Saltar al contenido principal
Reporter tiene 17 definiciones de eventos de negocio emitidos. Son mensajes CloudEvents 1.0 en modo binario. Recibes todos los eventos por una suscripción del Streaming Hub. Reporter no publica ningún evento de negocio en RabbitMQ, que lleva solo su cola interna de informes. Cuando el streaming está desactivado, Reporter no publica eventos.

Envelope y enrutamiento

Todos los eventos usan ce-source reporter y un ce-type calificado por fuente con la forma studio.lerian.reporter.<resource>.<event>. El payload es JSON con claves en snake_case. Usa el envelope compartido para el contrato completo de encabezados de CloudEvents. Estos encabezados ce-* describen lo que Reporter publica. El Hub reentrega cada evento con encabezados propios; consulta consumir eventos.

Semántica de entrega

Reporter emite después de confirmar el cambio de estado de negocio. Los errores de publicación no hacen fallar la operación subyacente.
  • Reporter persiste todo evento en el outbox duradero para su despacho y reintento. Nunca publica directamente.
  • La entrega del broker es al menos una vez. Los consumidores deben ser idempotentes y deduplicar según el id de evento del Hub (X-Lerian-Event-Id en webhook, ceId en pull).

Catálogo de eventos emitidos

Una presentación regulatoria emite regulatory.draft_ready en lugar de report.finished. Una ejecución de presentación que falla emite report.errored.

Identificadores de eventos

Reporter define un ce-id determinista en estos eventos. Los consumidores leen el ce-id del evento y nunca lo reconstruyen. Los ids UUIDv7 de abajo empiezan en Reporter 4.10.0; las versiones anteriores emiten un identificador aleatorio en los eventos de plantilla, en report.requested y en los eventos de creación, actualización y eliminación de plazos, y reporter.report.<status>.<report_id> y <report_id>:draft:<n>, y en los seis eventos de plazo y regulatorios reporter.deadline.<event>.<deadline_id>.<time>, <report_id>:approved y <document_id>:<adopted_version>:<tenant_id>. Todas las variantes de report.errored usan el mismo ce-id. Por eso, un consumidor que deduplica según el id del evento conserva solo el primer report.errored recibido para un report_id.

Contratos data completos

Estas declaraciones al estilo TypeScript reflejan la forma del JSON en el wire. ? indica que la propiedad es opcional. | null indica que la propiedad está presente pero puede ser null en JSON.
document_type lleva la categoría de la plantilla. Contiene un string vacío en la variante de fallo del worker que no lleva template_id. Trata un valor vacío como ausencia de categoría. document_id y document_version en report.errored nombran el documento regulatorio cuando una suscripción generó el informe, y son strings vacíos en los demás casos. artifact_object_key en report.finished, report.partial y regulatory.filing_approved es la clave de almacenamiento del archivo exactamente como Reporter la escribió, y nunca está vacía. Úsala tal cual. No la reconstruyas a partir de otros campos. En regulatory.filing_approved, verifica el objeto almacenado contra artifact_sha256 antes de enviarlo. parameters lleva los parámetros de generación sin los que empiezan con system.. binding_gaps_count en regulatory.version_adopted cuenta los campos de la versión adoptada que el mapeo existente deja sin asignar. El campo mapping_broken es true cuando Reporter no pudo evaluar el mapeo existente contra la versión adoptada. En ese caso, binding_gaps_count es 0.

Riel interno de comandos separado

Manager envía a worker un comando JSON que no es CloudEvents por RabbitMQ. Usa RABBITMQ_EXCHANGE, RABBITMQ_GENERATE_REPORT_KEY y RABBITMQ_GENERATE_REPORT_QUEUE, con entrega persistente. Este comando no forma parte del catálogo público de eventos, y su forma no es un contrato público.

Estado de eventos entrantes

Reporter no consume ningún evento de negocio público. Su suscriptor de Hub no está disponible: habilitarlo se rechaza al iniciar.