Trigger

Scopri come utilizzare i trigger per creare logica nelle app senza scrivere codice.

In questo articolo imparerai:

• I comandi dei trigger, la logica e il comportamento di esecuzione
• Le migliori pratiche per la creazione e l’organizzazione dei trigger
• Casi d’uso comuni

I trigger ti consentono di aggiungere logica alla tua app. Puoi utilizzare i trigger per interagire con i dispositivi, inviare avvisi, scrivere dati, comunicare con i sistemi di backend e molto altro ancora, il tutto senza scrivere una sola riga di codice.

Tra i casi d’uso più comuni dei trigger figurano:

• Navigazione all’interno di un’app: utilizzare una transizione per passare a un passaggio diverso.
• Completare un'app: registrare i metadati dell'app.
• Eseguire una funzione del connettore per accedere a un sistema di back-end: utilizzare i connettori per consentire a Tulip di interagire con sistemi di terze parti ed eseguire una funzione del connettore tramite un trigger.
• Invio di avvisi: inviare avvisi via e-mail o SMS da un'app a un amministratore. Questi messaggi possono includere immagini, informazioni sullo stato del processo o altre informazioni rilevanti.
• Archiviazione dei dati: archivia i dati di input provenienti da un'app in variabili o tabelle.
• Utilizzare un dispositivo: per gli operatori che utilizzano entrambe le mani durante un processo, aggiungere un trigger per un evento del dispositivo, come un pedale, per passare alla fase successiva.

Come funzionano i trigger?

Logica

I trigger utilizzano una struttura logica " quando, se, allora, altrimenti ":

• quando "l'evento viene registrato in Tulip"
• allora "esegui un'azione" o "effettua una transizione".

I trigger possono anche contenere logica condizionale:

• quando "si registra un evento in Tulip"
• if "la condizione è soddisfatta"
• allora "intraprendere un'azione"
• altrimenti "eseguire un'azione diversa"

Scopri di più sulla logica condizionale dei trigger qui.

I trigger sono raggruppati in un Trigger Event e consistono in un'azione e in condizioni.

I trigger possono essere semplici come nell’esempio seguente:

Quando viene premuto un pulsante, passare al passaggio successivo.

Oppure, i trigger possono essere più complessi, come la scansione di un codice a barre che interroga un database backend per restituire le informazioni sull'ordine sotto forma di variabile.

Quando lo scanner di codici a barre invia i dati alla Stazione corrente, una (eseguita tramite una Funzione Connettore) recupera i dettagli dell’ordine da un database esterno e memorizza il valore in una Variabile. Il trigger passa quindi al passaggio successivo.

Tipi di comandi

È possibile utilizzare due tipi di comandi in un trigger:

1. Azione: una modifica nell’app che non è correlata al cambio di fase (ad es. visualizzare un messaggio di errore, inviare un’e-mail, acquisire uno screenshot dell’app)
2. Transizione: un evento di navigazione all’interno dell’app stessa (ad es. passare alla fase successiva, completare un’app, annullare un’app). Le transizioni possono far scattare altri trigger (cioè avviarli). Ad esempio, è possibile creare un trigger a livello di app che si attiva ogni volta che l’app viene completata.

Coda dei trigger

Gli (ad es. clic su un pulsante) aggiungono i trigger a una sequenziale a thread singolo, da eseguire nel Tulip Player.

La influisce su:1. Funzioni: * Le funzioni sono incluse nella coda dei trigger2. Widget personalizzati: * L’esecuzione della logica in un widget personalizzato può influire sulla coda dei trigger

Ordine di esecuzione

I trigger vengono eseguiti in serie e in ordine in base all’ Trigger Event e (ad es. clic su un pulsante, timer, selezione di una riga della tabella).

I trigger vengono eseguiti in modo sequenziale, il che significa che il primo trigger della serie deve essere completato prima che il secondo inizi a essere eseguito. Questo ordine di esecuzione dei trigger è noto come coda dei trigger.

La coda dei trigger è separata dalle altre attività all’interno di un’app, quali le interazioni con le variabili (ad es. inserimenti di testo, caselle di controllo), i widget personalizzati e il codice JavaScript dei widget personalizzati.

Come vengono utilizzati i valori di input nei trigger?

I valori di input (ovvero le variabili) vengono passati per riferimento ai trigger.

I trigger fanno riferimento al valore di input di una variabile al momento dell’esecuzione del trigger. Se il valore di input cambia prima che un trigger venga eseguito, il trigger farà riferimento al valore più aggiornato.

Le variabili sono globali a livello di app, il che le rende modificabili da altre logiche presenti nell’app.

:

Quando vengono annullati i trigger?

I trigger presenti nella coda dei trigger vengono annullati, e quindi non verranno eseguiti, quando:

