La sezione Design consente di definire e personalizzare il comportamento dell’agente virtuale, configurando le diverse tipologie di servizi e tecnologie da integrare all’interno del flusso di processo che parte dalla richiesta, testuale o vocale, dell’utente finale e si conclude con la risposta fornita dall’agente virtuale.
Per rendere possibile ciò, viene messa a disposizione un’area di lavoro in cui posizionare e configurare singoli componenti da integrare e alcune sezioni specifiche che permettono di attivare e personalizzare comportamenti a livello di singoli intenti.
L’area di lavoro della sezione Process Flows consente di definire i singoli step del processo di elaborazione della richiesta inviata dall’utente finale all’agente virtuale, posizionare singoli elementi atomici, denominato connettori, i quali permettono di invocare specifici servizi, sistemi o tecnologie.
Ogni flusso di elaborazione prende il nome di journey, a cui può essere associata un singolo motore di NLU (es. Dialogflow) e un numero arbitrario di connettori che verranno processati nell’ordine in cui vengono disposti all’interno dell’area di lavoro (dall’alto verso il basso) ogni volta che l’agente virtuale viene invocato.
Come creare una nuova journey
Per definire una nuova journey è necessario selezionare il bottone posto nella barra inferiore dell’area di lavoro e specificare un nome che identifichi la journey stessa ed un’eventuale descrizione.
Inoltre è necessario stabilire se tipologia di journey che si intende creare, abilitando o meno la configurazione come “Fulfillment Journey” e se tale journey possa essere o meno invocata dall’esterno (“Public”).
Una journey non “Public” potrà essere invocata e testata unicamente all’interno della piattaforma Tellya (tale configurazione può essere modificata anche in seguito).
Creazione di una Fulfillment Journey
In determinate progettualità, Tellya non deve frapporsi tra il Front End ed il motore di NLU, ma bensì dovrà posizionarsi e agire solo in seguito all’interrogazione di tale motore. Sarà quindi un sistema esterno ad invocare il motore di NLU, il quale a sua volta dovrà invocare Tellya in modo da effettuare eventuali attività di processing configurate all’interno della journey.
Per rendere possibile questo comportamento è necessario creare una “Fulfillment Journey”, abilitato tale opzione in fase di creazione di una “Standard Journey”.
Una “Standard Journey” non può essere convertita in “Fulfillment Journey” dopo la sua creazione e non è neanche possibile il viceversa: è necessario eliminare la journey e crearne una nuova.
Configurazione di una Fulfillment Journey
Dopo aver creato una Fulfillment Journey è necessario procedere alla sua configurazione selezionando l’agente che invocherà tale journey.
Tale configurazione può essere eseguita selezionando l’alert che viene mostrato nella parte superiore dell’area di lavoro (“Fulfillment Journey”) quando in una Fulfillment Journey non è stato ancora configurato un agente, oppure selezionando l’icona dell’ingranaggio posta in basso a destra e successivamente la sezione “Fulfillment” della finestra visualizzata.
In questa sezione si trovano l’url da chiamare e l’apiKey che vanno inseriti nell’agente al momento della configurazione.
L’agente associato ad una Fulfillment Journey può essere modificato in qualasisi momento, scegliendo tra quelli previsti all’interno del proprio account Tellya.
Dialogflow ES
Se si utilizza Google Dialogflow ES come motore di NLU è necessario accedere alla console e configurare nella sezione “Fulfillment” le informazioni relative al Webhook, in particolare URL e l’apiKey della journey che si desidera invocare.
Nel caso in cui si utilizzino delle API Beta di DIalogflow bisogna disabilitarle per poter utilizzare la Fulfillment Journey.
Dialogflow CX
Se si utilizza Google Dialogflow CX come motore di NLU è necessario accedere alla console e configurare nella sezione “Webhooks” le informazioni relative al Webhook, in particolare URL e l’apiKey della journey che si desidera invocare.
Per entrambe le configurazioni si possono inserire come Headers opzionali:
- customResponse: di default impostato a False, che abilita l’utilizzo delle risposte custom channel al posto di quelle di Tellya
- save: di default impostato a True, che permette di non salvare, se impostato a false, le conversazioni su Tellya perdendo la possibilità di avere la History e le analitiche.
Creazione di una Dispatcher Journey
Una journey di tipo “Dispatcher” permette di orchestrare il dialogo tra l’utente finale e diversi agenti virtuali configurati all’interno di journey distinte, senza che l’utente percepisca il trasferimento del dialogo da un agente all’altro.
Questa tipologia di journey permette di superare il vincolo che impone l’utilizzo di un unico motore di NLU all’interno di una singola journey, dando possibilità di configurare il passaggio da una journey all’altra (e quindi da un agent all’altro) in specifici punti della conversazione e con regole pre stabilite.
È possibile configurare una journey “Dispatcher” durante la fase di creazione di una journey, selezionando l’opzione “Dispatcher journey”. In fase di creazione di una journey di tale tipologia, verrà automaticamente inserito un connettore “Dispatcher” all’interno del Process Flow della journey, il quale richiede di essere successivamente configurato.
Una journey “Dispatcher” verrà contrassegnata da un’icona specifica (
) all’interno delle liste che elenca journey configurate (ad esempio nel “Process Flow”), in modo da poterla distinguere dalle altre tipologie di journey.
All’interno di una journey di tipo “Dispatcher” non è possibile configurare connettori della categoria “Natural Language Understanding” e altre tipologie di connettori di sistema (“Action Mapping”, “Data Transfer”, “Event caller”, “Generic Rule”).
Come integrare una journey (Server integration)
Selezionando il bottone di impostazione della journey e successivamente la sezione “Server integration”, è possibile visualizzare i dettagli per invocare tramite richiesta HTTP POST la journey selezionata, integrando quindi il dialogo con l’agente virtuale all’interno di sistemi esterni.