2020.10.14

Date de publication : 7 décembre 2021

Nouveautés

Nouveau mécanisme de lancement de tâches via des déclencheurs de file d'attente

Dans ce correctif, nous avons modifié la logique des déclencheurs de file d'attente en prenant en compte les éléments de file d'attente Nouveau et En cours (In Progress) lors du calcul du nombre de tâches cibles à atteindre. Auparavant, seuls les nouveaux éléments étaient pris en compte. Ainsi, chaque fois qu'il y avait moins de nouveaux éléments que d'éléments en cours, aucune tâche n'était lancée malgré l'inactivité des robots. Cela s'est produit car le nombre de tâches en cours d'exécution dépassait le nombre de tâches cibles (c'est-à-dire traitement actif des éléments de la file d'attente).

Voici un exemple pour mieux comprendre le comportement avant et après le changement :

Supposons que nous ayons un déclencheur de file d'attente défini comme suit :

Champ	Valeur (Value)
Nombre minimal d'éléments pour déclencher la première tâche :	1
Nombre maximal d'exécutions en attente et en cours autorisées simultanément	100
Une autre tâche est déclenchée pour chaque ___ nouveau(x) élément(s)	1

Étapes et comportement de la réplication avant cette modification :

Ajoutez 3 éléments de file d'attente à la file d'attente. Orchestrator calcule le nombre de tâches cibles en fonction du nombre de nouveaux éléments => 3 tâches cibles sont nécessaires. Orchestrator lance 3 tâches pour traiter les 3 éléments de la file d'attente. Les 3 éléments passent à En cours (In Progress).
Ajoutez 2 nouveaux éléments à la file d'attente. Orchestrator calcule le nombre de tâches en fonction du nombre de nouveaux éléments => 2 tâches cibles sont nécessaires. Orchestrator ne lance aucune autre nouvelle tâche, car le nombre de tâches cibles est inférieur au nombre de tâches en cours d'exécution.
Ajoutez 2 nouveaux éléments à la file d'attente. Orchestrator calcule le nombre de tâches en fonction du nombre de nouveaux éléments => 4 (2+2) tâches cibles sont nécessaires. Orchestrator lance 1 tâche afin d'atteindre la cible de 4.

Étapes et comportement de la réplication après cette modification :

Ajoutez 3 éléments de file d'attente à la file d'attente. Orchestrator calcule le nombre de tâches cibles en fonction du nombre d'éléments nouveaux et en cours => 3 tâches cibles sont nécessaires. Orchestrator lance 3 tâches pour traiter les 3 éléments de la file d'attente. Les 3 éléments passent à En cours (In Progress).
Ajoutez 2 nouveaux éléments à la file d'attente. Orchestrator calcule le nombre de tâches en fonction du nombre d'éléments nouveaux et en cours => 5 (3+2) tâches cibles sont nécessaires. Orchestrator lance 2 nouvelles tâches pour atteindre l'objectif de 5.

Attention : Cette version marque un changement significatif dans la façon dont Orchestrator lance les tâches via les déclencheurs de file d'attente. Le nouveau comportement est activé par défaut et ne peut pas être désactivé. Lisez attentivement la note de version avant de passer à 2020.10.14. Si vous n'êtes pas sûr, guettez les prochains correctifs dans lesquels nous aborderons plus en détail ce comportement.

Journalisation des exceptions de runtime dans Elasticsearch

Pour offrir une meilleure visibilité sur les problèmes de runtime tels que les problèmes d'autorisation ou les échecs de connexion, Orchestrator journalise désormais les exceptions de runtime dans Elasticsearch.

Nom du service Web AIM personnalisé

À partir de maintenant, vous pouvez donner un nom personnalisé au service Web du fournisseur central d'informations d'identification. À cette fin, un nouveau champ est disponible lors de la configuration d'un magasin d'informations d'identification CyberArk CCP qui vous permet de définir le nom du service, Nom du service Web ( Web Service Name). Si vous laissez ce champ vide, le nom par défaut est utilisé : AIMWebService.