1. Un trigger viene messo in coda dopo una transizione: quandoviene eseguita una transizione (ad es. Avanti, Completa app, Vai al passaggio per nome, ecc.), tutti i trigger rimasti in coda vengono annullati.
2. Chiusura forzata del Tulip Player: seun operatore chiude forzatamente il Player (ad esempio, se un'app non risponde), tutte le azioni rimanenti in un trigger in esecuzione e tutti i trigger rimanenti nella coda vengono annullati.

Gestione degli errori

Gli errori dei trigger e la conseguente annullamento si verificano nei seguenti scenari:

1. Errore nell’azione del trigger
2. Timeout del trigger

Errore nell’azione del trigger

Quando un'azione all'interno di un trigger genera un errore, le azioni rimanenti in quel trigger vengono saltate o annullate:

Dopo un errore, per impostazione predefinita, eventuali trigger rimanenti nella coda e nell’evento del trigger non verranno eseguiti per i seguenti trigger a livello di app e di fase:* Avvio dell’app* Completamento dell’app* Annullamento dell’app* All’ingresso nella fase* All’uscita dalla fase

Per tutti gli altri tipi di trigger (ad es. «Quando si preme un pulsante»), l’opzione «Interrompi i trigger rimanenti in caso di errore» è disattivata per impostazione predefinita.

Timeout del trigger

Se un trigger va in timeout (vedere Timeout dei trigger), tutti i trigger rimanenti nella coda verranno annullati.

Comportamento tecnico

Tempo di esecuzione del trigger

• I trigger vengono eseguiti in sequenza in un unico ciclo di esecuzione. Un ciclo di esecuzione è il periodo durante il quale un trigger è attivamente in esecuzione in Tulip.
• I trigger non vengono mai eseguiti in parallelo o in background rispetto ad altri trigger. Un nuovo trigger non può iniziare l’esecuzione finché il trigger corrente, in esecuzione, non è terminato.
• Gli operatori possono comunque interagire con l’app (ad esempio, cliccare sui pulsanti, interagire con le tabelle) mentre un trigger è in esecuzione. Questi clic sui pulsanti e altri eventi relativi ai trigger aggiungeranno nuovi trigger alla coda dei trigger.

Timeout dei trigger - aggiornato a partire da LTS15 / r332

Il timeout predefinito di un trigger è di 10 minuti; trascorso questo tempo, il trigger e le eventuali azioni rimanenti verranno annullati e tutti gli altri trigger presenti nella coda verranno annullati.

Il periodo di timeout di 10 minuti si applica all’Trigger Event. Ad esempio, se il clic su un pulsante attiva 5 trigger, tutti e 5 i trigger presenti nella coda e le rispettive azioni devono essere eseguiti entro i 10 minuti.

Dopo 30 secondi dall’avvio del trigger, l’app visualizza il seguente messaggio all’operatore:

Dopo 100 secondi dall’avvio del trigger, l’app mostra all’operatore il seguente messaggio:

Dopo 10 minuti, il trigger viene annullato e l’app visualizza il seguente messaggio di errore:

Impostazioni opzionali del timeout

Modifica le impostazioni del timeout per un'istanza tramite i metodi riportati di seguito:

1. Tulip può abilitare o disabilitare un'impostazione che consente agli operatori di annullare manualmente un trigger di lunga durata dopo i primi 100 secondi. Contatta l'assistenza Tulip per abilitare questa funzionalità.

2. L'assistenza Tulip può ridurre o aumentare il periodo di timeout. Si noti che Tulip raccomanda un periodo di timeout di 10 minuti come punto di partenza, per aumentare la probabilità che la logica venga eseguita fino al completamento. Se l'esecuzione di un trigger richiede costantemente più di qualche minuto, prendere in considerazione quanto segue:

   • Semplificare la logica del trigger per migliorare l’esperienza dell’operatore e ridurre la probabilità di errore del trigger.
   • Se possibile, avviare un’automazione in background per alleggerire l’esecuzione della logica ed evitare di bloccare il proseguimento del lavoro dell’operatore.
   • Esaminare e ottimizzare eventuali dipendenze da sistemi di terze parti presenti nella logica del trigger (ad es. funzioni del connettore lente, API non ottimali utilizzate).

Azioni sui record della tabella

Creazione di un record di tabella

Per la creazione di un nuovo record di tabella, la best practice consiste nel far seguire immediatamente all'azione " Record di tabella / Crea record " le corrispondenti azioni di manipolazione dei dati per popolare le altre colonne del record di tabella appena creato.

Se sono presenti altre azioni tra l’azione «Record di tabella / Crea» e quelle per compilare le altre colonne, la generazione di quel record di tabella apparirà come eventi separati nel widget della cronologia dei record.

Creazione di un record di tabella – a partire da LTS15 / r332

A partire dalla versione LTS15, le azioni sequenziali relative alle tabelle " Record tabella / Crea record " e " Manipolazione dati / Salva " verranno raggruppate per lo stesso record. Ciò significa che le azioni "Crea" e "Manipolazione dati" in un trigger vengono eseguite in un'unica transazione.

Le azioni "Crea record" e "Manipolazione dati / Salva" non verranno raggruppate in un'unica transazione se tra di esse sono presenti altre azioni (ad esempio, manipolazioni di dati su variabili o altri record di tabella, funzioni del connettore, ecc...).

Nei trigger di esempio riportati di seguito, l’azione «Crea record» e le azioni «Manipolazione dati / Salva» verranno raggruppate e andranno a buon fine tutte insieme oppure falliranno tutte insieme. Se tutte le azioni falliscono, verranno riprovate insieme con tentativi di ripristino resilienti.

Esempio 1: "Crea" e manipolazioni dei dati sequenziali sullo stesso record di tabella. Queste operazioni andrebbero a buon fine tutte insieme o fallirebbero tutte insieme in LTS15, ma non nelle versioni precedenti a LTS12.

Esempio 2: Creazione sequenziale e manipolazioni dei dati su uno stesso record della tabella seguite da un’azione “Funzione connettore” Leazioni “Creazione record tabella” e “Manipolazione dati” verrebbero raggruppate in LTS15. L’azione “Funzione connettore” potrebbe fallire indipendentemente dal successo delle azioni relative alla tabella.

Nel trigger seguente, le azioni "Manipolazione dati" e "Salvataggio" vengono eseguite su due diversi record della tabella; pertanto, le azioni non saranno raggruppate in un’unica transazione.

Esempio 3: "Record della tabella / Crea" e "Manipolazione dati / Salva" sullo stesso record della tabella, separate da un’altra azione di "Manipolazione dati". Questeazioni non saranno raggruppate in un’unica transazione.

Nel trigger seguente, le azioni "Record della tabella" e "Manipolazione dati / Salva" non saranno raggruppate perché i metadati del record della tabella creato nell’azione precedente vengono utilizzati come input di dati per l’azione "Manipolazione dati / Salva".

Esempio 4: Creazione e aggiornamento con lettura dei dati da se stesso. Queste azioni non saranno raggruppate in un'unica transazione.

Quando si utilizza un’aggregazione in un’azione di aggiornamento della tabella raggruppata, il valore dell’aggregazione viene calcolato prima che avvenga l’aggiornamento. Il valore dell’aggregazione non rifletterà l’aggiornamento raggruppato del record della tabella.

Esempio 5: Creazione e aggiornamento con aggregazioni Questeazioni saranno raggruppate e il valore di aggregazione viene calcolato prima che avvenga l’azione di creazione.

Aggiornamento di un record della tabella

Le azioni di manipolazione dei dati sequenziali relative allo stesso record della tabella vengono raggruppate per essere eseguite in un'unica richiesta di rete, quindi avvengono tutte contemporaneamente

Le azioni di trigger che coinvolgono record di tabella vengono raggruppate in base al tipo di azione e all’ordine. Le azioni di memorizzazione che hanno la stessa posizione di memorizzazione vengono raggruppate in un’unica richiesta di rete. Al contrario, azioni come “Carica record” o “Crea record” vengono trattate come transazioni individuali.

Per ottenere le migliori prestazioni, si consiglia di raggruppare gli aggiornamenti relativi allo stesso record, ovvero di non interromperli con altre azioni relative a tabelle o dati.

Esempio 1: Aggiornamenti sequenziali allo stesso record Questeazioni verranno raggruppate in un’unica transazione:

Esempio 2: Aggiornamenti allo stesso record separati da altre azioni Queste azioni non verranno raggruppate, poiché gli aggiornamenti agli stessi record della tabella non sono sequenziali:

Nel trigger seguente, le azioni di manipolazione dei dati / salvataggio riguardano due record diversi della tabella e, pertanto, non saranno raggruppate in un’unica transazione.

Esempio 3: Aggiornamenti a due record diversi. Queste azioni non verranno raggruppate in un'unica transazione.

Quando si utilizza un’aggregazione in un’azione di aggiornamento raggruppata di una tabella, il valore dell’aggregazione viene calcolato prima che l’aggiornamento abbia luogo. Il valore dell’aggregazione non rifletterà l’aggiornamento raggruppato del record della tabella.

Esempio 4: Aggiornamenti che includono aggregazioni Questeazioni saranno raggruppate, il che significa che il valore di aggregazione viene calcolato prima che avvenga l’aggiornamento.

Ripetizione dei trigger (azioni sulle tabelle) - novità a partire da LTS15 / r332

I trigger ripetono solo le azioni sulle tabelle (ad es. scritture di dati nelle tabelle, aggiornamenti dei dati nelle tabelle, interazioni con le tabelle, ecc.).

Entro i 10 minuti di esecuzione del trigger, se una singola azione sulla tabella fallisce, verrà ripetuta per un massimo di 2 minuti. Se l’azione non viene eseguita dopo 2 minuti, tutte le azioni e i trigger rimanenti nella coda del trigger verranno annullati.

Per un trigger resiliente alla rete, assicurarsi che le azioni del trigger includano solo interazioni con le tabelle e aggiornamenti dei dati. Vedere Azioni sui record delle tabelle per indicazioni sulle azioni resilienti sulle tabelle.

I tentativi di esecuzione delle azioni del trigger non duplicheranno il risultato se l’azione viene eseguita accidentalmente due volte. Ciò garantisce che un’azione sulla tabella non scriva più volte gli stessi dati.

Limiti e timeout

Tipi di trigger

Esistono tre tipi di trigger:

Trigger a livello di app

È possibile applicare i trigger a livello di app ai seguenti eventi:

• Avvio dell'app
• App completata
• Annullamento dell'app

È possibile accedere ai trigger a livello di app dalla scheda App.

Scopri di più sui trigger a livello di app qui.

Trigger a livello di fase

È possibile applicare i trigger a livello di passo ai seguenti eventi:

• A intervalli di tempo regolari (“time fires”)
• Quando c’è un input da una macchina o da un dispositivo (“macchine e dispositivi”)
• All’apertura del Step
• Quando lo Step viene chiuso

È possibile accedere ai trigger a livello di Step dalla scheda “Step”.

Scopri di più sui trigger a livello di Step disponibili qui

Trigger dei widget

I trigger dei widget si attivano quando si preme un pulsante. In uno Step possono esserci più trigger relativi a pulsanti che si attivano quando l’operatore preme il pulsante corrispondente nel Tulip Player.

Seleziona il widget desiderato, quindi accedi ai trigger dei widget dalla scheda "Widget".

Scopri di più sui trigger dei widget qui.

Creare un trigger

1. Dal Side Pane, fare clic su + nella sezione Trigger. Si aprirà l’editor dei trigger.
2. Assegna un nome al trigger per identificarne la funzione nell'app. Puoi anche includere una descrizione per fornire ulteriori dettagli.

Migliori pratiche

• Configura i trigger per gestire gli errori: i triggerdovrebbero essere configurati in modo da proseguire o interrompersi in caso di errore. Un trigger può generare un errore a causa di input non validi, di un errore di esecuzione o di un tentativo fallito di scrittura in una tabella o di esecuzione di una funzione del connettore.
• Quando un trigger è configurato per proseguire, il trigger che ha generato l’errore si interromperà, ma il trigger successivo proseguirà
• Quando un trigger è configurato per interrompersi, gli altri trigger presenti nell’evento trigger verranno annullati.

• Evitare di avere trigger a esecuzione prolungata in un passaggio con widget interattivi. I widgetcambiano visivamente stato immediatamente al momento dell’interazione. Sebbene l’operatore veda l’azione avvenire immediatamente sul widget, la logica potrebbe essere eseguita con un leggero ritardo a causa di una rete lenta o di un connettore a esecuzione prolungata.
• Istruire gli operatori ad attendere dopo aver cliccato su una transizione (ad es. "Passo successivo"). In un passaggio, i trigger in coda dopo una transizione non verranno eseguiti. Se un operatore interagisce con un widget dotato di una transizione, rimarrà sul passaggio fino a quando la transizione non sarà stata eseguita. Ad esempio, se l’operatore fa clic su “Passo successivo” e poi attiva un altro trigger mentre attende, il trigger rimanente dopo la transizione non verrà eseguito.
• Eseguire i connettori a esecuzione prolungata e gli aggiornamenti dei dati in passaggi separati. Le interazioni con dati sensibili non dovrebbero essere eseguite nello stesso passaggio in cui è presente la logica di un connettore a esecuzione prolungata. Nel caso in cui un operatore interagisca con il passaggio dopo aver cliccato su un trigger o una transizione a esecuzione prolungata, sussiste il rischio che i dati critici non vengano memorizzati.
• Assicurarsi che le variabili abbiano un unico input per ogni passaggio. Le variabilinon dovrebbero essere condivise con logiche di input concorrenti (ad esempio, più pulsanti in un’app che aggiornano la stessa variabile) per evitare condizioni di competizione. Ad esempio, un trigger acquisisce il valore corrente di una variabile. Se il valore della variabile cambia prima che un trigger lo acquisisca, i dati risulteranno errati.

Approfondimenti

• Elenco delle azioni dei trigger e delle transizioni
• Logica dei trigger condizionali
• Migliori pratiche per app ad alte prestazioni

{{snippet.Hai trovato quello che cercavi?}}