> ## 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. # Cómo funciona la generación de informes > El camino que recorre un informe de Reporter: la solicitud, la extracción contra las fuentes de datos configuradas, el renderizado, el archivo en almacenamiento de objetos y la descarga. La generación de informes tiene dos mitades. El **manager** acepta tu solicitud, la revisa y la entrega a una cola. El **worker** extrae los datos, renderiza la plantilla y escribe el archivo. Reporter responde a tu solicitud en cuanto termina la primera mitad, así que la segunda la sigues por sondeo o por eventos. Las dos mitades se distribuyen en un solo binario. Un despliegue corre la superficie de API, la superficie de worker o ambas, y una cola lleva el trabajo entre ellas. Esta página sigue un informe a lo largo de ese camino. ## El camino de punta a punta *** Llamas a [Crear un informe](/es/reference/reporter/create-report) con un identificador de plantilla y los filtros de fila que quieres. Reporter valida la solicitud y guarda el informe como `Processing`. El worker consulta cada fuente de datos que nombra la plantilla, una sección por fuente de datos, y conserva solo los campos del mapa de campos de la plantilla. Las filas extraídas se vuelven el contexto de la plantilla. Reporter renderiza el documento en el formato de salida de la plantilla. Reporter escribe el archivo renderizado en el bucket de almacenamiento de objetos configurado y registra el estado terminal del informe. Llamas a [Descargar un informe](/es/reference/reporter/download-report) y recibes el archivo con su tipo de contenido y su nombre. ## Qué hace el manager *** El manager es dueño de todo lo que ocurre antes de la cola. Corre cuatro revisiones en orden, y cualquiera de ellas puede rechazar la solicitud de plano. **Aplica la idempotencia.** Envía una cabecera `X-Idempotency` para nombrar tú mismo la solicitud. Sin ella, Reporter deriva la clave del cuerpo de la solicitud. Una repetición de una solicitud en vuelo se rechaza como duplicada. Una repetición de una solicitud completada devuelve el informe original y marca la respuesta con `X-Idempotency-Replayed: true`. La ventana es de 30 segundos. **Resuelve la plantilla.** Reporter carga el mapa de campos, el formato de salida y la descripción que pertenecen al identificador de plantilla. Un identificador desconocido falla aquí. **Valida tus filtros.** Cada campo por el que filtras se contrasta con el esquema en vivo de su fuente de datos. Un nombre de campo equivocado hace fallar la solicitud en lugar de producir un informe vacío. **Registra el informe y encola el trabajo.** El informe se guarda como `Processing` y la respuesta vuelve de inmediato con ese estado. Reporter publica entonces el comando de generación para el worker. El informe conserva su propia copia del formato de salida y de la descripción de la plantilla. Ese snapshot es lo que hace reproducible un informe viejo después de que la plantilla siga su camino. ## Qué hace el worker *** El worker consume el comando y es dueño del resto del camino. Una cola puede entregar el mismo comando dos veces. Por eso el worker lee el informe antes de empezar una ejecución: un informe que ya quedó en `Finished` o `Error` se deja como está, en lugar de generarse de nuevo. Después carga el archivo de plantilla desde el almacenamiento de objetos y extrae los datos. **Cada fuente de datos es una sección.** Una sección que falla no detiene a las demás. El worker reúne el resultado de cada sección y solo entonces decide el estado del informe. Cuando todas las secciones fallan, Reporter registra el fallo y se salta el renderizado. Ningún archivo engañoso llega al bucket. El paso de renderizado convierte las secciones sobrevivientes en el documento. Cuando el formato de salida es PDF, Reporter renderiza primero HTML y lo convierte a través de un pool de navegadores headless. Los bytes terminados van al bucket, el estado terminal va al registro del informe y un evento terminal va al flujo de eventos. ## Estados de un informe *** Un informe alcanza uno de cuatro estados. | Estado | Significado | Artefacto | | ------------ | ------------------------------------------------------------------ | -------------------- | | `Processing` | Aceptado y encolado, o en extracción | Todavía no | | `Finished` | Cada sección devolvió datos | Listo para descargar | | `Partial` | Algunas secciones fallaron, otras devolvieron datos | Incompleto | | `Error` | Todas las secciones fallaron, o la solicitud nunca llegó al worker | Ninguno | Consulta [Verificar estado del informe](/es/reference/reporter/check-report-status) de forma periódica o consume el evento terminal. Un informe `Partial` lleva en sus metadatos el resultado por sección, que nombra las fuentes de datos que no respondieron: corrige esas fuentes de datos y genera el informe de nuevo. [Descargar un informe](/es/reference/reporter/download-report) sirve el artefacto una vez que el informe está en `Finished`. ## Límites de tiempo en el camino *** Cada etapa lleva su propio límite, y un operador los fija por despliegue. | Límite | Valor por defecto | Se aplica a | | --------------------------------- | ----------------- | --------------------------------------------- | | Ventana de idempotencia | 30 segundos | La detección de repeticiones en la solicitud | | Tiempo límite de extracción | 300 segundos | Una ejecución de extracción | | Concurrencia de extracción | 4 | Consultas en paralelo dentro de una ejecución | | Tiempo límite de conversión a PDF | 90 segundos | Una conversión de HTML a PDF | | Pool de workers de PDF | 2 | Conversiones simultáneas por worker | Los límites de volumen acotan la misma ejecución: 10 fuentes de datos, 50 tablas por fuente de datos, 200 campos por tabla y 100 MiB de resultado extraído. Consulta [Variables de entorno](/es/reporter/reporter-environment-variables) para los ajustes detrás de cada uno. ## Dónde encajan los plazos *** Un plazo es una fecha de vencimiento con una regla de recurrencia, y puede nombrar la plantilla que lo satisface. Está al lado del camino de generación, no sobre él. Un plazo nunca arranca un informe. Generas el informe por el camino de solicitud de arriba y después marcas el plazo como entregado. Reporter recalcula un plazo al leerlo. Una obligación recurrente que lleva marca de entrega avanza a su siguiente fecha de vencimiento en la primera lectura posterior a la fecha actual, y ese avance limpia la marca. La operación de notificaciones devuelve los plazos que están dentro de su ventana de alerta cuando se la pides. Consulta [Gestión de plazos](/es/reporter/managing-deadlines). ## Almacenamiento y descarga *** Los archivos renderizados viven en un único bucket compatible con S3, bajo el prefijo `reports/`. Reporter guarda cada archivo bajo el identificador de la plantilla y lo nombra según el informe, así que los archivos quedan agrupados por la plantilla que los produjo. La descarga devuelve los bytes con el tipo de contenido del formato de salida y un nombre de archivo construido a partir del identificador del informe. La descarga funciona después de eliminar la plantilla, porque el informe lleva su propio snapshot del formato. Un informe se crea una vez y después se conserva. Sus filtros, su estado y su archivo describen exactamente la solicitud que los produjo, que es lo que hace de un informe viejo la evidencia de lo que reportaste en su momento. Reporter mantiene los archivos renderizados en el bucket. Define la retención con una política de ciclo de vida sobre el bucket mismo. ## Próximos pasos *** El mapa de campos, el contexto de datos y las dos clases de filtro. Sube una plantilla, genera un informe y descarga el resultado. Sigue una obligación regulatoria y márcala como entregada. Un binario, dos superficies y los almacenes que comparten.