Desarrollando desde la trinchera.

Una de las tareas que tenemos por delante quienes desarrollamos con GeneXus desde hace mucho tiempo es pasar algunos de nuestros desarrollos que vienen de versiones anteriores de GeneXus en una KB monolítica, a varias KB interconectadas.  Los motivos de este cambio, no es caprichoso, sino que hoy que esta motivado por la necesidad de nuestros clientes de tener los cambios mas rapido y nosotros necesitamos instalar con mucha mayor frecuencia que lo que hacíamos antes.  En una KB monolítica, teníamos que esperar a tener TODO el sistema en un estado instalable, y los que desarrollamos sabemos que el tiempo de estabilización de los cambios para que sea instalable es proporcional a la cantidad de objetos, cantidad de desarrolladores y cantidad de cambios introducidos.  La mejor solución que ha encontrado la industria para este problema, es el clásico " divide & conquer ". Cuando tengo un problema grande que no puedo resolver en un tiempo limitado, es mejor dividirlo en pro...

Cuando se tienen aplicaciones GeneXus complejas, es natural que se hagan varias KB para dividir el problema, y hacer mas fácil el mantenimiento de las mismas.  En GeneXus 15 (y mejoro en la 16) se agrego la funcionalidad de poder exponer un modulo como binario, de tal forma de poder pasar un modulo a otra KB de forma mas fácil que hasta ahora.  Suponiendo que tenemos una KB que expone objetos públicos procedures y business component. Se puede elegir un módulo, y empaquetarlo como binario. Se genera un archivo de extension OPC. Esto va a ser visto como un modulo y se verán solo los objetos públicos y sus parámetros, pero no los fuentes.  Estos modulos no necesitan ser especificadas, por lo que se hacer mucho mas rapido el build de una KB que use ese tipo de modulos.  Es una forma mas radical de dividir una KB en modulos, donde algunos de los modulos se tienen solo en binario y se desarrollan en otra KB.  Las KB quedan mas chicas y permiten ace...

Hace unos días conversando con colegas de la comunidad Genexus,  en una charla por otro tema, comenté un problema que me hace pensar desde hace tiempo. Ese no era el lugar para hacer planteos técnicos. Los módulos son un objeto con muchísima potencia, muy sub utilizados y que les falta poco para obligar a una programacion modular en Genexus. Cual es el principal problema? Voy a mostrar un ejemplo ultra sencillo y pero creo que representativo. Para los programadores GeneXus que recién están empezando,  es mucho mas facil escribir for each     where EmpresaID=&EmpresaId         &NombreEmpresa=NombreEmpresa endfor que buscar cual es el procedure que devuelve el nombre de la Empresa y poner &NombreEmpresa=GetEmpresa_Nombre(&EmpresaID) En KB Grandes, es realmente dificil y lento encontrar cual es el objeto que tengo que llamar para traer el nombre de la empresa. No hay una forma facil de buscar los objetos publico...

En el post anterior sobre módulos, nombraba algunas características que serian buenas para mejorar en los módulos y algunas de ellas, no tenían nada que ver con los módulos, sino que era para lograr aplicaciones mas fáciles de modularizar. Algunas personas me hicieron preguntas, por lo que voy a tratar de explicar mejor lo que quise decir. Hoy GeneXus genera las transacciones de la forma: La transacción Deposito, accede a la tabla DEPOSITO (para hacer alta / baja y modificaciones de los datos) y también al tabla CIUDADES, para controlar que exista la ciudad del deposito si estoy agregando o modificando. A su vez, la transacción Ciudad, accede al tabla CIUDADES para el ABM y a DEPOSITOS para chequear si se puede borrar una CIUDAD (y no deja borrar si existe un depósito con esa Ciudad, para controlar que no queden datos inconsistentes. Con la forma actual de módulos, para no tener errores, hay que definir las transacciones Ciudad y Deposito con Visibility=Public y por lo tant...

La funcionalidad de los módulos en GeneXus es un desarrollo que tuvo un impulso inicial, y luego se estancó un poco, pues han surgido muchas otras cosas que han ocupado la agenda de desarrollo. Hace mas de un año escribí un articulo sobre el tema, y ahora voy a reforzar un poco la idea, pues sigo necesitando cosas de los módulos. Como veo estratégicos el tener un buen sistema de módulos, creo que vale la pena retomar y ampliar su funcionalidad para lograr manejar mejor nuestros desarrollos. El hacer que se extienda mas el uso de módulos, va a lograr mejorar los tiempos de build all y con eso también la productividad de quienes desarrollamos con Genexus. Si llegamos a tener módulos distribuibles en forma de binarios de forma facil y controlada, vamos tambien a estar mejor parados para arquitecturas interesantes como la de microservicios. Los puntos que a mi mas me duelen cuando uso módulos son: 1) Tablas publicas o privadas.  Me gustaria poder tener independencia ent...

