Déclencheurs

Découvrez comment utiliser les déclencheurs pour créer des logiques dans les applications sans écrire de code.

Dans cet article, vous apprendrez :

• Les commandes de déclencheurs, la logique et le comportement d’exécution
• Les bonnes pratiques pour créer et organiser les déclencheurs
• Cas d'utilisation courants

Les déclencheurs vous permettent d'ajouter de la logique à votre application. Vous pouvez les utiliser pour interagir avec des appareils, envoyer des alertes, enregistrer des données, communiquer avec des systèmes backend, et bien plus encore, le tout sans écrire une seule ligne de code.

Voici quelques cas d'utilisation courants des déclencheurs :

• Naviguer au sein d’une application : utilisez une transition pour passer à une autre étape.
• Finaliser une application: enregistrez les métadonnées de l’application.
• Exécuter une fonction de connecteur pour accéder à un système backend : utilisez les connecteurs pour permettre à Tulip d’interagir avec des systèmes tiers et exécutez une fonction de connecteur via un déclencheur.
• Envoyer des alertes : envoyez des alertes par e-mail ou SMS depuis une application à un administrateur. Ces messages peuvent inclure des images, des informations sur l’état d’avancement du processus ou d’autres informations pertinentes.
• Stockage de données : stockez les données d'entrée d'une application dans des variables ou des tables.
• Utiliser un périphérique : pour les opérateurs utilisant leurs deux mains pendant un processus, ajoutez un déclencheur pour un événement de périphérique, tel qu’une pédale, afin de passer à l’étape suivante.

Comment fonctionnent les déclencheurs ?

Logique

Les déclencheurs utilisent une structure logique « quand, si, alors, sinon » :

• «quand un événement est enregistré dans Tulip »
• alors « effectuer une action » ou « effectuer une transition ».

Les déclencheurs peuvent également contenir une logique conditionnelle :

• lorsque « un événement est enregistré dans Tulip »
• si « la condition est remplie »
• alors « effectuer une action »
• sinon « effectuer une autre action »

Pour en savoir plus sur la logique conditionnelle des déclencheurs, cliquez ici.

Les déclencheurs sont regroupés sous un et se composent d'une action et de conditions.

Les déclencheurs peuvent être simples, comme dans l’exemple ci-dessous :

Lors qu*’* un bouton est enfoncé, passer à l’étape suivante.

Ils peuvent également être plus complexes, comme la lecture d’un code-barres qui interroge une base de données backend pour renvoyer des informations sur la commande sous forme de variable.

Lorsque le lecteur de codes-barres transmet des données à la station actuelle, un API Call (exécuté via une fonction de connecteur) récupère les détails de la commande depuis une base de données externe et stocke la valeur dans une variable. Le déclencheur passe ensuite à l’étape suivante.

Types de commandes

Vous pouvez utiliser deux types de commandes dans un déclencheur :

1. Action : un changement dans l’application qui n’est pas lié à un changement d’étape (par ex. afficher un message d’erreur, envoyer un e-mail, capturer une capture d’écran de l’application)
2. Transition : un événement de navigation au sein même de l’application (par ex. passer à l’étape suivante, terminer une application, annuler une application). Les transitions peuvent déclencher d’autres déclencheurs (c’est-à-dire les lancer). Par exemple, vous pouvez créer un déclencheur au niveau de l’application qui se déclenche chaque fois que l’application est terminée.

File d’attente des déclencheurs

Les (par exemple, cliquer sur un bouton) ajoutent des déclencheurs à une séquentielle à thread unique, qui seront exécutés dans le Tulip Player.

