Gestori di stato

I gestori di stato, chiamati anche semplicemente gestori, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o eseguendo la transizione della pagina corrente. Per ogni turno di conversazione, i gestori vengono valutati e possono influire sulla sessione. I gestori hanno tre tipi generali di dati:

Termine Definizione
Requisiti per i gestori Questi sono i requisiti che devono essere soddisfatti affinché il gestore abbia effetto sulla sessione. Un gestore viene chiamato quando soddisfa i suoi requisiti e influisce in qualche modo sulla sessione.
Fulfillment del gestore Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte sono definite nei dati statici dell'agente o recuperate dinamicamente dal tuo servizio webhook.
Handler transition target Se viene chiamato un gestore, viene utilizzata una destinazione di transizione facoltativa per modificare la pagina corrente. La pagina successiva può essere solo una pagina iniziale del flusso o una pagina all'interno del flusso attualmente attivo.

Esistono due tipi di gestori di stato con requisiti diversi:

Termine Definizione
Route Le route vengono chiamate quando un input utente finale corrisponde a un intent e/o viene soddisfatta una condizione sullo stato della sessione. Un percorso con un requisito di intent è chiamato anche percorso di intent. Un percorso con un solo requisito di condizione è chiamato anche percorso di condizione.
Gestori di eventi I gestori di eventi vengono chiamati quando viene richiamato un evento. Alcuni eventi integrati vengono attivati quando viene ricevuto un input utente finale imprevisto o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati che richiami quando succede qualcosa al di fuori della conversazione.

L'elaborazione di un gestore dello stato prevede tre passaggi:

Termine Definizione
1. Ambito Un gestore deve essere nell'ambito per avere effetto sulla sessione. L'ambito è determinato dall'applicazione di un gestore a un flusso, a una pagina o a un parametro del modulo e dall'attivazione del flusso associato, della pagina associata o dal tentativo dell'agente di compilare il parametro del modulo associato.
2. Valutazione Ogni gestore nell'ambito viene valutato in ordine. Se i requisiti di un gestore sono soddisfatti, la valutazione viene superata.
3. Chiamata Se un gestore è nell'ambito e supera la valutazione, viene chiamato. Viene richiamato qualsiasi fulfillment associato e alla sessione viene applicata qualsiasi destinazione di transizione associata.

Ambito

Affinché un gestore venga valutato, deve essere nell'ambito. L'ambito del gestore è uno strumento importante e potente che ti aiuta a controllare la conversazione. Controllando l'ambito di un gestore, puoi controllare:

X Elemento
Quando è possibile trovare una corrispondenza con un intent
Quando deve essere controllata una condizione
Quando un determinato evento può essere gestito
Quando può verificarsi una transizione di pagina
Quando viene fornita una risposta di fulfillment statica
Quando un fulfillment abilitato per i webhook viene chiamato per risposte dinamiche

L'ambito è determinato dall'applicazione di un gestore a un flusso, a una pagina o a un parametro del modulo e dall'attivazione del flusso associato, della pagina associata o dal tentativo dell'agente di compilare il parametro del modulo associato.

Le regole di definizione dell'ambito dettagliate sono le seguenti:

  • Route applicate al flusso attivo:
    • Se la pagina corrente è la pagina iniziale del flusso, sono nell'ambito.
    • Se la pagina corrente non è la pagina di inizio del flusso, sono nell'ambito solo se hanno un requisito di intent.
  • Le route applicate alla pagina corrente rientrano nell'ambito.
  • I gestori di eventi applicati al flusso attivo sono inclusi nell'ambito.
  • I gestori di eventi applicati alla pagina corrente sono inclusi nell'ambito.
  • I gestori di eventi applicati a un parametro del modulo che l'agente sta tentando di compilare sono inclusi nell'ambito.

Route

Le route hanno due requisiti e ne deve essere fornito uno o entrambi. Se vengono forniti entrambi i requisiti, devono essere soddisfatti entrambi per chiamare la route:

Termine Definizione
Requisito per l'intent Un intent che deve essere abbinato all'input utente finale per il turno di conversazione corrente. Quando un percorso ha un requisito di intent, viene chiamato percorso di intent.
Requisito della condizione Una condizione che deve essere soddisfatta. Quando una route ha un requisito di condizione, viene chiamata route di condizione.