Este es un problema interesante, con unas cuantas consecuencias practicas. Tengo una KB con n objetos y la quiero modularizar. Para simplificar, defino que quiero dividirla en K modulos, con  1<= k <= n. De cuantas formas diferentes puedo modularizarla? Sea S(n,k) la función que cuenta la cantidad de formas de modularizar, con n objetos y k modulos.  Dividimos el problema en 2 casos excluyentes: Caso 1: Hago un modulo solo con el elemento n. Me quedan n-1 elementos, para agrupar en k-1 módulos, que puedo escribir de la forma S(n-1,k.-1).  Caso 2: n esta en un modulo con otros objetos. Esto es lo mismo que poner el objeto n en los k modulos que tienen los n-1 elementos restantes. y puede escribirse como k * S(n-1,k)  La cantidad de forma de modularziar entonces, seria la suma de ambos casos y puede escribirse de la forma:       S(n,k) =  S(n-1,k-1) + k* S(n-1,k) a estos numeros se los conoce como...

Una de las tareas mas importantes cuando se está modularizando una base de conocimiento (o cualquier sistema) es diseñar nuestros componentes de software de forma que cada uno de ellos pueda ser lo mas independiente de los demas ( bajo acoplamiento ). En mi experiencia de modularizar bases de conocimiento, he visto muchas veces que se definen Dynamic Combo Box con una definción de atributos. Esto trae como consecuencia, que el objeto que tiene ese Dynamic Combo Box, hace una referencia explicita a la tabla que contiene los atributos CountryID y CountryName. Si este objeto no esta en el mismo modulo que la tabla Countries, dicha tabla va a tener que quedar publica. Una forma muy sencilla de evitar esta dependencia, es basar el Dynamic Combo Box, en un Data Provider en vez de usar directamente los atributos. De esta forma, el programa, en vez de hacer una sentencia "Select CountryID, CountryName from Countries" , hara una llamada a el Data Provider. Que ventajas...

Un amigo me preguntó porque me había dedicado desde hace algún tiempo, a trabajar en la modularización de KB, si hasta el momento nos habíamos arreglado sin módulos y podíamos hacer aplicaciones sin problemas. El conocía las dificultades del proceso de modularización y los cambios que implica introducir módulos al proceso de desarrollo, pero no veia las ventajas de tener todo bien modularizado. Mi razonamiento para tener una KB modularizada, es bastante sencillo: Es la única forma rentable que veo, con la que podremos resolver problemas mayores en el futuro, con GeneXus. Paso a explicar un poco. GeneXus es una herramienta que resuelve muy bien el desarrollo de pequeñas aplicaciones. Cuando uno trabaja con 10 tablas, es difícil encontrar algo que demore o funcione lento. Cuando trabajamos con 100 tablas, el proceso de normalizacion y reorganización puede ponerse un poco mas pesado, pero no hay nada que un build all (o en el peor de lo casos un rebuild all) soluciona ca...

El tema de modularización de bases de conocimiento me parecen uno de los mas importantes para los próximos años. El definir módulos en las KB (nuevas y existentes) es un trabajo interesante, con grandes ventajas para la evolución de los sistemas.  Para ordenar el proceso de modularizacion y poder saber cuanto me falta,  se me ocurre una escala de madurez, en el manejo de los módulos. Nivel 1 - La nada absoluta - Solo tengo el modulo Root  - Todos los objetos son públicos. Puede servir para KB de menos de 200 objetos.  Es como quedan todas las KB migradas desde versiones anteriores a Evolution 3.  Nivel 2 - Defino algunos  módulos . - Empiezo a definir algunos módulos - Algunos objetos son públicos sin necesidad.  Nivel 3 - Modularizo - Todo objeto esta en un modulo - Minimizo cantidad de objetos públicos - Hay tablas marcadas como publicas. No permito update/insert/delete a tablas fuera del modulo al...

