Microservizi Serverless: il connettore Hubspot-Zoho

Far comunicare due applicazioni diverse può rivelarsi un compito difficile. In alcuni casi i sistemi parlano lingue diverse, ovvero utilizzano modi diversi di accedere alla stessa tipologia di dati. Generalmente, in questi casi si ricorre ad un connettore, l’equivalente software di un interprete che permette una comunicazione trasparente tra le due parti.

In questo articolo scopriremo l’architettura di un connettore che permette il dialogo tra due CRM diversi, composto da microservizi serverless.

La richiesta del cliente

Il nostro cliente ha richiesto una soluzione per sincronizzare i dati di contatti e aziende tra i CRM di:

• Hubspot, piattaforma leader nell’Inbound Marketing e
• Zoho, un noto CRM offerto come SaaS (Software as a Service)

Il Sync tra i due sistemi

Dopo un’attenta analisi, abbiamo consigliato al cliente una modalità di sync che vede Zoho come contenitore principale dei contatti ed Hubspot come contenitore dei soli contatti “caldi”, quelli su cui effettuare nurturing con tecniche di Inbound Marketing.

Di conseguenza, il nostro connettore avrà le seguenti logiche di sync:

Da Hubspot Verso Zoho

Quando viene creato un nuovo contatto/azienda su Hubspot, il connettore deve verificare se esiste già su Zoho, quindi:

1. se il contatto/azienda esiste già, deve sincronizzare i dati tra i due sistemi, privilegiando le informazioni più aggiornate;
2. se il contatto/azienda non esiste, deve crearlo.

Da Zoho verso Hubspot

Quando vengono apportate modifiche ad un contatto/azienda su Zoho, il connettore deve verificare se esiste già su Hubspot, quindi:

1. se il contatto/azienda esiste già, deve sincronizzare i dati tra i due sistemi, privilegiando le informazioni più aggiornate;
2. se il contatto/azienda non esiste, il connettore non deve eseguire alcuna operazione.

Requisiti fondamentali sono l’affidabilità del connettore nel tenere i dati più recenti sul contatto/azienda e la sua capacità di gestire un elevato numero di operazioni di creazione/modifica.

La nostra soluzione

In quanto AWS Partner, abbiamo progettato il connettore sviluppando dei microservizi serverless che sfruttano la resilienza dell’infrastruttura cloud di AWS.

• Per microservizio, intendiamo un componente dell’applicazione che svolge un compito preciso e che è indipendente dagli altri microservizi.
• Per serverless, intendiamo che le risorse hardware sono gestite direttamente da AWS, che le alloca sulla base del carico di lavoro richiesto dall’applicazione.

Nello specifico, il nostro connettore è composto da tre microservizi serverless.

1. Hubspot – Zoho Webhook

Il primo dei tre microservizi è il Webhook, l’unico dei tre ad essere esposto all’esterno tramite il servizio di API Gateway di AWS. Questo microservizio viene attivato:

• da Hubspot, quando viene creato un contatto/azienda;
• da Zoho, quando un contatto/azienda viene modificato.

I due CRM inviano al microservizio l’ID del contatto/azienda ed il tipo di operazione (creazione o modifica).

Questi dati vengono quindi passati ad una funzione Lambda che:

1. identifica il sistema chiamante (Hubspot o Zoho);
2. ne verifica l’autenticità;
3. invia una lista di operazioni da eseguire ad una coda Amazon SQS.

Amazon SQS è un servizio di accodamento di messaggi completamente gestito che permette la separazione e la scalabilità di microservizi ed applicazioni serverless.

Quindi:

1. Se il sistema chiamante è Hubspot, la lista di operazioni viene inviata ad una coda SQS indirizzata a Zoho;
2. Se il sistema chiamante è Zoho, la lista di operazioni viene inviata ad una coda SQS indirizzata ad Hubspot.

Il ché ci porta al secondo dei tre microservizi.

2. Il microservizio Consumer

Il secondo microservizio fa quindi riferimento a due code SQS che contengono la lista di operazioni necessarie per effettuare la sincronizzazione tra Hubspot e Zoho. La coda che abbiamo utilizzato è di tipo FIFO (First In First Out): questo tipo di coda garantisce che ciascuna operazione di creazione/modifica venga effettuata esattamente una volta e nell’ordine in cui le operazioni sono state inviate.

La lista di operazioni viene quindi prelevata da una delle due code dal microservizio Consumer, composto da due funzioni Lambda:

• La funzione zohoConsumer
• La funzione hubspotConsumer

che lavorano rispettivamente su Zoho e su Hubspot.

Quando una delle due funzioni riceve un messaggio da una delle due code, legge i dati relativi al contatto/azienda del sistema sorgente (Hubspot o Zoho) e verifica se esiste già nel sistema di destinazione.

• Se esiste, i dati vengono sincronizzati;
• Se non esiste, le due funzioni lambda assumono comportamenti diversi:
  • zohoConsumer, che sincronizza i dati da Hubspot verso Zoho, crea il contatto su Zoho;
  • hubspotConsumer, che sincronizza i dati da Zoho verso Hubspot, non esegue alcuna operazione.

Eventuali operazioni fallite a causa di campi mancanti o formato non corretto vengono notificate al cliente tramite il servizio Amazon SES, che invia un’email con la lista delle operazioni fallite. Per ciascuna operazione fallita viene indicato:

• il tipo di operazione;
• l’id del contatto/azienda;
• il messaggio di errore.

Arriviamo infine al terzo microservizio.

3. Zoho Oauth Service

Il controllo dei dati e la scrittura sui due sistemi avviene effettuando delle chiamate alle REST API esposte sia da Hubspot che da Zoho. Il CRM comunque richiede che ciascuna chiamata venga autenticata attraverso un token, che ha scadenza di un’ora.

Il microservizio che gestisce la generazione di questo token e che fornisce un token sempre valido usa il protocollo OAuth.

Questo microservizio è composto da due funzioni Lambda e da un database DynamoDB, ovvero un database NoSQL completamente gestito che garantisce prestazioni di pochi millisecondi con qualsiasi carico di lavoro.

Le due funzioni svolgono le seguenti operazioni:

• La funzione refreshZohoToken crea un nuovo token e lo salva su DynamoDB insieme alla sua data di scadenza, così da sapere anche quando aggiornarlo.
• La funzione getZohoToken legge semplicemente il token da DynamoDB e lo restituisce al microservizio consumer per poter effettuare le operazioni di lettura/scrittura su Zoho.

Conclusioni

Avere la possibilità di concentrare gli sforzi esclusivamente in direzione della richiesta del cliente ci ha permesso di sviluppare una soluzione efficace e su misura per lui. È proprio il cliente infatti in primo luogo a trarre vantaggio dalle caratteristiche del cloud computing, in termini di affidabilità, rapidità e costi.

La semplificazione che comporta questo nuovo modo di gestire le risorse informatiche è ormai un fattore determinante nei processi di sviluppo di software di business intelligence. La tolleranza ai guasti, la continuità di servizio, la rapidità con cui le idee possono essere portate dallo sviluppo alla produzione permettono alle imprese di raggiungere nuovi livelli di competitività.

CTMobi è AWS Partner

Costruiamo insieme il tuo successo

[mautic type=”form” id=”3″]