Karina me lo dijo hace 20 años y tenía razón |
| | (22/06/2009-17:13) |
| Un artículo de Gustavo Carriquiry, gerente de operaciones de Artech, que empieza con una anécdota personal sobre inicializar datos con transacciones (Business Components) y Data Providers; y que concluye con ejemplos prácticos de uso para GeneXus X Evolution 1, como lo es el video de Business Component y Data Providers. |
Hace unas semanas descubrí que Karina tenía razón hace 20 años, sólo hizo falta que esos 20 años pasaran, que yo abriera mi mente y me animara a más. A modo de reconocimiento y por si ayuda a algún otro a abrir su mente, va este post.
Mi problema en ese momento
Hace muchos años que trabajo con GeneXus, empecé en un cliente hace como 20 años y recuerdo una llamada a soporte, en ese momento Karina era “soporte-documentación-test-capacitación-consultoría-y-aindamais”.
En ese momento yo estaba desarrollando un sistema para el control de flotas (stock de repuestos, manejo de combustible, manejo del taller, etc). Precisaba hacer un proceso de actualización de stock “batch” pero GX en ese momento sólo tenía Transacciones y Reportes. No existían los procedures (mucho menos workpanels ni nada de lo que existe hoy).
Llamé a soporte para ver como podía resolver el tema y Karina me intentó convencer de que lo que estaba haciendo estaba “conceptualmente mal”, que la actualización a la base de datos debia ser vía la transacción que era donde estaban las reglas del negocio y aseguraba la consistencia de los datos, etc, etc. Argumentación atendible.
Yo tenía 20 años, era un pollito de Facultad y Karina era muy convincente. A pesar de ello no me convenció y yo pecador (y vasco) hice un programita en DBase III Plus (¡que producto!) muy sencillo e integrable que resolvió el tema, por suerte no hubo que migrar eso a RPG porque ahí hubiera patinado un poco más :)
Mi problema hoy
Hace unos días tuve que hacer una aplicación y quería que tuviera Geografías (la típica de Pais/Estado/Ciudad) y tomé por el camino “conocido”.
Lo primero que hice fue definir la estructura geográfica que quería, bastante sencilla:
CountryID* CountryName (StateId* StateName (CityId* CityName))
Luego me puse a desarrollar por el “viejo_conocido_seguro_confiable” camino de un procedure con “news” que poblara los datos. Algo como:
new
CountryId=1
CountryName=”Uruguay”
Endnew
new
CountryId=1
StateId=1
StateName=”Montevideo”
endnew
new
CountryId=1
StateId=1
CityId=1
CityName=”Montevideo”
endnew
etc, etc, etc.
Estuve un rato de “copy/paste” bastante largo y aburrido, proceso en el cual cometí N errores (me suele suceder cuando me aburro) porque en un bloque ponía el código del país mal y me quedaban mal los datos y así sucesivamente.
Tiene que haber un modo mejor
Esto de “inicializar” datos es algo que suelo precisar porque hago muchas KBs “from scratch” y siempre el tener un juego de datos “razonable” es un problema. Creo también que es algo bastante común en procesos de implantación donde luego del “create” hay que poblar con datos iniciales la base de datos.
Anduve buscando algunas KBs a ver como lo tenían resuelto (¡aguante GXserver!) y me encontré en varios lugares la misma solución del procedure y los news. Incluso alguna parecida a lo que quería pero no lo suficiente para re-usarla a bajo costo.
Me acordé de un DataProvider que publiqué hace tiempo en el wiki, uno que hice con un programita que leía los ISO codes de un excel y generaba un TXT con el formato DP, luego “copié/pegué” del TXT en el DataProvider. A veces practico esos deportes.
Ese Data Providers está bueno, pero no tiene los estados ni ciudades… en fin… no aplicaba mucho a mí caso, sin embargo por el lado de los DP parecía venir la solución.
Al final de la historia (así la hago corta) me quedé con una solución con DataProviders que retorna los datos y un procedure que en lugar de un “new” usa un business component, también usé autonumber y un par de serial para sacarme de encima el lío de la primary key.
A continuación un video de cómo lo hice:
Ejemplo/Escenario de uso de BC y DP from guscarr on Vimeo. Ventajas que encontré 1. Más simple. Quiero poblar la estructura de Countries, entonces Drag&Drop de la misma a un DP y alguna cosita más y listo.
2. Más barato. Me llevó mucho menos tiempo la versión inicial. Si bien tuve un trabajo de “copy/paste” fue más sencillo, al menos no me preocupé para nada de los CountryCode, StateCode, etc.
3. Más claro. Separé el “alta” de la “fuente de datos”, con esto si quiero agregar datos no tengo que meterme con los news ni nada, simplemente los agrego en el DP.
4. Más potente. En mi caso era una estructura bastante sencilla con reglas sencillas, pero igual me resolvió el alta, la numeración y las reglas que tuviera o vaya a tener asociadas al Country, etcétera (si le tengo que agregar alguna regla a la TRN de Countries sé que no tendré que modificar el procedure, esto es importante para la consistencia/calidad de los datos).
5. Más re-usable. Mi desafío ahora es evitarme el copy/paste e intuyo que via el Data Provider Generator y servicios como los de freesbase.com no tendré mayores inconvenientes en hacerlo (quedará para cuando pueda bucear en freebase.com un poco más).
En cualquier caso si esto lo fuera a implantar en un cliente tal vez la fuente de datos sea otra y habiendo separado los datos del alta en si creo que será más fácil adaptarel “input” del DP.
En fin, unas cuantas ventajas del uso de DP y BC en un escenario como el descrito. Luego de “abrir mi mente” respecto a los DP y BC creo que hay muchos más escenarios de uso posibles para los mismos así que mi mensaje es solamente ese: mantenga su mente alerta, hay nuevas y mejores soluciones para nuevos y viejos problemas.
Ahh… me olvidaba: Karina, tenías razón, sólo se trata de abrir la mente y para la actualización alcanza la transacción (o casi).
* Publicado en Blog de Gustavo Carriquiry |
|