Problemas comunes de IBM FileNet y cómo resolverlos

Respuesta corta: la mayoría de las fallas de IBM FileNet no están en FileNet mismo, sino en algo de lo que depende: el directorio de usuarios (LDAP), los certificados, la base de datos, el almacenamiento o el índice de búsqueda. Antes de reiniciar servidores conviene confirmar que el Content Platform Engine responde, leer su log de errores y ubicar en qué pieza está el problema. Esta guía recorre los siete problemas que más vemos en terreno y qué revisar en cada uno.

Antes de tocar nada: tres revisiones de cinco minutos

1. ¿El Content Platform Engine está arriba? La página de ping del motor (en la ruta /FileNet/Engine del servidor) muestra si responde y qué versión corre. Si no carga, el problema está en el servidor de aplicaciones o en la red, no en los documentos.
2. ¿Qué dice el log de errores? El archivo p8_server_error.log del Content Platform Engine suele decir exactamente qué falló: una conexión a la base de datos, un usuario que no se encuentra en el directorio o un área de almacenamiento sin espacio. Leerlo ahorra horas de prueba y error.
3. ¿Le pasa a todos o a algunos? Si falla para todos los usuarios, apunta a la infraestructura (directorio, certificados, base de datos). Si le pasa a una persona o a un grupo, apunta casi siempre a permisos.

1. Content Navigator no conecta con el repositorio

Síntoma: IBM Content Navigator carga, pero al abrir el repositorio aparece un error de conexión o la sesión se corta.

Qué revisar:

• Que la dirección de conexión al Content Platform Engine configurada en el escritorio de Navigator siga siendo la correcta, sobre todo después de una migración o un cambio de servidor.
• Certificados SSL vencidos entre Navigator y el motor. Es de las causas más frecuentes y la más fácil de prevenir con un calendario de vencimientos.
• Que el servicio del motor esté arriba (la página de ping del punto anterior).

2. Nadie puede iniciar sesión

Síntoma: todos los usuarios reciben un error de credenciales, aunque estén bien escritas.

Qué revisar:

• La cuenta de servicio que FileNet usa para consultar el directorio (LDAP o Active Directory): si su contraseña venció o se cambió, nadie entra.
• El certificado del directorio, cuando la conexión es segura (LDAPS) y el certificado se renovó del lado de Active Directory.
• Tiempos de espera hacia el directorio cuando hay problemas de red o un controlador de dominio caído.

3. Un usuario no ve documentos que debería ver

Síntoma: a una persona le aparece la carpeta vacía o un error de acceso, mientras sus compañeros ven todo.

Qué revisar:

• La seguridad del documento o de la carpeta (sus listas de control de acceso) y si hereda permisos de donde corresponde.
• El grupo del directorio: si la persona cambió de área, puede que su grupo no se haya actualizado o que FileNet aún tenga en caché la membresía anterior.
• Políticas de seguridad o marcas de seguridad aplicadas a ciertos tipos de documento.

La consola de administración (Administration Console for Content Platform Engine) permite ver los permisos efectivos de un usuario sobre un documento puntual, que es la forma más rápida de salir de dudas.

4. Las búsquedas son lentas o no encuentran nada

Síntoma: buscar por una propiedad tarda minutos, o la búsqueda por texto no encuentra documentos que sí existen.

Qué revisar:

• Índices de la base de datos en las propiedades por las que más se busca. Una propiedad muy consultada sin índice obliga a recorrer tablas completas.
• El índice de texto completo (IBM Content Search Services): si está detenido o atrasado, los documentos nuevos no aparecen en las búsquedas por contenido aunque sí estén guardados.
• Búsquedas guardadas demasiado amplias, sin filtros de fecha o de clase de documento.

5. Error al subir o guardar documentos

Síntoma: al agregar un documento o una versión nueva aparece un error, aunque ayer funcionaba.

Qué revisar:

• Espacio en el área de almacenamiento, ya sea un disco, un NAS o un almacenamiento de objetos. Es la causa más común y suele avisar con tiempo si alguien monitorea.
• Permisos de escritura de la cuenta del servidor sobre esa ruta, que pueden cambiar tras una mantención de la infraestructura.
• Espacio en la base de datos (tablespaces o archivos de datos llenos).

6. Workflows detenidos

Síntoma: las tareas no avanzan, las bandejas de trabajo quedan pegadas o los casos no cambian de estado.

Qué revisar:

• Que el motor de procesos y sus conexiones estén arriba.
• Ítems con excepción en las colas del sistema de workflow: un paso que falló (por ejemplo, una llamada a otro sistema) deja el ítem detenido hasta que alguien lo corrige y lo reintenta.
• Cambios recientes en la definición del flujo que no se transfirieron correctamente.

7. Todo anda lento

Síntoma: FileNet responde, pero cada acción tarda más de lo normal, sobre todo en horas punta.

Qué revisar:

• Memoria del servidor de aplicaciones (la máquina virtual de Java) y su recolección de basura.
• El pool de conexiones a la base de datos, que puede quedarse corto cuando crece el número de usuarios o de integraciones.
• Trazas de diagnóstico activadas y olvidadas. Encender el registro detallado para investigar un problema y no apagarlo después es una causa clásica de lentitud.

Lo que evita la mayoría de estos problemas

• Calendario de vencimientos: certificados SSL, certificados del directorio y contraseñas de cuentas de servicio.
• Monitoreo de espacio: almacenamiento, base de datos y logs, con alertas antes de llegar al límite.
• Versiones con soporte vigente: IBM publica fechas de fin de soporte para cada versión; operar fuera de ellas complica cualquier caso con IBM.
• Un respaldo probado: no basta con que exista; hay que restaurarlo de prueba al menos una vez al año.
• Documentación de la instalación: servidores, cuentas, rutas y configuraciones. Cuando la persona que lo instaló ya no está, esto vale oro.

Cuándo pedir ayuda

Si el problema afecta a todos los usuarios, involucra datos que podrían perderse o requiere tocar la base de datos directamente, conviene escalar antes de improvisar. En Atuz damos soporte a plataformas IBM de gestión documental (FileNet, Content Manager OnDemand y Content Manager Enterprise) con especialistas certificados, desde la resolución de incidentes hasta migraciones y mantención preventiva.