À propos des tâches

Vue d'ensemble (Overview)

Les tâches représentent les exécutions de processus au niveau d'un Robot UiPath. Vous pouvez lancer une exécution en mode assisté ou non-assisté. Vous ne pouvez pas lancer une tâche depuis Orchestrator sur les robots assistés, et ils ne peuvent pas s'exécuter sous un écran verrouillé.

Mode Attended	mode non assisté
Panneau du Robot UiPath Assistant UiPath Interface de ligne de commande du Robot	Page Automatisations (Automations) > Tâches (Jobs) Page Automatisations (Automations) > Déclencheurs (Triggers) Page Automatisations (Automations) > Processus (Processes)

Trois emplacements dans Orchestrator vous permettent de configurer et de démarrer une tâche : les pages Tâches (Jobs), Déclencheurs (Triggers) et Processus (Processes). La page Tâches (Jobs) représente le centre de contrôle des tâches, sur laquelle vous pouvez surveiller les tâches déjà lancées, afficher leurs détails et journaux, et arrêter/forcer l'arrêt/reprendre/redémarrer une tâche.

Remarque :

Par défaut, tout processus peut être modifié lorsque des tâches en cours ou en attente leur sont associées.

Les tâches en cours d'exécution associées à un processus modifié utilisent la version initiale du processus. La version mise à jour est utilisée pour les tâches récemment créées ou au déclenchement suivant de la même tâche.

Les tâches en attente associées à un processus modifié utilisent la version mise à jour.

Remarque : Si le robot ne répond pas (la machine robot est arrêtée, ou le service de robot échoue) au cours de l'exécution de la tâche, une fois la reconnexion effectuée, il redémarre l'exécution des tâches qui s'exécutaient lors du blocage.

Sources de tâche

Il existe trois sources de tâche possibles, selon le mécanisme de lancement de tâche :

• Manuel (Manual) : la tâche a été lancée et configurée à partir des pages Tâches (Jobs)/Déclencheurs (Triggers)/Processus (Processes) à l’aide du bouton Démarrer (Start).
• Agent : la tâche a démarré en mode Attended depuis le panneau du robot UiPath, l'Assistant UiPath ou à l'aide de la ligne de commande.
• [Nom_déclencheur] ([Trigger_Name]) : la tâche a été lancée par un déclencheur, utilisé pour son exécution planifiée au préalable.

Cible d'exécution (Execution Target)

	Description
Allouer dynamiquement	Un processus de premier plan est exécuté plusieurs fois sous l'utilisateur et la machine qui deviennent disponibles en premier. Si l’utilisateur est également sélectionné, seule l’affectation de la machine se fait dynamiquement. Les processus d'arrière-plan sont exécutés par n'importe quel utilisateur, qu'il soit occupé ou non, à condition que le nombre de runtimes disponibles soit suffisant. Vous pouvez exécuter un processus jusqu’à 10 000 fois.
Utilisateur (User)	Le processus est exécuté sous un utilisateur spécifique.
Machine	Le processus est exécuté sur une machine hôte spécifique. Assurez-vous que les runtimes correspondant au type de tâche sont affectés au modèle de machine associé. Seules les machines hôtes connectées associées au dossier actif s'affichent.

Avertissement :

Vous devez enregistrer un utilisateur Windows pour chaque utilisateur sur une machine hôte qui appartient aux dossiers auxquels le modèle de machine correspondant est affecté.

Imaginons que vous ayez connecté un serveur à Orchestrator à l'aide de la clé générée par le modèle de machine FinanceT. Ce modèle de machine est affecté aux dossiers FinanceExecution et FinanceHR, auxquels 6 utilisateurs ont également été affectés. Ces 6 utilisateurs doivent être enregistrés en tant qu'utilisateurs Windows sur le serveur.

Si vous configurez une tâche pour exécuter le même processus plusieurs fois, une entrée de tâche est créée pour chaque exécution. Les tâches sont commandées en fonction de leur priorité et de leur heure de création avec une priorité plus élevée, les tâches plus anciennes étant placées en premier. Dès qu’un robot devient disponible, il exécute la tâche suivante dans la file. Dans l'intervalle, les tâches restent dans un état en attente.