Puoi applicare le route ai flussi (route a livello di flusso) e alle pagine (route a livello di pagina). Ad esempio, puoi utilizzare le route nelle seguenti situazioni:

X Elemento
Quando l'input utente finale corrisponde a un intent, la corrispondenza deve attivare una risposta di fulfillment statico.
Quando l'input utente finale corrisponde a un intent, la corrispondenza deve attivare un fulfillment abilitato per il webhook per una risposta dinamica.
Quando l'input utente dell'utente finale ha fornito l'ultimo parametro del modulo richiesto, un controllo della condizione attiva una transizione della sessione a un'altra pagina.
Quando l'input utente finale ha fornito un parametro del modulo specifico, un controllo della condizione attiva una risposta di fulfillment statico.
Un controllo della condizione impostato su true che forza una transizione di pagina.

Propagazione degli intent

In genere, quando viene chiamata una route a causa di un intent corrispondente, l'intent viene consumato. Un intent consumato non può essere abbinato di nuovo, a meno che un nuovo input utente finale non attivi una nuova corrispondenza dell'intent. Tuttavia, è possibile propagare una corrispondenza di intent da un flusso a un altro nel seguente scenario:

  • Una route in flow F1 ha intent I1 come requisito e flow F2 come target di transizione.
  • Flow F2 ha una route che richiede anche intent I1.

In questo caso, quando viene chiamato il percorso in flow F1, intent I1 viene abbinato due volte per un singolo input utente finale e vengono chiamati entrambi i percorsi.

La propagazione degli intent è utile per:

X Elemento
Cambia la pagina corrente in una pagina specifica in un altro flusso (il percorso del flusso di destinazione della transizione ha una pagina di destinazione della transizione specifica).
Crea un messaggio di benvenuto per la pagina iniziale di un flusso (il percorso del flusso di destinazione della transizione ha un fulfillment).

Gruppi di route

Quando crei un agente, potresti notare che molte pagine hanno un insieme comune di route. Per rendere i percorsi riutilizzabili, puoi definire gruppi di percorsi. Puoi creare queste risorse di gruppo riutilizzabili all'interno del flusso o dell'intero agente.

Ad esempio, potresti voler gestire l'input utente finale, come "Voglio aggiungere un condimento alla mia pizza" e "Voglio cambiare la dimensione della mia bevanda". Questi input devono essere gestiti quando una delle pagine del flusso è attiva. Potresti definire due percorsi con intent per gestire questi input per tutte le pagine pertinenti, ma questo comporterebbe un lavoro duplicato. In alternativa, puoi definire il gruppo di percorsi una sola volta e aggiungere un riferimento al gruppo in tutte le pagine pertinenti.

Gruppi di route a livello di flusso

I gruppi di route a livello di flusso sono risorse di gruppi di route create con un flusso come elemento principale. Sono riutilizzabili all'interno del flusso.

Gruppi di route a livello di agente

I gruppi di route a livello di agente sono risorse di gruppi di route create con un agente come elemento principale. Sono riutilizzabili nell'intero agente, ma non consentono percorsi che passano a una pagina non simbolica come destinazione.

Route a livello di flusso

Le route a livello di flusso sono route applicate a un flusso aggiungendole alla pagina iniziale del flusso. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
I gestori con un requisito di intent o condizione nell'ambito della pagina di avvio del flusso.
Gestori con un requisito di intent nell'ambito di tutte le pagine del flusso.

Per creare route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sul pulsante Aggiungi nell'intestazione Route.
  3. Si apre il riquadro di modifica del percorso.
  4. Fornisci i campi del percorso.
  5. Fai clic su Salva.

Per riordinare le route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Route.
  3. Viene visualizzato il riquadro dell'elenco dei percorsi.
  4. Trascina le route nell'ordine che preferisci. In alternativa, fai clic sul menu opzioni e seleziona Sposta in.

Per eliminare le route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Fai clic sul menu delle opzioni .
  5. Seleziona Elimina.

Route a livello di pagina

Le route a livello di pagina sono route applicate a una pagina. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito di intent o condizione nell'ambito quando sono attive pagine specifiche.

