Déclencheurs de temps

Important :

Fuseaux horaires du déclencheur : le fuseau horaire configuré pour un déclencheur ne se limite pas à celui du locataire. Cependant, si vous utilisez des calendriers de jours non ouvrables, vous ne pouvez pas définir de fuseaux horaires différents.

Les déclencheurs sont lancés en fonction du fuseau horaire défini au niveau du déclencheur.

Les déclencheurs de temps sont désactivés en fonction du fuseau horaire du déclencheur.

Les déclencheurs de temps configurés pour une exécution récurrente prennent en compte la seconde de leur temps de création. Voici comment la modification se traduit dans les expressions Cron :

• Pour un déclencheur de temps créé à 12:23:34 avec l'expression Cron 0 * * ? * * (c'est-à-dire configuré pour s'exécuter toutes les minutes), la prochaine exécution sera fixée à 12:24:34.

• Pour un déclencheur de temps créé à 12:23:34 avec l'expression Cron 1 * * ? * * (c'est-à-dire configuré pour s'exécuter à toutes les minutes et 1 seconde), la prochaine exécution sera fixée à 12:24:01.

Trigger disabling

Par défaut, lorsqu’un déclencheur connaît 10 échecs de lancement consécutifs et n’a pas été lancé avec succès au cours des dernières 24 heures, il est automatiquement désactivé. Cependant, si l’une de ces conditions n’est pas remplie, par exemple si le déclencheur se lance avec succès au moins une fois dans la journée, ou s’il n’atteint pas 10 échecs consécutifs, il reste actif.

Remarque : si un déclencheur est automatiquement désactivé, l’action est enregistrée en tant que « Déclencheur désactivé par l’administrateur du système de l’utilisateur » dans les journaux d’audit.

Cette valeur peut être personnalisée à l’aide du paramètre Triggers.DisableWhenFailedCount .

Recommandations

• Lorsqu’un déclencheur est désactivé, recherchez dans les journaux d’audit les raisons pour lesquelles la tâche a échoué.

• Si vous avez des tâches de longue durée, essayez de définir le déclencheur de manière à autoriser davantage de tâches en attente, ou essayez de planifier le déclencheur pour qu’il s’exécute moins souvent.

Cible d'exécution (Execution Target)

Vous pouvez configurer plusieurs règles en fonction des processus associés exécutés.

	Description
Allocation dynamique	Allouer dynamiquement Définissez le nombre d'exécutions d'un processus en fonction du déclencheur donné. Cette option permet d'utiliser vos ressources au maximum. Dès qu'un robot est Disponible (Available), il exécute le processus indiqué en fonction du déclencheur fourni.
	Compte (Account) Le processus est exécuté sous un compte spécifique. Si vous spécifiez uniquement le compte, Orchestrator affectera dynamiquement la machine. Le fait de spécifier à la fois le compte et le modèle de machine signifie que la tâche se lance sur cette paire compte-machine spécifique.
	Machine Le processus est exécuté sur l'une des machines hôtes associées au modèle de machine sélectionné. Si vous spécifiez uniquement le modèle de machine, Orchestrator affectera dynamiquement le compte. Le fait de spécifier à la fois le compte et le modèle de machine signifie que la tâche se lance sur cette paire compte-machine spécifique. Remarque : Assurez-vous que les licences de runtime requises pour exécuter la tâche sont affectées au modèle de machine associé.
	Nom de l'hôte Après avoir sélectionné un modèle de machine, l'option Nom d'hôte (Hostname) s'affiche, vous permettant de sélectionner la session de poste de travail/Robot souhaitée pour exécuter le processus. Toutes les sessions disponibles dans le dossier actif sont affichées, qu'elles soient non connectées, déconnectées ou connectées. Remarque : Seuls des runtimes Unattended peuvent être utilisés pour configurer le mappage. Assurez-vous que les licences de runtime requises pour exécuter la tâche sont affectées au modèle de machine associé.
