2020.10.4

Date de publication : 15 décembre 2020

Nouveautés

Intégration CyberArk CCP

Plusieurs bonnes nouvelles sont à venir, étant donné que nous avons élargi et amélioré nos fonctionnalités de magasin d’identifiants en intégrant CyberArk CCP à Orchestrator

Vue d'ensemble (Overview)

Le fournisseur d’identifiants central (CCP) est la méthode AAM sans agent utilisée pour intégrer Orchestrator à CyberArk. Il permet la récupération d’informations sensibles telles que les informations d’identification du robot et les actifs d’identifiants de CyberArk sans déployer d’agent sur le serveur, car les mots de passe stockés dans un coffre sont récupérés dans le fournisseur d’identifiants central, où ils peuvent être consultés par des applications distantes autorisées. Un certificat client est nécessaire pour assurer la récupération sécurisée des informations d’identification.

Pour réussir l’intégration à CyberArk® CCP, nous vous suggérons de jeter un œil à la façon de configurer correctement votre environnement dans CyberArk® PVWA :

Lors de la mise à niveau vers v2020.10.4, CyberArk CCP est activé automatiquement si CyberArk est activé dans votre instance avant la mise à niveau. Si ce n’est pas votre cas, ajoutez UiPath.Orchestrator.SecureStore.CyberArkCCP.dll au paramètre Plugins.SecureStores dans UiPath.Orchestrator.dll.config pour l’activer.

Améliorations

Stratégies de comptage des tâches

Dans cette version, nous vous donnons le plein contrôle sur la stratégie de comptage des tâches lancées par le biais de déclencheurs. Le paramètre Triggers.JobsCountStrategy vous permet de choisir la stratégie qui convient le mieux à vos besoins comme suit :

PerProcess - Un déclencheur lance le nombre de tâches requises en tenant compte de toutes les tâches en attente pour le processus spécifié. Par exemple, deux déclencheurs définis pour le même processus lancent respectivement 3 et 5 tâches. Si le premier déclencheur lance 3 tâches à un moment donné, lorsque le second déclencheur est déclenché, 2 tâches sont lancées de manière à atteindre les 5 tâches requises.
PerTrigger - Un déclencheur lance le nombre requis de tâches en tenant compte des tâches existantes précédemment lancées par ce même déclencheur. Par exemple, un déclencheur est défini pour lancer 9 tâches à un moment donné. Si 2 tâches ont été complétées avec succès au moment où ce déclencheur est à nouveau déclenché, Orchestrator lance 2 autres tâches afin d’atteindre les 9 tâches requises.
NoLimit- Le déclencheur lance le nombre de tâches requises sans tenir compte des tâches existantes en attente. Par exemple, un déclencheur est défini pour lancer 5 tâches à un moment donné. La deuxième fois que le déclencheur est déclenché, 5 autres tâches sont lancées.

En savoir plus sur le paramètre Triggers.JobsCountStrategy.

Prise en charge des activités de persistance

Dans cette version, nous avons ajouté une prise en charge des activités de persistance dans les workflows basés sur les éléments de la file d’attente. Auparavant, Orchestrator abandonnait les éléments de la file d’attente en cours depuis plus de 24 heures, interférant ainsi avec les workflows de longue durée qui dépassaient la limite des 24 heures. Cette limitation a été supprimée, ce qui vous permet d’avoir une intervention humaine en ce qui concerne vos transactions sans être pressé par le temps.

Attention : cette fonctionnalité n'a pas été livrée dans la version 2020.10.4, comme indiqué dans les notes de publication, en raison d’un incident de notre part. Notre priorité est de l'ajouter au correctif Orchestrator suivant. La limite de 24 heures pour les éléments de file d'attente en cours continue d'exister jusqu'à ce que notre équipe l'inclue dans la prochaine version.

Configuration

Nous vous recommandons maintenant d’utiliser le mode passif pour les installations de nœuds secondaires. Vous pouvez spécifier le paramètre /passive pour activer une interface utilisateur limitée avec une barre de progression et des fenêtres contextuelles d’erreurs. Alors que seul le mode silencieux était auparavant disponible, vous devriez maintenant utiliser /Q uniquement pour les installations non assistées.

Autres