Per creare route a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sul pulsante Aggiungi nell'intestazione Route.
  3. Si apre il riquadro di modifica del percorso.
  4. Fornisci i campi del percorso.
  5. Fai clic su Salva.

Per riordinare i percorsi a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Route.
  3. Viene visualizzato il riquadro dell'elenco dei percorsi.
  4. Trascina le route nell'ordine che preferisci. In alternativa, fai clic sul menu opzioni e seleziona Sposta in.

Per eliminare i percorsi a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Fai clic sul menu delle opzioni .
  5. Seleziona Elimina.

Gestori di eventi

I gestori di eventi hanno un requisito per essere chiamati:

Termine Definizione
Requisito per gli eventi Un evento che deve essere richiamato. Gli eventi sono identificati dal nome. Alcuni eventi integrati vengono richiamati quando viene ricevuto input utente finale imprevisto o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati da richiamare quando succede qualcosa al di fuori della conversazione.

Puoi applicare gestori di eventi ai flussi (gestori di eventi a livello di flusso), alle pagine (gestori di eventi a livello di pagina) e ai parametri (gestori di eventi a livello di parametro). Ad esempio, puoi utilizzare i gestori di eventi nelle seguenti situazioni:

X Elemento
Quando l'input utente finale non corrisponde ad alcun intent, un gestore di eventi nessuna corrispondenza fornisce una risposta di fulfillment statico specifica.
Un timer scade nel tuo sistema e vuoi fornire informazioni di promemoria all'utente finale con una risposta di fulfillment statico specifica.

Gestori di eventi a livello di flusso

I gestori di eventi a livello di flusso sono gestori di eventi applicati a un flusso. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito per gli eventi nell'ambito della pagina iniziale del flusso.
Gestori con un requisito per gli eventi nell'ambito di tutte le pagine del flusso.
Gestione di input imprevisti dell'utente finale, condivisi da tutte le pagine di un flusso.
Gestione degli errori del webhook, condivisa da tutte le pagine di un flusso.
Gestione degli eventi personalizzati richiamati dal tuo sistema, condivisi da tutte le pagine di un flusso.

Ogni flusso ha gestori di eventi per gli eventi integrati no-match e no-input. Questi gestori di eventi vengono creati automaticamente quando crei un flusso e non possono essere eliminati.

Per creare gestori di eventi a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sul pulsante Aggiungi nell'intestazione Gestori di eventi.
  3. Viene visualizzato il riquadro del gestore di eventi.
  4. Fornisci i campi del gestore di eventi.
  5. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Gestori di eventi.
  3. Viene visualizzato il riquadro dell'elenco dei gestori di eventi.
  4. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Gestori di eventi a livello di pagina

I gestori di eventi a livello di pagina sono gestori di eventi applicati a una pagina. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito per gli eventi nell'ambito quando sono attive pagine specifiche.
Gestione di input imprevisti dell'utente finale, specifici per una pagina.
Gestione degli errori del webhook, specifici per una pagina.
Gestione degli eventi personalizzati richiamati dal tuo sistema, specifici per una pagina.

Per creare gestori di eventi a livello di pagina dalla console:

  1. Apri una pagina (non la pagina iniziale del flusso).
  2. Se non è presente l'intestazione Gestori di eventi, fai clic su Aggiungi gestore di stato, seleziona Gestori di eventi, quindi fai clic su Applica.
  3. Fai clic sul pulsante Aggiungi nell'intestazione Gestori di eventi.
  4. Viene visualizzato il riquadro del gestore di eventi.
  5. Fornisci i campi del gestore di eventi.
  6. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di pagina dalla console:

  1. Apri una pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Gestori di eventi.
  3. Viene visualizzato il riquadro dell'elenco dei gestori di eventi.
  4. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Gestori di eventi a livello di parametro

I gestori di eventi a livello di parametro sono gestori di eventi che vengono applicati a un parametro del modulo. Sono anche noti come gestori di nuovi prompt. Questi gestori di eventi non consentono eventi personalizzati, poiché sono destinati specificamente a gestire input non validi degli utenti finali durante la compilazione dei moduli.

Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
L'utente finale non ha fornito un input valido quando gli è stato chiesto di compilare un parametro del modulo.

