Automação do fluxo de trabalho com Ruby on Rails
Jarod Reyes
Um dos conceitos mais abstratos que você lidará ao criar sua empresa é como será o fluxo de trabalho.
Em sua essência, a configuração de um fluxo de trabalho padronizado é permitir que seus provedores de serviços (agentes, hosts, representantes de atendimento ao cliente, administradores e o restante da equipe) atendam melhor aos seus clientes.
Para ilustrar um exemplo muito real, vamos criar um aplicativo da web Ruby on Rails para encontrar e reservar propriedades de férias — provisoriamente chamado de Airtng.
Veja como ficará:
- Um host cria uma listagem de propriedades de férias
- Um hóspede solicita uma reserva para um estabelecimento
- O host recebe um SMS notificando‐o sobre a solicitação de reserva. O host pode aceitar ou rejeitar a reserva
- O hóspede é notificado se uma solicitação foi rejeitada ou aceita
Blocos de construção do fluxo de trabalho
Usaremos a API REST da Twilio para enviar mensagens aos nossos usuários em encontros importantes. Veja um pouco mais sobre nossa API:
Pronto para começar? Clique com ousadia no botão logo após esta frase.
O modelo de propriedade de férias
O modelo de VacationProperty pertence ao User que o criou (chamaremos esse usuário de host a partir de agora) e contém apenas duas propriedades, uma description e um image_url.
Ele tem duas associations (associações) nela e tem muitas reservas e, portanto, muitos usuários por meio dessas reservas.
A melhor maneira de gerar o modelo e todo o CRUD scaffolding (scaffolding CRUD) básico dos quais precisaremos é usar a ferramenta Rails command line (linha de comando do Rails):
bin/rails generate scaffold VacationProperty
description:string image_url:string
Um dos benefícios de usar o gerador do Rails é que ele cria todas as nossas rotas, controladores e visualizações para que tenhamos uma interface CRUD totalmente funcional pronta para uso. Muito bom!
Vamos mergulhar a fundo e, em seguida, analisar o modo de reserva.
O modelo de reserva
O modelo Reservation está no centro do fluxo de trabalho para este aplicativo. É responsável por manter o controle de:
- a
VacationPropertyà qual está associada - o
Userque é proprietário dessa propriedade de férias (o host) - o nome e número de telefone do hóspede
Como a reserva pode ter apenas um hóspede para o nosso exemplo, simplificamos o modelo atribuindo um name e phone_number diretamente.
Abordaremos como fizemos isso mais tarde. Em seguida, no entanto, vamos analisar o status da reserva.
Status da reserva
Primeiro, validamos algumas propriedades‐chave e definimos as associações para que possamos pesquisar posteriormente essas relações por meio do modelo. (Se você quiser mais contexto, o Rails guide (guia do Rails) explica muito bem os modelos e as associações.)
A propriedade principal que precisamos para ativar um fluxo de trabalho de reserva é algum tipo de status que podemos monitorar. Esse é um candidato perfeito para um atributo de status enumerado.
Atributos enumerados
Os Enumerated attributes (Atributos enumerados) nos permitem armazenar um número inteiro simples na tabela, dando a cada status um nome pesquisável. Veja um exemplo:
# reservation.pending! status: 0
reservation.status = "confirmed"
reservation.confirmed? # => true
Quando tivermos um atributo que possa acionar nossos eventos de fluxo de trabalho, é hora de escrever alguns retornos de chamada. Vamos ver em seguida.
O controlador de reservas
Publicaremos os detalhes da nossa reserva na rota create a partir da página da propriedade de férias.
Depois de criar a reserva, queremos notificar o host que ele tem uma solicitação pendente. Depois de aceitá‐la ou rejeitá‐la, queremos notificar o hóspede sobre as notícias.
Enquanto o modelo de Reservation lida com a notificação, queremos manter todas essas ações no controlador para mostrar nossas intenções.
Em seguida, vamos dar uma olhada em como exatamente notificaremos o host de sorte.
Notificar o host
Em teoria, notificar o host deveria ser tão simples quanto procurar o User host e enviar um SMS a ele. No entanto:
Como nos certificamos de que nossos anfitriões: a) estão respondendo à consulta de reserva correta e b) não estão recebendo spam?
Reservas pendentes
Nossa solução simples para ambos os problemas:
- Nós só notificamos o host sobre a reserva pendente mais antiga.
- Não enviamos outro SMS até que o host tenha lidado com a última reserva.
A maneira mais fácil de destacar pending_reservations para um usuário é criar um método auxiliar no modelo de User. Vamos ver isso na próxima etapa.
Enviar o SMS
Se, na verdade, o host tiver apenas uma reserva pendente, nós iremos disparar um SMS para o host imediatamente.
Vamos dar uma olhada no modelo de User.
O modelo de usuário
Temos um modelo para os hóspedes e para os anfitriões que estão usando o Airtng.
Quando o Airtng decolar, valerá a criação de mais duas classes que herdam da classe base de User. Como ainda estamos no chão, isso deve nos servir bem (para ficar com ousadia...).
Primeiro, validamos a "exclusividade" de nosso usuário - eles devem ser exclusivos, assim como todas as outras pessoas. Especificamente, é importante garantir que o atributo phone_number seja exclusivo, pois usaremos ele para pesquisar os registros do User nos SMSs recebidos.
Depois disso, criamos nossas associações para quando precisarmos consultar reservas.
Provavelmente a tarefa mais importante delegada ao nosso modelo de User é enviar um SMS ao usuário quando nosso app solicitar. Clique em "Avançar" abaixo para ir para esse painel.
Enviar mensagens para o vazio
Como só enviamos mensagens de texto em nosso aplicativo quando estamos nos comunicando com usuários específicos, faz sentido criar essa função na classe User. E sim: essas 7 linhas são tudo o que você precisa para enviar SMSs com a Ruby e a Twilio! São apenas duas etapas:
- Procuramos o número de telefone do nosso app.
- Iniciamos nosso Twilio Client e criamos a mensagem.
Agora, sempre que precisarmos nos comunicar com um usuário, seja ele um host ou um hóspede, podemos passar uma mensagem para este método de usuário e... Voilà! Enviamos um texto a eles.
(Se você verificar abaixo desse método, verá os métodos auxiliares para descobrir as pending_reservations que mencionamos anteriormente.)
Agora precisamos de uma forma de lidar com mensagens de texto recebidas para que o nosso host de sorte possa aceitar ou rejeitar uma solicitação. Vamos ver em seguida.
Tratamento de mensagens recebidas
O controlador accept_or_reject lida com nossa solicitação recebida da Twilio e faz três coisas:
- Verifica se há uma reserva pendente de propriedade do usuário
- Atualiza o status da reserva
- Responde ao host (e ao hóspede)
Solicitação recebida da Twilio
Uma solicitação recebida da Twilio vem com alguns parâmetros úteis, incluindo o número de telefone From e o Body da mensagem.
Usaremos o parâmetro From para pesquisar o host e verificar se ele tem alguma reserva pendente. Se ele fizer isso, usaremos o corpo da mensagem para verificar se ele aceitou ou rejeitou a reserva.
Em seguida, redirecionaremos a solicitação para uma resposta TwiML para enviar uma mensagem de volta ao usuário.
Resposta do TwiML
Geralmente, um controlador do Rails tem um modelo associado a ele que processa uma página da web. Em nosso caso, a única solicitação que está sendo feita será pela API da Twilio, então não precisamos de uma página pública. Em vez disso, estamos usando a API do Ruby da Twilio para processar uma resposta TwiML personalizada como XML bruto na página.
Em seguida, vamos ver como notificar o hóspede.
Notificar o hóspede
A etapa final em nosso fluxo de trabalho é notificar o hóspede que sua reserva foi concluída com êxito (ou, sim, rejeitada).
Chamamos esse método anteriormente do reservations_controller quando atualizamos o status da reserva. Veja o que ele faz:
- Pesquisamos o hóspede com o
reservation.phone_number - Se o status foi alterado para um resultado esperado, notificamos o hóspede sobre a alteração.
E, é claro, tudo o que precisamos fazer para enviar a mensagem por SMS ao hóspede é chamar o método send_message_via_sms que está presente em todos os usuários.
Muito obrigado pela ajuda! O Airtng agora tem um bom fluxo de trabalho com base em SMS e você está pronto para adicionar um fluxo de trabalho ao seu próprio aplicativo.
No próximo painel, veremos alguns outros recursos que você pode querer adicionar para seus casos de uso.
Para onde ir em seguida?
Ruby and Rails e Twilio: uma excelente combinação. Aqui estão algumas outras ideias que você pode seguir:
Masked Phone Numbers (Números de telefone mascarados)
Proteja a privacidade de seus usuários conectando‐os anonimamente com o Twilio Voice e o SMS.
Automated Survey (Pesquisa automatizada)
Receba feedback instantâneo de seus clientes com SMS ou Voice.
Isso ajudou?
Obrigado por conferir este tutorial! Envie um tweet para nós em @twilio com o que você está criando!
Precisa de ajuda?
Às vezes, todos nós precisamos; a programação é difícil. Receba ajuda agora da nossa equipe de suporte, ou confie na sabedoria da multidão navegando pelo Stack Overflow Collective da Twilio ou buscando a tag Twilio no Stack Overflow.
