Hola,
Me llegó la siguiente pregunta, muy interesante por eso la subo aquí a la sección de Q&A del Blog.
Problemática
Una empresa quiere desarrollar una aplicación móvil en Windows Mobile que funcione desconectada con datos extraídos de SAP en la mañana (usando la cuna) y por la tarde poniéndolos en el móvil en la cuna subir los datos nuevamente. Para ello utiliza un Web Service que expone el módulo Business Connector.
¿Cómo hacer eso? ¿Usar Active Sync?
“Solucionatica”
En este caso se me ocurren dos soluciones, la primera 100% implementada en Service-Oriented y la segunda una combinación de Data-Centric y Service-Oriented. Para los que no estén familiarizados con estos conceptos, pueden ver este POST.
Opción 1: Service-Oriented
Que la aplicación móvil consuma los servicios Web de descarga de datos directamente (cuando está en la cuna) e inserte los valores en la DB. Luego la aplicación trabaja desconectada para al final del día cuando sea puesta en la cuna subir los datos a través de un Servicio Web de Update y solución de conflictos.
Opción 2: Mixta Service-Oriented y Data-Centric
En esta solución se utilizaría una base de datos intermedia (MSSQL2005) la cual utilizando SSIS cargaría los datos desde SAP a través del Web Services. Luego, utilizando replicación con la PDA transfiere los datos necesarios para móvil. Luego al final del día se sincronizan los datos utilizando las facilidades de MSSQL y su motor de resolución de conflictos. Por último, SSIS pasa los datos ya consolidados desde MSSQL a SAP a través del Web Services de Upload.
Los Pro y contras de cada solución.
Aspecto |
Service-Oriented |
Mixta |
Esfuerzo de programación. |
Alto, la resolución de conflictos no es simple |
Si MSSQL resuelve los conflictos es trivial. |
Costos Licenciamiento |
Sin costos adicionales. |
Licencia de MSSQL 2005 |
Rapidez de descarga |
Está es más rápida, no tiene SSIS intermediando ni el servicio de replicación de MSSQL. |
Tiene una pieza intermedia extra. |
Efectividad en resolución de conflictos en datos |
Puede ser 100% efectiva, todo depende de la lógica programada. |
Tiene las limitaciones del motor de resolución de conflictos de MSSQL, que no es malo pero tiene sus limitaciones. |
Administración |
Solo se requiere instalar la aplicación. |
Además de instalar la aplicación hay que configurar en cada equipo la replicación. |
Conocimientos del equipo |
Web Services. Aplicaciones Móviles. TSQL |
Web Services Aplicaciones móviles SSIS y TSQL |
En mi opinión yo tomaría la opción 1 si tengo un equipo de desarrollo con experiencia. Si no es así me iría por la opción mixta, para no tener que programar la resolución de conflictos.
Salu2
Interesantisimo, JotapeTe hago un pregu de ignorante que soy en temas de mobile computing. Vos mencionabas que en el caso II la Administracion requiere que "además de instalar la aplicación hay que configurar en cada equipo la replicación"Mi pregu es, esa configuracion es indefectiblemente manual o puede ser automatizable y a#adible como parte del proceso de instalacion (aunque sea en otra etapa). Quiero decir, es evitable editar valores a mano (como strings de conexion, etc) y limitar todo a un -por asi decir- doble click a un icono?Thanks por lo que me puedas comentar al respecto. As usual, congrats for your blog
Hola Dagum,
Cuando usares replicación en los móviles tienes que configurar los siguientes datos:
1. la uri del proveedor de la base de datos
2. El nombre de la publicación
3. Usuario y contraseña
4. Nombre del publicador
5. y el PubliserDatabase
Si tienes un software que pueda escribir esa configuración en los equipos te salvas de hacerlo uno a uno. Me parece que no es el caso del Señor que me hizo la pregunta.
Nosotros para el banco mas grande de Chile, estamos haciendo un Middleware Movil que se hace cargo de escribir él todos los datos de configuración necesarios, ahorrando el tema de la administración manual. Pero es otra pieza de Software.
PD: Francisco Arevalo, Ingeniero de Datco especialista en movilidad me ayudo el detalle de los parametros a configurar.
Salu2