Per creare gestori di eventi a livello di parametro dalla console:

  1. Apri una pagina che contiene parametri del modulo.
  2. Fai clic su un parametro.
  3. Si apre il riquadro dei parametri.
  4. Scorri verso il basso fino alla sezione Gestori di eventi di nuovo prompt, quindi fai clic su Aggiungi gestore di eventi.
  5. Viene visualizzato il riquadro del gestore di eventi.
  6. Fornisci i campi del gestore di eventi.
  7. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di parametro dalla console:

  1. Apri una pagina contenente i parametri del modulo.
  2. Fai clic su un parametro.
  3. Si apre il riquadro dei parametri.
  4. Scorri verso il basso fino alla sezione Gestori di eventi di nuovo prompt.
  5. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Eventi integrati

I seguenti eventi sono integrati e vengono richiamati da Dialogflow CX. Alcuni eventi sono limitati a determinati livelli.

Nome evento
 Livello di flusso A livello di pagina A livello di parametro Richiamato quando
sys.no-match-default ✔ ✔ ✔
  • A livello di flusso o pagina: l'input utente finale non corrisponde ad alcun intent per i gestori che rientrano nell'ambito.
  • Per il livello di parametro: l'input utente finale non soddisfa il parametro del modulo.
sys.no-match-[1-6] ✔ ✔ ✔ Se fornisci gestori per uno di questi eventi ordinati numericamente, questi vengono richiamati al posto di sys.no-match-default e nell'ordine: sys.no-match-1, sys.no-match-2…
sys.no-input-default ✔ ✔ ✔ L'input utente finale non è stato ricevuto. Questo può essere richiamato quando:
  • Dialogflow CX riceve un input di testo vuoto dall'utente finale.
  • Dialogflow CX riceve un input audio vuoto dall'utente finale o l'input non contiene parlato riconosciuto.
  • Un timeout di assenza di parlato si verifica prima che l'input audio dell'utente finale contenga un parlato riconosciuto.
sys.no-input-[1-6] ✔ ✔ ✔ Se fornisci gestori per uno di questi eventi ordinati numericamente, questi vengono richiamati al posto di sys.no-input-default e nell'ordine: sys.no-input-1, sys.no-input-2…
sys.invalid-parameter ✔ Viene richiamato quando una risposta del webhook invalida il parametro impostando WebhookResponse.pageInfo.formInfo.parameterInfo.state su INVALID.
sys.long-utterance ✔ ✔ ✔ L'input utente finale supera la lunghezza massima consentita (256 caratteri) corrispondente a intent non generativi o parametri. Se non viene fornito, Dialogflow CX tratta l'espressione lunga dell'utente come no-match. Per gli input audio in streaming, questo evento viene attivato solo dopo che il client chiude lo stream audio.
webhook.error ✔ ✔ La chiamata webhook ha restituito un errore. Questo evento viene richiamato solo: 1) se non esiste un gestore di eventi webhook granulare (ad es. webhook.error.timeout) che corrisponde al codice di errore del webhook, 2) se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
webhook.error.timeout ✔ ✔ La chiamata webhook è scaduta. Un evento webhook verrà richiamato solo se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
webhook.error.bad-request ✔ ✔ Il webhook ha restituito 400 Bad Request. Un evento webhook verrà richiamato solo se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
webhook.error.rejected ✔ ✔ Il webhook ha restituito 401 Unauthorized o 403 Forbidden. Un evento webhook verrà richiamato solo se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
webhook.error.unavailable ✔ ✔ Il webhook ha restituito 503 Service Unavailable. Un evento webhook verrà richiamato solo se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
webhook.error.not-found ✔ ✔ La chiamata webhook non è riuscita perché l'URL webhook non era raggiungibile. Un evento webhook verrà richiamato solo se non è impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook in errore. Per i dettagli, consulta la sezione Ordine di valutazione.
flow-cancelled ✔ ✔ L'utente finale ha richiesto l'annullamento del flusso. Questo evento viene attivato dalla pagina Termina flusso con annullamento, consulta la END_FLOW_WITH_CANCELLATION destinazione della transizione simbolica.
flow-failed ✔ ✔ Questo flusso non è stato in grado di completare l'attività specificata. Questo evento viene attivato dalla pagina Termina flusso con errore. Consulta la END_FLOW_WITH_FAILURE destinazione della transizione simbolica.
flow-failed-human-escalation ✔ ✔ L'utente finale ha richiesto di parlare con agenti umani. Questo evento viene attivato dalla pagina Termina flusso con escalation umana, consulta la END_FLOW_WITH_HUMAN_ESCALATION destinazione della transizione simbolica.