Exemple

Configuration

• 1 dossier
• 1 modèle de machine avec deux runtimes
• 2 comptes : john.smith et petri.ota

• 2 processus qui nécessitent l’interaction de l'utilisateur : P1, qui ajoute des éléments de file d’attente à une file d’attente ; P2, qui traite les éléments dans la file d’attente

  Le modèle de machine et les comptes doivent être associés au dossier contenant les processus.

Résultat souhaité

• P1 est exécuté avec une priorité élevée par toute personne.
• P2 est exécuté avec une faible priorité par petri.ota.

Configuration de tâche requise

• Démarrez une tâche en utilisant P1, ne l’affectez à aucun utilisateur particulier, définissez la priorité sur Élevé (High).
• Démarrez une tâche pour P2, affectez-la à petri.ota, définissez la priorité sur Basse (Low).

Priorité d'exécution

Vous pouvez contrôler quelle tâche est prioritaire sur les autres via le champ Priorité des tâches (Job Priority), soit lors du déploiement du processus, soit lors de la configuration d'une tâche/d'un déclencheur pour ce processus. Une tâche peut avoir l'une des priorités suivantes : Basse (Low) (↓), Normale (Normal) (→), Élevée (High) (↑).

Démarrage manuel d'une tâche

La priorité est héritée de l'emplacement de configuration initial. Vous pouvez utiliser la configuration initiale ou la modifier.

Si vous le configurez à partir de la page Automations ( Automations ) > Tâches ( Jobs ) : la tâche hérite de la priorité définie au niveau du processus.

Si vous le configurez à partir de la page Automations > Triggers (Automations > Déclencheurs) : la tâche hérite de la priorité définie au niveau du déclencheur. Si le déclencheur a hérité de la priorité définie au niveau du processus, celle-ci est alors utilisée.

Si vous le configurez à partir de la page Automations ( Automations ) > Processes (Processes) : les tâches utilisent la priorité définie pour ce processus.

Si vous configurez une tâche pour exécuter le même processus plusieurs fois, une entrée de tâche est créée pour chaque exécution. Les tâches sont commandées en fonction de leur priorité et de leur heure de création avec une priorité plus élevée, les tâches plus anciennes étant placées en premier. Dès qu’un robot devient disponible, il exécute la tâche suivante dans la file. Dans l'intervalle, les tâches restent dans un état en attente.

Démarrage d'une tâche via un déclencheur

La priorité est définie par défaut sur Hérité (Inherited), en d'autres termes, elle hérite de la valeur définie au niveau du processus. La sélection d'un processus met à jour automatiquement l'icône de flèche pour illustrer la valeur définie au niveau du processus. Toutes les tâches lancées par le déclencheur ont la priorité définie au niveau du déclencheur. Si la valeur Hérité (Inherited) est conservée, les tâches sont lancées avec la priorité définie au niveau du processus.

Toute modification ultérieure effectuée au niveau du processus se répercute sur le déclencheur, ainsi que les tâches créées via ce déclencheur implicitement.

Remarque : Si vous démarrez une tâche nécessitant une intervention d'utilisateur sur plusieurs robots sur la même machine (qui ne s'exécute pas sur Windows Server), le processus sélectionné est exécuté uniquement par le premier robot, et les autres échouent. Une instance de chacune de ces exécutions est créée et affichée sur la page Tâches (Jobs).

Types de processus

Il existe deux types de processus, selon les exigences de l'interface utilisateur :

• Processus d’arrière-plan (Background Process) : ne nécessite pas d’interface utilisateur ni d’intervention de l’utilisateur pour être exécuté. De ce fait, vous pouvez exécuter plusieurs tâches en mode Unattended et en simultané sur le même utilisateur. Chaque exécution nécessite une licence Unattended/NonProduction. Les processus d'arrière-plan s'exécutent dans la session 0 lorsqu'ils sont démarrés en mode Unattended.
• Nécessite une interface utilisateur - Nécessite une interface utilisateur, car l'exécution nécessite la génération de l'interface utilisateur, ou le processus contient des activités interactives. Vous ne pouvez exécuter qu'un seul de ces processus sur un utilisateur à la fois.

