En la mayoría de las empresas que vienen utilizando Genexus, lo tenían bien ponderado o por lo menos lo aceptaban como bueno a partir de la idea de un reorganizador de base de datos automático (aunque a veces ni tan automático).
Algunos de sus sistemas back-office y servicios en linea "críticos" lo tienen bajo la programación tradicional , y es aquí la mayor critica que va en aumento. Genexus no es útil para procesamiento con alto requerimiento de respuesta, en otras palabras, "alta performance".
Creo también que Genexus no esta concebido para administrar "conocimiento" de un proyecto "Grande" tirando a Gigante, mas bien esta orientado para administrar pequeños a medianos proyectos. En la practica no conozco a ningún "consultor Gx" que de con la receta mas acertada de como administrar una KB Grande/Gigante.
- Sistema original (programas y archivos hechos a mano)
- Compra de Genexus
- Nuevos requerimientos hechos en Gx (abm con gx de las transacciones, algunos procedimientos, adaptacion del viejo sistema hecho a mano para lectura de los archivos hechos con GX)
- Molificación de parámetros con Gx del viejo sistema utilizando DataView
- Poco a poco se van reemplazando el sistema hecho a mano y se lleva a GX
- Gx. Útil para conocer rápidamente el negocio (visualmente) y brindar posibles soluciones
- Los sistemas hechos con Gx son lentos. Se entregan mas rápidos, pero el sistema entregado es lento.
- ¿Será conveniente reemplazar mi servicio de respuesta rápida con Gx.?
- ¿Será conveniente irme a web, mis entradas diarias aumentaran en comparación con los servicios win que hoy ofrezco?
10 comentarios:
Este demasiado Light tu comentario.
Es poco específico, y no creo que sea tanto problema de Gx como de la forma que han hecho las TRNs.
Me ofrezco a resolver cualquier problemas de manejo de Performance, Optimización de KBs, etc. No entiendo de que sistema hablás, creo que las 1000 TRNs que podés hacer para que GeneXus sea lento, no son necesarias... . Si uno es suficientemente ingenioso, con unas pocas TRNs "complejas", intrincadas y quizá mal diseñadas se puede hacer que los procesos se tornen "eternos"... .
Me gustaría aceptar el desafío de resolver estos inconvenientes que estas teniendo.
Saludos,
gab
Yo personalmente conozco el sistema del que habla Adolfo, implementado con el soporte directo de Genexus Consulting (si ellos no saben como hacerlo mejor, entonces quien?) y opino que tiene razon en cuanto a la problematica de la administracion de KBs muy extensas. En la medida que la KB aumenta de tama#o en numero de objetos, sean transacciones, subtipos, webpanels etc se producen necesariamente problemas de performance derivados en algunos casos de la navegabilidad sobre tablas innecesarias. A los problemas de performance se suman el engorroso proceso de consolidacion de esta Mega KB (que duran en algunos casos una eternidad). Aparentemente, lo razonable sería partir el problema en varias KB mas peque#as, pero implementar algo semejantes resulta tedioso y engorroso, ya que las tablas comunes compartidas por varias KB deben mantenerse sincronizadas via Dataviews. Personalmente en mi empresa dentro de nuestro proyecto de redise#o Genexus, teniamos pensado dejar las bases de datos criticas en el DB2, mientras que las tablas asociadas en otra Base de Datos (por ej Oracle). La perspectiva de los Dataviews mas los problemas del proceso de consolidacion para varias plataformas, nos obligo finalmente a tener mas de una KB. Creo que Artech debería enfocarse para sucesivas mejoras en permitir separar un proyecto muy grande en proyectos mas peque#os y manejables. Podria establecerse una base comun sobre la cual los demas subproyectos "heredaran" (concepto de orientacion a objetos tradicional) los objetos definidos sobre esta.
Creo que se mezclan varios temas.
Por un lado esta la performance de las aplicaciones generadas con Genexus. En este aspecto creo que se pueden lograr aplicaciones que tengan buena performance, independientemente del tamaño de la KB Genexus y la cantidad de tablas.
Es fundamental tener bien definido el modelo de datos. Si un buen modelo de datos, es muy dificil llegar a tener buena performance.
En cuanto al uso de KB grandes, es cierto que hay dificultades. A medida que el proyecto se hace mayor, la performance de ciertas operaciones se hacen lentas. Si bien esto tambien sucede con otras plataformas de desarrollo, creo que no es excusa y hay que solucionarlo. Lo que tenemos son ciertas recetas que se han ido juntando a lo largo de los años, pero creo que es momento de encarar el diseño de motodologias probadas para el ataque de grandes problemas con grandes KB. En lo que me es personal he estado promoviendo el estudio del manejo de KB grandes, para diagnosticar cuales son los problemas que nos aquejan. Una de las ventajas de Genexus es que ha demostrado que puede manejar modelos de 1000 tablas. Lo que nos falta ahora, es que dicho manejo sea con menos traumas que los que produce ahora.
Otra de las necesidades que estamos teniendo es la de MODULARIZAR el conocimiento dentro de las KB. De esta forma, al estar fraccionado el conocimiento, usando "divide and conquer" podremos resolver problemas aun mas grandes.
Enrique:
Hace como dos meses trate de hacer correr la siguiente idea, pero no le di continuidad por una cuestión del día a día y se necesitaba bastante tiempo.
La idea básica es tener 2 KB's como mínimo.
1- KB de datos
2- KB de procesos
En la kb de datos solo se tiene para crear las transacciones y por ende las reorg. Desde esta kb no se genera ni especifica nada. La transacción debe ser idéntica en cantidad de atributos de la tabla.
En la kb de proceso, la 2ª o nnnª KB, debe contener la transacción tal cual de la kb de datos (las necesarias para esa KB) mas una copia de la transacción a utilizar con un sufijo fijo, el cual indica que es una transacción que se utiliza en el modelo de procesos. En esta KB tambien se generan las formulas y la inclusion de atributos de tablas extendidas en la transacción con sufijo, se le aplica pattern y por supuesto, se genera y publica. Nunca se hace reorg desde esta KB, siempre COPY MODEL para reflejar las transacciones.
La idea de todo esto es permitir tener "n" KB's para generar modulos especificos e inclusive tercerizar dichos modulos sin necesidad de que el analista/programador tenga "toda la kb". Eso si, todos los atributos si o si deben de estar reflejados en la kb de datos.
Alguna ves solicite a Artech (no directamente) la inclusión de una propiedad en el objeto, que diga que ese objeto no debe generarse, esta en el modelo solo por una cuestión de conocimiento. Con esa opción en las transacciones esta idea, la KB seria rapidísima!!!!
Adolfo:
El tener 2 KB una solo con transacciones con estructuras solamente y otra con todo lo demas, es una alternativa valida, pero creo que agrega demasiada administracion que no agrega mucho valor y que se deberia poder conseguir de otras formas.
El tema esta en conseguir que las KB grandes, funcionen con buena performance. Creo que el trabajo mayor esta en identificar cuales son las tareas que mas demoran, y reportarlas para que se arreglen o se le encuentre una forma de hacerlo mas rapido.
La propiedad para que una Transaccion (o cualquier objeto) no se genere, ya esta implementada en la version GeneXus X. Mira en :
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?GenerateObject+Property,
Si no lo implementan en un version, hay que seguir insistiendo...
Enrique:
Ojala que la propiedad de no generar este tambien en la 9.0 (podes hacer la presión?)
Segun mi experiencia considero deberia ser mas rapidas dos operaciones
1- Al crear subtipos (el caso del atributo moneda es un tiempazo!) Hay situaciones para evitar ese tiempo tuve que crear atributos sin subtiparlo)
2- Cuando es necesario impact database pudiendo solo ser un Impact Objects (digamos que el tiempo de una reorg forma parte del diseño y un mal diseño no es culpa de Genexus, pero a veces se te pasa el Text Column que utiliza los Pattern y ahi no creo que debiera tardar tanto, aunque es cuestion de disciplina hacer bien una transaccion a la primera)
La definicion de subtipos en modelos grandes, es una de las opraciones que en la version 9.0, puede demorar (depende como esten definidos los subtipos).
Es algo en lo que se deberia trabajar para poder evitar esas demoras.
El caso 2 no lo entendi.... si no se necesita el impacto en la base,en general no lo hace.. En mis casos no he detectado problemas con esto..
PD: El no generar un objeto para la 9.0, no creo que tengas(mos) esa suerte. Ya lo habia pedido en el ciclo de betatesting de la YI (9.0) y no logre convencer a quienes cortan el bacalao de la utilidad /necesidad del mismo, a pesar que es una funcionalidad que no deberia dar demasiado trabajo ni problemas...
Hola Amigos: La verdad es que adquire Genexus X pensando en desarrollar mas y mejor, he estudiado libros, videos, foros, ejemplos y todo eso y tecnicamente se mucho sobre Genexus, en estos momentos estoy trabajando con KBs que tienen menos de 30 Transacciones y la verdad es que el desempeño de Genexus es realmente pobre comparado con mi otra herramienta de desarrollo y con cualquier herramienta de desarrollo, tiene muchos problemas fantasmas que hacen que el programa generado funcione de una manera un día y de otra otro día, a veces, corrompe las KBs dejandolas totalmente inutiles, por eso debo respaldar por lo menos 2 veces al día las KB y anotar todas las modificaciones en un archivo fuera de Genexus, tengo miedo de hacer alguna modificación a alguna aplicación ya funcionando bien en Genexus porque un pequeño cambio altero todo el proceso, envie varios correos al representante de Genexus en mi pais para devolver el producto, porque realmente lo considero una estafa, pero nada.
Actualmente tengo una aplicación que en Genexus ocuparia al menos unas 300 Transacciones y mas de 1000 objetos, pero me doy cuenta de que Genexus es solo para proyectos pequeños y no confiaria un sistema critico en manos de esta herramienta, la verdad es que para ser un producto con casi 20 años creo, es algo muy malo y deprimente, la verdad que la compra de Genexus fue un error y un dolor de cabeza tremendo.
#Alfonso,
Me gustaría que enviaras los problemas que tuviste al foro GeneXus, no sólo al tu distribuidor, creo que muchos distribuidores directamente no tienen tiempo para atender a sus clientes... .
Con respecto a tus dichos de que Gx, es sólo para proyectos pequeños estoy en total desacuerdo.
Con respecto a que conoces mucho GeneXus,estudiando videos y "todo eso" la verdad que es bastante rara la forma de conocer mucho que presentas.
En fin tu POST, es poco creíble.
Saludos,
gab
En mi opinión este chico Alfonso esta equivocado.
Porque lo digo, yo puedo leer mucho sobre medicina, videos, foros, blog, etc.,etc., y no me creo medico y mucho menos que se mucho. Primer error de Alfonso.
Te recomiendo hacer un curso como dios manda de GeneXus, porque por lo visto no lo has hecho.
Luego, problemas para desarrollar sistemas grandes los podes tener desarrollándolos a mano con .Net o Java, sino sabes diseñar bien un sistema y luego programarlo bien seguramente no funcionara al 100%. Y ni te digo sino sabes diseñar bien la base de datos.
Hay que ver que es un sistema grande para ti.
Yo personalmente conozco sistemas grandes que han sido desarrollados por gente de que sabe de GeneXus y funcionan muy bien.
Esta mas que comprobado que GeneXus = desarrollar mas y mejor, por lo menos así lo han demostrado los años.
Y por ultimo, GeneXus como toda herramienta de desarrollo a nivel mundial tiene sus problemas, nadie lo discute, sino esto seria una mina de ORO, nadie en los años que tiene de vida la informática ha hecho una herramienta que te resuelva todo sin darte dolor de cabeza.
Si tu Alfonso eres cliente de GeneXus como lo dices, dudo mucho que no hayas tenido soporte por parte de la gente de Artech, soporte que seguramente te ayudaría a resolver problemas.
Creo que tu comentario carece de credibilidad.
GeneXus no te va a solucionar la vida, pero seguramente te ayudara que sea más fácil.
Tema Performance, en sistemas grandes son muchos los problemas de Performance, comenzando por un buen motor de base de datos.
La fiabilidad en un DBMS que tenga miles de tabla muchas veces hace perder Performance a las aplicaciones.
Por otro lado, es cierto que la gente de Artech deba de mejorar este punto.
Pero creo que siempre le estamos buscando la 5ta pata al gato, sino es una cosa es otra.
20 años de GeneXus, Partners de las mejores marcas, recomendado por las más grandes, es más que suficiente para demostrar que es una buena herramienta, pero como todo siempre tendrá cosas para mejorar.
Señores a trabajar que el año recién comienza.
Alfonso, estoy convencido que el soporte de Artech estará encantado de darte una mano en los problemas que puedas tener.
Por cierto nos gustaría conocerte, ya que tu perfil no lo permite. O por lo menos yo no lo pude ver.
Saludos.
Publicar un comentario