Eventi personalizzati

Puoi creare eventi e gestori di eventi personalizzati. Gli eventi personalizzati vengono utilizzati per gestire ciò che accade al di fuori della conversazione con l'utente finale. Ad esempio, l'utente finale ha fatto clic su un pulsante, è trascorso un certo periodo di tempo, l'inventario disponibile è cambiato durante la conversazione e così via.

Gli eventi sono semplicemente identificati dal nome. Per evitare conflitti con gli eventi integrati, non utilizzare nomi di eventi che iniziano con sys. o webhook..

Per richiamare un evento con l'API, consulta il campo queryInput.event del metodo detectIntent per il tipo Session.

Seleziona un protocollo e una versione per il riferimento alla sessione:

Protocollo V3 V3beta1
REST Risorsa Session Risorsa Session
RPC Interfaccia della sessione Interfaccia della sessione
C++ SessionsClient Non disponibile
C# SessionsClient Non disponibile
Vai SessionsClient Non disponibile
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP Non disponibile Non disponibile
Python SessionsClient SessionsClient
Ruby Non disponibile Non disponibile

Ordine di valutazione

I gestori vengono valutati in un ordine specifico. Si applicano le seguenti regole generali:

  1. Vengono valutati solo i gestori in scope.
  2. Possono essere chiamati solo i gestori i cui requisiti sono soddisfatti.
  3. Se viene chiamato un gestore senza un target di transizione, la valutazione dell'elenco dei gestori continua. A causa di questa regola, più fulfillment possono aggiungere più messaggi alla coda di risposta.
  4. Se viene chiamato un gestore con un target di transizione, la valutazione dell'elenco dei gestori termina.
  5. Se viene chiamato un gestore con fulfillment e il fulfillment genera un errore del webhook:
    • Se il gestore ha un target di transizione definito, il webhook non va a buon fine senza generare errori.
    • Se un gestore di eventi è nell'ambito dell'evento, gestisce l'evento e la valutazione dell'elenco dei gestori termina.
    • Se non è presente alcun gestore di eventi nell'ambito dell'evento, il webhook non va a buon fine senza generare errori.
  6. Quando un requisito di intent viene soddisfatto, l'intent viene utilizzato, pertanto può essere chiamato solo il primo gestore di route trovato per l'intent (consulta la sezione Propagazione degli intent per le eccezioni).
  7. Quando un requisito della condizione è soddisfatto, la condizione non viene consumata, quindi è possibile chiamare più route con la condizione.
  8. Quando un requisito per gli eventi è soddisfatto, l'evento viene utilizzato, quindi può essere chiamato solo il primo gestore di eventi trovato per l'evento.
  9. Lo stack di chiamate del gestore può influire sull'ordine di valutazione.

La valutazione si articola in tre fasi:

  1. Le route che hanno un requisito di intent vengono valutate in questo ordine:
    1. A livello di pagina: singoli percorsi applicati alla pagina corrente, nell'ordine fornito.
    2. Gruppi a livello di pagina: gruppi di route applicati alla pagina corrente, nell'ordine fornito.
    3. A livello di flusso: percorsi applicati al flusso attivo, nell'ordine fornito.
    4. Gruppi a livello di flusso: gruppi di route applicati al flusso attivo, nell'ordine fornito.
  2. Le route con un solo requisito di condizione vengono valutate in questo ordine:
    1. A livello di pagina: singoli percorsi applicati alla pagina corrente, nell'ordine fornito.
    2. Gruppi a livello di pagina: gruppi di route applicati alla pagina corrente, nell'ordine fornito.
    3. A livello di flusso (solo se la pagina corrente è la pagina iniziale del flusso): percorsi applicati al flusso attivo, nell'ordine fornito.
    4. Gruppi a livello di flusso (solo se la pagina corrente è la pagina di inizio del flusso): gruppi di route applicati al flusso attivo, nell'ordine fornito.
  3. I gestori di eventi vengono valutati in questo ordine:
    1. A livello di parametro: gestori di eventi applicati al parametro del modulo della pagina corrente che l'agente sta tentando di compilare (gestori di invio di un nuovo prompt), nell'ordine fornito.
    2. A livello di pagina: gestori di eventi applicati alla pagina corrente, nell'ordine fornito.
    3. A livello di flusso: gestori di eventi applicati al flusso attivo, nell'ordine fornito.

