Avril 2022

18 avril 2022

Prise en charge des connexions multicompte

Remarque : Cette fonctionnalité est disponible uniquement dans les espaces de travail personnels.

Face aux projets d'automatisation avec des connexions multicompte, nous avons mis en œuvre une nouvelle fonctionnalité qui permet aux propriétaires d'espaces de travail personnels de voir ces comptes et d'en spécifier un pour lancer la tâche. Vous pouvez modifier le compte dans l'onglet Exigences du package (Package Requirements) lors de la création d'un processus ou de la modification d'un processus existant. Une liste déroulante est disponible pour chaque connexion avec plusieurs comptes, vous permettant de voir la liste complète des comptes disponibles et de modifier le compte actif au besoin.

Pour gérer vos connexions ou en ajouter de nouvelles, vous pouvez accéder à Integration Service en cliquant sur le bouton .

En savoir plus sur les connexions dans le guide d’Integration Service.

De l'authentification basée sur cookie à l'authentification basée sur jeton

Nous sommes passés de l'authentification basée sur cookie à l'authentification basée sur jeton. À la suite de cette modification, les tentatives de connexion des utilisateurs ne sont plus enregistrées dans Orchestrator. Par conséquent, le point de terminaison /odata/UserLoginAttempts({key}) et la section Tentatives de connexion (Login Attempts) correspondante sur la page Mon profil (My Profile) dans Orchestrator sont obsolètes et ne renvoient que les tentatives de connexion effectuées avant cette modification (autrement dit, les tentatives de connexion avec des cookies). Désormais, les tentatives de connexion effectuées à l'aide de jetons d'accès sont accessibles uniquement via les journaux d'audit dans Automation Cloud. Contactez votre Administrator pour demander ces données.

L'authentification basée sur jeton modifie la façon dont Orchestrator calcule l'heure de la dernière connexion d'un utilisateur. Désormais, l'heure de la dernière connexion est calculée une fois par heure pour un utilisateur utilisant activement Orchestrator.

Supposons qu'un utilisateur utilise Orchestrator entre 14 h 10 et 15 h 00. Du fait qu'il s'est authentifié à 14 h 10, 14 h 10 s'affiche en tant qu'heure de sa dernière connexion jusqu'au prochain contrôle horaire. Dans le cas d'une utilisation d'Orchestrator jusqu'à 16 h 00, 15 h 10 s'affiche en tant qu'heure de dernière connexion de l'utilisateur.

Voici à quel endroit de l'interface utilisateur d'Orchestrator se retrouvent les changements au niveau du calcul de l'heure de la dernière connexion de vos utilisateurs :

