2020.10.16

Date de publication : 7 avril 2022

Nouveau mécanisme de lancement de tâches via des déclencheurs de file d'attente

Après de récents changements au niveau des déclencheurs de file d'attente, nous revoyons la façon dont les déclencheurs de file d'attente lancent les tâches avec ce que nous espérons bien être la dernière et la meilleure des implémentations.

Énoncé du problème : chaque fois que vos files d'attente contenaient moins de nouveaux éléments que d'éléments en cours, aucune tâche n'était lancée malgré l'inactivité des Robots. Cela se produisait car le nombre de tâches en cours d'exécution (traitant activement les éléments de la file d'attente) dépassait le nombre de tâches cibles (tâches nécessaires pour traiter les nouveaux éléments).

Correctif initial : Orchestrator tenait compte à la fois des éléments de la file d'attente nouveaux et en cours lors du calcul du nombre de tâches cibles, au lieu des seuls nouveaux éléments. Malheureusement, cela ne fonctionnait pas très bien.

Tout dernier correctif : Orchestrator prend en compte les nouveaux éléments lors du calcul du nombre de tâches cibles, mais examine le nombre de tâches en attente au moment de décider de lancer ou non une nouvelle tâche.

• Supposons que vous ayez 2 nouveaux éléments dans une file d'attente, et 2 tâches en attente => aucune nouvelle tâche n'est lancée.

• Supposons que vous ayez 2 nouveaux éléments, et 1 tâche en attente => 1 nouvelle tâche est lancée.

Cela garantit qu'Orchestrator lance suffisamment de tâches pour traiter tous les nouveaux éléments sans se laisser dépasser.

Résolution de bogues

• Un problème a été résolu qui permettait à un pirate disposant d'un accès privilégié à un Robot de récupérer la clé de licence (MachineKey) d'autres Robots au sein du même locataire en effectuant des appels d'API forcés à Orchestrator. Cela permettrait théoriquement au pirate d'accéder à des ressources réservées uniquement à ce Robot.

  Lisez l'avis de sécurité UiPath - Prise de contrôle d'un compte par un Robot (Robot Account Takeover).

• Parfois, les exécutions de tâches de workflows de longue durée restaient bloquées sur le statut En cours d'exécution (Running) sans passer à l'état Suspendu (Suspended). Lors de la suppression de ces tâches, elles passaient et restaient bloquées à l'état En fin d'exécution (Terminating). Le problème sous-jacent a été résolu et les tâches de longue durée passent désormais aux différents états comme prévu et s'exécutent sans problème.
• La récupération des ressources d'informations d'identification pour le magasin d'informations d'identification CyberArk échouait lors de la définition de Plugins.SecureStores.CyberArk.UsePowerShellCLI sur true dans le fichier UiPath.Orchestrator.dll.config d'Orchestrator.
• Le bouton Tester les paramètres de messagerie ne pouvait pas être utilisé lorsque Utiliser les informations d'identification par défaut était sélectionné si les champs Nom d'utilisateur SMTP et Mot de passe SMTP étaient vides.