solrfal para TYPO3: Indexación de archivos con Apache Solr

Por qué la búsqueda estándar de TYPO3 capitula ante grandes volúmenes de documentos

En cuanto una instalación TYPO3 gestiona más de unos cientos de PDF, el buscador incorporado choca con dos límites: solo encuentra contenidos almacenados en campos de base de datos, no dentro de los archivos, y su lógica de ranking ignora las señales de relevancia que los redactores necesitan. solrfal cubre exactamente ese hueco acoplando el File Abstraction Layer (FAL) de TYPO3 directamente a Apache Solr y haciendo que cada archivo, incluidos sus metadatos, sea buscable. La extensión va dirigida a organizaciones que consideran los documentos el núcleo de su trabajo con el conocimiento: administraciones con formularios, editoriales con literatura especializada, universidades con material docente.

Escenarios típicos de uso

En una universidad politécnica con cerca de 40.000 estudiantes, el reglamento académico está distribuido en 180 archivos PDF repartidos entre doce facultades. Sin solrfal, un estudiante solo encuentra el apartado sobre la matrícula de exámenes si un redactor ha copiado ese texto adicionalmente como meta descripción. Con solrfal, Apache Tika indexa cada página y la consulta devuelve el párrafo exacto con su cita.

Un segundo escenario lo conocen bien las administraciones públicas que entregan leyes, directivas y formularios a través de un CMS TYPO3. Los documentos cambian con frecuencia y los permisos de acceso están ligados a unidades organizativas. solrfal sincroniza automáticamente la pertenencia a fe_groups de los archivos dentro del índice Solr, de modo que un empleado de una subdirección solo ve los resultados para los que tiene permiso de lectura.

El tercer caso aparece en editoriales especializadas: una editorial con 12.000 artículos de revistas en PDF quiere hacer consultable su archivo mediante una búsqueda facetada por año, autor y sección. solrfal extrae los metadatos, rellena los campos Solr y proporciona la base de datos para una facetación que extensiones clásicas de TYPO3 como ke_search ya no pueden sostener a esa escala.

Arquitectura técnica sobre Apache Tika y EXT:solr

solrfal es una extensión de la extensión principal EXT:solr de dkd Internet Service y requiere obligatoriamente un servidor Apache Solr en funcionamiento, típicamente en la versión 8 o 9. La extracción de texto la realiza Apache Tika, ya sea como servicio embebido en el contenedor Solr o como servidor Tika independiente. solrfal se engancha al ciclo de vida del FAL a través de la API de eventos de TYPO3: cada archivo subido, movido o eliminado dispara un trabajo de indexación que se procesa de forma asíncrona en el scheduler de TYPO3.

La configuración de solrfal se realiza mediante TypoScript y la configuración de la extensión. El schema de Solr puede ajustarse mediante la Managed Schema API, de modo que se pueden añadir campos adicionales como tipo de documento, departamento o idioma sin reiniciar Solr. El ajuste de relevancia se realiza mediante boosting queries y function queries definidos en la configuración de consultas de EXT:solr. solrfal hereda todas las características multilingües de EXT:solr, incluidos los analizadores multilingües para castellano, catalán, inglés, alemán y otros idiomas estándar.

Problemas frecuentes y soluciones

El primer problema suele aparecer en la indexación inicial: Apache Tika aborta con un OutOfMemoryError ante PDF dañados o cifrados y arrastra consigo a todo el indexador. La extensión marca entonces el archivo como erróneo pero no lo omite automáticamente en la siguiente ejecución. Analizamos los logs de Tika, separamos los cifrados de los realmente defectuosos y configuramos un pre-check que descarta los archivos problemáticos antes de que lleguen al indexador.

El segundo tema recurrente es la relevancia. Los equipos informan de que la búsqueda encuentra todos los documentos, pero los resultados irrelevantes aparecen arriba del todo. La causa está casi siempre en la ponderación de campos por defecto: solrfal indexa todo el contenido del archivo en un único campo, sin distinguir entre título, encabezados y cuerpo de texto. Una solución limpia requiere un schema adaptado con campos separados para título, metadatos y cuerpo, así como reglas de boosting que den más peso a las coincidencias en el título.

El tercer problema afecta al rendimiento con grandes volúmenes. A partir de unos 50.000 archivos indexados, el scheduler se convierte en cuello de botella porque solrfal procesa cada trabajo individualmente. La solución es la indexación en lotes combinada con un proceso worker dedicado que corre en paralelo a las tareas normales del scheduler y prioriza los trabajos de solrfal. Además, conviene una indexación diferencial que, en cada pasada, solo reprocesa los archivos nuevos o modificados, lo que reduce considerablemente el esfuerzo de mantenimiento en fondos documentales estables.

Un cuarto asunto, menos frecuente, se da en instalaciones multilingües: solrfal indexa los archivos sin tener en cuenta el idioma en un índice común, de modo que un estudio en francés aparece en la lista de resultados en castellano cuando la palabra buscada tiene difusión internacional. Una separación limpia por idioma requiere varios cores Solr o una faceta adicional de idioma, controlable por site-root a través de la configuración de EXT:solr.

Migración y compatibilidad de versiones

solrfal sigue el ciclo de releases de EXT:solr, que actualmente soporta TYPO3 v12 y v13. El salto de TYPO3 v9 a v12 es la ruta de migración más habitual y casi siempre implica también el salto de Solr 6 a Solr 9. En el proceso cambian el formato del schema, la Managed Schema API y algunas clases analizadoras, lo que obliga a una reindexación completa. Las reglas de boosting existentes deben validarse contra el nuevo comportamiento del query parser, ya que Solr 9 evalúa ciertos operadores por defecto de forma distinta a Solr 6.

Quien migra desde ke_search o desde una búsqueda meramente basada en base de datos debe tener en cuenta que solrfal requiere un servidor Solr propio y, por tanto, amplía los requisitos de hosting. Gosign acompaña estas migraciones desde hace años y se encarga, si es necesario, también del cambio a una configuración Solr basada en contenedores que encaja en los pipelines de despliegue existentes.

Conviene además recordar que la carga de mantenimiento de solrfal no es despreciable: Solr recibe actualizaciones de seguridad periódicas y el schema debe revisarse frente a nuevas clases analizadoras en cada actualización mayor. Un proyecto que opta por solrfal asume la responsabilidad de un stack de búsqueda propio y debería calcularlo ya en el dimensionamiento inicial y en la planificación de los recursos operativos.