Sobre Migrabilidad de KB

Después de mi charla en el Evento Genexus sobre Migración de KB grandes, algunas personas se me acercaron para consultar y comentar sobre procesos de conversión de Kbs.

Un par de conocidos, me comentaron que la charlas los había decidido a migrar (*)  y uno me dijo que iba a tener que ajustar un presupuesto que estaba haciendo para una migración  pues veía que le iba a llevar mas horas de las que pensaba dedicarle.  Esos comentarios me dejaron contento y si  pudo ayudar a un par de personas, la charla valió la pena.

También converse con otras personas, que comentaban algunas dificultades en la migración de sus KB, porque tenían particularidades que hacían que no funcionaran en la nuevas versiones de GeneXus.

Algunas que me comentaron

  • Modificación de la GXClasses, para adaptarla a mi problemática
  • Inclusión de javascript en el HTML para mejorar la usabilidad (simular el IsValid).
  • Sistema de menúes propios, no Genexus
  • Modificación de objetos generados por Patterns
  • Modificación del fuente generado por Genexus. 
  • Inclusión de código nativo (c#, java, etc) en los objetos.
Confieso, haber hecho todas estas "salidas" (y varias mas como uso de tablas temporarias) para poder solucionar problemas o carencias que no se podían resolver de forma standard en versiones anteriores de GeneXus. 
Si dentro del grupo de desarrollo hay gente que programa con herramientas como Visual Studio, Eclipse y demás  es muy tentador solucionar los problemas de la forma rápida y nativa. Estos arreglos solucionan el problema puntual, pero introducen nuevos problemas para el futuro.  

La opción que hemos utilizado en estos casos, es la de solucionar el problema puntual, con las siguientes consideraciones:
  • Estudiar las opciones para hacerlo en GeneXus
  • Tratar de aislar lo mas posible la funcionalidad, de forma de no tener que modificar muchos objetos 
  • Reportar a GeneXus el caso, para que se estudien formas de hacerlo en futuras versiones en forma natural en GeneXus. 
  • Cuando encontramos una solución dentro de Genexus, reprogramar lo necesario para quedarnos lo mas nativos posibles. 
Estas cosas generalmente pasan con funcionalidades de "borde", cuando se exige algo que GeneXus aun no hace, por ser demasiado nuevo, por ser usado solo en una plataforma o que aun no es considerado de uso común. 

Con GeneXus X, aparecieron formas de extender nuestra aplicación, de una forma mas prolija que antes, por lo que la problemática es menor, pero el problema igual se presenta. 
Por ejemplo, si con los dispositivos móviles queremos tener impresión vía Bluetooth es necesario la implementación o adquisición de un user control para poder imprimir en la plataforma elegida, por mas sencillo que sea el reporte. 
Seguramente en versiones posteriores Artech va a desarrollar un forma de hacer impresiones desde los dispositivos móviles  con lo cual, va convenir dejar de usar el User Control y pasar a usar el metodo nativo de impresión, de forma que nos funcione en todas las plataformas. 

Resumiendo, la migrabilidad (**) de una KB, es algo que hay que tener presente y trabajar, para poder tener la KB lo mas migrable posible. De esta forma, estaremos protegiendo nuestra inversión en el conocimiento que la KB contiene y preparándonos mejor para el futuro. 


(*) Como son conocidos y amigos, no les creo mucho :)
(**) Supongo que es una palabra que no existe en castellano, pero creo que aplica para este caso. 

PD: Todo esto me hizo pensar si no valdrá la pena agregarle al KBDoctor un reporte que permita listar todos aquellos objetos que tengan cosas que puedan tener problemas al migrarse. 





Comentarios

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.