TravelMate – Our first in-pilot app

I nostri consulenti hanno sviluppato un’applicazione completa durante una fase del percorso di formazione presso Cloud Side Company: TravelMate.
In questo breve articolo vi mostrerò il funzionamento e le tecnologie che abbiamo utilizzato per portare a termine questo progetto.

ENG

Our consultants developed a complete application during one phase of training at Cloud Side Company: TravelMate.
In this short article I will show you how it works and the technologies we used to complete this project.

Di cosa si tratta (What it is about)

TravelMate è un’applicazione creata per rendere più veloce l’organizzazione di un viaggio.

Bisogna solo scegliere la città di destinazione e TravelMate invierà direttamente sul cellulare e nella email personale, informazioni su:

• Il miglior hotel in cui alloggiare;
• Il miglior ristorante;
• Le città più vicine;
• Le condizioni meteo;
• La situazione Covid;
• E tutte le notizie collegate.

ENG

TravelMate is an application created to make the organization of a trip faster.

You only have to choose the destination city, a date and TravelMate will send directly to your cell phone and personal email, information about:

• The best hotel to stay in;
• The best restaurant;
• The nearest cities;
• The weather conditions;
• The Covid situation;
• And all related news.

Le architetture di riferimento (Reference architectures)

Alla base di questa applicazione c’è un architettura di riferimento cosi strutturata:

• Un’applicazione di Data Ingestion per l’inserimento dei dati iniziali;
• Delle applicazioni di Data Processing per elaborare i dati in input;
• Delle applicazioni di Orchestrazione che interagiscono con sistemi esterni come API, code e topic;
• Delle applicazioni di Data Persistence per l’inserimento dei dati elaborati all’interno di un database;
• Delle applicazioni di Auditing per monitorare le performance di tutte le altre applicazioni.

Tutte queste applicazioni comunicheranno tra di loro attraverso un canale di messaggistica (Messaging Bus).

Nel dettaglio quindi avremo:

• L’utente che attraverso un’interfaccia web, che è stata sviluppata con un framework (Angular), inserirà i dati di input come il nome della città, la data di partenza, il numero di cellulare e l’email.
• Questi dati vengono elaborati e inviati su un topic (JMS) a cui sono sottoscritte le applicazioni di orchestrazione.
• Queste applicazioni inviano su una coda (JMS) le informazioni sul miglior hotel, il miglior ristorante, le condizioni meteo e così via.
• Le informazioni presenti sulla coda vengono inserite nel database (Postgres).
• Un’applicazione di batch indica quando tutte le altre applicazioni sono terminate
• E alla fine parte l’applicazione di notifica che unisce tutte le informazioni ricavate e invia un sms/email all’utente.

ENG

At the base of this application there is a reference architecture structured as follows:

• A Data Ingestion application for initial data entry;
• Data Processing applications to process the input data;
• Orchestration applications that interact with external systems such as APIs, queues and topics;
• Data Persistence applications for inserting processed data into a database;
• Auditing applications to monitor the performance of all other applications.

All these applications will communicate with each other through a messaging channel (Messaging Bus).

In detail then we will have:

• The user that through a web interface, which has been developed with a framework (Angular), will enter input data such as city name, departure date, mobile number and email.
• This data is processed and sent on a topic (JMS) to which orchestration applications are subscribed.
• These applications send information on a queue (JMS) about the best hotel, the best restaurant, the weather conditions and so on.
• The information on the queue is entered into the database (Postgres).
• A batch application indicates when all other applications are finished.
• And at the end the notification application starts, which combines all the information obtained and sends an sms/email to the user.

L’architettura tecnica (Technical architecture)

A un più basso livello di astrazione c’è l’architettura tecnica che mostra nello specifico cosa fa l’applicazione.

1. I dati inseriti dall’utente vengono elaborati nell’applicazione TM starter. Si aggiunge il trackID che permette di identificare in maniera univoca una data richiesta. Invia su un topic che si chiama Travel Mate un messaggio con le informazioni ottenute.
2. Le applicazioni di Orchestrazione sono sottoscritte al topic e partono quando arriva un messaggio. Invocano un’API (in questo caso le API sono state fornite da RapidAPI) e restituiscono il numero di casi Covid, le notizie della città, il miglior ristorante ecc.
3. Queste informazioni vengono inviate su un’altra coda.
4. Le applicazioni per la gestione della persistenza dei dati consumano i messaggi sulla coda e inviano le informazioni in un database.
5. Ogni 3 secondi l’applicazione CheckTrackId controlla se tutte le altre applicazioni sono finite e invia un messaggio sulla coda Final.
6. L’applicazione TravelMate Notification consuma il messaggio sulla coda Final, unisce tutte le informazioni ricavate e usa una API per inviare un messaggio all’utente finale.

ENG

At a lower level of abstraction is the technical architecture that shows specifically what the application does.

• The data entered by the user is processed in the TM starter application. It adds the trackID that allows to uniquely identify a given request. It sends on a topic called Travel Mate a message with the information obtained.
• Orchestration applications are subscribed to the topic and start when a message arrives. They invoke an API (in this case the API was provided by RapidAPI) and return the number of Covid instances, city news, best restaurant, etc.
• This information is sent to another queue.
• Data persistence management applications consume the messages on the queue and send the information to a database.
• Every 3 seconds, the CheckTrackId application checks to see if all other applications have finished and sends a message on the Final queue.
• The TravelMate Notification application consumes the message on the Final queue, merges all the information from it, and uses an API to send a message to the end user.

Punti deboli (Waek Points)

Il punto debole di questa architettura riguarda la gestione degli errori. Se una delle applicazioni di Orchestrazione dovesse fallire si bloccano tutte le altre e il messaggio non arriverà mai all’utente*.

ENG

The weak point of this architecture concerns error handling. If one of the Orchestration applications fails, all the others crash and the message will never reach the user*.

Tempi di realizzazione (Time effort)

La realizazzione dell’app e il suo deployment on premise, ha richiesto circa 80 ore lavorative.

ENG

The realization of the app and its deployment on premise, took about 80 working hours.

Note (notes):

* In un secondo momento abbiamo pensato che una soluzione potesse essere un sottoprocesso che permette di aggiornare la tabella che si occupa di tenere traccia del numero di applicazioni concluse, anche nel caso in cui si verificasse un errore. In questo modo l’ultima applicazione può inviare un messaggio all’utente contenente solo le informazioni che si sono riuscite a ricavare.

ENG

* At a later time we thought that a solution could be a subprocess that allows to update the table that keeps track of the number of completed applications, even if an error occurs. In this way, the last application can send a message to the user containing only the information that could be obtained.