2021.10.1

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

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 à 2021.10.1. Si vous n'êtes pas sûr, guettez les prochains correctifs dans lesquels nous aborderons plus en détail ce comportement.

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 :

1. 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).
2. 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.
3. 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 :

1. 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).
2. 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.

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.

Stockage compatible S3

Plug and play de votre stockage compatible S3 avec Orchestrator et profitez de tous ses avantages uniques : évolutivité, coût et fiabilité.

Découvrez comment activer les fournisseurs compatibles S3 pour créer des compartiments de stockage dans Orchestrator.

Découvrez comment créer et configurer des compartiments de stockage.

Azure AD au niveau de l'organisation/du locataire

À 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 Azure AD.

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

Configuration

• 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.

Stratégie de mot de passe

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.

Problèmes connus

• 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.exe correspondant 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.