Le même utilisateur peut exécuter plusieurs processus d'arrière-plan et un seul processus nécessitant une IU en simultané.

À propos des Robots haute densité

Si vous démarrez une tâche sur plusieurs robots haute densité à partir de la même machine exécutant Windows Server, cela implique que le processus sélectionné est exécuté simultanément par chaque robot spécifié. Une instance de chacune de ces exécutions est créée et affichée sur la page Tâches (Jobs).

Si vous utilisez des robots haute densité et que vous n'avez pas activé RDP sur cette machine, chaque fois que vous démarrez une tâche, l'erreur suivante s'affiche : « Une session de connexion spécifiée n'existe pas. Il est peut-être déjà terminé. » Pour savoir comment configurer votre machine pour les robots haute densité, consultez la page Configuration de Windows Server pour les robots haute densité.

Workflows de longue durée

Remarque : Cette fonctionnalité est uniquement prise en charge pour les environnements Unattended. Le démarrage d'un processus long sur un robot Attended n'est pas pris en charge car l'arrêt de la tâche ne peut pas être forcé depuis Orchestrator, et il est également impossible de la reprendre.

Les processus qui nécessitent une fragmentation logique ou une intervention humaine (validations, approbations, gestion des exceptions), tels que le traitement des factures et les évaluations des performances, sont gérés avec un ensemble d'instruments dans la suite UiPath : un modèle de projet dédié dans Studio appelé Processus d'orchestration, les actions et les capacités d'allocation de ressources dans Orchestrator.

D'une manière générale, vous pouvez configurer votre workflow avec une paire d'activités. Le workflow peut être paramétré avec les détails de l'exécution, de sorte qu'une tâche suspendue ne peut être reprise que si certaines conditions sont remplies. Ce n'est qu'après que les exigences ont été remplies que des ressources sont allouées à la reprise de la tâche, garantissant ainsi aucun gaspillage en termes de consommation.

Dans Orchestrator, cela est marqué en faisant suspendre la tâche, en attendant que les conditions requises soient remplies, puis en faisant reprendre et lancer la tâche comme d'habitude. En fonction de la paire utilisée, les conditions requises d'achèvement changent et la réponse d'Orchestrator est adaptée en conséquence.

Tâches (Jobs)

Activités

Cas d'utilisation

Start Job and Get Reference Attendre le travail et reprendre

Introduisez une condition d'exécution, telle que le téléchargement d'éléments de file d'attente. Une fois l'exécution principale suspendue, l'exécution auxiliaire est lancée. Une fois ce processus terminé, l'exécution principale reprend. Selon la manière dont vous avez configuré votre workflow, l'exécution reprise peut utiliser les données obtenues à partir du lancement du processus auxiliaire. Remarque : si votre workflow utilise l'activité Start Job and Get Reference pour invoquer un autre workflow, le rôle de votre Robot doit être mis à jour à l'aide des autorisations suivantes : Consultation (View) des processus Consultation (View), Modification (Edit), Création (Create) des exécutions Consultation (View) des environnements.

Files d'attente (Queues)

Activités (Activities)

Cas d'utilisation

Ajouter un élément de la file d'attente et obtenir la référence Attendre un élément de la file d'attente et reprendre

Introduisez une condition de file d'attente, telle que le traitement des éléments de file d'attente. Une fois l'exécution principale suspendue, les éléments de file d'attente doivent être traités via l'exécution auxiliaire. Une fois ce processus terminé, l'exécution principale reprend. Selon la manière dont vous avez configuré votre workflow, l'exécution reprise peut utiliser les données de sortie obtenues à partir de l'élément de file d'attente traité.

Actions

Actions de formulaire

Activités (Activities)

Cas d'utilisation

