Como desenvolver um módulo Smart Device sobre uma aplicação existente
•Download as PPTX, PDF•
0 likes•623 views
O documento discute três cenários para integrar um módulo de dispositivo inteligente a uma aplicação existente: 1) Usar um modelo de dados próprio para o dispositivo, 2) Acessar diretamente o banco de dados existente, 3) Acessar através de serviços web. Cada cenário apresenta características, vantagens, desvantagens e exemplos. O objetivo é auxiliar na decisão da melhor arquitetura de integração considerando fatores como autonomia, flexibilidade, disponibilidade e impactos no sistema principal.
Recommended
Recommended
More Related Content
Similar to Como desenvolver um módulo Smart Device sobre uma aplicação existente
Similar to Como desenvolver um módulo Smart Device sobre uma aplicação existente (20)
More from GeneXus
More from GeneXus (20)
Como desenvolver um módulo Smart Device sobre uma aplicação existente
- 1. #GXBR Como desenvolver um módulo Smart Device sobre uma aplicação existente? Pablo Mazzilli | pmazzilli@genexus.com | @PabloMazzilli
- 2. #GXBR ?
- 3. #GXBR Arquitetura SD - OnlineArquitetura SD - Offline Cliente SD Server - Backend Serviços
- 4. #GXBR Cenários de integração 1. Modelo de datos próprio do app SD 2. Acesso ao banco de dados existente 3. Acesso através de serviços
- 5. Cenário 1: Modelo de dados próprio para SD
- 6. #GXBR Modelo de dados próprio para SD (Online) API / Serviços
- 7. #GXBR Exemplo Online - Sistema Escolas
- 8. #GXBR Exemplo Online – Find My Plane
- 9. #GXBR Modelo de dados próprio para SD (Offline) API / Serviços
- 10. #GXBR Exemplo Offline – Força Vendas
- 11. #GXBR Modelo de dados próprio para SD Características: • Autonomia • Flexibilidade • Disponibilidade • Dados duplicados? • Outro servidor?
- 12. Cenário 2: Acesso direto ao banco
- 13. #GXBR Acesso direto ao banco (Online / Offline) Acesso Direto / Data Views
- 15. #GXBR Acesso direto ao banco Características: • Acesso em tempo real ao dados • Não requer criar serviços de cópia de dados • Data Type Mapping – Domínio Semântico? • Impactos no sistema principal tem que ser considerados no SD
- 16. Cenário 3: Acesso através de serviços
- 17. #GXBR Acesso através de serviços (Online) Web Services
- 18. #GXBR Exemplo
- 19. #GXBR Acesso através de serviços (Offline) Web Services
- 20. #GXBR Exemplo
- 21. #GXBR Acesso através de serviços Características: • Segurança • Não existe duplicação de dados Desvantagens app Online • Disponibilidade do App depende do sistema principal • Escalabilidade
- 23. Muito obrigado ! Pablo Mazzilli | pmazzilli@genexus.com | @PabloMazzilli
Editor's Notes
- Ao longo deste encontro veram as facilidades que dispomos hoje para desenvolver potentes apps SD. Tanto apps novos, como integrar apps SD sobre meu sistema atual. Se vou desenvolver um app totalmente novo , acho que a solução fica clara, pegar a XEv3 e começar ! Mas a pergunta que muitos de vocês devem estar se perguntando é como posso acrescentar um modulo SD e integra-lo com meu sistema atual, que possivelmente esteja numa versão anteiror de GX. Posso fazer um app SD sobre um sistema externo (não GX) ?
- Entonces, tengo mi sistema, ya desarrollado y funcionando perfecto hace tiempo. Este sistema es de mediano o gran porte, a su vez, el mismo fue desarrollado en versiones viejas de GeneXus anteriores a la Evolution 2, donde se incluyó la posibilidad de generar aplicaciones para Smart Devices, o incluso, no fue implementado con GeneXus o es un sistema cerrado, de caja negra. Y pasa que tengo el requerimiento de agregarle o integrarlo con un modulo de Smart Devices.La interrogante que surge enseguida es:¿Puedo desarrollar un módulo para Smart Devices con GeneXus para estos sistemas?La respuesta es si, si se puede. Bueno, entonces pasemos a ver COMO hacemos esto, que alternativas tenemos para elegir.Podemos también preguntarnos, ¿Necesito migrar mis sistemas a GeneXusEvolution 2 para poder integrarles un módulo para Smart Devices? No, no es necesario.Las opciones son varias y cual es la mejor y más viable opción depende de muchos factores, por ejemplo,Tamaño del sistema, tamaño del módulo para Smart Devices que necesitamos, requerimientos de infraestructura o seguridad que tengamos, el nivel de acceso que tengamos en el sistema existente y varios más
- Para empezar a ver los distintos escenarios que tenemos, repasemos en dos lineas nomas la arquitectura de las aplicaciones para Smart Devices generadas con GeneXus.Estas aplicaciones pueden ser online u offline, o también las llamamos conectadas y ocasionalmente conectadas.En el caso de las aplicaciones online, la aplicación que corre en el dispositivo, se conecta a una capa de servicios, la cual es la que ejecuta toda la lógica de la aplicación, posiblemente accediendo a una base de datos.En el dispositivo solo se maneja todo lo que es interfaz, interpretando una metadata y las respuestas que devuelve la capa de servicios en cada requerimiento.En el caso de las aplicaciones offline, lo que aparece la inclusion de una base de datos del lado del dispositivo y ahora los procesos corren locales, generadores para los lenguajes nativos, accediendo a la base de datos local.
- Dispongo de la KB GX? Tengo acceso a la base de datos ? Solo por servicios?Como les mencioné antes, los escenarios de integración entre un sistema existente y un modulo para Smart Devices son varios y cual usar en cada caso depende de muchos factores.Para la charla yo los dividí en 3 categorias o en 3 tipos, Primero, aquellos donde el la aplicación para Smart Devices tiene su base de datos propia, independiente del sistema existente.Segundo, aquellos que trabajan con un acceso directo a los datos, a la base de datos, del sistema existente.Y por último, aquellos donde el módulo para Smart Devices se comunica, accede al sistema existente exclusivamente a través de servicios.
- Entonces veamos el primero de ellos, cuando tenemos uns base de datos en el módulo para Smart Devices.Tenemos la aplicación SD, tenemos el sistema existente y aquí vamos a ver que en lo que tenemos que trabajar es en cómo comunicamos estos dos componentes, o sea, como sincronizamos la información entre ambas partes.Las opciones son muchas, lo más común es implementar servicios o programas que replican datos de un lado al otro. Puede ser en un sentido o en el otro.Estos programas pueden ser reactivos, por ejemplo, al ejecutar alguna accion en la aplicación para Smart Devices, se llama a un servicio que replica esa nueva informacion en el sistema existente, o viceversa. O tambien se pueden tener programas schedulados, que ejecutan en forma independiente a la operativa de ambas partes, replicando datos de un lado al otro.En un esquema asi seguramente terminemos teniendo varios “tipos” de replicacion, algunos datos los replicaremos automaticamente, en un sentido y en el otro, y otros cada determinado tiempo.¿Y que pasa en el caso de las aplicaciones offline?En este escenario, lo que pasa es que cambia el lugar a donde accede a los datos o ejecuta los programas la aplicación SD en el dispositivo, pero no se afecta en nada lo que refiere a la comunicación con el sistema existente.Los servicios y programas de replicación que implementamos para la arquitectura online, siguen siendo validos y funcionan igual si nos pasamos a la arquitectura offline.
- WAE es un ERP para escuelas. Esta siendo convertido de la 75 a la Xev2 de GX. Pero se queria aprovechar la ola SD y en paralelo se desarrollo este modulo para los alumnos y profesores. Hoy esta en produccion en una de las esculas, con mas de 15000 alumnos y 1200 profesores.
- Entonces veamos el primero de ellos, cuando tenemos uns base de datos en el módulo para Smart Devices.Tenemos la aplicación SD, tenemos el sistema existente y aquí vamos a ver que en lo que tenemos que trabajar es en cómo comunicamos estos dos componentes, o sea, como sincronizamos la información entre ambas partes.Las opciones son muchas, lo más común es implementar servicios o programas que replican datos de un lado al otro. Puede ser en un sentido o en el otro.Estos programas pueden ser reactivos, por ejemplo, al ejecutar alguna accion en la aplicación para Smart Devices, se llama a un servicio que replica esa nueva informacion en el sistema existente, o viceversa. O tambien se pueden tener programas schedulados, que ejecutan en forma independiente a la operativa de ambas partes, replicando datos de un lado al otro.En un esquema asi seguramente terminemos teniendo varios “tipos” de replicacion, algunos datos los replicaremos automaticamente, en un sentido y en el otro, y otros cada determinado tiempo.¿Y que pasa en el caso de las aplicaciones offline?En este escenario, lo que pasa es que cambia el lugar a donde accede a los datos o ejecuta los programas la aplicación SD en el dispositivo, pero no se afecta en nada lo que refiere a la comunicación con el sistema existente.Los servicios y programas de replicación que implementamos para la arquitectura online, siguen siendo validos y funcionan igual si nos pasamos a la arquitectura offline.
- Bueno que ventajas nos provee este escenario:Flexibilidad en el desarrollo del modulo para Smart Devices, al tener su propia base de datos, vamos a poder desarrollarlo como queramos, sin ningun tipo de restriccion en lo que refiere al modelo de datos, de transacciones.Vamos a crear las estructuras que necesitemos, y como las necesitemos para que la aplicación para Smart devices funcione como queramos, pasando la lógica del mapeo con el sistema existente al desarrollo de los programas de replicación.Otra ventaja es que la disponibilidad de la aplicación para Smart devices no depende de la disponibilidad del sistema existente, si se cae el sistema existente, la aplicación SD sigue funcionando sin problema, lo unico que se veria afectado es justamente la replicacion.Como desventaja, lo principal es el hecho de tener datos duplicados. Vamos a tener la misma informacion en dos lugares diferentes, lo que dependiendo del tamaño del sistema y de la cantidad de datos que necesitemos replicar puede llegar a tornar un problema importante el mantenimiento de la replicacion de los mismos.Hay que ver si la flexibilidad que ganamos en el desarrollo SD se compensa con el esfuerzo que nos lleve la implementacion y mantenimiento de la replicacion.
- El segundo escenario, lo podemos ver como un derivado del anterior.La aplicación para Smart Devices, va a seguir accediendo a una base datos, sólo que esa base de datos será directamente la del sistema existente.Tenemos varias formas de implementar esto, en caso de que el sistema existente no haya sido desarrollado en GeneXus la unica opción que tenemos es mediante ingenieria reversa, utilizando el DBRET, acceder a las tablas y crear una KB con transacciones y desarrollar la aplicación para Smart Devices sobre esas transacciones.Si el sistema existente fue desarrollado con versiones viejas de GeneXus, anteriores a la Evolution 2, además de la opcion de usar el DBRET, podemos llegar a crear las transacciones de la aplicación SD mediante un export/import, o sea, exportamos las transacciones desde la KB de la version vieja de GeneXus y las importamos en una KB Evolution 2 para crear la aplicación SD.Bueno y que pasa en el caso que implementemos la arquitectura offline?De vuelta, no van a haber cambios significativos, no va a ser exactamente igual como en el escenario anterior, porque se agrega el hecho de que la aplicación SD va a poder trabajar aún cuando la conexión con el sistema existente no esté disponible.Y en el caso que el sistema existente ya esté desarrollado en una KB en GeneXusEvolution 2, podemos llegar a implementar el modulo para Smart Devices en la propia KB, trabajando sobre las mismas transacciones que el sistema existente, o creando transacciones paralelas para uso exclusivo del desarrollo SD.
- Bien, veamos entonces que ventajas nos trae este nuevo escenario:El acceso directo a la base de datos del sistema existente es de por si una ventaja, tenemos acceso instantaneo a las actualizaciones que se hagan en el sistema existente, no es necesaria ningun tipo de replicacion o mantenimiento.No se duplica informacion y no es necesario realizar ningun tipo de modificacion en el sistema existente o con la comunicación con el mismo.Las deventajas, pueden venir por el lado de mapeo de los tipos de datos que maneje la base de datos del sistema existente, creada con versiones viejas de GeneXus, o sin GeneXus, con los tipos que maneja una KB de Evolution 2.Por ejemplo con lo que refiere a multimedia, imágenes, videos, o archivos, podemos llegar a necesitar desarrollar algun mecanismo de conversion entre lo que espera la KB, el sistema en Evolution 2 y lo que se obtiene de la base de datos del sistema existente.Otra desventaja es que cualquier impacto que haya sobre la base de datos del sistema existente puede llegar a hacer que la aplicación para Smart Devices deje de funcionar sino trasladamos ese impacto al módulo SD.Como ven, en general, estamos mencionando la misma caracteristica, como una ventaja y una desventaja, por ejemplo el acceso directo a la base es una ventaja por la inmediatez de la informacion obtenida, pero tambien una desventaja si llega a haber un impacto en la misma, de que depende si es ventaja o desventaja? Del sistema que tengamos y del modulo para Smart Devices que necesitemos crear, o sea, hay que analizar en cada caso estos puntos y ver que es lo que mas nos conviene.
- Bien, llegamos al tercer escenario de integracion.Muchas veces pasa que al momento de crear una aplicación para Smart Devices integrada a un sistema existente, tenemos restricciones en lo que respecta a la infraestructura del almacenamiento de la informacion.Por ejemplo, un banco, tiene sus sistemas funcionando, con todas las medidas de seguridad necesarias, pero al mismo tiempo desean agregar modulos para Smart Devices para permitir algunas funcionalidades, como consultas, pagos, transferencias, etc.El banco entonces, está dispuesto a desarrollar estos modulos para Smart devices, pero no quiere que se redunde ningun tipo de informacion en los dispositivos o en la aplicación para Smart Devices en general. Entonces, vamos a tener nuestro módulo para Smart Devices, con su capa de servicios pero sin el acceso a una base de datos. Lo que va a hacer es comunicarse con otra capa de servicios provistos por el sistema existente.Como vimos en el primer escenario, aquí donde vamos a poner un poco mas de foco es en el desarrollo de la comunicación entre esas dos capas de servicios.Bueno, y que pasa con la arquitectura offline? O mejor dicho, aplica la arquitectura offline en este escenario?Ya vimos que uno de los requerimientos o necesidades que nos llevan a adoptar este escenario, es no tener ningun tipo de almacenamiento, por lo cual online u offline no podemos tener una base de datos.Pero como tambien vimos al repasar la arquitectura de las aplicaciones offline generadas con GeneXus, no solamente se genera una base de datos del lado del dispositivo, sino que también se generan programas que ejecutan en los dispositivos, por lo que tenemos un nuevo escenario que sería asi:Accediendo a los servicios provistos por el sistema existente, directamente desde los programas que ejecutan en el dispositivo, prescindiendo de esa capa intermedia de servicios de la aplicación para Smart Devices.Les menciono un caso donde se aplicó lo que explica este escenario, una encuestadora, tenia su sistema existente de encuestas y querian desarrollar aplicaciones para Smart devices para que utilizaran los encuestadores, Estas aplicaciones deben funcionar en forma offline, porque se van utilizar en ambientes donde no hay conexión o la conexión es mala y quiere permitirse la realizacion de las encuestas de todas maneras.En este caso hicieron una aplicación para Smart Devices, offline, donde si hay una base de datos en el dispositivo, en la cual se almacena todo lo que ingresan los encuentadores, y luego cuando tiene conexión, se conecta directamente con los servicios provistos por el sistema existentes para mandar y sincronizar informacion.
- http://showcase.genexus.com/app.aspx?infonetcobranzas,esFue hecha por Dvelop y Bancard (Paraguay), es la versión SD del sitio Infonet (no hecho con GX).Permite pagar cuentas mediante debito automático de los bancos o tarjetas.Bancard es como si fuera nuestro Abitab, Redpagos, Sistarbank, todo junto (los principalesbancos son accionistas de esta entidadfinanciera). Procesan 80% de las transacciones con tarjeta de PY.Características de GX que usa:1) Versión X Evolution 2 Upgrade 32) Seguridad bancaria! GAM, con Autenticación externa (Custom )(De hecho contrataron una tercer empresa , argentina, que hizo los securitytests correspondientes y pasaron los tests OK )3) Es completamente basada en Servicios4) Extensibilidad: fue hecha con SD Plus que es un pattern para SD que provee Dvelop
- Bien, llegamos al tercer escenario de integracion.Muchas veces pasa que al momento de crear una aplicación para Smart Devices integrada a un sistema existente, tenemos restricciones en lo que respecta a la infraestructura del almacenamiento de la informacion.Por ejemplo, un banco, tiene sus sistemas funcionando, con todas las medidas de seguridad necesarias, pero al mismo tiempo desean agregar modulos para Smart Devices para permitir algunas funcionalidades, como consultas, pagos, transferencias, etc.El banco entonces, está dispuesto a desarrollar estos modulos para Smart devices, pero no quiere que se redunde ningun tipo de informacion en los dispositivos o en la aplicación para Smart Devices en general. Entonces, vamos a tener nuestro módulo para Smart Devices, con su capa de servicios pero sin el acceso a una base de datos. Lo que va a hacer es comunicarse con otra capa de servicios provistos por el sistema existente.Como vimos en el primer escenario, aquí donde vamos a poner un poco mas de foco es en el desarrollo de la comunicación entre esas dos capas de servicios.Bueno, y que pasa con la arquitectura offline? O mejor dicho, aplica la arquitectura offline en este escenario?Ya vimos que uno de los requerimientos o necesidades que nos llevan a adoptar este escenario, es no tener ningun tipo de almacenamiento, por lo cual online u offline no podemos tener una base de datos.Pero como tambien vimos al repasar la arquitectura de las aplicaciones offline generadas con GeneXus, no solamente se genera una base de datos del lado del dispositivo, sino que también se generan programas que ejecutan en los dispositivos, por lo que tenemos un nuevo escenario que sería asi:Accediendo a los servicios provistos por el sistema existente, directamente desde los programas que ejecutan en el dispositivo, prescindiendo de esa capa intermedia de servicios de la aplicación para Smart Devices.Les menciono un caso donde se aplicó lo que explica este escenario, una encuestadora, tenia su sistema existente de encuestas y querian desarrollar aplicaciones para Smart devices para que utilizaran los encuestadores, Estas aplicaciones deben funcionar en forma offline, porque se van utilizar en ambientes donde no hay conexión o la conexión es mala y quiere permitirse la realizacion de las encuestas de todas maneras.En este caso hicieron una aplicación para Smart Devices, offline, donde si hay una base de datos en el dispositivo, en la cual se almacena todo lo que ingresan los encuentadores, y luego cuando tiene conexión, se conecta directamente con los servicios provistos por el sistema existentes para mandar y sincronizar informacion.
- La app PED de SEADE.SEADE (Fundacao Sistema Estadual de Analisis de Dados) de Brasil (http://www.seade.gov.br/) desarrollaron una app Offline de Encuestas, para recopilar info sobre Empleo/Desemplep en la zona metropolitana de Sao Paulo. Es una app que va sobre servicios existentes. No tiene middleware. Se conecta a los servicios directamente desde la App offline.
- Bueno, ventajas de este esquema:Podemos adaptarnos a los requerimientos de seguridad que se nos imponga sobre el sistema existente, ya que accedemos al mismo solo por lo canales establecidos y autorizados.Por supuesto no hay ninguna duplicacion de informacion, y además obtenemos adaptabilidad para nuestro modulo para Smart Devices. Al ser una aplicación que se comunica exclusivamente a traves de servicios, puedo por ejemplo tomar esa aplicación para Smart Devices y utilizarla integrada a otro sistema existente del mismo tipo, o capaz con pequeñas modificaciones en los servicios del sistema existente, puedo integrarle este módulo.Desventajas, volvemos a tener disponibilidad dependiente, o sea, si dejan de funcionar esos servicios que provee el sistema existente, deja de funcionar la aplicación para Smart Devices,Y bueno, luego, pensemos,
- La interrogante que surge enseguida es:¿Puedo desarrollar un módulo para Smart Devices con GeneXus para estos sistemas?La respuesta es si, si se puede. Podemos también preguntarnos, ¿Necesito migrar mis sistemas a GeneXusEvolution 2 para poder integrarles un módulo para Smart Devices? No, no es necesario.Bueno, entonces pasemos a ver COMO hacemos esto, que alternativas tenemos para elegir.Las opciones son varias y cual es la mejor y más viable opción depende de muchos factores, por ejemplo,Tamaño del sistema, tamaño del módulo para Smart Devices que necesitamos, requerimientos de infraestructura o seguridad que tengamos, el nivel de acceso que tengamos en el sistema existente y varios más