Automatización del flujo de trabajo con Ruby y Rails
Jarod Reyes
Uno de los conceptos más abstractos que te encontrarás al crear tu empresa es el aspecto que tendrá el flujo de trabajo.
En esencia, la configuración de un flujo de trabajo estandarizado consiste en permitir que tus proveedores de servicios (agentes, anfitriones, representantes del servicio de atención al cliente, administradores y el resto del grupo) presten un mejor servicio a tus clientes.
Para ilustrar un ejemplo muy real, hoy crearemos una aplicación web de Ruby on Rails a fin de buscar y reservar propiedades vacacionales, llamada provisionalmente Airtng.
Así es como funcionará:
- Un anfitrión crea una lista de propiedades vacacionales
- Un huésped solicita la reserva de una propiedad
- El anfitrión recibe un SMS que lo notifica sobre la solicitud de reserva. El anfitrión puede aceptar o rechazar la reserva
- Se notifica al huésped si se aceptó o rechazó la solicitud
Componentes básicos del flujo de trabajo
Utilizaremos la API REST de Twilio para enviar mensajes a nuestros usuarios en momentos importantes. Aquí hay un poco más de información sobre nuestra API:
¿Listo para empezar? Haz clic en el botón que se encuentra justo después de esta oración.
El modelo de propiedad vacacional
El modelo de VacationProperty pertenece al User que lo creó (a partir de ahora, a este usuario lo llamaremos anfitrión) y contiene solo dos propiedades, una description y una image_url.
Tiene dos asociaciones en el sentido de que tiene muchas reservas y, por lo tanto, varios usuarios en esas reservas.
La mejor manera de generar el modelo y toda la estructura CRUD básica que necesitaremos es usar la herramienta de línea de comandos de Rails:
bin/rails generate scaffold VacationProperty
description:string image_url:string
Una de las ventajas de utilizar el generador de Rails es que crea todas nuestras rutas, controladores y vistas para disponer de una interfaz de CRUD totalmente funcional desde el comienzo. ¡Excelente!
Empecemos y veamos a continuación el modo de reserva.
El modelo de reserva
El modelo de Reservation se encuentra en el centro del flujo de trabajo para esta aplicación móvil. Es responsable de realizar un seguimiento de los siguientes elementos:
- la
VacationPropertya la que está asociado - el
Userque posee esa propiedad vacacional (el anfitrión) - el nombre y el número de teléfono del huésped
Dado que la reserva solo puede tener un huésped para nuestro ejemplo, simplificamos el modelo mediante la asignación de un name y un phone_number directamente.
Explicaremos cómo lo hicimos más adelante. Sin embargo, a continuación analizaremos en detalle el estado de la reserva.
Estado de reserva
En primer lugar, validamos algunas propiedades clave y definimos las asociaciones para poder buscar más adelante esas relaciones a través del modelo. (Si deseas obtener más contexto, la guía de Rails explica muy bien los modelos y las asociaciones).
La propiedad principal que necesitamos para habilitar un flujo de trabajo de reservas es algún tipo de status que podamos monitorear. Este es un candidato perfecto para un atributo status enumerado.
Atributos enumerados
Los atributos enumerados nos permiten almacenar un número entero simple en la tabla, a la vez que damos a cada estado un nombre que se puede buscar. Este es un ejemplo:
# reservation.pending! status: 0
reservation.status = "confirmed"
reservation.confirmed? # => true
Una vez que tenemos un atributo que puede activar nuestros eventos de flujo de trabajo, es el momento de escribir algunas devoluciones de llamada. Veamos esto a continuación.
El controlador de reservas
Publicaremos los detalles de nuestra reserva en la ruta create desde la página de propiedades vacacionales.
Después de crear la reserva, se debe notificar al anfitrión que tiene una solicitud pendiente. Después de que la acepte o rechace se debe notificar al huésped sobre esta decisión.
Mientras el modelo de Reservation gestiona la notificación, se deben mantener todas estas acciones en el controlador para mostrar nuestras intenciones.
A continuación, echemos un vistazo a cómo notificaremos exactamente al anfitrión afortunado.
Notificar al anfitrión
En teoría, notificar al anfitrión debe ser tan simple como buscar al User y enviarle un SMS. Sin embargo:
¿Cómo nos aseguramos de que nuestros anfitriones: a) respondan a la solicitud de reserva correcta y b) no reciban spam?
Reservas pendientes
A continuación, mostramos una solución sencilla a ambos problemas:
- Solo notificamos al anfitrión de la reserva pendiente más antigua.
- No enviamos otro SMS hasta que el anfitrión haya tratado la última reserva.
La forma más sencilla de mostrar las pending_reservations a un usuario es mediante la creación de un método auxiliar en el modelo de User. Lo analizaremos en el siguiente paso.
Envío del SMS
Si el anfitrión solo tiene una reserva pendiente, le enviaremos un SMS de inmediato.
Ahora veamos el modelo de User.
El modelo de usuario
Tenemos un modelo tanto para los huéspedes como para los anfitriones que usan Airtng.
Cuando Airtng comience a funcionar, requerirá la creación de dos clases más basadas en la clase de User base. Como todavía no terminamos, esto debería servirnos (para seguir adelante...).
En primer lugar, validamos la “singularidad” de nuestro usuario, que debe ser único, como todos los demás. Específicamente, es importante que nos aseguremos de que el atributo phone_number sea único, ya que lo usaremos para buscar los registros de User en los SMS entrantes.
Después de eso, creamos nuestras asociaciones para cuando necesitemos consultar las reservas.
Posiblemente la tarea más importante que se delega a nuestro modelo de User es enviar un SMS al usuario cuando la app lo solicite. Haz clic en “Next” (Siguiente) a continuación para desplazarte a ese panel.
Enviar mensajes al vacío
Dado que solo enviamos mensajes de texto en nuestra aplicación móvil cuando nos comunicamos con usuarios específicos, tiene sentido crear esta función en la clase de User. Y sí: estas 7 líneas son todo lo que necesitas para enviar SMS con Ruby y Twilio. En realidad son solo dos pasos:
- Buscamos el número de teléfono de nuestra app.
- Iniciamos nuestro Twilio Client y creamos el mensaje.
Ahora, siempre que necesitemos comunicarnos con un usuario, ya sea un anfitrión o huésped, podemos transferir un mensaje a este método de usuario y... ¡Listo! Le enviamos un mensaje.
(Si consultas debajo de este método, verás los métodos auxiliares para encontrar las pending_reservations que mencionamos anteriormente).
Ahora necesitamos una manera de gestionar los textos entrantes para que nuestro afortunado anfitrión pueda aceptar o rechazar una solicitud. Veamos esto a continuación.
Gestionar mensajes entrantes
El controlador de accept_or_reject gestiona nuestra solicitud entrante de Twilio y realiza las siguientes tres cosas:
- Comprueba si hay una reserva pendiente que posea el usuario
- Actualiza el estado de la reserva
- Responde al anfitrión (y al huésped)
Solicitud entrante de Twilio
Una solicitud entrante de Twilio cuenta con algunos parámetros útiles, incluido el número de teléfono From y el Body del mensaje.
Usaremos el parámetro From para buscar a la anfitriona y comprobar si tiene reservas pendientes. Si es así, utilizaremos el cuerpo del mensaje para comprobar si aceptó o rechazó la reserva.
A continuación, redirigiremos la solicitud a una respuesta TwiML para enviar un mensaje de vuelta al usuario.
Respuesta TwiML
Por lo general, un controlador de Rails cuenta con una plantilla asociada que representa una página web. En nuestro caso, la única solicitud la realizará la API de Twilio, así que no se necesita una página pública. En su lugar, utilizamos la API de Ruby de Twilio para representar una respuesta TwiML personalizada como XML sin procesar en la página.
A continuación, veamos cómo notificar al huésped.
Notificar al huésped
El paso final en nuestro flujo de trabajo es notificar al huésped que su reserva se realizó correctamente (o se rechazó).
Llamamos a este método antes desde reservations_controller cuando actualizamos el estado de la reserva. Esto es lo que hace:
- Se busca al huésped con el
reservation.phone_number - Si el estado cambió a un resultado esperado, notificamos el cambio al huésped.
Y, por supuesto, todo lo que tenemos que hacer para enviar el mensaje SMS al huésped es llamar al método send_message_via_sms que se encuentra en todos los usuarios.
¡Muchas gracias por tu ayuda! Ahora, Airtng cuenta con un buen flujo de trabajo basado en SMS y se encuentra listo para agregar un flujo de trabajo a tu propia aplicación móvil.
En el siguiente panel, veremos algunas otras funciones que podrías agregar para tus casos de uso.
¿Dónde ir a continuación?
Ruby, Rails y Twilio: una excelente combinación. Aquí hay un par de otras ideas que es posible que te interesen:
Números de teléfono enmascarados
Protege la privacidad de tus usuarios al conectarlos de forma anónima con Twilio Voice y SMS.
Recopila comentarios instantáneos de tus clientes mediante SMS o Voice.
¿Esto fue de ayuda?
Gracias por consultar este tutorial. Escríbenos en Twitter, a @twilio, ¡y cuéntanos sobre lo que estás creando!
¿Necesitas ayuda?
Todos la necesitamos a veces; la programación es difícil. Obtén ayuda ahora de nuestro equipo de soporte, o recurre a la sabiduría de la multitud visitando Stack Overflow Collective de Twilio o navegando por la etiqueta de Twilio en Stack Overflow.
