La nostra strategia di onboarding: un primo approccio all’integrazione di sistemi

Alberto Melati - developer - racconta la sua esperienza di onboarding in Thread Solutions
 

Quando un team acquisisce un nuovo membro è estremamente importante avere un ottimo e solido piano di onboarding. Una strategia di apprendimento strutturata aiuta infatti i nuovi membri del team ad acquisire familiarità con tutte le tecnologie che usiamo nel nostro business.

Il nostro piano di studi comprende molte delle tecnologie comunemente usate in ambito IT, ma il nostro onboarding è principalmente focalizzato sullo sviluppo di API e sul concetto di API-led connectivity di MuleSoft. Il primo, e probabilmente più importante, elemento costitutivo del piano è il corso “Mule Development Fundamentals”, necessario al fine di introdurre un principiante allo sviluppo di API utilizzando Anypoint Platform di MuleSoft. Ma, ovviamente, seguire un corso non è abbastanza: dopo aver imparato le basi è il momento di affrontare un problema reale e stimolante. Perciò, una volta concluso il corso, ho iniziato lo sviluppo di un progetto interno, sotto la supervisione di un senior developer: sebbene tale progetto sia stato affrontato come un “progetto di studio”, è stato un vero progetto i cui risultati ci aiutano ora a migliorare il nostro business (cioè il progetto è stato fin dall’inizio destinato a seguire tutto il ciclo di vita dallo sviluppo alla produzione). Il seguente è il progetto di integrazione che ho sviluppato durante il mio periodo di onboarding in Thread Solutions.

Il problema

L’azienda usa avaza.com come piattaforma di management. Avaza gestisce tutti gli aspetti del nostro business. In particolare tutte le richieste di ferie devono essere sottomesse ed approvate su Avaza. Attualmente la pianificazione delle assenze lavorative del team è un po’ complicata perché ognuno non può vedere le richieste fatte degli altri membri del team. Quindi, per la convenienza dell’intero team, vorremmo vedere tutte le ferie programmate su un calendario (di Google). Perciò dobbiamo costruire un sistema di integrazione che connetta Avaza e Google Calendar attraverso le loro API.

La soluzione

Dopo l’analisi preliminare del problema, che è stata utile per imparare i fondamenti dell’API-led, ho deciso di sviluppare la seguente soluzione. Prima di tutto servono due system-APIs (sAPI) per comunicare con Avaza e Google Calendar. Sviluppare sAPI è sempre un’ottima abitudine perché esse creano un livello di astrazione dal mondo esterno. Dopodichè serve una process-API (pAPI) che implementi tutte le logiche di business (in questo caso particolare sarà un’applicazione di tipo If This Then That, IFTTT).

Lo sviluppo delle due system-API è già di per sé un progetto sfidante. Sebbene queste due API non implementino alcuna logica, il loro sviluppo dà la possibilità di familiarizzare con alcune tecnologie moderne come oAuth2 (utilizzato per l’autenticazione sulle API di Google e Avaza). Fortunatamente Mule ha una struttura estremamente ben fatta che permette di gestire questo (comune) scenario con facilità.
Dall’altro lato la process-API implementa tutte le logiche che servono nel progetto. Sfrutta le due sAPI per ottenere i dati da Avaza e, dopo alcune logiche di validazione, scriverli su Google Calendar. Anche lo sviluppo di questa pAPI dà la possibilità di imparare alcune delle “best practices” comunemente usate nell’IT moderno: quando viene inserita una richiesta di ferie, Avaza invia un webhook alla nostra pAPI e quindi dobbiamo implementare un reliability pattern. Per questa ragione abbiamo usato un database, ospitato da Amazon Web Services (AWS), per archiviare tutti i dati ricevuti da Avaza. Successivamente la pAPI prende i dati dal DB e li processa (o riprocessa, in caso di errori). Infine, poiché tutte le API sono ospitate su CloudHub, la pAPI sfrutta il sistema di notifiche della piattaforma per gestire allerte e richieste non adeguate.
Come parte della strategia di onboarding, tutta la struttura presentata non è stata pianificata all’inizio, ma al contrario è stato usato un approccio incrementale: ho iniziato da piccoli compiti e solo successivamente ho aggiunto nuove funzionalità in modo graduale (logica addizionale, gestione degli errori e, alla fine, un reliability pattern completo).

Questo progetto, che è ovviamente semplice se confrontato con i progetti che gestiamo abitualmente per i nostri clienti, mi ha dato una buona e solida introduzione a tutte le tecnologie di integrazione di MuleSoft e perciò mi ha fornito una buona base per progetti futuri legati ai nostri clienti.
E’ importante sottolineare che questo sistema di integrazione è ora in ambiente di produzione e pienamente funzionante!

In conclusione

È degno di nota che durante lo sviluppo di questo progetto interno, che è stato ovviamente sviluppato come percorso di apprendimento, ci ha anche dato la possibilità di testare alcune tecnologie MuleSoft all’avanguardia (come Anypoint Visualizer e Monitoring) portando quindi beneficio a tutto il team. Per esempio questo è come (automaticamente) Anypoint Visualizer mostra l’effettiva implementazione del progetto:

La duplicazione al livello process è dovuta al fatto che abbiamo utilizzato il nostro server di servizio per chiamare le API (ovvero, in realtà c’è solo una pAPI).

Un altro esempio è Anypoint Monitoring che mostra tutte le metriche delle API (nella figura sotto le metriche della nostra process-API).