Create Form Task Wait for Form Task and Resume

Introduisez les conditions d'intervention de l'utilisateur, disponibles dans Orchestrator en tant qu'actions. Une fois la tâche suspendue, une action est générée dans Orchestrator (tel que configuré dans Studio). La tâche reprend une fois l'action terminée. Les actions du formulaire doivent être remplies par l'utilisateur affecté. L'affectation de l'utilisateur peut être gérée directement dans Orchestrator ou via l'activité Affecter des tâches (Assign Tasks).

Actions externes

Activités (Activities)

Cas d'utilisation

Create External Task Wait For External Task and Resume

Introduisez les conditions d'intervention de l'utilisateur, disponibles dans Orchestrator en tant qu'actions. Une fois la tâche suspendue, une action est générée dans Orchestrator (tel que configuré dans Studio). La tâche reprend une fois l'action terminée. Les actions externes peuvent être effectuées par n’importe quel utilisateur doté d'autorisations de Modification (Edit) sur les Actions et d'un accès au dossier associé.

Actions de validation du document

Activités (Activities)

Cas d'utilisation

Create Document Validation Action Wait For Document Validation Action And Resume

Introduisez les conditions d'intervention de l'utilisateur, disponibles dans Orchestrator en tant qu'actions. Une fois la tâche suspendue, une action est générée dans Orchestrator (tel que configuré dans Studio). La tâche reprend une fois l'action terminée. Les actions de Validation de document doivent être remplies par l'utilisateur affecté. L'affectation de l'utilisateur peut être gérée directement dans Orchestrator ou via l'activité Affecter des tâches (Assign Tasks). Pour que le robot télécharge ou supprime des données à partir d’un compartiment de stockage, il doit obtenir les autorisations appropriées. Cela peut être fait en mettant à jour le rôle du robot comme suit : Pour importer des données de document : Autorisations Consultation (View), Création (Create) par rapport aux fichiers de stockage Consultation (View) pour les Compartiments de stockage Pour supprimer les données du document après le téléchargement : Autorisations Consultation (View), Suppression (Delete) par rapport aux fichiers de stockage Consultation (View) pour les Compartiments de stockage

Duration

Activité	Cas d'utilisation
Reprendre après le délai	Introduisez un intervalle de temps comme délai, durant lequel le workflow est suspendu. Une fois le délai écoulé, l'exécution reprend.

Les fragments de tâche ne sont pas limités à être exécutés par le même Robot. Ils peuvent être exécutés par n'importe quel Robot disponible à la reprise de la tâche et prêt à être exécuté. Cela dépend également de la cible d'exécution configurée lors de la définition de la tâche.

Exemple

J’ai défini ma tâche de façon à ce qu'elle soit exécutée par des robots spécifiques, par exemple X, Y et Z. Lorsque je démarre la tâche, seul Z est disponible, c’est pourquoi ma tâche est exécutée par Z jusqu’à ce qu’il soit suspendu en attendant la validation de l’utilisateur. Une fois la validation obtenue et que la tâche reprend, seul X est disponible, c’est pourquoi la tâche est exécutée par X.

• Du point de vue de la surveillance, ce genre de tâche est considérée comme une seule tâche, qu'elle soit fragmentée ou exécutée par différents robots.
• Des tâches suspendues ne peuvent pas être affectées à des robots, contrairement aux tâches dont l'exécution a repris.

Pour vérifier les déclencheurs requis pour la reprise d’une tâche suspendue, vérifiez l’onglet Déclencheurs (Triggers) dans la fenêtre Détails de la tâche (Job Details).

Enregistrement

Pour les tâches défaillantes Unattended, si l'option Activer l'enregistrement ( Enable Recording ) de votre processus était activée, vous pouvez télécharger les supports d'exécution correspondants pour vérifier les derniers moments de l'exécution avant l'échec.

L'option Télécharger l'enregistrement (Download Recording) est uniquement affichée dans la fenêtre Tâches (Jobs) si vous disposez des autorisations de Consultation (View) pour les supports d'exécution.