Ir al contenido principal

Venta en Gradas

Venta en Gradas fue el proyecto que me mantuvo ocupado (muy ocupado) durante el verano pasado. El objetivo era que los asistentes a un partido de fútbol pudieran realizar pedidos desde sus asientos en las gradas del Ramón Sánchez-Pizjuán.

Actualmente, varios operarios repartidos por las gradas, portan PDAs y mediante una interfaz sencilla e intuitiva realizan pedidos de productos asociados a una zona del estadio, una fila y un asiento. Simultáneamente se imprime un ticket-resguardo para el cliente (a través de una impresora portátil bluetooth que lleva cada operario) con estado pendiente, y un ticket análogo en la impresora de la barra más próxima. En ésta se prepara el pedido, que otro operario lleva a la Zona-Fila-Asiento indicados. En el momento de entregar el pedido, se realiza el intercambio de tickets, quedándose el cliente con el que tiene estado "entregado".

La arquitectura de la aplicación es la siguiente:


El software del cliente se desarrolló en .NET C#, y se usó una base de datos SQL Server Compact Edition v3.5. Se utilizaron componentes IntTheHand.Net para implementar la impresión por bluetooth en la impresora portátil. El canal de comunicación puede ser wifi, GPRS, HSDPA...

Para el servidor se desarrolló un Java Restlet que recoge los pedidos (XML), los inserta en una base de datos MySQL 5 (a través del framework Ibatis), y envía el pedido a la impresora de barra asociada. Si se produjera algún error (falta de papel, tapa de impresora abierta...), se recogería por el servidor, y se notificaría a la PDA correspondiente.

Por último se programó una aplicación web en PHP, que a través de consultas a la base de datos del servidor, ofrece al administrador todo tipo de estadísticas sobre las ventas (producto más vendido, partido en el que más se ha vendido,...).

Después del trabajo realizado, fue muy gratificante poder leer esto en la web del Sevilla F.C.. El pasado 28 de abril, pude leer en ABC el artículo Aperitivos Telemáticos donde vuelve a aparecer. Como comprenderéis, como "padre de la criatura", el orgullo es tremendo, y espero que pronto lo podamos usar en otros estadios y en todo tipo de espectáculos.

Comentarios

  1. Muy interesante. El otro día, estando en el RSP, pedí un perrito y una cocacola y pude comprobar que "tu" sistema funciona a las mil maravillas.

    ResponderEliminar
  2. Hola. Estaba leyendo tus posts y me ha surgido una duda: en este proyecto de Venta en Gradas comentas que usaste Sql Server CE 3.5 para la aplicación cliente, pero también cuentas (o yo lo entiendo así) que los datos de ésta los consumías y los enviabas desde/hacia el servidor usando un servicio web. Entonces, ¿es realmente necesario usar Sql Server CE?, ¿qué te aporta?. Quiero decir que si podías recoger XML's desde el servidor con todos los datos necesarios para la aplicación (artículos, precio, stock, ...) y guardarlos en un DataSet local realmente no veo necesario almacenar dichos datos de forma persistente, ya que la aplicación simplemente podría consumirlos cada vez que fuera iniciada y refrescarlos cada X tiempo.
    Si estuviésemos hablando de que esos datos son modificados en la aplicación cliente y luego hay que sincronizarlos con la BD del servidor o que se tratase de datos de gran volumen entonces tendría sentido, pero en el escenario que tú planteas no termino de ver la necesidad del Sql Server CE. ¿Tú qué piensas?.

    Salu2!

    ResponderEliminar
  3. Buenos días eccho, es bastante sencillo, se hizo así por varios motivos, pero el más importante sería este:

    - Tu me hablas de escenarios ideales, y créeme que un campo de fútbol con 40000 personas, dista mucho de serlo. Pueden darse periodos de falta de conectividad, y los pedidos no pueden irse al limbo. Es decir, en el momento de hacer el pedido, un hilo se encarga de enviarlo en segundo plano. Por tanto se puede seguir realizando otro pedido, y si el hilo envía el pedido con éxito, el pedido se guardará en la base de datos local como enviado, y se notificará el éxito de la operación por pantalla. Si por el contrario, no se ha podido enviar (falta de conectividad), el pedido se guardará como no enviado, y se notificará, de manera que el operario pueda recuperarlo y reenviarlo... hay más casuística, pero creo que con esto ya se entiende.

    Un saludo.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas. Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla. Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que

Portales Colaborativos I

El concepto de portal convencional supone una plataforma donde se ofrecen contenidos, funcionalidad (búsquedas, inscripciones,...), publicidad... Un Portal Colaborativo está influenciado por la filosofía Web 2.0: - Los usuarios saben donde encontrar la información (está centralizada). Dependiendo del perfil se le mostrará una información u otra. - Aúna los procesos de negocio de las organizaciones. - Se fomenta el trabajo compartido Online. - En definitiva, los usuarios son lo más importante. En Soltel andamos enfrascados en el diseño y desarrollo de un Portal Colaborativo, que nos permita agilizar ciertos procesos y por supuesto, estamos trabajando para que "no se quede" en la empresa. Para ello, hacemos hincapié en la abstracción, modularización y en los servicios generales que debería tener para poder convertirlo en producto. ¿Qué debería tener un portal colaborativo? - Un repositorio centralizado de todo tipo de documentos. Punto de acceso único a la información. - Agend

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos. Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes. En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja. Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en