Vous pouvez désormais contrôler si les codes d’erreur de connexion sont affichés ou non dans l’interface utilisateur en utilisant le HideErrorCodesInUiparamètre dans le fichier appsettings.Production.json de l’Identity Server.
La fonctionnalité d’Orchestrator peut être altérée si l’élément <system.webServer> de web.config contient des sections verrouillées. C’est pourquoi nous avons ajouté une vérification supplémentaire dans l’outil de configuration de Platform qui vérifie si l’élément entier <system.webServer> contient des sections verrouillées. Si de telles sections existent, vous devez les déverrouiller manuellement dans IIS.
Pour éviter toute confusion sur ce que le bouton bascule Processus toujours en cours d’exécution (Always Running Processes) fait, nous l’avons renommé Impossible d’arrêter le processus depuis l’assistant UiPath (Process can’t be stopped from UiPath Assistant). Cela signifie que si vous activez cette fonctionnalité à partir de la page des paramètres Processus (Processes), vous ne serez pas en mesure d’arrêter le processus correspondant à partir de l’assistant UiPath.

Résolution de bogues

Tous les journaux générés avant la version 2019.10 étaient affichés sur la page Journaux (Logs) sans être filtrés par le dossier qui les contient (anciennement unité d’organisation). Nous avons ajouté et activé par défaut un nouveau paramètre UiPath.Orchestrator.dll.config (Logs.Elasticsearch.EnableFolderIdFilter) qui empêche l’affichage des journaux qui ne peuvent pas être filtrés sur la page Journaux (Logs). Vous pouvez toujours voir ces journaux en accédant aux Journaux (Logs) à partir des pages Robots (dossiers classiques) et Tâches (Jobs) (Autres actions (More Actions) > Afficher les journaux (View Logs)).
Chaque fois qu’une mise à niveau échouait et qu’une restauration était exécutée, le rôle Administrateur (Administrator) perdait les autorisations Modifier (Edit) sur les actions et les autorisations Créer (Create) sur l’Affectation de l’action. Le rôle conserve maintenant les deux, même en cas d’échec de la mise à niveau.
En raison du déplacement de appSettings de Web.Config vers UiPath.Orchestrator.dll.config, le script Configure-PlatformNode.ps1 provoquait l’échec des migrations d’un seul à plusieurs nœuds. Le script ne génère plus d’erreur.
La migration des paquets ne nettoyait pas le dossier Storage importé mais inutilisé suite à une mise à niveau ratée. Le contenu restant est maintenant supprimé.
Le programme d’installation UiPathOrchestrator.msi ne vérifiait pas l’espace disque disponible avant le début de la mise à niveau, ce qui pouvait provoquer l’échec de la migration du paquet. Maintenant, un avertissement est émis avant le début de la migration.
UiPathPlatformInstaller.exe ne validait pas les certificats SSL avec des formats d’objets spécifiques, ce qui entraînait soit une défaillance de l’installation, soit un avertissement de mise à niveau.
L’utilisation de l’authentification Windows lors d’une mise à niveau empêchait le programme d’installation UiPathOrchestrator.msi de valider les informations d’identification. Cela entraînait l’échec du processus de mise à niveau.
Le type d’argument n’était pas validé dans Orchestrator, ce qui permettait aux utilisateurs de définir des valeurs de paramètres inappropriées pour leurs processus. La validation est maintenant correctement effectuée et une erreur est générée si l’entrée ne correspond pas au type d’argument défini au moment de la conception.
La suppression d’un dossier classique ne supprimait pas les utilisateurs associés. Les utilisateurs sont maintenant supprimés lors de la suppression d’un dossier classique.
La mise à niveau de la version v2020.4 à v2020.10 d’Orchestrator n’attribuait pas les utilisateurs d’Active Directory à partir de dossiers modernes basés sur le modèle d’autorisation Hériter du locataire (Inherit from Tenant). Cela se produisait en dépit d’avoir le groupe parent Active Directory affecté au dossier.
La suppression des informations d’identification des actifs résidant dans les magasins d’identifiants en lecture/écriture ne les supprimait que dans Orchestrator. Désormais, la suppression des informations d’identification d’un actif dans Orchestrator supprime également l’objet des informations d’identification associé référencé dans le magasin d’identifiants. Veuillez vous assurer que les informations d’identification des actifs à supprimer ne sont pas utilisées dans d’autres endroits tels que les projets d’automatisation.
Les sessions utilisateur n’expiraient pas après la fin du délai d’inactivité, empêchant les utilisateurs d’être déconnectés de leur session comme prévu.