Sélectionner des mappages compte-machine valides	Le processus peut être exécuté sur plusieurs paires utilisateur-machine spécifiques. En savoir plus sur les mappages utilisateur-machine. Remarque : Un avertissement s'affiche lors de la sélection d'un nom d'hôte qui n'est pas actif (autrement dit, qui présente le statut Ne répond pas (Unresponsive) ou Déconnecté (Disconnected)). Les comptes faisant partie des mappages utilisés dans les déclencheurs ne peuvent pas être supprimés ou désaffectés du dossier dans lequel réside le déclencheur. Assurez-vous que le compte n'est pas défini comme cible d'exécution dans un déclencheur afin de pouvoir le supprimer.

Remarque : Un avertissement s'affiche lors de la sélection d'un nom d'hôte qui n'est pas actif (autrement dit, qui présente le statut Ne répond pas (Unresponsive) ou Déconnecté (Disconnected)). Les tâches planifiées pour être exécutées par la session inactive restent à l'état En attente (Pending) jusqu'à ce que la connexion correspondante à Orchestrator soit établie.

• Pour confirmer votre sélection du nom d'hôte inactif, cliquez sur Confirmer (Confirm).

• Pour revenir en arrière et sélectionner un autre nom d'hôte, cliquez sur Annuler (Cancel).

La configuration du même déclencheur avec le même mappage compte-machine, mais avec la sélection du nom d'hôte supplémentaire, double le nombre de tâches à exécuter.

• Par exemple, supposons que vous ayez configuré un déclencheur T1 avec le compte A1 mappé au modèle de machine MT1. Dix tâches sont mises en file d'attente pour exécution dans cette configuration.

  Puis, vous configurez le même déclencheur T1 avec le compte A1 mappé au modèle de machine MT1, tout en sélectionnant également un nom d'hôte H1. Les dix mêmes tâches sont à nouveau mises en file d'attente dans ce cas, car Orchestrator interprète la configuration comme étant nouvelle.

Remarque : Si la connexion à la base de données SQL est perdue pour une raison quelconque, les déclencheurs censés être activés à un moment donné échouent, et une alerte avec le niveau Erreur (Error) est générée.

Scénarios de tâches mises en file d'attente

1. Si vous définissez plusieurs déclencheurs sur le même robot et que leur délai d'exécution se chevauche au moins une fois, les tâches sont mises en file d'attente dans un état en attente. Le robot exécute les tâches en file d'attente dans l'ordre chronologique.

2. Si le même processus est planifié plusieurs fois sur le même robot et que leur délai d'exécution se chevauche, seul un processus est mis en file d'attente, dans un état en attente. Par exemple, si le processus A sur le robot X est planifié pour être exécuté à 11 h 20, 11 h 21 et 11 h 25, le comportement est le suivant :

   • 11 h 20, le premier processus est exécuté.

   • Si la première exécution se termine avant le second déclencheur :

     • Le deuxième déclencheur est traité.

       • Si cette exécution se termine avant le déclencheur de 11 h 25, ce dernier est également exécuté.
       • Si l'exécution du déclencheur de 11 h 21 ne se termine pas avant celle de 11 h 25, cette dernière est ajoutée à une file d'attente, dans un état en attente.
   • Si la première exécution ne se termine PAS avant le second déclencheur :

     • Le déclencheur de 11 h 21 est placé dans une file d'attente, dans un état en attente.

       • Si l'exécution du déclencheur de 11 h 21 se termine avant celle de 11 h 25, cette dernière est également exécutée.
       • Si l'exécution du déclencheur de 11 h 21 démarre, mais ne se termine pas avant celle de 11 h 25, le dernier déclencheur est ajouté à une file d'attente, dans un état en attente.
       • Si le déclencheur de 11 h 21 est encore en attente lorsque celui de 11 h 25 doit démarrer, ce dernier n'est plus exécuté ni ajouté à la file d'attente, et le message suivant s'affiche : Les robots ont déjà des tâches en attente pour ce processus (The Robots already have pending jobs for this process).

