Recomendados
Recomendados
Más contenido relacionado
Más de GeneXus
Más de GeneXus (20)
Modulos en su kb
- 1. #GX23 Módulos en su KB Cristian Inthamoussu #GX3176
- 2. En la mira: módulos de conocimiento Ana Berta aberta@artech.com.uy Claudia Murialdo cmurialdo@artech.com.uy
- 4. #GX23 Módulos en su KB Cristian Inthamoussu #GX3176
- 6. Escenarios
- 7. #GX23 Módulo COMPRAS Módulo PRESUPUESTO Módulo CONTABILIDAD Módulo TESORERI A Módulo PAGAR Módulo STOCKMódulo DEMANDA Escenario I - Subsistema Entendimiento y Mantenibilidad facturan solicitan recursos ¿tengo? si entrego recibo compro no pago contabilizo controlo y reservo presupuesto
- 8. #GX23 Escenario II – KB Componente Interoperabilidad Expedientes Electrónicos • Binarios + Interfaz
- 9. Subsistemas
- 11. #GX23 Objeto ¿Módulo? Dominios, Imágenes, Lenguajes, Temas No WorkPanel, Menu, MenuBar No (solo raíz) Atributo, Tabla Indirecta Transacción, Procedimiento, WebPanels, Panels for SD, etc. Directa ¿Qué objetos están en un módulo?
- 12. #GX23 Nivel de acceso Object Visibility = Public | Private Call For each
- 13. #GX23 Namespace <nombre módulo> . <nombre objeto>
- 14. #GX23 Diagrama
- 15. #GX23 Diagrama
- 16. #GX23 Compatiblidad Bases de conocimiento actuales no sufren cambios de comportamiento Bases de conocimiento con módulos no son compatibles con versiones anteriores de GeneXus
- 17. KB Componente
- 19. #GX23 Reorganización Ver 1 Ver 2 Ver 3 Ver 4
- 21. #GX23 Personalización Event “Imprimir“ Notify "FacturaImpresa" &FacturaId EndEvent Handle(Customer.Events.BeforeInsert, in:&CustomerBC, out:&cancel) Notify “NuevoClienteGrande” if ClienteSaldo > 100000 and after(insert); Eventos definidos por el usuario BeforeInsert AfterUpdate Eventos Predefinidos
Notas del editor
- Bienvenidos! Mi nombre es Cristian Inthamoussu y soy parte del equipo de desarrollo del ambiente de GeneXus.Hoy voy a estar hablando sobre los Módulos en GeneXus.Para los que tienen algunos años con nosotros quizás se acuerden que estano es la primera vez que hablamos de esto.Si bien la necesidad de modularizar la KB existe de antes, en el 2008 nosplanteamosencontrarleunasolución al tema, e identificamosuna serie de escenarios para los cuales seria útil tenerlos.
- En el evento del 2008 hicimos una charla donde contamos cual era la idea que habíamos estado pensado y que queríamos implementar.En ese momento recién habíamos liberado la versión X, que fue en la cual rehicimos de cero el ambiente de desarrollo y para liberarla rápido solo teníamos la parte web.El objetivo de la próxima versión X Evolution 1 era empatar con lo que ya teníamos en la 9.0 o sea la parte window y texto, después de eso venia otra versión que iban a tener los módulos.Entonces además de X Evolution 1 empezamos a trabajar en una nueva versión para implementar los módulos. Esta nueva versión llamamos Pinar.
- Así llego 2010 donde dimos otra charla volviendo a presentar la idea de módulos y mostrando lo que ya teníamos funcionando en esta versión Pinar.Esta versión Pinar era lo que venia luego de la X Evolution 1, sin embargo también había llegado la ola de SmartDevices y se decidió acertadamente liberar una XEvolution 2 que era lo de X Evolution 1 + SD para poder tener algo para SD lo mas pronto posible.Las mejoras de la versión Pinar pasaron a estar luego de la Evolution 2, seguimos trabajando en ambas versiones, luego que se libero la Evolution 2 juntamos las dos versiones y a eso le llamamos la versión Tilo.La versión Tilo es lo próximo que vamos a liberar y ya empezó el proceso de Beta test, ya hay una Beta 1 liberada y una Beta 2 planificado para fin de mes. Esta versión Tilo es la que esta trayendo los módulos.
- Y eso nos trae a hoy donde voy a mostrar nuevamente la solución de módulos en GX pero esta vez hay una versión beta liberada que ya lo tiene.
- Primero voy a explicar los escenarios que queremos solucionar que son básicamente 2, les llamamos subsistemas y kb componente, el primero (subsistemas) es lo que vamos a liberar en Tilo, y el otro va a estar para la próxima versión.
- Vemos cuales son los escenarios
- El primero que llamamos subsistema se da en grandes bases de conocimiento.Supongamos que tenemos un ERP cuyo diagrama seria algo así, cada uno de estos iconos en realidad esta implementado con muchos objetos entonces yo quisiera agrupar estos objetos, esta agrupación serian los diferentes módulos de un sistema.En general un programador va a estar trabajando en un módulo en particular, por ejemplo el módulo de Compras, tenerlo modularizado permite entender mejor cuales son los limites de mi módulo, el programador va a poder especificar que cosas son internas al modulo y cuales van a ser visibles desde fuera, entonces cuando quiera usar otro módulo como el de stock va solo a ver disponible los puntos de entrada que el desarrollador de ese modulo quiso.Esta modularización en realidad se puede hacer hoy manualmente con carpetas, nomenclatura y metodología, el problema que al ser manual se pueden cometer errores, y si por ejemplo entra un desarrollador nuevo hay que explicarle como se debe trabajar y se corre el riesgo que por desconocimiento haga las cosas mal.Al GX saber lo que es un módulo puede controlar que cosas se pueden usar de otros módulos, y simplificar las cosas que veo accesibles, también puede mostrarnos cuales son las dependencias de un modulo a los demás automáticamente.Este escenario entonces nos ayuda al entendimiento y mantenibilidad de una KB.
- El segundo escenario es de bases de conocimiento componente.Hoy tenemos dos casos existentes nuestros de KB componente, estos son Gxflow y GAM, ambos son un caso de un módulo genérico de software que quiero utilizar en diferentes bases de conocimientos.Otro ejemplo podría ser un módulo genérico de manejo de expediente electrónicos.La diferencia con el escenario anterior es que yo quiero distribuir los binarios de mi modulo mas cuales son los puntos de entrada a mi módulo, hoy para GAM por ejemplo lo que se importa es un conjunto de objetos externos que representa la interfaz que tengo para usarlo, pero lo mejor sería que se vea como un solo objeto que es el modulo GAM, de esa manera una KB que usa GAM queda más limpia.Existe un caso particular de este escenario cuando se quiere que la misma KB sea componente y cliente a la vez. Por ejemplo en la KB de escenario anterior podría tener el modulo de compras en mi KB y todo el resto de los módulos tenerlos como binarios.Este escenario entonces ayuda a la interoperabilidad entre bases de conocimiento.
- Vemos entonces como resolvemos el escenario de subsistemas
- Venimos hablando de módulo y seguro que todos tenemos una idea de que son, pero me gustaría tomar un segundo para ver esta definición global (no referente a la informática propiamente).Un concepto interesante que aparece es el de “componente autocontrolado” que no se ha mencionado: la idea de los módulos es que sean una unidad funcional, y eso solo lo pueden decidir quiénes lo están desarrollando.El segundo concepto es el de “interfaz”, este es primordial sobre todo en el segundo escenario para que una base de conocimiento componente pueda ser consumida correctamente.Tenemos el concepto de “facilitar”.Y por último “reparar” o como mencionamos en el primer escenario, mantener nuestra base de conocimiento.
- ¿Qué es un módulo en GeneXus?Es un nuevo objeto es una forma nueva de categorizar los demás objetos. Si ven en el árbol es similar a un folder.Todos los objetos pertenecen a un modulo, hay un módulo que van a tener todos que es la raiz llamado Root Module, un modulo puede tener submodulos dentro como estan ahí Compras, Autorizaciones, etc.
- ¿Cómo impacta en los otros objetos de la base de conocimiento?Cada objeto de la base de conocimiento pertenece a un módulo, excepto el caso de los dominios, imágenes, lenguajes y temas. Estos objetos son globales a la base de conocimiento.El resto de los objetos pertenece a un módulo, y a solo uno. Tenemos los objetos WorkPanel, Menu, MenuBar que estan en el Root Module pero solo son validos ahí, esto es porque los generadores Windows y de Texto no van a soportar módulos.Los demás si pueden estar en cualquier modulo pero hay dos clases de pertenencia: Directa e Indirecta. La pertenencia directa se realiza a través de una propiedad en el objeto; la indirecta es la que aplica para el caso de atributos y tablas: pertenecen al módulo al cual pertenece la transacción que los define.Como consecuencia de este tercer punto, tenemos el caso de “Transacciones paralelas” : como todo objeto pertenece a un solo módulo, una tabla solo puede pertenecer a un módulo, y por lo tanto todas las transacciones que la definen deben encontrarse en el mismo módulo.
- Los objetos que pertenecen a un modulo tienen una propiedad ObjectVisiblity con valores Publico y Privado.Publico significa que el objeto puede ser utilizado desde cualquier punto de la base de conocimiento,Privado significa que puede ser usado solo dentro del módulo. Eso incluye a los submodulos. O sea un submodulo puede usar los objetos privados del modulo padre.La lista de objetos públicos son los que conforma la interfaz del módulo, esta puede ser vista abriendo el módulo en una parte Interface, también hay una parte Diagram que veremos más adelante y la Documentation que tienen todos los objetos.Al momento de llamar a un objeto de un modulo solo se verán los que son visibles para el lugar donde estoy haciendo la llamada.Para el foreach me dejara solo utilizar las tablas y atributos que son visibles. La propiedad ObjectVisibility para Tablas y Atributos es inferida a partir de la transacción que la define.
- Los módulos van a definir un namespace, esto quiere decir que voy a poder tener dos objetos del mismo nombre si están en módulos diferentes.Los objetos entonces van a tener un nombre totalmente calificado que es la ruta de módulos y el nombre, pero en realidad al usarlo el nombre del módulo es opcional a menos que haya ambigüedad.
- Como comentaba antes voy a tener la posibilidad de tener un diagrama con los módulos de mi KB.En esta se ven los módulos hijos de Compras que son Autorizaciones y Cotizaciones y los módulos usados por Compras que son Contabilidad y Stock.Si ven las flechas que indican referencias hay un botón, que al presionarlo muestra el detalle.
- Aquí podemos ver todos los objetos del módulo Compras que usan a Stock, y si voy seleccionando veo a que objetos esta usando.
- Como toda característica nueva, las bases de conocimientos actuales van a seguir funcionando sin ningún cambio.Pero si al abrirlas en la versión Tilo va a haber una conversión donde básicamente va a poner a todos los objetos en el módulo Root Module.Esto quiere decir que luego de convertido no se va a poder abrir con versiones anteriores, y que para trabajar con GxServer voy a precisar un GxServer Tilo.
- Veamos ahora el segundo escenario de KB Componente
- Voy a tener mi modulo exportado como un interfaz que va a ser lo que importen en la otra KB y por otro lado un conjunto de binarios para los cuales tengo que decidir que plataforma y base de datos usar, teniendo la posibilidad de tenerlo para varias.¿Qué ventajas tiene este mecanismo?No impacta en la performance de la aplicación en diseño, la cantidad de objetos que va a tener es solo uno que es la interfaz de mi módulo.Dado que el código va como binarios se puede resolver el problema de la propiedad intelectual.No tiene impacto en la base de datos, ya que no se tienen las transacciones en la base de conocimiento. Puede utilizar una base de datos independiente, puede configurarse para esta aplicación en particular (puede ser la misma base de datos que mi aplicación o no).
- A medida que voy desarrollando un KB empiezo con una base de datos versión 1 que va evolucionando con el tiempo a otra versión 2, versión 3 y así.Para cada uno de esto pasos GX genera una reorganización de los datos. Si uno guarda cada una de estas reorganizaciones se puede hacer ir a una BD con cualquiera de estas versiones y llevarla a la versión última.Eso vamos a automatizar, guardar las reorganizaciones, detectar automáticamente en que versión estoy y aplicar las necesarias para llevarla a la ultima.
- Una caracterisica que tiene por ejemplo GAM es que junta varios objetos GX en uno solo de forma que sea más fácil de usar.Aquí tenemos un BC Expendiente y un par de procedimientos, que para la KB destino lo va a ver como un objeto Expediente con propiedades y métodos.
- Por ultimo hay veces que quiero que mi módulo pueda ser extendido y personalizado para contemplar cierta funcionalidad que es particular para la KB que usa nuestro módulo.Para esto vamos a permitir definir y manejar eventos.Voy a tener eventos predefinidos para algunos objetos por ejemplo BeforeInsert o AfterUpdate para una transaccion.Y voy a poder definir eventos particulares, esto lo puedo hacer en las reglas o en el código.Luego voy a poder manejar eventos publicados por otros objetos, por ejemplo acá maneja el evento BeforeInsert del objeto Customer que recibe el BC y permite cancelarlo.
- Resumiendo entonces, en la versión Tilo vamos a liberar las características para resolver el escenario de subsistemas, y queda el escenario de KB componente que va a ser implementado en la próxima versión.
- Muchas gracias