Gestión de portales web: mi experiencia en el INAP

Toda organización necesita utilizar alguna solución para gestionar sus portales web. Aunque las necesidades concretas dependen de cada organización, entre los requisitos suelen encontrarse, entre otros:

  • Gestión de usuarios y roles.
  • Creación y edición de contenidos HTML.
  • Disponibilidad de un editor gráfico.
  • Posibilidad de definir flujos de publicación y validación de contenidos.
  • Facilidad a la hora de definir los permisos de los diferentes portales y páginas.

En el INAP se lanzó hace unos años un proyecto para redefinir de manera integral la manera en que el organismo gestiona su información al exterior. Este proyecto abarcó la definición del modelo organizativo y los flujos de trabajo, así como el despliegue de una infraestructura técnica que lo soportara.

Modelo organizativo

A la hora de definir el flujo de trabajo es necesario conciliar las necesidades de todas las partes implicadas. Por un lado, el proceso debe ser lo suficientemente ágil para no desincentivar la publicación de contenidos en los portales. En este sentido, el establecimiento de un modelo descentralizado para la gestión de contenidos tiene indudables ventajas frente al modelo centralizado tradicional, en el que una única unidad se encarga de todos los contenidos web de la organización. El hecho de que la propia unidad responsable de unos trámites o funciones redacte los contenidos web que los describen conlleva un mayor valor práctico a los contenidos.

Por otro lado, se deben respetar una serie de limitaciones para asegurar la accesibilidad de los portales y la consistencia en la imagen corporativa de la organización.

De este modo, en el INAP se optó por un modelo distribuído con validación de los contenidos por parte de un grupo de trabajo constituído a tal efecto (Webmaster).

Para definir el esquema de trabajo se establecieron Comunidades y Organizaciones. Una comunidad es un portal web, como la página web o la sede del INAP. Una organización es un conjunto de usuarios que trabaja en tareas similares. Suele representar a departamentos de la organización.

En cuanto a los usuarios, se definieron dos perfiles básicos. Un editor de contenidos puede crear y editar contenidos web. Un publicador de contenidos aprueba o deniega las peticiones.

Roles y responsabilidades

Cada organización definió los usuarios que debían tener roles de editor y publicador de contenidos. Estos usuarios son responsables de los contenidos editados y publicados por su unidad. Típicamente, el rol de publicador queda reservado a subdirectores o subdirectores adjuntos

El área TIC es la encargada del mantenimiendo de la infraestructura técnica y la administración global del sistema. Adicionalmente se encarga de crear o modificar páginas en Liferay, así como de vincular contenidos publicados a cada página. Este paso sólo es necesario cuando se publica un contenido por primera vez; una vez publicado y vinculado a una página, los editores y publicadores son totalmente autónomos para modificar el contenido y que éste sea visible inmediatamente.

Además, el área TIC ha realizado alguna tarea en principio fuera de su ámbito como la impartición de formación en materia de creación de contenidos, así como de la publicación de guías , con las que se trata de mejorar la calidad de los contenidos publicados. Estas guías abarcan aspectos como el uso de imágenes, enlaces, etc.

Por último, el grupo de webmaster vela por asegurar la consistencia de los contenidos publicados con la imagen corporativa del INAP. Por ello se ocupa de funciones como la revisión de la accesibilidad de los contenidos o la publicación de noticias.

Flujo de publicación

Un editor de contenidos trabaja sobre un contenido web. Cuando ha finalizado, solicita su publicación en el espacio de publicación correspondiente. El usuario tiene la opción de seleccionar si desea notificar por correo electrónico a algún publicador de la tarea enviada.

A continuación un publicador aprueba o rechaza la petición. Si el contenido ya estaba vinculado a una página en Liferay aparece automáticamente. Por el contrario, si se trata de un nuevo contenido el publicador solicita al área TIC la creación de una nueva página y la vinculación del contenido recién publicado.

Infraestructura técnica

En lo relativo a la infraestructura, se eligió Liferay como gestor de portales, pero dado que en aquel momento aún no disponía de flujos de publicación se optó por almacenar los contenidos web en el gestor documental Alfresco. Esta infraestructura soporta actualmente la página web, la sede electrónica y la intranet.

Aprovechando que se implantaban dos aplicaciones importantes se incorporó el despliegue de una solución Single Sign On que permitiera ir consolidando la identificación de usuarios en un único punto. Para ello se eligió Jasig CAS, aunque las credenciales de los usuarios se almacenan en Openldap y éstos pueden acceder utilizando certificado digital. También se utilizó PWM para proporcionar funcionalidades sobre Openldap, como olvidé mi contraseña.

Diagrama de alto nivel de los portales web

Físicamente los productos se ejecutan en Apache Tomcat, poniendo frontales Apache que realizan proxy inverso hacia los Tomcat.

Productos y licencias

Tanto Liferay como Alfresco ofrecen su producto en dos modalidades: Community y Enterprise. Aunque las diferencias exactas dependen de cada producto, el espíritu es muy parecido:

La versión Community se puede descargar libremente, pero sólo se tiene disponible la última versión y no se proporcionan parches de seguridad. De este modo, si se detecta un problema importante el modo de solucionarlo es modificar el código directamente o actualizar a la última versión (suponiendo que en ella se haya solucionado el problema). Sin embargo, si se dispone de la licencia Enterprise se puede solicitar al proveedor un hotfix que solucione el problema en la versión desplegada en producción sin necesidad de actualizar.