• Page Attribuer des rôles (Assign roles) (Locataire (Tenant) > Gérer l'accès (Manage access))

• Page Espaces de travail personnels (Personal workspaces) (Locataire (Tenant) > Dossiers (Folders) > Espaces de travail personnels (Personal workspaces))

  Remarque :À titre d'exception à notre cadence de publication habituelle, cette fonctionnalité n'est pas disponible pour les utilisateurs Enterprise une semaine après la date de publication pour Community. Elle sera mise à la disposition des utilisateurs Enterprise la semaine du 2 mai.

Autorisation des appels d'API dans Swagger

Vous pouvez désormais autoriser les appels d'API dans l'interface utilisateur Swagger à l'aide d'OAuth2.

Découvrez comment obtenir un jeton d'accès, envoyer des requêtes ou révoquer l'accès.

Autres améliorations

Elastic Robot Orchestration

• L'ajout d'un Elastic Robot à un dossier ajoute désormais également le pool à tous les sous-dossiers. De cette façon, toutes les tâches des sous-dossiers peuvent également être exécutées à l'aide de l'orchestration d'Elastic Robots.
• Nous avons retiré la restriction imposant d'avoir un seul pool par dossier. Mettez-vous à l'échelle !

CyberArk CCP

• Orchestrator prend désormais en charge les certificats .cer en tant que certificats AC de racine du serveur.
• Les erreurs de configuration de certificat contiennent désormais plus de détails sur la cause du problème.

5 avril 2022

Cloud robots - Serveless (Aperçu)

Cette fonctionnalité est uniquement disponible pour les utilisateurs de Community.

Vous êtes-vous déjà demandé à quoi ressemblerait votre travail quotidien si vous n’aviez pas à vous soucier de l’infrastructure sur laquelle vos automatisations sont exécutées ?

Nous avons fait de ce scénario notre priorité numéro un au cours des derniers mois, et vous proposons aujourd’hui les robots UiPath Automation Cloud^TM - Serverless, ou Cloud robots - Serverless, en forme abrégée.

Les Cloud robots Serverless facilitent l'exécution d'une automatisation en arrière-plan, sans que vous ayez à vous soucier de l'infrastructure nécessaire. Ils vous permettent de vous affranchir totalement des aspects enregistrement des robots, gestion, maintenance et mise à l'échelle d'une quelconque infrastructure sous-jacente. UiPath fait tout le travail « en coulisses », pour que vous puissiez laisser de côté tout ce qui a trait aux conteneurs, machines virtuelles et autres serveurs physiques.

Consultez les détails de Automatisation Cloud Robots - Sans serveur et les instructions pour les configurer.

4 avril 2022

Modifications des rôles, édition de l'API

API : nouveau point de terminaison pour l'attribution des rôles

Un nouveau point de terminaison est désormais disponible dans l'API Orchestrator pour attribuer des rôles ou remplacer les rôles attribués pour un compte existant :

Publier /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

Ce point de terminaison est amélioré par rapport à nos points de terminaison Utilisateurs (Users) existants car il attribue des rôles en fonction de l'ID de rôle plutôt que du nom de rôle, ce qui rend l'opération plus fiable.

Vous pouvez trouver le nouveau point de terminaison dans la bibliothèque Swagger de l'API Orchestrator, disponible via <OrchestratorURL>/swagger.

Guide de l'API : Attribution de rôles

API : changements radicaux

Avec les autres améliorations récentes apportées aux rôles (détails ici et ici), qui ont entraîné le changement de nom de certains rôles, tous les appels d'API faisant référence à un rôle renommé doivent être mis à jour pour utiliser le nouveau nom de rôle.

Cela impacte :

• Appels d'API liés à une version personnalisée d'un rôle par défaut, désormais renommé Role name - Personnalisé (Custom)
  Attention : Ces appels continuent de fonctionner sans apporter de modifications, mais le résultat est inattendu. Autrement dit, l'appel attribue désormais le rôle par défaut au lieu de la version personnalisée du rôle.

• Appels d'API liés à l'ancien rôle Tenant Administrator, désormais nommé Administrator Orchestrator.

  Ces appels ont échoué avec une erreur en raison de l'impossibilité de trouver un rôle avec le nom spécifié.

Points de terminaison affectés

Les requêtes suivantes peuvent attribuer un rôle en fonction de son nom :

• POST /odata/Users
• PUT /odata/Users({key})
• PATCH /odata/Users({key})
• POST /odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole

Remédiation

Pour résoudre ce problème, vous pouvez utiliser le nouveau point de terminaison afin d'attribuer des rôles en fonction de l'ID de rôle au lieu du nom de rôle.

Il existe deux manières de mettre à jour vos intégrations qui ont été affectées par ce changement afin qu'elles fonctionnent comme prévu :

A. Ajouter un deuxième appel d'API (recommandé)

Vous pouvez laisser vos requêtes d'API existantes telles quelles, mais suivre chaque appel qui attribue des rôles par un appel au nouveau point de terminaison afin de remplacer les rôles attribués par des rôles corrigés.

Par exemple, si vous avez une requête POST pour /odata/Users visant créer un compte Tenant Administrator (autrement dit, lors de la création du compte, la requête tente d'attribuer le rôle Tenant Administrator, qui a été renommé Administrator Orchestrator), alors vous devez la faire suivre d'une nouvelle requête POST pour /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles afin de transmettre l'ID de ce rôle au rôle Administrator Orchestrator afin qu'il soit correctement attribué.

Pour cette méthode de remédiation : vous devez identifier les requêtes impactées dans votre intégration puis, pour chaque requête identifiée :

1. Notez l'ID utilisateur et les noms de rôle à attribuer par la requête impactée.
2. Envoyez une requête GET à /odata/Roles pour récupérer la liste actuelle des rôles.
3. Notez les ID des noms de rôle que vous avez notés précédemment.

4. (Facultatif, mais recommandé) Dans votre intégration, mettez à jour la requête impactée pour supprimer la propriété de nom de rôle.

   Avec cette modification, la requête n'attribue plus de rôles, et la requête à l'étape suivante gérera l'attribution des rôles à l'avenir.

   Vous pouvez choisir de ne pas supprimer la propriété de rôle de cette requête, car la requête à l'étape suivante remplace tous les rôles attribués.

5. Immédiatement après la requête impactée, ajoutez une requête POST à /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles en incluant les ID de rôle dans le corps de la requête.
   La valeur {key} doit être l'ID utilisateur de la requête impactée.

Cela garantit que tous les rôles que la requête impactée identifiée aurait affectés sont immédiatement remplacés par les bons rôles.

B. Mettre à jour les noms de rôle

Une méthode de remédiation plus simple mais moins efficace consiste à mettre à jour les requêtes impactées avec les nouveaux noms de rôle.

Remarque : Bien que cette méthode soit plus simple, nous vous recommandons d'envisager d'utiliser la méthode précédente à la place, car elle renforce votre intégration en cas de modification ultérieure des noms de rôle.

Pour cette méthode de remédiation, vous devez identifier les requêtes impactées dans votre intégration puis, pour chaque requête identifiée :

1. Envoyez une requête GET à /odata/Roles pour récupérer la liste actuelle des rôles.
2. Notez le nom actuel des attribués par les requêtes impactées.
3. Dans votre intégration, mettez à jour les valeurs de propriété de nom de rôle dans la requête impactée avec les noms de rôle mis à jour.

API : avis d'obsolescence

En raison des modifications récentes, et parce que nous souhaitons conserver notre capacité à mettre à jour les rôles à l'avenir sans que cela ne vous affecte, nous annonçons notre intention de rendre obsolète l'utilisation de la propriété de nom de rôle dans l'API Orchestrator.

Nous continuerons à prendre en charge cette propriété pendant au moins 6 mois à partir d'aujourd'hui.

Cependant, nous vous recommandons de commencer la transition pour utiliser le nouveau point de terminaison d'attribution de rôles afin d'éviter tout changement radical dû à l'obsolescence.

Améliorations

Nous avons augmenté le nombre maximum de caractères autorisés pour les noms de rôle de 32 à 64 caractères.

Erratum 2 novembre 2022 : la charge utile du webhook jobs.created pour le cas de test affiche désormais l'ID de robot spécifique et la machine utilisée pour l'exécution de la tâche.

Résolution de bogues

Nous avons ajouté les autorisations Consultation (View) aux Robots comme condition requise pour démarrer ou créer des tâches dans des dossiers modernes. Par conséquent, le bouton de tâche Démarrer (Start) est inactif jusqu'à ce que vous attribuiez les autorisations requises, qui sont affichées dans l'info-bulle du bouton. Auparavant, lorsque vous démarriez ou créiez des tâches dans des dossiers modernes, le message d'erreur You are not authorized! (#0) s'affichait.