3. Pour exécuter plusieurs fois un processus sur des robots disponibles, vous avez la possibilité de le faire à l'aide de l'option Allouer dynamiquement (Allocate Dynamically) dans l'onglet Cible d'exécution (Execution Target). Les tâches sont mises en file d'attente, dans un état en attente, dans l'environnement correspondant, et chaque fois qu'un robot est disponible, la première tâche de la ligne est exécutée. De cette manière, aucun Robot n'est disponible tant que des tâches sont en attente.

   Imaginons que vous souhaitiez exécuter un processus 7 fois. Au moment où votre déclencheur se lance, 7 tâches en attente sont ajoutées à la charge de travail de l'environnement, sans être affectées à des Robots spécifiques. Plusieurs scénarios sont possibles :

   • Au moins 7 Robots sont disponibles au moment du déclenchement : un Robot se voit affecter une seule tâche de sorte que toutes les tâches sont exécutées simultanément.
   • Moins de 7 Robots sont disponibles au moment du déclenchement, disons 4 : chacun des 4 Robots se voit affecter une seule tâche, si un nouveau Robot ou l'un des 4 devient disponible. Il reprend alors une autre tâche des 3 restants. Cela se produit pour chaque Robot disponible jusqu'à ce que toutes les tâches soient terminées.

4. Si au moins deux déclencheurs exécutent le même processus, chacun pendant un nombre de fois différent, le nombre maximum de tâches entre eux est ajouté à la charge de travail de l'environnement lors du déclenchement suivant. Elles ne sont pas cumulées. Imaginez la situation suivante : le déclencheur A exécute un processus 13 fois et le déclencheur B l'exécute 20 fois. Les scénarios suivants peuvent se produire :

   • A et B sont déclenchées simultanément : 20 tâches (le maximum entre 13 et 20) sont mises en file d'attente dans la charge de travail de l'environnement.

   • B se déclenche en premier : 20 tâches sont en file d’attente

     • Si entre l'heure de déclenchement de B et celle de A, 7 tâches au moins ont été exécutées, disons 9 (11 tâches en attente restantes), 13 tâches (le maximum entre 11 et 13) sont mises en file d'attente dans la charge de travail de l'environnement.
     • Si entre l'heure de déclenchement de B et celle de A, moins de 7 tâches ont été exécutées, disons 5 (15 tâches en attente restantes), plus aucune tâche n'est en file d'attente, car plus de 13 tâches sont déjà en attente. En outre, le message suivant s'affiche : Les robots ont déjà des tâches en attente pour ce processus (The Robots already have pending jobs for this process).

   • A se déclenche en premier : 13 tâches sont en file d'attente

     • À chaque fois que B se déclenche lors de l’exécution de A, un maximum de 20 tâches sont ajoutées à l’environnement, en fonction du nombre de tâches de A qui sont en cours d’exécution, ou qui ont déjà été exécutées. Imaginons que 6 tâches aient été exécutées. Lorsque B se déclenche, 13 tâches sont ajoutées. Le maximum de 20 est donc atteint.

5. Si un déclencheur exécute le même processus plusieurs fois, les tâches associées en file d'attente sont limitées au nombre d'exécutions spécifiées lorsque vous avez défini le déclencheur, dans l'onglet Exécuter la cible (Execute Target). Elles ne sont pas cumulées avec chaque exécution du déclencheur.

   Imaginons que vous souhaitiez exécuter le même processus 10 fois toutes les 30 minutes. La première fois que votre déclencheur est lancé, 10 tâches sont en file d'attente. Si entre les déclenchements, moins de 10 tâches ont été exécutées (disons 4), seules 6 nouvelles tâches sont mises en file d'attente lors du déclenchement suivant, car le nombre de tâches en attente pour ce processus ne peut pas dépasser 10.

Déclencheurs temporels créés à l'aide de UiPath Activities

Les déclencheurs de temps peuvent également être créés par les développeurs RPA au moment de la conception dans Studio, à l'aide de l'activité Déclencheur de temps du package UiPath.Core.Activities.

Orchestrator identifie ces types de déclencheurs comme des exigences de package, et la seule façon de les ajouter dans Orchestrator est à partir de la page Exigences du package (Package Requirements).

Toute configuration définie au moment de la conception se reflète dans Orchestrator et ne peut pas être modifiée.

Par exemple : chaque jour ouvrable, à 18 h 00, je souhaite télécharger automatiquement tous les nouveaux fichiers Excel vers un lecteur cloud. La différence ici est que le déclencheur de temps indique à l'automatisation de démarrer depuis l' intérieur du workflow, contrairement aux déclencheurs de temps Orchestrator, qui indiquent à l'automatisation de démarrer depuis l'extérieur du workflow.