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.

To manage your connections or add new ones, you can jump to Integration Service by selecting the button.

Learn about connections in the Integration Service guide.

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.

See how to obtain an access token, send requests or revoke access.

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 ?

In the past couple months, we have made it our number one priority to make it happen and today we bring you UiPath Automation CloudTM robots - Serverless, or Cloud robots - Serverless for short.

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 :

POST /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

With the other recent improvements to roles (details here and here), which resulted in the renaming of some roles, any API calls that refence a renamed role need to be updated to use the new role name.

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)
  Important :

  These calls continue to work without making any changes, but the result is not as expected. Namely, the call now assigns the default role instead of the customized version of the role.

• API calls related to the old Tenant Administrator role, which is now named Orchestrator Administrator. These calls failed with an error due to the inability to find a role with the specified name.

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. (Optional, but recommended) In your integration, update the impacted request to remove the role name property. With this change, the request no longer assigns roles and the request in the next step will handle assigning roles going forward. You can choose to not remove the role property from this request because the request in the next step overwrites any assigned roles.
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 :

While this method is easier, we recommend that you consider using the previous method instead because it hardens your integration against any subsequent changes to role names.

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 02 November 2022: The payload of the jobs.created webhook for Test Case now displays the specific robot ID and the machine used for the job run.

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.