Agregué algunas opciones al KBDoctor para poder manejar la modularización de KB. List Modules Errors.  Cuando hacemos cambios en la visibility de los objetos y/o cambiamos los objetos de modulos, no detecta automáticamente los cambios.  Al menos en Evo3, hay que hacer un rebuild para poder detectar los errores y eso demora muchisimo. Este reporte lo que lista son los objetos (tablas y programas) privados que estan siendo accedido desde afuera del modulo. Tambien las tablas publicas que son actualizadas fuera del modulo. Esto no es un error para Genexus, pero es algo que es bueno evitar. Por ultimo, tiene una lista de los objetos que seria bueno mover para el modulo, pues solo usa tablas y objetos de este modulo. List Tables in modules.  Permite lista un conjunto de tablas, y muestra si son privadas o publicas, en modulo esta y cuales son las transacciones que la generan. Tambien muestra la transaccion que GeneXus eligio para definir el modulo de la tabla. Toda ...

Cuando tengo un sistema desarrollado, tengo muchísimas formas de dividirlo en módulos. Segun la bibliografia, el problema mas general de particionar un grafo en diferentes agrupamientos de nodos (clusters) es considerado NP-Completo, por lo que no se ha encontrado aun una forma eficiente de resolverlo. Al tener tantas opciones, es bueno contar con alguna herramienta que me permita medir que tan buena o mal es dicha division, en el caso de una KB, seria medir que tan buena o mala es la modularizacion que he realizado. Algunas de las características perseguidas por la modularizacion, son la de tener un gran cohesion entre los nodos que están dentro de un modulo y tener poco acoplamiento con otros módulos. Esto se traduce, a que queremos maximizar las  aristas dentro de los módulos y minimizar las aristas entre los módulos. Resulta mas facil, verlo en imagenes. Supongamos que tenemos un grafo que representa la relaciones entre objetos. Los objetos pueden ser cualquier objeto e...

En las últimas semanas, trabajé en la modularización de una KB grande, un proyecto que aun no finalizó. Esto me llevo a reflexionar un poco sobre el estado actual de los módulos en GeneXus. Mis reflexiones están basadas en la experiencia de trabajo de modularizacion algunas KB chicas en GeneXus 15 y una KB grande en Evolution 3. Faltarian varias mas para sacar conclusiones mas generales, pero creo que el intercambio de ideas de como se usan los módulos es necesario. Para que sirven los módulos?  Uno de los problemas que tienen los módulos, es que sirven para mucha cosas diferentes, lo cual ha hecho que se pierda un poco el foco hacia donde hay que seguir desarrollándolos. Pueden servir para * Entender mejor la KB * Ayudar en el mantenimiento de la KB * Distribuir el desarrollo entre varios integrantes o grupos * Hacer mas fácil el Deploy de la aplicación * Unir mas de una KB * Distribución de binarios e interfaces. * Hacer mas rapido el proceso de desarrollo y ...

Problema: Tengo una KB con mas de 10.000 objetos y se debe organizar en módulos mas pequeños. Se necesita: Metodología que permita realizar dicha modularización, de forma de mantener el funcionamiento del sistema generado a partir de la KB. Metodología propuesta.  Bajar una KB desde GXServer. Hacer un build all exitoso (es importante pues se agregan referencias a tablas) Mientras queden objetos de la aplicación sin módulo hacer: Elección que modulo se va a  crear  y cuales seran sus tablas.  Sacar una lista de URL de todos los objetos de la KB Crear Modulo y poner Visibility como Private.  Mover los Folders correspondientes al Modulo.  Identificar todas las transacciones que generan las tablas del modulo y moverlas al modulo.  Sacar del modulo los objetos que no correspondan  Marcar como públicos los objetos interfaz del modulo. (Todos los dames se mantendrán privados por default) Revisar los objetos externos al modulo que ...

