Notes de publication d'Orchestrator
2021.10.4
Date de publication : 7 avril 2022
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.
Une fois de plus, nous réservons une surprise à tous ceux qui ont installé Orchestrator sur une machine virtuelle Azure ou Azure App Service : nous proposons désormais une prise en charge d'Azure AD. Vous pouvez utiliser cette méthode d'authentification pour connecter Orchestrator à SQL Server. Pour plus de détails, voir notre documentation.
-
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
- L'outil de configuration de la plate-forme ne vérifie plus le nom d'hôte du certificat lors de la mise à niveau à partir d'une version antérieure à 2020.4. Cette modification est due au fait que la vérification n'est pas applicable dans ce scénario de mise à niveau.
- Lors de la mise à niveau d'Orchestrator, vous recevez désormais un avertissement si une version d'Insights antérieure à 2021.10 est activée. Ce message est destiné à vous rappeler que la configuration matérielle requise pour Insights a considérablement changé à partir de la version 2021.10. Avant une mise à niveau d'Orchestrator, vous devez vous assurer que vous répondez aux nouvelles exigences d'Insights.
-
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êteAuthorization: Bearer {access_token}
.
-
-
Exécutez le script PowerShell suivant :
- Ne fermez pas le navigateur et envoyez la requête POST à
$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"
}
$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"
}
-
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.
- 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
surtrue
dans le fichierUiPath.Orchestrator.dll.config
d'Orchestrator. - Lorsque les bases de données Orchestrator et Identity utilisaient un classement spécifique à la Turquie, les mises à niveau de la version 2020.10 vers 2021.10 échouaient. Lorsque vous optiez pour le classement SQL basé sur Latin1, le même comportement se produisait si la culture turque (
tr-tr
) était utilisée sur le serveur d'applications. Pour résoudre ce problème, passez à la cultureen-us
et réessayez l'installation.