En búsqueda de la ortogonalidad perdida.

En las últimas dos semanas he estado divertido con una migración de una aplicación a GeneXus 9.0.
La migración en si, no dió demasiados dolores de cabeza. Si tuvimos que hacer bastante testeo, pues hubieron que hacer varios cambios por joins que cambiaron y reglas que cambiaron el momento en que se disparaban.

La parte WEB (que es la mayoría de la aplicación) no tuvo mayores inconvenientes y los módulos que usan webforms tuvieron mas problemas fundamentalmente en el momento de la instalación.
Las herramientas que tenemos para instalar un aplicación Genexus, son bastante pobres.
En nuestro caso la aplicación se instala de la siguiente forma

WIN
  • GENERAL
  • BATCH

WEB
  • PUBLICO (directorio virtual con acceso anonimo autorizado)
  • PROTEGIDO (directorio virtual con SSL/HTTPS)
  • WEBSERVICES (directorio virtual para webservices)
Estaría bueno poder definir en GeneXus en que lugar se instala cada cosa, de forma de poder hacer el deployment en forma mas prolija. Hoy lo hacemos a traves de archivos con la listas de objetos que se instalan, las cuales se procesan con scripts que instalan en los directorios correctos. Esta es una tarea que casi todos sufrimos y seria bueno contar con herramientas que ayuden en la misma.


Lo que si me vuelve a complicar, es la falta de independencia entre los diversos ejecutables WIN cuando se genera con .NET. En la versión 8.0, el generador .NET generaba un assembly por folder, lo cual complicaba mucho el saber que es lo que hay que instalar.
En la versión 9.0, mejoró mucho el poder instalar algo, pues hay una propiedad ("Assemblies structure") y se puede poner "By main", que permite generar un exe y una dll que contiene casi todo lo necesario para ejecutar dicho programa.
Lo que queda afuera son:
messages.spa.dll (el nombre depende del idioma que se este usando) que contiene los strings de la aplicacion y su traduccion
GxCommon.dll que contiene la definicion de webservices y tambien el codigo necesario para el manejo de SDTs.

Y esto en que complica?. Puede pasar, que una persona esté haciendo un cambio en un SDT, por ejemplo importando un WSDL que deje la GXCommon sin compilar, con lo cual, una parte imporante de mi aplicación queda en un estado de no-instalable.

Estaria bueno, que cuando un pone que se genere los assemblies por main, se genere un solo ejecutable que contenga TODO lo necesario (los SDT, los WebServices) para que el mismo ejecute, de forma independiente del resto, dejando a los main realmente ortogonales (*). Va en contra de las prácticas recomendadas de instalación, pero es un caso claro en el cual la teoría y la práctica tienen algunas diferencias, cuando se trata de instalaciones agiles.

(*) Ahora que se lo que es ser ortogonal en el ambito de la computación tengo que usar el término mas a menudo.
Si se pudiera solucionar esto (que creo que solo afecta la generacion de los archivos *.rsp) podría también facilitar la compilación de aplicacaciones cuando hay mas de una persona en la KB ejecutando otro main, facilitando asi el trabajo en grupo sobre una misma KB.

Comentarios

  1. El tema de GXCommon en web applications tambien es bastante complicado a veces ya que si upgradeas un SDT tenes que asegurarte de upgradear al mismo tiempo todos los demas que lo usen o se te cae todo. Tu sugerencia tendria sentido tambien para casos asi ... al menos deberia ser una opcion ...

    ResponderEliminar
  2. Cecilia, lo que decis es verdad. Se solucionaria tambien incorporando el codigo que generan los SDTs y Web services dentro de los asemblies de los webpanels. No es lo optimo (pues hay codigo que quedaria redundante), pero es lo mas controlable, de forma de instalar solo que cambie y no romper nada en el proceso (y lo peor es no darme cuenta que estoy rompiendo algo).

    Enrique

    ResponderEliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Paleta de colores en GeneXus