El poder de la sincronización
La sincronización de sistemas es una solución muy utilizada para vincular información de distinta naturaleza pero con algún punto en común: por ejemplo, actualizar la lista de clientes entre el ERP y CRM en ambos sentidos. También puede ser utilizada para vincular información de la misma índole pero de forma temporal, “apagando” uno de los sistemas al final de un período. Este es el típico caso de una migración por etapas.
Sin embargo, existen otros casos menos frecuentes en donde se sincroniza información de dos sistemas de la misma naturaleza y objetivos, pero de forma permanente. En esta nota vamos a describir una experiencia de este tipo, aplicada a la industria portuaria.
De los sistemas al negocio portuario
Todas las terminales portuarias tienen un TOS (Terminal Operating System), que es el sistema informático que les permite realizar la gestión operativa portuaria. Existen varios proveedores y productos, pero el objetivo de los TOS es siempre el mismo (o muy similar), ya que la gestión portuaria presenta muchos procesos en común que los distintos TOS intentan cubrir.
Montecon, (operador portuario en el Puerto de Montevideo, Uruguay) cuenta con un TOS desarrollado in-house para todo su grupo empresario, llamado EasyStow, que cubre las necesidades de la Terminal en aspectos tales como: recepción y entrega de contenedores, manejo de reefers, integración EDI, integración con Aduana, generación de reportes, y distintas funciones de planificación en patio y buques.
Hace algún tiempo, Montecon decidió complementar su core portuario con la solución SPARCS N4 de Navis (el TOS más implementado a nivel global) para dar mayor soporte a las tareas operacionales, aprovechando sus fortalezas (como planeamiento, carga, descarga, gestión de patio), y aumentar la eficiencia en sus procesos.
Este nuevo esquema toma lo mejor de los dos mundos, pero plantea el desafío de mantenerlos continuamente sincronizados en tiempo real para que la información en EasyStow esté disponible en N4, y viceversa. El equipo de Flux IT Ports (al cual pertenezco) tuvo como misión implementar una solución que permitiera a ambos TOS convivir, asegurando la integridad y consistencia de la información que cada uno genera, para que los dos operen correctamente.
Arquitectura propuesta
Para lograr este objetivo, unimos fuerzas con los equipos IT de Montecon fusionando la experiencia de cada uno con los sistemas operativos en juego.
A partir de esto, diseñamos una arquitectura que logró cumplir tanto con los requerimientos técnicos de la integración, a la vez que sirvió para sacar el mejor provecho de los dos equipos, como así también las necesidades de colaboración y distribución del trabajo entre ambos. Una primera aproximación de esta arquitectura se muestra en la figura siguiente:
En el gráfico puede verse la arquitectura básica, formada por tres componentes: los dos TOS (EasyStow y N4) y un componente Middleware que los comunica. El objetivo fue no intervenir técnicamente los TOS con modificaciones que puedan convertirse en obstáculos en su desarrollo evolutivo autónomo (upgrades), sino ubicar toda la inteligencia de convivencia y comunicación en la capa de middleware.
A su vez, la capa de middleware está conformada por dos componentes principales, que pueden clasificarse como de tipo ETL (Extract, Transform and Load). Si bien difieren en su implementación técnica, el objetivo de ambos es el mismo: tomar información de su fuente (uno de los TOS), procesarla y enviarla al destino (el otro TOS). En cuanto al procesamiento, cada uno garantiza la integridad de los datos en su transformación, como también su arribo en el orden original; o al menos en un orden que no viole reglas de prioridades que puedan generar inconsistencias de información o errores.
De esta manera, uno de los ETLs toma datos desde EasyStow y los envía a N4, mientras que el otro ETL realiza lo mismo en sentido inverso. Estos componentes fueron desarrollados por Montecon y Flux IT, respectivamente.
Conectar estos ETL a su fuente (TOS), no siempre es un proceso sencillo; y ese fue otro desafío que tuvimos que enfrentar. Fue necesario un gran esfuerzo de desarrollo para que el ETL que toma información de N4 pudiera detectar correctamente ciertos eventos y tomar su información.
Un aspecto importante de este tipo de soluciones es cómo implementar un mecanismo de tolerancia a fallas. Es decir, cómo nos repondremos ante la caída de alguno de los sistemas involucrados.
En este caso, se implementó un esquema de colas a nivel de base de datos (existen otras alternativas como Active MQ o Amazon SQS) que permitía encolar los mensajes y solo desencorlados una vez que se haya informado la información correctamente.
Finalmente, dado el gran volumen de información generado en las operaciones ETLs, nos vimos obligados a instrumentar herramientas para el procesamiento de logs que faciliten las tareas de soporte y mantenimiento. En este caso, el producto Kibana fue el utilizado permitiendo procesar y almacenar grandes volúmenes de logs de forma eficaz. Los agentes en cada nodo del cluster de integración filtraban las líneas de log colocándolas en un repositorio para su indización y posterior consulta.
Los resultados
El Go Live fue planificado con antelación y a nivel operativo duró más de una semana, por la cantidad y diversidad de operaciones sincronizadas. Los resultados fueron los esperados tanto en calidad como en volumen: sólo en las primeras dos semanas operaron exitosamente 53 naves, se produjeron 7.835 cargas, 10.044 descargas, 4.462 recepciones de exportación y 4.527 entregas de importación. Quizás parezcan sólo unos cuantos números, pero créanme: son muchos goles de un gran equipo!
