Orchestrator
2020.10
False
  • Notes de publication
    • 2020.10.1
    • 2020.10.2
    • 2020.10.3
    • 2020.10.4
    • 2020.10.5
    • 2020.10.6
    • 2020.10.7
    • 2020.10.8
    • 2020.10.9
    • 2020.10.10
    • 2020.10.11
    • 2020.10.12
    • 2020.10.14
    • 2020.10.15
    • 2020.10.16
    • 2020.10.17
    • 2020.10.18
    • 2020.10.19
    • 2020.10.20
    • 2020.10.21
Image de fond de la bannière
Non pris en charge par l'assistance
Notes de publication d'Orchestrator
Dernière mise à jour 12 déc. 2023

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 d’e-mail (Test Email Settings) ne pouvait pas être utilisé lorsque Utiliser les informations d’identification par défaut (Use Default Credentials) était sélectionnée si les champs Nom d’ utilisateur SMTP (SMTP Username) et Mot de passe SMTP (SMTP Password) étaient vides.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Logo Uipath blanc
Confiance et sécurité
© 2005-2024 UiPath. All rights reserved.