042 Compartiendo Fuentes De Datos Data Providers
•Descargar como PPTX, PDF•
0 recomendaciones•1,098 vistas
Recomendados
Recomendados
Más contenido relacionado
Similar a 042 Compartiendo Fuentes De Datos Data Providers
Similar a 042 Compartiendo Fuentes De Datos Data Providers (14)
Más de GeneXus
Más de GeneXus (20)
Último
Último (20)
042 Compartiendo Fuentes De Datos Data Providers
- 1. Compartiendo fuentes de datos: data providers Luis Murillo lmurillo@artech.com.uy
- 5. Agenda Motivación Casos de uso Lo nuevo en Evolution 1 Futuro
- 6. Motivación Motivación Casos de uso Lo nuevo en Evolution 1 Futuro
- 7. Motivación Declarativo vs Imperativo Qué en lugar de Cómo
- 8. Motivación
- 10. Motivación QUE
- 11. Motivación COMO QUE 16/09/2009 09:45 Evolución del lenguaje GeneXusby Gaston Milano
- 12. Motivación
- 13. Casos de uso Motivación Casos de uso Lo nuevo en Evolution 1 Futuro
- 14. Casos de uso Un dominio especifico de problemas
- 15. Casos de uso Datos con estructura
- 19. Casos de uso Inicialización de datos DP y BC para inicializar datos http://arminbachmann.blogspot.com/ Karina me lo dijo hace 20 años…. http://blog.genexus.com/guscarr/
- 20. Casos de uso Datos con estructura Web 2.0 – UserControls Arquitectura de los sistemas Inicialización de datos
- 21. Lo nuevo en Evolution 1 Motivación Casos de uso Lo nuevo en Evolution 1 Futuro
- 22. Lo nuevo en Evolution 1 FreeBasewww.freebase.com ‘Freebase is an open, shared database of the world's knowledge’
- 23. Lo nuevo en Evolution 1 Data ProviderGenerator
- 24. Lo nuevo en Evolution 1 Data ProviderGenerator - Arquitectura
- 25. Lo nuevo en Evolution 1 Data ProviderGenerator - Overview
- 26. Futuro Motivación Casos de uso Lo nuevo en Evolution 1 Futuro
- 27. Futuro Data Provider in line o embedded
- 28. Futuro Data ProviderGenerator Alimentándose de mas fuentes de datos
- 29. Data Providers
- 30. Conferencias relacionadas 16/09/2009 09:45 Gastón Milano Ballroom BEvolución del Lenguaje GeneXus16/09/2009 11:00 Alejandro Panizza Ballroom AREST web services
Notas del editor
- Vamos a estar hablando en esta charla sobre el nuevo tipo de objetos introducido en GeneXus X llamado Data Provider.Primero que nada, para los que no conocen los DP, les voy a contar qué son. Los DP son un nuevo tipo de objeto introducido en GX X para resolver un subconjunto de problemas que resolvíamos con procedures.Esto lo quisimos hacer debido al objetivo que siempre tuvo GX de ser declarativo. Los DP tienen un nivel mayor de declaratividad que los procedures.¿No se si muchos de ustedes han venido a mi charla sobre el tema que di en el encuentro del año pasado?Bueno, yo abría esa charla con la siguiente grafica, la cual mostraba la distribución de objetos en una KB GX entes de la existencia de los DP, en la cual se veía un numero considerable de Procedimientos.
- Al finalizar la charla, mostraba esta otra grafica con mi deseo para las mediciones futuras de KB GeneXus, donde – quizá exageradamente en forma intencional – mostraba el surgimiento de el uso de este nuevo tipo de objetos llamado Data Provider.
- Bueno, hoy tengo la grata noticia de informarles, que la realidad esta comenzando a cumplir mi deseo. Aquí vemos la grafica de la KB utilizada en el laboratorio que estamos brindando en este Evento. Y así como en esta KB en todas las KB que se están desarrollando en GX X y GX X ev1, comienzan a aparecer objetos de tipo Data Provider sustituyendo a una clase especifica de procedimientos. Espero que después de esta charla, cada vez que estemos frente a un requerimiento perteneciente al domino de problemas para los que creamos los DP, no escribamos mas un procedimiento como hacíamos antes sino que lo resuélvamoscon un Data Provider.
- Entonces hablaremos en esta charla sobre la motivación que tuvimos para crear los DP.Veremos los casos de uso mas destacados.Lo nuevo introducido en Evolution 1.Y las expectativas de futuro que tenemos en relación a esto.
- Cual fue la motivación para tener este nuevo tipo de objeto. Estudiando varias KBs veíamos que había mucho código procedural. Siendo que la filosofía GeneXus es y será ser declarativo, intentamos ver si podíamos sustituir algunos de esos procedimientos con un tipo de objeto mas declarativo.Para ver porqué queremos ser declarativos en nuestra sintaxis, lo mejor es ver qué es ser declarativo. Es decir qué queremos implementar en lugar de decir como debe ser implementado.Los lenguajes imperativos están mas orientados a la arquitectura del computador, en cambio los lenguajes declarativos están mas bien basados en el modo de pensar de los humanos (están próximos a las matemáticas).Están mas cerca de una especificación que de un programa.En los lenguajes declarativos un programa es mas parecido a un query a una base de datos que a un programa tradicional.Eso fue entonces lo que se busco en la implementación de los DP, dentro de la problemática que estábamos resolviendo con Procedimientos, identificamos un subconjunto para los que podíamos ofrecer una sintaxis mas elegante, declarativa.
- Cual es ese dominio de problemas que identificamos entonces.Todos los procedimientos los podríamos definir de la siguiente forma y aparentemente serian iguales.Es decir un proceso que recibe algún input, se realiza una transformación y entregan un output. La diferencia es que en un procedure común el foco esta en el lenguaje de transformación mientras que en los Data Providers el foco esta en el Output.Por lo tanto cuando tenemos un proceso cuyo objetivo principal es devolver un conjunto de datos con estructura, la mejor solución es usar un Data Provider.Veámoslo en el siguiente ejemplo, supónganse que tuviéramos la necesidad de devolver una lista de Clientes con lo facturado pero detallando además el total por producto, claramente acá el foco esta en la salida.
- Aquí vemos como resolvíamos esto con un procedure. No vamos a analizarlo en detalle pero ahí ven que hay un recorrido por clientes, dentro de eso un recorrido por productos, algunas variables auxiliares para ir calculando totales, los ‘new’ que crean nuevos registros, y entre medio de todo eso, se van cargando los campos del SDT… El punto es justamente que está mezclada la lógica de obtener los datos, con la lógica de cargarlos en la estructura de salida.En definitiva estamos de alguna manera, diciendo mas que nada cómo hacer las cosas, mezcladas con lo qué queremos obtener.Déjenme contarles algo que a mí me pasaba y que quizá a ustedes también les haya pasado. Cuando escribía este tipo de procs, en los que tenía que dar como resultado una estructura, sentía como una tendencia a escribir el código indentándolo de acuerdo a esa estructura, las asignaciones de los campos del primer nivel están en un primer nivel de indentación, las asignaciones del siguiente nivel están en un nivel adicional de indentación. Era algo que me ayudaba a entender lo que estaba escribiendo, y que para cosas simples me funcionaba bastante bien. Eso facilita bastante leer el código y entender qué es lo que se está haciendo.Pero ya ven en este ejemplo (que tampoco es tan complejo), se tiene que agregar algún otro “foreach” para resolver alguna cosa, o incluir un “íf” para hacer algún calculo diferente según alguna condición, etc., etc.. El problema es que cada una de estas estructuras nos lleva a utilizar también niveles de indentación, y entonces hace imposible mantener solamente los niveles de indentación que replicaban la estructura de salida (con lo cual dificultaba identificar en el código la estructura de lo que estaba cargando), a menos que renunciara a indentar dentro de las estructuras de control (con lo cual dificultaría la legibilidad de la lógica de obtención de los datos). Esto pasa en el ejemplo que estábamos viendo, y este es un ejemplo bastante sencillo simplemente para ilustrar el punto; la realidad suele ser bastante más compleja que esto.Esta tensión entre una cosa y otra resulta bastante frustrante, y en definitiva no es sino una consecuencia natural de que en el código estamos mezclando la lógica de obtención de los datos con la carga de la estructura que devolvemos. Justamente porque está mezclada una cosa y la otra, se hace difícil mirando el código, entender una u otra cosa por separado.Acá en definitiva hay mucho del Cómo resolver el problema.
- Por eso me cautivaron rápidamente los DP, cuando vi que yo podía expresar lo mismo que en el proc de este ejemplo con el siguiente DP.¿Por qué se puede lograr eso con los DP y no con los proc? Precisamente porque en los DP solamente declaramos lo que queremos cargar, junto con algunas pequeñas precisiones acerca de dónde salen los valores. Por ejemplo, el campo CustomerId se carga desde el atributo CustomerId, así que con poner CustomerId no hace falta aclarar más. Para indicar que en CustomerTotal se suman los InvoiceTotal, uso una expresión simple que indica eso; no tengo que declarar una variable, hacer un foreach, ir sumando, etc. Y por supuesto, cada nivel de indentación que ponemos es suficiente para que GX sepa que tiene que hacer una iteración, sin necesidad de que escribimos un foreach explícitamente. Ahora que la lógica de cómo obtener los datos no es necesario escribirla en forma procedural, tampoco es necesario tener un segundo criterio de indentación que entre en conflicto con el de la estructura de los datos. En el proc era difícil leer una cosa u otra a simple vista, porque estaban las dos mezcladas. Ahora no hay manera de que se mezclen porque una de las cosas ¡directamente ya no está! ¡La solución era obvia! Bueno, al menos eso parece, como suele pasar con todas las soluciones una vez que las encontramos.
- Eso fue lo que nos llevo a sustituir los procedimientos para resolver una determinada clase de problemas con una sintaxis declarativa: Data ProvidersPero no solo la estética visual y claridad de lectura es lo que importa.Pensaba en una analogía para ejemplificar, imaginen que después de un día de trabajo quisieran que una vez en la vida su hijo le hiciera la cena. Supongo que mas de uno lo habrá pensado alguna vez. Pero para poder hacer eso, primero deben indicarle Cómo hacerlo, para que luego sí él repita lo aprendido. Eso es ser Imperativo.Compárenlo con la diferencia de ir a un restaurante (que en definitiva supongo es por lo que optaran), en ese caso se sientan y le indican al mozo Qué quieren comer, es el chef el que decide como hacerlo.La ventaja de esto es que en el caso anterior se repetirá lo aprendido, en este caso el chef decidirá cual es la mejor forma de implementar lo que uds. desean.Esto es lo que buscamos en GeneXus, los invito a participar de la charla que va a estar dando Gaston Milano sobre Evolución del lenguaje GeneXus.
- Por lo tanto como en los DP digo “qué quiero obtener” pasa lo mismo que en el restaurante, siempre estaremos a un F5 de distancia de que GeneXus implemente la solución de la mejor forma posible. El Data Provider siempre será valido. Hoy GeneXus implementara la solución pensando en un equipo con un solo procesador, con la tendencia actual de tener cada vez mas procesadores por equipo, podría implementarlo utilizando esta facilidad distribuyendo la consulta en varios subselects y en el futuro de acuerdo a lo que el futuro ofrezca.
- Decíamos antes que el dominio de problemas que proponemos resolver con DP es aquel donde lo mas importante es la estructura de salida que pretendemos devolver. O sea aquellos procesos donde el foco esté en la estructura a devolver.Veamos entonces algunos casos de uso, algunos tradicionales y otros que en la realidad actual se transformaron en problemas comunes.
- Identificar bien el dominio de problemas al cual aplican es importante, porque el surgimiento de los DP ¿significa que dejaremos de usar los procedimientos? No. Miren, cuando solo existían los barcos como medio de transporte, todos los viajes se hacían en barco. Luego aparecieron los aviones. Esto quiere decir que no se usaran mas los barcos. No. Cada uno resuelve de la mejor manera un tipo de problemas. Si estoy en viajes de negocio y no quiero perder tiempo en el traslado, usare el avión. Pero en cambio si quiero hacer un viaje de placer al estilo crucero, el barco sigue siendo valido. Cada uno tiene un dominio especifico de problemas para lo cual es la mejor solución.Veamos entonces algunos casos de uso para Data Providers.
- El compartir datos estructurados o proveer datos estructurados es cada día mas una necesidad, dándole además a estos datos un formato, formatos que ya son estándares hoy como XML o JSON para hacer mas liviana la transferencia, y otros que aparezcan en el futuro. Tan común se están volviendo que hasta en las remeras se usan.Por lo tanto para estos casos es mejor usar DP. Por que el foco en estos casos esta en la estructurada a devolver, donde el tema de darle formato ya sea XML o JSON, en GeneXus es trivial, solo tenemos que pedírselo, GeneXus lo hace solo.Que queremos obtener: el output, la estructura de datos a devolver, descripta declarativamente en el DP. Y en que formato: p.e. en GX los metodosToXML(), ToJSON()
- Web 2.0, aplicaciones ricas, usables. Hoy las aplicaciones son web y necesitan este tipo de interfaces. Las reclama el usuario, no hay alternativa.Para esto entre otras cosas en GeneXus tenemos los UserControls.
- La mayoría de estos controles, se alimentan precisamente de datos en formato estructurado, o sea de SDTs. Por lo tanto la mejor opción para compartir los datos de mi DB con estos controles o proveerles de datos es a través de Data Providers. Incluso muchos de los controles, directamente se alimentan del Data Provider. Esto es, directamente hay una property en el control donde puedo indicar el DP del cual se alimenta.
- La arquitectura de los sistemas esta cambiando. Hoy ya no es del todo posible implementar mi sistema monolítico, ya que en general el nivel de automatización de las empresas es grande, por lo tanto es muy posible que lo que se quiera es la mejor solución en su clase para cada área.Esto hizo cambiar la arquitectura de los sistemas que debemos desarrollar hoy.
- Estamos hablando de la Arquitectura orientada a servicios.Por lo tanto cada modulo de mi sistema debe tener implementada una capa SOA. Esto es, un conjunto de servicios que permitan a mi aplicación interactuar con otras, compartir mis datos con el mundo. Estamos hablando de disponibilizar las operaciones de interacción con la DB de mi sistema (CRUD) con aplicaciones de terceros. Si bien el Insert/Update/Delete lo tenemos bien resuelto con los BC los cuales podemos exponer como WS, también es una especie de estándar para esta arquitectura contar con la operación GetList, o sea GetClientList, GetProductList. Pedir a otra aplicación una lista de una determinada entidad. Claramente la mejor forma de resolver esto es con Data Providers, los cuales también cuentan con una property para indicar si los quiero exponer como WS.Esta arquitectura es una de las causas por las cuales se había incrementado el numero de procedimientos por KB.
- Por ultimo la inicialización de datos a la hora de implantación de los sistemas.
- No podemos pensar en enloquecer a los usuarios, a la hora de implantar un sistema, haciéndolos ingresar todos los datos necesarios para la operativa. Hay un gran conjunto de datos que son universales y debemos proveerlos precargados.Nos referimos por ejemplo a las unidades de medida, países, monedas y un sinfín mas.
- Esta problemática era resuelta tradicionalmente con procedimientos que hacían un montón de News.Este es otro caso donde la mejor solución es el Data Provider.Las ventajas:Mas legible (queda mas claro que registro del segundo nivel corresponde a cual del primero)No preciso usar variables auxiliares para obtener el resultado del AutonumberMenos asignaciones porque las cosas se resuelven en el BC (p.e.InicialValue de InvoiceDate en Today())No vuelvo a programar reglas de negocios en el procedimiento evitando errores e inconsistenciasHay dos post muy interesantes sobre el tema en los blogs de Gustavo y Armin.Veremos ahora después, que en Evolution 1 es mas fácil aún la solución a este tipo de problemas.
- A modo de resumen, entonces estos son los cuatro principales dominios de problemas para los que los DP es la mejor solución.
- Y ahora si, pasemos a lo nuevo en Evolution 1.
- Como veíamos antes, la problemática de inicializar datos a la hora de implantar un sistema es algo común. Esto ha hecho que comience a surgir una especie de nicho de mercado, la oferta de datos.Así surge, entre otras FreeBase. Free base es básicamente un UDM, colaborativo y gratuito, el cual, simplificando un poco, organiza los datos en Types (que serian como la temática de los datos que buscamos), donde cada Type tiene Properties que son los datos en si que deseamos. O sea podría buscar Types como ser Países, Monedas, Películas y elegir la que mas me convenga, la cual por ejemplo tendrá las Properties, NombrePais, IdiomaPais.Como la definió Jodal, es una especie de Wikipedia pero para los datos, la cual además de poder buscar on line, disponibiliza un conjunto de Apis.
- Aprovechando esta nueva realidad en GX X evolution 1 implementamos Data ProviderGeneratos. Esta nueva tooles un generador de Data Providers. Recuerdan lo que veíamos recién, los Data Providers para inicializar datos. Bueno, si contamos con una fuente de datos con la información necesaria, ya ni siquiera tendremos que escribir manualmente el DP que recién veíamos. Data ProviderGenerator se puede alimentar de ella y automáticamente escribirnos el DP para inicialización.Eligiendo la opción DPG, le indicamos un par de cosas a la herramienta y escribe automáticamente el DP con los Datos.Saben lo que mas me gusta de esto, que parece que con el paso del tiempo cada ves estamos viendo no solamente que GeneXus genera código en los lenguajes tradicionales, sino que comenzaron a aparecer herramientas que ahora generan código GeneXus. Un nivel mas de abstracción. Piensen en GeneXusPatterns, piensen en Data ProviderGenerator.
- Veamos un poco la arquitectura, de DPG.Se puede alimentar de fuentes de datos donde tengamos los datos que necesitamos, los cuales puedo buscar de acuerdo al tipo que tengan en su almacenamiento. Una ves que elijo la fuente deseada, le indico cual será el SDT (el item) que deseo cargar. Realizo el mapeo entre los elementos del item y las propiedades de la fuente y DPG escribirá el DP por nosotros con los datos para que luego lo usemos para poblar un BC de mi sistema.
- Veamos rápidamente el funcionamiento de DPG (alimentándose de Freebase).Esta es la pantalla que aparece al ejecutar DPG. Ahí buscamos por alguna palabra clave que indica que tipo de información queremos obtener. Country en el ejemplo.En este momento (utilizando las apis que provee Freebase) DPG presenta todas las fuentes de datos relacionada con países y elegimos una.En el siguiente paso se muestran las properties de la fuente elegida, con un ejemplo con datos cargados. Nosotros debemos elegir el SDT que se va a cargar y matchear cada elemento del SDT con una propiedad de la fuente.Al confirmar, DPG escribe el DP para inicialización con los datos obtenidos de Freebase.Lo único que resta hacer es alimentar el BC de nuestra transacción con dicho DP y obtenemos los datos cargados.
- Como ya vimos un escenario cada vez mas común en el código procedural GX (procs, events) es el tener que cargar un SDT. En general este código no es muy elegante, por ejemplo el código para cargar los Tabs en el WorkWith es algo como lo que se ve en la ppt. Claro que este código se puede sustituir por un Data Provider y llamar en el código al DP. El problema de esta solución es que se crea un objeto nuevo cuando si embebemos el DataProvider en el código quedaría todo mas fácil de entender.Frente a las posibilidades de reúso del DP, podremos en el futuro decidir si escribimos el DP o lo escribimos inLine.No se si será esta la sintaxis exacta pero es la idea lo que les quiero transmitir.
- Data ProviderGenerator hoy se alimenta solamente de Freebase como ya vimos, pero este tema de proveer datos en formatos relativamente estructurados, parece ser un negocio que estaría surgiendo.No es objetivo de esta charla analizar el modelo de negocios para esto, pero claramente ingresar datos a un sistema tiene un costo determinado de horas/hombre, por lo tanto es una cuestión de costos.Así como freebase, existen otras. P.e.Swivel, Google Base.Y por que no GXBase? Buscando información en repositorios de KBs que estén en algún GXServer.Nosotros con GXServer mas un conjunto de APIs REST (las cuales tenemos en beta y estaremos liberando en algún Upgrade) podremos acceder a el conocimiento en un GXServer. Siempre lo vimos por el lado de compartir conocimiento, pero ya que tenemos ahora esta clase de DP con datos para inicializar, también podremos acceder a ellos usando estas Apis desde DPG. Con lo cual ahora además de conocimiento podremos compartir Datos.La idea entonces seria un GXServer, con un buen conjunto de DP por tema (mantenidos por la comunidad, gratis o no de acuerdo al creador de los mismos), el cual podemos seleccionar como fuente de información para DPG y obtener automáticamente el DP en mi KB con esos datos.
- Concluyendo entonces, la idea a transmitir es que a partir de GeneXus X contamos con un nuevo tipo de objetos, declarativo que resuelve un subconjunto especifico de problemas que antiguamente resolvíamos con Procedimientos. Entonces los invito a usarlos. Si tenemos un clavo usemos un martillo, pero si tenemos un tornillo lo mejor es un destornillador. Y parecería que cada vez están apareciendo mas tornillos.Por lo tanto los invito a usarGeneXus X para poder entre otras cosas utilizar estas nuevas funcionalidades que vimos, Data Provider, Data ProviderGenerator y un gran numero más de beneficios incorporados en esta versión.Es tiempo de actuar!!!