À 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)

Three locations in Orchestrator enable you to configure and start a job: the Jobs,Triggers, and Processes pages. The Jobs page represents the jobs control center, where you can monitor already launched jobs, view their details and logs, and stop/kill/resume/restart a job.

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 :

If the Robot becomes unresponsive (the robot machine is down, or the Robot Service crashes) during job execution, after reconnecting, it restarts the execution of the jobs that were running during the crash.

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.
• [Trigger_Name] - the job has been launched through a trigger, used for preplanned job execution.

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 à l'aide de P1, ne l'affectez à aucun compte en particulier et définissez la priorité sur Élevée .
• 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) (↑).

Orchestrator affecte les tâches en utilisant la séquence d’étapes suivante :

1. Un Robot devient disponible pour exécuter une nouvelle tâche.
2. Orchestrator identifie le modèle de machine affecté à ce Robot ainsi que tous les dossiers associés à ce modèle.
3. Orchestrator évalue toutes les tâches en attente dans ces dossiers.
4. Orchestrator attribue la tâche avec la priorité la plus élevée au Robot. Si plusieurs tâches ont la même priorité, elles sont envoyées au Robot dans l’ordre chronologique, de la plus ancienne à la plus récente.

Veuillez noter que les modèles de machine et les machines haute densité peuvent exécuter des tâches à partir de plusieurs dossiers de façon simultanée.

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.

If you configure it from the Automations > Jobs page**:** The job inherits the priority set at the process level.

If you configure it from the Automations > Triggers page: The job inherits the priority set at the trigger level. If the trigger itself inherited the priority at the process level, then that one is used.

If you configure it from the Automations > Processes page: The jobs uses the priority set for that process.

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 :

• Background Process - Does not require a user interface, nor user intervention to get executed. For this reason, you can execute multiple such jobs in unattended mode on the same user simultaneously. Each execution requires an Unattended/NonProduction license. Background processes run in Session 0 when started in unattended mode.
• Requires User Interface - Requires user interface as the execution needs the UI to be generated, or the process contains interactive activities. You can only execute one such a process on a user at a time.

The same user can execute multiple background processes and a singular UI-requiring process simultaneously.

À 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).

If you are using High-Density Robots and did not enable RDP on that machine, each time you start a job, the following error is displayed: “A specified logon session does not exist. It may already have been terminated.” To see how to set up your machine for High-Density Robots, please see the Setting Up Windows Server for High-Density Robots page.

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.

Processes that require logical fragmentation or human intervention (validations, approvals, exception handling) such as invoice processing and performance reviews, are handled with a set of instruments in the UiPath suite: a dedicated project template in Studio called Orchestration Process, actions and resource allocation capabilities in 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. Si votre workflow utilise l'activité Démarrer la tâche et obtenir une référence (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 View,Edit,Create on Jobs View on Environments.

Files d'attente (Queues)

Activités

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	Cas d'utilisation
Create Form Task Wait for Form Task and Resume	Introduce user intervention conditions, found in Orchestrator as 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. Form actions need to be completed by the assigned user. User assignment can be handled directly in Orchestrator, or through the Assign Tasks activity.

Actions externes

Activités	Cas d'utilisation
Create External Task Wait For External Task and Resume	Introduce user intervention conditions, found in Orchestrator as 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

Cas d'utilisation

Create Document Validation Action Wait For Document Validation Action And Resume

Introduce user intervention conditions, found in Orchestrator as 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. Document Validation actions need to be completed by the assigned user. User assignment can be handled directly in Orchestrator, or through the Assign Tasks activity. 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 : View,Create on Storage Files Consultation (View) pour les Compartiments de stockage Pour supprimer les données du document après le téléchargement : View,Delete on Storage Files 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

For unattended faulted jobs, if your process had the Enable Recording option switched on, you can download the corresponding execution media to check the last moments of the execution before failure.

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.