Blogs

Usualmente se suele tener una petición de prueba (readiness-probe) a la Home con el fin de comprobar cuándo ha terminado de arrancar el Portal en cada Servidor de Aplicaciones, para así poder meter en el balanceo de carga el nodo back-end.

En versiones previas a Liferay 7/DXP, al desplegarse todas las aplicaciones dentro del Servidor de Aplicaciones, cuando éste estaba levantado correctamente, la readiness-probe a la Home podía ser suficiente. En versiones actuales de Liferay 7/DXP las aplicaciones se despliegan dentro del contenedor OSGi, permitiendo un arranque más ágil al Servidor de Aplicaciones mientras que el contenedor OSGi continúa desplegando aplicaciones en él. En el momento en el que el Servidor de Aplicaciones esté arrancado, las respuestas a esas peticiones empezarán a despacharse.

Con este cambio, los clientes suelen preguntar qué tienen que hacer para comprobar cuando su solución de negocio (normalmente, portlets en gran medida) construida sobre Liferay DXP está completamente levantada para prestar servicio. 

Por este motivo he desarrollado el siguiente módulo como solución: business-core-status 

¿Cómo funciona?

Básicamente lo que hace el módulo es ofrecer un endpoint dentro del Portal cuando todas las dependencias se encuentren disponibles. Pero… ¿Qué dependencias? Las que realmente nos importan en nuestro negocio, nuestros Portlets y Servicios.

Técnicamente, el módulo es un servicio OSGi que expone un servlet en el endpoint /o/business-core-status/check

Este servicio OSGi únicamente estará disponible cuando las dependencias de la interface ModuleServiceLifecycle  para los eventos PORTAL_INITIALIZED y PORTLETS_INITIALIZED se encuentren disponibles. Estas estarán disponibles una vez se completen las fases correspondientes a cada evento en el arranque en DXP.

Seguidamente tenemos una referencia a un listado de portlets, Este listado de portlets es el que contiene los portlets importantes para el negocio. Este listado de portlets, inicialmente está configurado por *, lo que requiere configuración para indicar el listado de nombre de los portlets de negocio.

Utilizamos la propiedad cardinality.minimum para indicar que queremos que se inyecte el listado completo de portlets, para que en el caso de que cuando al menos uno del listado no esté disponible, el endpoint tampoco lo estará y nuestra readiness-probe no devolverá un code 200 ni un html response esperado para el nodo en cuestión.
 

¿Cómo lo configuramos?

Para indicar qué portlets queremos referenciar, podremos crear un fichero de configuración OSGi del Component, con el nombre com.liferay.business.core.status.BusinessCoreStatus.config

y desplegarlo en el directorio ${liferay.home}/osgi/configs

En mi caso, hago referencia a 2 portlets Spring que figuran en el mismo Workspace, para que el endpoint esté disponible únicamente cuando ambos portlets estén disponibles.

Conclusión

Desplegando business-core-status en cada servidor de aplicaciones, podremos monitorizar el endpoint que ofrece el servlet con el fin de determinar cuando un nodo está listo para meter al balanceo o incluso como health-check del Portal, teniendo en cuenta las aplicaciones que estimemos vitales para nuestra solución.