2021.10.4

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.

Améliorations

• Nous savons que les tables de votre base de données Ledger peuvent être très encombrées, ce qui nécessite un nettoyage fréquent. Pour cela, nous vous fournissons un nouveau script de nettoyage, vous permettant de supprimer les données Ledger tous les 7 jours et d'appliquer une taille de lot de 1 000 entrées. Découvrez le nouveau script dans notre documentation :

  • Installation autonome d'Orchestrator
  • Installation d'Automation Suite

Problèmes connus

• En tant qu'hôte, essayer de mettre fin à une fenêtre de maintenance via l'interface utilisateur Swagger peut échouer. Cela se produit parce que l'interface utilisateur Swagger utilise des cookies pour l'authentification, qui sont perdus lorsque vous fermez le navigateur.

  Pour mettre fin au mode de maintenance via l'API, utilisez l'une des solutions de contournement suivantes :

  • Ne fermez pas le navigateur et envoyez la requête POST à /api/Maintenance/End à partir de l'interface utilisateur Swagger.

  • Utilisez une application de test d'API (par exemple, Postman) pour :

    • récupérer un jeton d'accès en échangeant vos informations d'identification avec le point de terminaison /api.Account/Authenticate , puis
    • envoyer une requête POST au point de terminaison /api/Maintenance/End à l'aide de l'en-tête Authorization: Bearer {access_token}.

  • Exécutez le script PowerShell suivant :

$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

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 l'état 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.
• Nous avons fait une faute de frappe dans la fenêtre Attribuer des rôles à un compte Robot (Assign roles to a robot account). Au lieu de Rechercher un compte Robot (Search for a robot account), le champ indiquait Rechecher un compte Robot (Seach for a robot account). Le nom du champ est désormais correctement orthographié.
• Les noms des packages téléchargés manuellement n'étaient pas affichés dans les détails de l'audit. Ce problème affectait les packages téléchargés à la fois individuellement et en masse. Désormais, les noms de tous les packages téléchargés sont correctement enregistrés dans les détails de l'audit.
• Les utilisateurs qui n'avaient pas de nom de famille spécifié dans Active Directory ne pouvaient pas se connecter.