- Notes de publication
2021.10.1
Date de publication : 7 décembre 2021
Dans ce correctif, nous avons modifié la logique des déclencheurs de file d'attente en tenant compte à la fois des éléments de la file d'attente Nouveau (New) 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, et 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 se produisait parce que le nombre de tâches en cours d'exécution (autrement dit, qui traitaient 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).
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.
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.
Plug and play de votre stockage compatible S3 avec Orchestrator et profitez de tous ses avantages uniques : évolutivité, coût et fiabilité.
À partir de cette version, l'intégration avec Azure Active Directory (Azure AD) est également disponible au niveau de l'organisation/du locataire (chaque organisation comprend un locataire).
Une intégration avec Azure AD était déjà disponible au niveau de l'hôte, ce qui vous permet de l'exploiter pour l'authentification unique. Avec ce changement, si l'intégration Azure AD est configurée au niveau de l'organisation/du locataire, vous bénéficiez de l'authentification unique, mais également de la recherche dans l'annuaire et de l'enregistrement automatique des utilisateurs.
Pour plus d’informations et d’instructions, consultez Configuration de l’intégration d’Azure AD.
À 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.
- Dans les nouvelles installations et les mises à niveau, Update Server utilise désormais par défaut la base de données Orchestrator existante au lieu de sa propre base de données.
Nous avons apporté les modifications suivantes aux paramètres de sécurité au niveau de l'hôte, disponibles dans le portail de gestion de l'hôte :
- Nous autorisons désormais la valeur du champ Longueur minimale du mot de passe (Minimum password length) à être comprise entre 1 et 256. Auparavant, la valeur maximale autorisée était de 14.
- Nous autorisons désormais la valeur du champ Nombre de jours avant l’expiration du mot de passe (Days before password expiration) dans la plage de 0 à 1000. Auparavant, la valeur maximale autorisée était de 120.
- Le paramètre SignalR par défaut dans Orchestrator (avec uniquement le transport Websocket sélectionné) empêche l'utilitaire de robot distant
UiPath.RemoteDebugging.Agent.execorrespondant de s'exécuter dans des environnements multi-nœuds (installations autonomes ou Automation Suite). Pour corriger ce comportement, sélectionnez tous les transports SignalR disponibles - WebSocket (sélection par défaut), Événements envoyés par le serveur (SEE) et interrogation longue - et activez les sessions persistantes sur l'équilibreur de charge.
- Nouveautés
- Nouveau mécanisme de lancement de tâches via des déclencheurs de file d'attente
- Journalisation des exceptions de runtime dans Elasticsearch
- Stockage compatible S3
- Azure AD au niveau de l'organisation/du locataire
- Nom du service Web AIM personnalisé
- Améliorations
- Configuration
- Stratégie de mot de passe
- Problèmes connus
