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.

  Read the security advisory for UiPath - Robot Account Takeover.

• Occasionally, job executions of long running workflows would get stuck in a Running status without being transitioned to a Suspended state. Upon killing those jobs, the jobs transitioned to and got stuck in a Terminating state. The underlying issue has been fixed and long running jobs are now transitioned to the different states as expected and are executed without issues.

• 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.

• The Test Email Settings button could not be used when Use Default Credentials was selected if the SMTP Username and SMTP Password fields were blank.