Estendere Calybron

La piattaforma è fatta per essere estesa da chi la adotta, in due direzioni che non si sovrappongono: si può aggiungere un canale, cioè un mezzo nuovo attraverso cui gli utenti arrivano, e si può aggiungere un modulo, cioè una capacità nuova che la piattaforma non aveva. In entrambi i casi il resto non si tocca.

Un canale nuovo

Porta dentro le domande. Un chiosco in una sede, un gateway SMS, la chat di un portale scritto in casa, un sistema di ticketing: tutto ciò con cui le persone comunicano già e che Calybron ancora non conosce.

Un modulo nuovo

Porta dentro le capacità. Un componente che dichiara quali intenti sa gestire e li esegue: logica di dominio, un sistema proprietario, un'automazione che vive fuori dalla piattaforma.

Il principio

Un canale non interpreta e un modulo non conosce i canali. Chi costruisce un canale impara quattro cose — aprire la connessione, mandare un messaggio, ricevere una risposta, dire di chi è la conversazione — e non ha bisogno di sapere come la piattaforma riconosce le intenzioni. Chi costruisce un modulo dichiara i propri intenti e i dati che servono a ciascuno, riceve le richieste già riconosciute e con i dati raccolti, e risponde: non sa se l'utente ha scritto da Telegram, dalla posta o al telefono.

È la ragione per cui i cinque canali esistenti si assomigliano tanto, e per cui lo stesso modulo risponde su tutti i mezzi senza una riga in più.

Come funziona il collegamento

Canali e moduli si collegano alla piattaforma con due protocolli gemelli — il CIP per i canali, l'IIP per i moduli — che condividono la stessa forma:

• una connessione sicura e persistente, aperta dal componente verso la piattaforma: nella rete del cliente non serve aprire nessuna porta;
• un token nel momento del collegamento, generato dalla dashboard, che identifica il componente e ne stabilisce il perimetro — l'organizzazione e gli scope su cui può operare;
• un aggancio confermato dalla piattaforma, dopo il quale il componente è operativo e compare nel monitoraggio;
• messaggi con un nome, nei due sensi, e la riconnessione automatica quando la rete cade.

Un modulo, in più, si presenta: al collegamento dichiara gli intenti che sa gestire, con la descrizione e i dati che servono a ciascuno. Da quel momento quegli intenti esistono nello scope, e la piattaforma li propone, raccoglie i dati conversando e consegna al modulo la richiesta completa. Il modulo può anche chiedere un dato in più nel mezzo dell'esecuzione — un sub intent — e la raccolta la conduce la piattaforma.

Cosa serve

	Un canale	Un modulo
Si crea dalla dashboard	Un canale di tipo proprio, con il suo token	Un modulo registrato sullo scope, con il suo token
Si implementa	Il traduttore fra il mezzo e il protocollo	Il contratto degli intenti e la loro esecuzione
Linguaggio	Qualsiasi, con una libreria WebSocket	Qualsiasi; per Node.js esiste la libreria di riferimento, con un modulo di esempio da cui partire
Si vede	Nello Stato Sistema e nelle sessioni	Nello Stato Sistema e nella scheda del modulo, con i suoi intenti

Oltre i protocolli

Tutto ciò che si fa dalla dashboard — creare un'organizzazione, collegare un canale, pubblicare una Knowledge Base, avviare un processo — si può fare anche via API, con la stessa autenticazione e gli stessi permessi degli operatori. È la strada per automatizzare l'attivazione di un cliente o per integrare la piattaforma nei sistemi di chi la gestisce.

I processi, dal canto loro, espongono un webhook: un indirizzo che i sistemi del cliente chiamano per avviare un flow da un evento esterno, e il blocco di un flow può chiamare qualsiasi servizio attraverso le Integrazioni.

Il contratto completo

La specifica dei due protocolli — messaggi, campi, sequenza del collegamento, gestione degli errori — e il riferimento API completo sono forniti a chi costruisce un'estensione, insieme a un ambiente in cui provarla.