Target di transizione simbolici

Quando inserisci una destinazione di transizione per un gestore, puoi inserire flussi o pagine specifici, ma anche destinazioni di transizione simboliche:

Target di transizione simbolica
 Descrizione
START_PAGE Transizione alla pagina iniziale del flusso attivo con lo stesso nome.
END_FLOW Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. Consulta anche Limite dello stack di chiamate e dello stack di flusso del gestore.
END_FLOW_WITH_CANCELLATION Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato flow-cancelled. Consulta anche Limite dello stack di chiamate e dello stack di flusso del gestore.
END_FLOW_WITH_FAILURE Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato flow-failed. Consulta anche Limite dello stack di chiamate e dello stack di flusso del gestore.
END_FLOW_WITH_HUMAN_ESCALATION Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato flow-failed-human-escalation. Consulta anche Limite dello stack di chiamate e dello stack di flusso del gestore.
END_SESSION Cancella la sessione corrente e passa alla pagina speciale denominata END_SESSION. Il successivo input utente riavvierà la sessione nella pagina di avvio del flusso di avvio predefinito.
PREVIOUS_PAGE Transizione alla pagina precedente che ha causato una transizione alla pagina corrente. Lo stato della pagina precedente verrà ripristinato dopo la transizione.
CURRENT_PAGE Esegui nuovamente la transizione alla pagina corrente. Questa opzione può essere utile se vuoi che l'agente ripeta qualcosa.

Limite dello stack di chiamate e dello stack di flusso del gestore

Quando una sessione passa da un flusso all'altro con target di transizione specifici, ogni flusso viene inserito nello stack dei flussi.

Stack di chiamate del gestore

Quando una sessione passa a END_FLOW, torna alla pagina chiamante che ha causato una transizione al flusso completato. In questo caso, lo stack di chiamate del gestore viene conservato. Tutti i gestori precedentemente valutati dalla pagina chiamante verranno ignorati e i gestori rimanenti verranno valutati in ordine.

Ad esempio:

  1. La pagina P ha tre gestori in questo ordine: H1, H2, H3.
  2. H1 viene valutato, ma non causa una transizione.
  3. H2 viene valutato e causa una transizione al flusso F.
  4. Una pagina nel flusso F passa a END_FLOW.
  5. La sessione torna alla pagina P, che diventa di nuovo attiva con uno stato conservato.
  6. La valutazione del gestore nella pagina P continua dallo stato conservato, quindi viene valutato H3.

Limite dello stack di flusso

Il limite massimo dello stack di flusso è 25. Il superamento del limite massimo dello stack potrebbe causare la rimozione dei flussi dallo stack, con un comportamento imprevisto durante l'utilizzo della transizione END_FLOW. Per evitare questi potenziali problemi, riduci al minimo il numero di transizioni da flusso a flusso che precedono la transizione END_FLOW.

Se lo stack di flusso è vuoto, la transizione END_FLOW termina la sessione.

Imposta condizioni

Per impostare le condizioni con la console, fornisci le regole di condizione con una delle tre opzioni logiche:

  • Corrispondenza con ALMENO UNA regola (OR)
  • Corrispondenza con OGNI regola (AND)
  • Personalizza espressione

Per comodità, puoi utilizzare le opzioni AND/OR per creare condizioni semplici o composte per i valori parametro.

Puoi utilizzare l'opzione in formato libero Personalizza espressione per tutti i tipi di condizioni, incluse le funzioni di sistema e le costanti booleane.

Ad esempio, per impostare una condizione che ha il 10% di probabilità di superare la valutazione, seleziona l'opzione Personalizza espressione e inserisci $sys.func.rand() < 0.1 nel campo Condizione:

Screenshot dell'impostazione di una condizione personalizzata

Indietro
Pagine
Avanti
Intent