Améliorations de la configuration

Nous avons mis en place quatre nouveaux paramètres de ligne de commande pour ajouter de la flexibilité à la configuration et à la personnalisation des connexions à vos bases de données Orchestrator. Incluez-les dans une commande d'installation en mode silencieux d'Orchestrator, qu'il s'agisse d'installations nouvelles ou de mises à niveau. Vous pouvez également ajouter les nouveaux paramètres dans le fichier parameters.JSON.

Découvrez quels sont les nouveaux paramètres et consultez quelques exemples sur la façon de les utiliser dans notre guide d’installation.

Problèmes connus

Lors de la modification du mécanisme derrière GenerateReportsJob (statistiques de calcul de la tâche en arrière-plan sur la page Files d'attente (Queues)) depuis un échange incrémentiel en échange de partition, vous rencontrerez l'erreur suivante : « La propriété 'LastQueueItemEventProcessed' sur 'UiQueueProcessingRecordBase' n'a pas pu être définie sur une valeur 'null' évaluer » (The 'LastQueueItemEventProcessed' property on 'UiQueueProcessingRecordBase' could not be set to a 'null' value). Pour contourner ce problème, définissez le champ QueueProcessingRecords.LastQueueItemEventProcessedd de la base de données sur 0 en utilisant la requête suivante : UPDATE [dbo].[QueueProcessingRecords] SET [LastQueueItemEventProcessed] = 0 WHERE [LastQueueItemEventProcessed] IS NULL.

Résolution de bogues

La commande GetPassword ne fonctionnait pas correctement lorsque le paramètre d'application Plugins.SecureStores.CyberArk.UsePowerShellCLI était activé (la sortie n'était pas formatée correctement). Le problème a été résolu et les champs de sortie de la commande GetPassword sont désormais correctement formatés.
L'utilisation des magasins d'informations d'identification CyberArk AAM avec l'authentification Path (Plugins.SecureStores.CyberArk.UsePowershellCLI défini sur true) échouait avec le message d'erreur suivant : Failed to retrieve robot password from UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: Could not find password! Reason: '.\GetCredential.bat : The term '.\GetCredential.bat' is not recognized as the name of a cmdlet, function, script file, or operable program.

Cela était du à la publication du fichier GetCredentials.bat dans le dossier d'installation d'Orchestrator au lieu du dossier Plugins. Le fichier est maintenant publié dans le dossier Plugins.
Des blocages se produisaient dans les environnements Orchestrator 2020.10.10 lorsque le traitement des éléments de file la d'attente prenait moins d'une seconde par élément. Les processus généraient plusieurs erreurs « Une erreur s'est produite. Code d'erreur : 0 » (An error has occurred. Error code: 0) avant de planter. Le problème a été résolu et vous pouvez désormais traiter les éléments de la file d'attente sans subir de blocages.
La suppression du média d'exécution en effectuant des requêtes POST au point de terminaison /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId nécessite désormais des autorisations de Suppression (Delete) sur le support d'exécution, alors qu'auparavant, vous aviez besoin des autorisations de Consultation (View).
Les activités Définir la ressource (Set Asset) et Définir l'identifiant (Set Credential) expiraient pour les actifs ciblant un grand nombre de robots. Nous avons ajouté un nouveau mécanisme amélioré pour définir des valeurs de robot qui implique un nouveau point de terminaison d'API : /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey.
Le déchiffrement de la chaîne de connexion d'Orchestrator était affecté par un problème empêchant le client Webhooks de fonctionner. Nous avons résolu ce problème.
Dans les environnements multi-nœuds, la chaîne de connexion de tous les nœuds doit être identique. Assurez-vous qu'il n'y a pas d'incohérences car cela entraînerait des chaînes de connexion différentes pour les nœuds et pourrait générer des erreurs. Notez que même des incompatibilités mineures telles qu'un espace supplémentaire génèreraient un problème.