Altea booking integration into social networking - Rapacki, Ricardo Chagas (2013)
Hoje em dia, com o surgimento das redes sociais, as pessoas estão gradativamente realizando mais tarefas cotidianas em sites como Facebook e Twitter – desde comprar roupas a checar informações sobre o trânsito. Baseado nisto, a Amadeus, empresa líder mundial em soluções de TI para a indústria de turismo e viagem, decidiu desenvolver um aplicativo Facebook para permitir aos usuários buscarem reservas, compartilhá-las e combinar viagens com amigos. Para isto, as reservas podem ser obtidas através da utilização dos Web Services implementados pela Amadeus através de um record locator (identificador único de uma reserva) ou criadas sem este identificador ao salvar uma viagem no aplicativo que ainda não foi reservada no sistema. O núcleo do aplicativo foi implementado na linguagem Python utilizando o framework Django, além de diversas outras tecnologias Web como Javascript, jQuery, SOAP, API Facebook, API Google Maps, etc. Suas funcionalidades focam na idéia de administrar viagens já reservadas ou criadas através do aplicativo, compartilhá-las no mural do usuário no Facebook ou convidar diretamente amigos para participar. Quando um usuário é convidado para uma viagem, ele pode utilizar a viagem do amigo como referência e checar, para cada trecho necessário, a disponibilidade de vôos e preços. A arquitetura da aplicação é dividida nos seguintes elementos: Canvas Facebook, API Facebook, Amadeus We Go App, Web Services e banco de dados. O Canvas é um espaço em uma página Facebook onde arquivos HTML, Javascript e CSS do aplicativo são carregados através de um URL e a utilização da API Facebook é essencial para utilizar todas funcionalidades e dados da rede social. Em relação ao módulo principal da aplicação Amadeus We Go, é utilizada uma arquitetura MVC (Model-View-Controller), onde o arquivo views.py controla que dados são apresentados, os templates Django nos arquivos HTMLs controlam como estes dados são apresentados e o controlador é o próprio framework. Além disso, os dados são salvos em um banco de dados SQLite, criado pelo Django automaticamente pelo arquivo models.py. Além deste, há também o banco de dados RFD da Amadeus e o banco de dados acessado pelos Web Services. O primeiro é salvo no servidor da companhia e fornece informação atualizada sobre aeroportos, cidades, companhias aéreas, terminais, países e tudo relacionado à indústria de turismo e viagem. Por exemplo, é possível procurar informações de um aerporto através do código IATA de 3 dígitos, como GRU para Garulhos, ou então listar todos aeroportos em determinado país. A fim de realizar o deployment da aplicação, foi necessário configurar um servidor Apache no Linux e não somente utilizar o servidor web disponibilizado pelo Django, pois este último não suporta o protocolo HTTPS nativo, mandatório para aplicações no Canvas do Facebook. Como já citado anteriormente, três tecnologias são essenciais para o aplicativo Amadeus We Go e serão explicadas mais detalhadamente a seguir. Apesar da API Facebook, por essência, poder ser utilizada normalmente através de requisições HTTP e retornar objetos JSON, o Facebook suporta oficialmente SDKs para Javascript, PHP, iOs e Android para abstrair este processo. Considerando que Python foi a linguagem de programação escolhida, foi decidido que para abstrair a API seria utilizado o SDK opensource chamado Python for Facebook. Este, além de abstrair as requisições HTTP com funções simples de usar, é bastante portável e suportado por uma grande comunidade. Apesar disso, é necessário utilizar o SDK Facebook para Javascript para implementar a autenticação no modo canônico com o Facebook e, em seguida, utilizar o cookie obtido no arquivo Python. Adicionalmente, a API Facebook utiliza o protocolo OAuth 2.0 para autenticação de usuários que fornece um fluxo de autorizações específicas para aplicações web. Uma das maiores vantagens disto é que a aplicação não tem acesso ao usuário e senha porque todo o fluxo é controlado pelo Facebook. O pedido de autorização é feito pela aplicação para o usuário, que é redirecionado a um diálogo Facebook para inserir seus dados e, se correto, o Facebook retorna um token de acesso à aplicação. Este token está ligado às permissões definidas pela aplicação no momento da autorização, como acesso a fotos e amigos, e está limitado somente a estas permissões. Deste modo, a aplicação não terá liberdade para fazer nada além do que já pediu e, se definir novas permissões, irá gerar outro diálogo Facebook para criar um novo token de acesso. Para o aplicativo Amadeus We Go, as permissões requisitadas são user_likes (para páginas curtidas pelo usuário), friends_about_me (para informações pessoais de amigos), friends_location (para local de moradia dos amigos) e publish_stream (para publicar postagens no mural do Facebook. Esta última permissão é a única que é individualmente revocável pelo usuário, enquanto as outras são obrigatórias para o uso do aplicativo. Finalmente, o núcleo da API Facebook é a API Graph, cuja função é representar todo grafo da rede social uniformemente com objetos (pessoas, fotos, eventos, páginas, etc) e conexões entre eles (amizades, conteúdo compartilhado, tags em fotos, etc). Logo, após adquirir o objeto chamado Graph com a SDK Python for Facebook, qualquer conteúdo pode ser acessado através de seu ID e conexões. Igualmente importante para o aplicativo, os Web Services integram as funcionalidades da Amadeus com a rede social. De modo a obter preços e disponibilidade de vôo atualizados, o aplicativo envia mensagens SOAP para estes Web Services da Amadeus e analisa a mensagem que recebe como resposta. Este processo está encapsulado pelo cliente SOAP implementado utilizando a biblioteca nativa urllib2 e é responsável por guardar todas informações necessárias como URL do Web Service, ID da sessão, token de segurança e número de sequência. Este último é utilizado para checar se alguma mensagem foi perdida entre cliente e servidor e o incremento do número é realizado por esse cliente. Além disso, cada serviço utilizado possui um arquivo Python específico que recebe os parâmetros da chamada, cria a mensagem SOAP através de um template e analisa a resposta. Entretanto, o primeiro passo para utilizar tais serviços é se autenticar utilizando o LSS (Logon and Security Server), um identificador único para cada aplicação ou empregado. Após feito isso, as seguintes operações são utilizadas pelo aplicativo: PNR Retrieve by Record Locator: Obtém informações sobre uma reserva ativa, chamada de PNR (passage name record) , utilizando um record locator. Flight Availability: Buscar disponibilidade de vôos buscando por países de destino e origem, datas e classe de assento  Itinerary Fare: Fornece tarifa atualizada para determinado vôo Finalmente, a última tecnologia a ser detalhada é o banco de dados SQLite, responsável por salvar usuários, passageiros, viagens e ligações entre elas. Adicionalmente, é neste nível que é criada a distinção entre duas reservas diferentes: as já compradas e salvas no sistema da Amadeus e as salvas somente no aplicativo. Para salvar informações sobre usuários Facebook e passageiros, é utilizada a tabela Customer. Uma tupla pode ser criada em dois momentos:  Quando uma nova viagem é criada, salvando informações do perfil Facebook do usuário para evitar chamar a API e melhorar o desempenho da aplicação  Quando uma reserva é obtida através de um record locator, onde todos passageiros presentes na reserva são salvos sem informações Facebook. No segundo caso, se o usuário em seguida confirme que é um dos passageiros em questão, a tupla é atualizada com suas informações de perfil. Relacionado às viagens, a tabela Trip representa as informações sobre uma viagem salva pelo aplicativo e guarda também ligações com viagens de amigos no atributo linkedTrips. Como casos mais simples, estão as tabelas Booking, DummyBooking, Trip_Customer, Trip_Booking e Trip_DummyBooking para representar, respectivamente, uma reserva presente no sistema da Amadeus, uma reserva feita pelo aplicativo e tabelas para representar as relações entre tabelas. Elas existem, pois, como no caso de Trip_Customer, ela guarda um atributo informando se o usuário é proprietário da viagem ou foi convidado por outro e, se sim, quem é o usuário que convidou. A última tabela é a Segment, representando o trecho de uma reserva, contendo todas informações úteis sobre as viagens. Um segmento está sempre ligado a uma reserva com record locator ou uma sem. Logo, se a reserva for destruída, o segmento também é. De modo a validar cada versão do aplicativo, foi utilizada ferramenta de controle de versionamento distribuído chamado Mercurial. Para isto, é necessário primeiramente que o desenvolver execute um commit localmente na máquina e, sempre que a modificação na versão tenha sido significativa, será executado um nominate que envia um pedido aos integradores. Ao receber o pedido, cabe ao integrador a tarefa de baixar o código e executá-lo em sua máquina. Se nenhum problema for encontrado, é executado um push e o código atualizado se encontrará no repositório principal, disponível já nas próximas vezes que alguém o recuperar. Em relação à análise do desenvolvimento do software, a decisão de utilizar Python com Django contribuiu muito para abstrair tarefas como o banco de dados e permitiu criar um código extremamente modular e facilmente extensível. Por exemplo, caso um novo Web Service da Amadeus venha a ser utilizado, é necessário somente a criação de um novo arquivo com o template da mensagem a ser enviada e a lógica da leitura da resposta, pois a parte da troca de mensagens e exemplos de outros serviços já estão implementados. Além disso, o SDK Python for Facebook foi bastante importante para a integração com a rede social mesmo não sendo oficialmente suportado pelo Facebook. Por outro lado, houve algumas complicações com a implementação do cliente SOAP. Devido à falta de documentação por parte da própria empresa Amadeus e das bibliotecas testadas, SUDS, SOAPpy e ZSI, o desenvolvimento foi atrasado em um mês e o grande problema era a inconsistência entre a mensagem enviada e a mensagem esperada pelo servidor. Adicionalmente, o envio de requisições HTTP para os Web Services piorou o desempenho do aplicativo e, apesar de uma chamada HTTPS para o API Facebook não ser tão pesada, o conjunto de operações realizadas pode ficar extremamente custoso, pois cresce proporcionalmente em função do número de amigos do usuário, por exemplo. Considerando possíveis melhorias futuras, a alta latência dos Web Services pode ser mitigada se o deployment do aplicativo for feito nos servidores do datacenter da Amadeus na cidade de Erding, Alemanha, pois o custo de rede será minimizado. Além disto, a utilização de cache ou salvar informações no banco de dados pode evitar a chamada de operações pesadas e melhorar o desempenho da aplicação. Diversas funcionalidades discutidas na fase de especificação do projeto ou outras novas poderiam ser implementadas futuramente para melhorar a experiência do usuário e aproveitar todo o potencial da API Facebook e de todos Web Services da Amadeus. Uma das funcionalidades identificada como importante, permitir a compra de passagens aéreas através do aplicativo, não foi implementada devido às regras de negócio da Amadeus. Neste projeto, o aplicativo está limitado a somente salvar as informações sobre as viagens em seu banco de dados. Concluindo, mesmo que nem todas as funcionalidades planejadas inicialmente tenham sido implementadas, o aplicativo soluciona os problemas que motivaram o desenvolvimento. Adicionalmente, para incluir novas funcionalidades ou atualizar as já existentes, a extensão do aplicativo é simples, seja utilizando novos Web Services da Amadeus ou novas funções e dados da API Facebook para maior integração com a rede social. Assim, o projeto pode ser continuado e oferece um futuro promissor como um aplicativo para uso em redes sociais que venha a integrar o cotidiano de viagens e turismo das pessoas.