Después de probar varias formas de modularizar, la que mas me convence es hacerla orientada a los datos o las tablas del modulo. Mi definición de modulo, seria: Conjunto de tablas, todos los objetos que hacen UPDATE/INSERT/DELETE sobre las mismas y casi-todos los objetos que hagan referencia a dichas tablas. Las excepciones, son objetos que hacen referencias a tablas de un modulo, sin pertenecer al mismo son: * Transacciones con integridad referencial sobre las tablas del modulo. * Join entre tablas de diferentes módulos En un diagrama: GeneXus ya controla que no se puedan acceder a objetos privados (tablas u otros objetos) y da errores al especificar. Estos son los que estan a la izquierda. Para todos los objetos publicos (no tablas) esto tambien esta bien manejado.  El problema para soportar nuestra forma de trabajo, viene con las tablas publicas.  Una tabla, no tiene modulo, ni es publica o privada en forma directa (lo cual creo que es una gran ...

Cuando trabajamos con GeneXus Evolution 3 o superior, una de las funcionalidades que mas ayudan a mantener el desarrollo ordenado, es la de los Módulos. Una de las consecuencias de usar Módulos en la KB es que cambian el nombre de los objetos: Cambia la URL de las aplicaciones WEB Cambia el nombre de los web services publicados Cambia el nombre de los procesos batch command line Me ha tocado trabajar en KB que vienen de versiones anteriores de GeneXus que en las cuales es bueno usar la metodología de módulos, pero es difícil y costoso cambiar el nombre de los web services publicados por la aplicación, pues son usados por muchas empresas. Estuve buscando una forma temporaria de trabajo, que me permita usar módulos, pero que no modifique los objetos y llegue a una metodología que no es matenible en el tiempo, pero permite avanzar en la modularización hasta llegar a algo mas definitivo. Supongamos que tengo un Folder llamado  ALERTAS y quiero hacer un modulo con los obje...

Soy promotor de la modularización de KB Genexus, pues ayuda en muchos aspectos mejorar  la salud de la KB y de la aplicación. Al tener la KB modularizada, se puede entender mas rapido, y por lo tanto, se pueden hacer cambios mas agiles y con menos riesgos. Algunos de los patrones de problemas comunes que aparecen en KB que he estado modularizando son: Tengo un objeto que recorre una tabla privada de otro modulo y ejecuta código utilizando objetos del modulo B, por ejemplo actualizando o haciendo inserts. En este caso, conviene sacar la logia del Object1 y crear un nuevo objeto en el ModuleB De esta forma el ModuloB pasa a tener un nuevo servicio que puede ser usado por otros modulos y la tabla queda como privada. Caso 2: Se intenta recorrer una tabla privada de otro modulo, y luego se ejecuta logica propia del modulo en el que estoy.  Una posible solución es hacer un Data Provider que devuelva los datos de la tabla privada y utilizar los elementos d...

Subi al Marketplace una versión nueva del KBDoctor con varios cambios y arreglos. Algunas de las novedades son : Generar SQL scripts para validar la estructura de la base de datos con lo esperado en la KB, validar datos de integridad referencial, cambiar valores nulos, etc.  Sustituir un dominio por otro Listar dominios Listar atributos Listar modulos y tablas por modulos  Utilitario para acortar el nombre de atributos y objetos a su largo significativo de nombre Mejorado de codigo (cambia codigo, saca calls, udp.   varios etc.  Los compilé para Evolution 3 Upgrade 9 y GeneXus 15.   Dejo este link por si alguien quiere bajarla, antes que se soluciones unos inconvenientes que hay con el marketplace. 

Estoy haciendo el cuarto intento de modularizar una KB con GeneXus Evolution 3, con el Upgrade 3. Para esto, uso el objeto Module  , tratando de dividir una KB en grupos de objetos que estén lógicamente relacionados para hacer mas fácil su mantenimiento.  Los módulos, me parecen una muy buena idea y que puede ser muy util, pero que en su implementación actual (U3/Evo3) hay errores que dificultan mucho su uso. Mis intentos han sido con el generador .NET y apenas empiezo a usar módulos, aparecen errores de compilación.  Por ejemplo, reporté un error con los módulos en Evo3 Upgrade 1, hace mas de 6 meses y el mismo sigue dando en la Upgrade 3.   SAC # 36763 También da problemas cuando un SDT de mas de un nivel, están en módulos.  Otro problema es cuando se tiene objetos que se usan en ambiente WIN y WEB, se quieren mover a un modulo. Seria bueno que un objeto WIN pudiera estar en un modulo, aunque se generara siempre igual que en el pasado. ...