Como desarrollarunmoduloparasd sobreunaappexistente2ivette
•Descargar como PPTX, PDF•
0 recomendaciones•214 vistas
Recomendados
Más contenido relacionado
Destacado
Destacado (16)
Similar a Como desarrollarunmoduloparasd sobreunaappexistente2ivette
Similar a Como desarrollarunmoduloparasd sobreunaappexistente2ivette (20)
Más de GeneXus
Más de GeneXus (20)
Como desarrollarunmoduloparasd sobreunaappexistente2ivette
- 1. #GXMX ¿Cómo desarrollar un módulo para Smart Devices sobre una aplicación existente? Ivette González García igonzalez@genexus.com @gx_ivette
- 2. #GXMX ¿Puedo desarrollar un módulo para SD sobre una aplicación ya existente? SI
- 3. #GXMX Arquitectura SD - OfflineOnline
- 4. #GXMX Escenarios de integración Base de datos en el módulo SD Acceso directo Acceso mediante servicios
- 5. #GXMX Base de datos en el módulo SD
- 6. #GXMX • Desventajas Duplicación de datos Mantenimiento • Ventajas Disponibilidad independiente Flexibilidad Base de datos en el módulo SD
- 8. #GXMX • Ventajas Acceso directo No hay duplicación No se requieren modificaciones en el sistema existente • Desventajas Mapeo de tipos de datos Impactos en el sistema existente Acceso directo
- 10. #GXMX • Ventajas Seguridad No hay duplicación Adaptabilidad • Desventajas Disponibilidad dependiente Acceso mediante servicios
- 11. #GXMX • Servicios como datos • Transacciones dinámicas ¿Funcionalidad limitada? NO Acceso mediante servicios
- 12. #GXMX
- 13. #GXMX ¿Puedo desarrollar un módulo para SD sobre una aplicación ya existente?
Notas del editor
- Buenas tardes, Mi nombre es Ivette González, formo parte del equipo de Operaciones de GeneXus México y es un gusto para mi poder estar aquí con ustedes. En el transcurso de las conferencias pudieron observar que se ha hablado de la importancia de generar aplicaciones para dispositivos móviles ya que hoy en dia han impactado fuertemente no solo en el uso de aplicaciones como redes sociales o juegos, sino aplicaciones con funciones más variadas como aquellas que puedan interactuar con sistemas corporativos.
- Ahora, que pasa cuando tengo mi sistema ya desarrollado, funciona correctamente y no se encuentra en la última versión de GeneXus, lo tengo en alguna versión anterior o inclusive se puede dar el caso de que este hecho con alguna otra herramienta. La interrogante sería: ¿Puedo desarrollar un módulo para Smart Devices con una aplicación ya existente? …. La respuesta es SI y lo que deseo mostrarles en esta charla son 3 escenarios donde podemos realizar una integración de un módulo para Smart Devices con un sistema Existente sin necesidad de tener por ejemplo, que migrar toda la aplicación a la última versión o crearla desde cero si no estuviera hecha con GeneXus.
- Antes de empezar a mostrarles los escenarios que les comento, quiero hacer mención de las diferentes arquitecturas de las aplicaciones para Smart Devices generadas con GeneXus. Estas aplicaciones pueden ser online u offline, o también llamadas 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, aparece del lado del dispositivo una base de datos que esta corriendo en el mismo, además de que la lógica de la aplicación que corría en la capa de servicios ahora corre en el mismo dispositivo, sin embargo la capa de servicios se sigue manteniendo por que eventualmente sincroniza los servicios de la bd centralizada y la Bd local de cada uno de los dispositivos.
- Ya identificadas las arquitecturas, los diferentes escenarios de intregración entre un sistema existente y un módulo para aplicaciones móviles son variados y determinar cual usar depende de muchos factores, por ejemplo, el tamaño del sistema existente, el tamaño del módulo que deseamos hacer para la aplicación SD, incluso depende del nivel de acceso al sistema existente, si podemos tener acceso a la BD, si podemos modificar los datos directamente, si no podemos hacer nada. En base a esto se mostrarán 3 categorias: Primero, aquellos donde 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 accede al sistema existente exclusivamente a través de servicios.
- Entonces veamos el primero de ellos, cuando tenemos una 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. 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. Para que quede más claro, les voy a poner un ejemplo. La aplicación que desarrollamos para el evento, la agenda que espero la hayan podido descargar, esta basada en este escenario, donde, la BD corporativa de la app existente tiene varias tablas e información que para este caso no nos interesa. Por tanto el módulo de la app del evento se desarrollo con una BD local con tablas particulares. Entonces cuando haciamos un cambio, por ejemplo en alguna conferencia, ya fuera el cambio de horario o de orador, era un cambio importante donde deseamos que se actualizara en automático en ambos lados, por tanto se tenia un servicio que se ejecutaba en el momento que se hacia el cambio pero si necesitamos agregar información adicional como un nuevo hotel era un cambio de importancia menor que para actualizar la inf. Se lanzaba un procedimiento programado eventualmente. ¿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 GeneXus Evolution 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. Un ejemplo podría ser: Imaginen que el INEGI necesitará una aplicación donde poder generar las encuestas para ya no hacerlas en papel. Si se les hiciera una app SD se debe considerar que debe 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 donde puedan, dentro del dispositivo almacenar todo lo que ingresan los encuentadores, y luego cuando tengan conexión, se conecte directamente con los servicios provistos por el sistema existentes para mandar y sincronizar información.
- 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,