En el caso de Liferay, si se desea implantar alta disponibilidad (clúster) la licencia Enterprise es obligatoria. El coste de la licencia que permite alta disponibilidad no es en absoluto despreciable.

Debido a estos condicionantes, la mayoría de las organizaciones que utilizan estos productos suelen optar por la licencia Enterprise.

El resto de los productos utilizados (Jasig CAS, PWM, Openldap, Apache Tomcat, Apache Web Server, etc) son software libre y totalmente gratuitos.

Desarrollos a medida

La peculiaridad de la solución elegida obligó a realizar varios desarrollos, como por ejemplo:

  • Módulo de integración Liferay <-> Alfresco, utilizando los servicios REST existentes y desarrollando nuevos.
  • Portlets a medida en Liferay, como por ejemplo el portlet de visualización de contenidos Web almacenados en Alfresco.
  • Asistente de edición y publicación de contenidos en Alfresco.
  • Sistema de notificación a los publicadores de que tienen tareas pendientes de aprobación.

Próximos retos

Con la perspectiva que da el tiempo, hay algunos aspectos sobre los que queremos trabajar para seguir mejorando. Probablemente no todos se puedan llevar a cabo, pero es positivo tenerlo en cuenta incluso para futuros proyectos.

Desde un punto de vista organizativo

Anteriormente se han citado las ventajas que tiene optar por un modelo descentralizado de publicación de contenidos. Sin embargo, ese modelo tiene el riesgo de que esa descentralización implique una menor consistencia de los contenidos entre sí y con la imagen corporativa. A la hora de detectar contenidos poco consistentes se pueden realizar comprobaciones del estilo de:

  • Todas las imágenes tiene un tamaño apropiado, están optimizadas y tienen texto alternativo.
  • No se usan etiquetas HTML no permitidas.
  • Los enlaces están correctamente construidos.
  • No se modifican los colores de la imagen corporativa.
  • Todos los contenidos son accesibles.

Existen varias alternativas para mitigar este riesgo, entre las que podría estudiarse:

Modificar el flujo de publicación para que un contenido no sea publicado si no cumple las directrices mínimas establecidas previamente.A la hora de implementar estas validaciones, podría optarse por un procedimiento automatizado: cada vez que se intentara publicar un contenido un algoritmo debería parsear el contenido HTML para verificar que se cumplen las directivas. En caso contrario, debería indicar los puntos a mejorar y no permitir la publicación hasta que el editor cumpla con las directrices establecidas.

Otra opción sería facilitar la supervisión manual ex post. Para ello, podría establecerse un sistema de notificaciones al grupo webmaster cada vez que un contenido sea publicado, de modo que se pudiera efectuar una revisión manual y solicitar correcciones si se considerara oportuno.

El procedimiento automatizado tiene la ventaja de no generar trabajo extra al grupo de webmaster, pero puede ser difícil modelar todos los aspectos a comprobar en un algoritmo. Posiblemente el enfoque más eficaz se encuentre entre ambas opciones.

Desde un punto de vista técnico

El avance que han experimentado productos como Liferay, Drupal o incluso WordPress amplía el abanico de opciones disponibles a la hora de elegir una arquitectura técnica para un proyecto como éste. Hay que tener en cuenta que toda integración de productos aumenta la complejidad de la infraestructura final, lo que dificulta la actualización de versiones y penaliza el crecimiento.

Por ello, podría estudiarse el empleo de un sólo producto, prescindiendo de Alfresco para almacenar los contenidos web. Para decidir entre los gestores de portales disponibles habría que valorar aspectos como la escalabilidad, facilidad de uso por parte de los usuarios finales, disponibilidad de módulos y plugins, coste, etc.

Contratación: medir rendimiento y despliegues automatizados

Otro de los aspectos que podrían considerarse es la medición del rendimiento o despliegues automáticos. Herramientas como Google Pagespeedz permiten medir con gran nivel de detalle el tiempo de carga real de una página, mientras que los sitemas de integración contínua como Jenkins contribuyen a la calidad de los desarrollos sin generar trabajo adicional.

Medir tiempos de respuesta siempre es complejo y muy dependiente de la infraestructura previa, pero podrían establecerse puntuaciones mínimas en el test de Google Pagespeedz, tanto para versión móvil como para escritorio.

Actualmente la web del INAP da una puntuación de 93/100 en escritorio y 80/100 en móvil, lo que sería un buen punto de partida. Aunque el tiempo de carga varía, con carga baja la página suele cargarse en unos dos segundos, pero la página es visible (DOMContentLoaded) en un segundo y pico. Tiempo de carga de la página web del INAP, medido con carga baja (festivo)

También podría exigirse en los pliegos un número mínimo de usuarios concurrentes, que podrían medirse utilizando herramientas del estilo Apache Jmeter. En nuestro caso, la web del INAP ha aguantado bien picos de alrededor de 550 usuarios concurrentes.

En cuanto a los despliegues, podría exigirse en el pliego al menos un script maestro que hiciera la compilación y despliegue de manera totalmente automatizada. Idealmente, el pliego podría incluir la integración del procedimiento de despliegue en un sistema de integración continua.

Publicado en proyectos Etiquetado con: , , , , ,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*