La {{glossary.file d'attente de déclencheurs}} a un impact sur :1. Les fonctions : * Les fonctions sont incluses dans la file d'attente de déclencheurs2. Les widgets personnalisés : * L'exécution de la logique dans un widget personnalisé peut avoir un impact sur la file d'attente de déclencheurs

Ordre d’exécution

Les déclencheurs s’exécutent en série et dans l’ordre défini par l’ Trigger Event e (c’est-à-dire clic sur un bouton, minuterie, sélection d’une ligne de tableau).

Les déclencheurs s’exécutent de manière séquentielle, ce qui signifie que le premier déclencheur de la série doit s’achever avant que le deuxième ne commence à s’exécuter. Cet ordre d’exécution des déclencheurs est appelé « file d’attente des déclencheurs ».

La file d’attente des déclencheurs est distincte des autres tâches au sein d’une application, telles que les interactions avec les variables (par exemple, les champs de saisie de texte, les cases à cocher), les widgets personnalisés et le code JavaScript des widgets personnalisés.

Comment les valeurs saisies sont-elles utilisées dans les déclencheurs ?

Les valeurs saisies (c'est-à-dire les variables) sont transmises par référence aux déclencheurs.

Les déclencheurs font référence à la valeur d’entrée d’une variable au moment de leur exécution. Si la valeur d’entrée change avant l’exécution d’un déclencheur, celui-ci fera référence à la valeur la plus récente.

Les variables sont globales à une application, ce qui signifie qu’elles peuvent être modifiées par d’autres logiques de l’application.

:

Quand les déclencheurs sont-ils annulés ?

Les déclencheurs présents dans la file d’attente des déclencheurs sont annulés, et ne s’exécuteront donc pas, lorsque :

1. **Un déclencheur est mis en file d’attente après une transition : lorsqu’**une transition est exécutée (par exemple « Suivant », « Terminer l’application », « Aller à l’étape par son nom », etc.), tous les déclencheurs restants dans la file d’attente sont annulés.
2. Fermeture forcée du Tulip Player : siun opérateur force la fermeture du Player (par exemple, si une application ne répond plus), toutes les actions restantes d’un déclencheur en cours d’exécution et tous les déclencheurs restants dans la file d’attente sont annulés.

Gestion des erreurs

Des erreurs de déclencheur et l’annulation qui en découle se produiront dans les cas suivants :

1. Erreur d’action de déclencheur
2. Délai d’exécution du déclencheur expiré

Erreur d'action de déclencheur

Lorsqu'une action d'un déclencheur génère une erreur, les actions restantes de ce déclencheur sont ignorées/annulées :

Après une erreur, par défaut, les déclencheurs restants dans la file d’attente et dans l’événement de déclenchement ne s’exécuteront pas pour les déclencheurs suivants au niveau de l’application et des étapes :* Démarrage de l’application* Fin de l’application* Annulation de l’application* À l’entrée d’une étape* À la sortie d’une étape

Pour tous les autres types de déclencheurs (par exemple, « Lorsqu’un bouton est enfoncé »), le bouton bascule « Arrêter les déclencheurs restants en cas d’erreur » est désactivé par défaut.

Délai d’expiration du déclencheur

Si un déclencheur atteint son délai d’expiration (voir Délais d’expiration des déclencheurs), tous les déclencheurs restants dans la file d’attente seront annulés.

Comportement technique

Exécution du déclencheur

• Les déclencheurs sont exécutés de manière séquentielle au cours d’un seul cycle d’exécution. Un cycle d’exécution correspond à la période pendant laquelle un déclencheur est activement en cours d’exécution dans Tulip.
• Les déclencheurs ne s’exécutent jamais en parallèle ni en arrière-plan d’autres déclencheurs. Un nouveau déclencheur ne peut pas commencer à s’exécuter tant que le déclencheur en cours d’exécution n’est pas terminé.
• Les opérateurs peuvent continuer à interagir avec l’application (par exemple, cliquer sur des boutons, interagir avec des tableaux) pendant l’exécution d’un déclencheur. Ces clics sur les boutons et autres événements de déclenchement ajouteront de nouveaux déclencheurs à la file d’attente des déclencheurs.

Délais d'exécution des déclencheurs – mise à jour à partir de la version LTS15 / r332

Le délai d’expiration par défaut d’un déclencheur est de 10 minutes, après quoi le déclencheur et toutes les actions restantes seront annulés, et tous les autres déclencheurs de la file d’attente seront annulés.

Le délai d’expiration de 10 minutes s’applique à l’Trigger Event. Par exemple, si un clic sur un bouton déclenche 5 déclencheurs, ces 5 déclencheurs présents dans la file d’attente ainsi que leurs actions respectives doivent s’exécuter dans les 10 minutes.

Au bout de 30 secondes d’exécution du déclencheur, l’application affiche le message suivant à l’opérateur :

Au bout de 100 secondes d’exécution du déclencheur, l’application affiche le message suivant à l’opérateur :

Au bout de 10 minutes, le déclencheur est annulé et l’application affiche le message d’erreur suivant :

Paramètres de délai d'expiration facultatifs

Modifiez les paramètres de délai d’expiration d’une instance à l’aide des méthodes ci-dessous :

1. Tulip peut activer ou désactiver un paramètre permettant aux opérateurs d’annuler manuellement un déclencheur s’exécutant depuis longtemps après les 100 premières secondes. Contactez l’assistance Tulip pour activer cette fonctionnalité.

2. L'assistance Tulip peut réduire ou augmenter la durée du délai d'expiration. Notez que Tulip recommande une durée de 10 minutes comme point de départ, afin d'augmenter les chances que votre logique s'exécute jusqu'à son terme. Si l'exécution d'un déclencheur prend systématiquement plus de quelques minutes, envisagez les mesures suivantes :

   • Simplifier la logique du déclencheur afin d’améliorer l’expérience de l’opérateur et de réduire le risque d’échec du déclencheur.
   • Si possible, lancez une automatisation en arrière-plan pour décharger l’exécution de la logique et éviter de bloquer la poursuite du travail de l’opérateur.
   • Passez en revue et optimisez toutes les dépendances vis-à-vis de systèmes tiers présentes dans la logique du déclencheur (par exemple, fonctions de connecteur lentes, API non optimale utilisée).

Actions sur les enregistrements de table

Création d’un enregistrement de table

Pour la création d’un nouvel enregistrement de table, la meilleure pratique consiste à faire suivre immédiatement l’action « Enregistrement de table / Créer un enregistrement » par les actions de manipulation de données correspondantes afin de remplir les autres colonnes de l’enregistrement de table nouvellement créé.

Si d’autres actions interviennent entre l’action « Enregistrement de table / Créer un enregistrement » et les actions de remplissage des autres colonnes, la génération de cet enregistrement de table s’affichera sous forme d’événements distincts dans le widget d’historique des enregistrements.

Création d’un enregistrement de table – à partir de LTS15 / r332

À partir de la version LTS15, les actions de table séquentielles « Enregistrement de table / Créer un enregistrement » et « Manipulation des données / Stocker » seront regroupées pour un même enregistrement. Cela signifie que les actions « Créer » et « Manipulation des données » d’un déclencheur s’exécutent en une seule transaction.

Les actions « Créer un enregistrement » et « Manipulation des données / Stocker » ne seront pas regroupées en une seule transaction si d’autres actions s’intercalent entre elles (par exemple, des manipulations de données sur des variables ou d’autres enregistrements de table, des fonctions de connecteur, etc.).

Dans les déclencheurs d’exemple suivants, l’action « Créer un enregistrement » et les actions « Manipulation des données / Stocker » seront regroupées et réussiront toutes ou échoueront toutes. Si toutes les actions échouent, elles seront réessayées ensemble avec des réessais résilients.

Exemple 1 : Création et manipulations de données séquentielles sur le même enregistrement de table. Celles-ci aboutiraient toutes ou échoueraient toutes dans LTS15, mais pas dans les versions antérieures à LTS12.

Exemple 2 : Création et manipulations de données séquentielles sur le même enregistrement de table, suivies d’une action de fonction de connecteur. Les actions de création d’enregistrement de table et de manipulation de données seraient regroupées dans LTS15. L’action de fonction de connecteur pourrait échouer même si les actions sur la table aboutissent.

Dans le déclencheur suivant, les actions « Manipulation de données » / « Stockage » s’appliquent à deux enregistrements de table différents ; elles ne seront donc pas regroupées dans une seule transaction.

Exemple 3 : « Enregistrement de table / Créer » et « Manipulation de données / Stocker » sur le même enregistrement de table, séparées par une autre action de manipulation de données. Cesactions ne seront pas regroupées dans une seule transaction.

Dans le déclencheur suivant, les actions « Enregistrement de table » et « Manipulation de données / Enregistrement » ne seront pas regroupées, car les métadonnées de l’enregistrement de table créé lors de l’action précédente sont utilisées comme données d’entrée pour l’action « Manipulation de données / Enregistrement ».

Exemple 4 : Créer et mettre à jour en lisant les données de l’enregistrement lui-même. Ces actions ne seront pas regroupées dans une seule transaction.

Lorsqu’une agrégation est utilisée dans une action de mise à jour de table regroupée, la valeur d’agrégation est calculée avant que la mise à jour n’ait lieu. La valeur d’agrégation ne tiendra pas compte de la mise à jour de l’enregistrement de table regroupé.

Exemple 5 : Création et mise à jour avec agrégations Cesactions seront regroupées, et la valeur d’agrégation est calculée avant que l’action de création n’ait lieu.

Mise à jour d’un enregistrement de table

Les actions de manipulation de données séquentielles portant sur le même enregistrement de table sont regroupées pour être exécutées en une seule requête réseau ; elles s’effectuent donc toutes simultanément

Les actions de déclenchement impliquant des enregistrements de table sont regroupées en fonction de leur type et de leur ordre. Les actions de stockage ayant le même emplacement de stockage sont regroupées en une seule requête réseau. En revanche, les actions telles que « Charger un enregistrement » ou « Créer un enregistrement » sont traitées comme des transactions individuelles.

Pour optimiser les performances, nous recommandons de regrouper les mises à jour portant sur un même enregistrement, c’est-à-dire de ne pas les intercaler avec d’autres actions portant sur des tables ou des données.

Exemple 1 : mises à jour séquentielles d’un même enregistrement. Ces actions seront regroupées en une seule transaction :

Exemple 2 : Mises à jour d’un même enregistrement séparées par d’autres actions Ces actions ne seront pas regroupées, car les enregistrements de la même table ne sont pas consécutifs :

Dans le déclencheur suivant, les actions de manipulation de données / de stockage concernent deux enregistrements de table différents ; ces actions ne seront donc pas regroupées en une seule transaction.

Exemple 3 : mises à jour de deux enregistrements différents. Ces actions ne seront pas regroupées en une seule transaction.

Lorsqu’une agrégation est utilisée dans une action de mise à jour groupée de tables, la valeur d’agrégation est calculée avant que la mise à jour n’ait lieu. La valeur d’agrégation ne tiendra pas compte de la mise à jour groupée des enregistrements de table.

Exemple 4 : mises à jour incluant des agrégationsCes actions seront regroupées, ce qui signifie que la valeur d’agrégation est calculée avant que la mise à jour n’ait lieu.

Nouvelles tentatives de déclencheurs (actions sur les tables) – nouveauté à partir de LTS15 / r332

Les déclencheurs ne réessaient que les actions sur les tables (par exemple, les écritures de données dans les tables, les mises à jour de données dans les tables, les interactions avec les tables, etc.).

Si une action de table échoue au cours des 10 minutes d’exécution du déclencheur, elle fera l’objet d’une nouvelle tentative pendant 2 minutes maximum. Si l’action ne parvient pas à s’exécuter au bout de 2 minutes, toutes les actions et tous les déclencheurs restants dans la file d’attente du déclencheur seront annulés.

Pour un déclencheur résilient au niveau du réseau, assurez-vous que les actions du déclencheur ne comprennent que des interactions avec les tables et des mises à jour de données. Consultez la section Actions sur les enregistrements de table pour obtenir des conseils sur les actions de table résilientes.

Les tentatives de réexécution des actions de déclencheur ne dupliqueront pas le résultat si l’action s’exécute accidentellement deux fois. Cela garantit qu’une action sur une table n’écrira pas plusieurs fois les mêmes données.

Limites et délais d’expiration

Types de déclencheurs

Il existe trois types de déclencheurs :

Déclencheurs au niveau de l’application

Vous pouvez appliquer des déclencheurs au niveau de l’application aux événements suivants :

• Lancement de l'application
• Fin de l'application
• Annulation de l'application

Accédez aux déclencheurs au niveau de l'application depuis l'onglet « Application ».

Pour en savoir plus sur les déclencheurs au niveau de l'application, cliquez ici.

Déclencheurs au niveau des étapes

Vous pouvez appliquer des déclencheurs au niveau des étapes aux événements suivants :

• À intervalles réguliers (« déclenchements temporels »)
• Lorsqu’une entrée provient d’une machine ou d’un appareil (« machines et appareils »)
• Lors de l’ouverture de l’étape
• Lorsque l'étape est fermée

Accédez aux déclencheurs au niveau des étapes depuis l'onglet « Étapes ».

Pour en savoir plus sur les déclencheurs au niveau des étapes, cliquez ici

Déclencheurs de widget

Les déclencheurs de widget sont activés lorsqu'un bouton est enfoncé. Une étape peut comporter plusieurs déclencheurs de bouton qui se déclenchent lorsque l'opérateur appuie sur le bouton correspondant dans Tulip Player.

Sélectionnez le widget souhaité, puis accédez aux déclencheurs de widget depuis l'onglet « Widget ».

Pour en savoir plus sur les déclencheurs de widget, cliquez ici.

Créer un déclencheur

1. Dans le , cliquez sur + dans la section « Déclencheurs ». L'éditeur de déclencheurs s'ouvre.
2. Donnez un nom à votre déclencheur afin d’identifier son rôle dans l’application. Vous pouvez également ajouter une description pour plus de détails.

Bonnes pratiques

• Configurez les déclencheurs pour gérer les erreurs. Les déclencheursdoivent être configurés pour se poursuivre ou s'arrêter en cas d'erreur. Un déclencheur peut générer une erreur en raison de données d'entrée non valides, d'une erreur d'exécution ou d'un échec de la fonction de connecteur ou de la tentative d'écriture dans une table.
• Lorsqu'un déclencheur est configuré pour se poursuivre, celui qui a généré l'erreur s'arrête, mais le déclencheur suivant se poursuit
• Lorsqu’un déclencheur est configuré pour s’arrêter, les autres déclencheurs de l’événement de déclenchement seront annulés.

• Évitez d’avoir des déclencheurs dont l’exécution est longue sur une étape comportant des widgets interactifs. Les widgetschangent visuellement d’état immédiatement lors d’une interaction. Alors que l’opérateur voit l’action se produire instantanément sur le widget, la logique peut s’exécuter avec un léger retard en raison d’un réseau lent ou d’un connecteur dont l’exécution est longue.
• Formez les opérateurs à patienter après avoir cliqué sur une transition (par exemple « Étape suivante »). Sur une étape, les déclencheurs mis en file d’attente après une transition ne s’exécuteront pas. Si un opérateur interagit avec un widget comportant une transition, il restera sur l’étape jusqu’à ce que la transition soit exécutée. Par exemple, si l’opérateur clique sur « Étape suivante » puis déclenche un autre déclencheur pendant qu’il attend, le déclencheur restant après la transition ne s’exécutera pas.
• Exécutez les connecteurs à exécution longue et les mises à jour de données sur des étapes distinctes. Les interactionsavec des données sensibles ne doivent pas être effectuées sur la même étape que la logique d’un connecteur à exécution longue. Si un opérateur interagit avec l’étape après avoir cliqué sur un déclencheur ou une transition à exécution longue, il existe un risque que des données critiques ne soient pas enregistrées.
• Veillez à ce que les variables aient une seule entrée par étape. Les variablesne doivent pas être partagées avec des logiques d’entrée concurrentes (c’est-à-dire plusieurs boutons dans une application mettant à jour la même variable) afin d’éviter les conditions de concurrence. Par exemple, un déclencheur capture la valeur actuelle d’une variable. Si la valeur de la variable change avant qu’un déclencheur ne la capture, les données seront alors incorrectes.

Pour en savoir plus

• Liste des actions de déclencheurs et des transitions
• Logique des déclencheurs conditionnels
• Meilleures pratiques pour les applications hautement performantes

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}