Remarques concernant l'installation

Cet article identifie les principales zones affectées que vous devez connaître dans un nouveau déploiement d'Orchestrator. Certains des éléments abordés dans cet article doivent être pris en charge avant une mise à niveau / installation. Plusieurs d’entre eux sont validés par l’installateur ou par l’outil de configuration de la plate-forme si vous choisissez de l’utiliser. Nous vous recommandons fortement de télécharger et d’utiliser l’outil de configuration de la plate-forme pour valider votre environnement avant une mise à niveau.

.NET Core 3.1

Infrastructure cible

Pour maintenir les plugins de magasin d’informations d’identification et la fonctionnalité d’extensions NLog, le TargetFramework doit être mis à niveau, de l'ancienne infrastructure .NET 4.7.2 vers une infrastructure cible prise en charge. L'infrastructure cible des magasins d’informations d’identification et des extensions NLog est vérifiée par l'installateur UiPathOrchestrator.msi.

Cette restriction s’applique également à toutes les références qu’un plugin ou une extension NLog pourrait avoir.

Infrastructures cibles prises en charge	Versions prises en charge
Norme .NET	1.0 - 1.6
Norme .NET	2.0 (recommandé)
.NET	8.0

Astuce :

Vous devrez peut-être recompiler tous les plugins Credential Store et les extensions NLog que vous avez développés en interne.

Vous devrez peut-être identifier et copier dans l’annuaire Orchestrator d’autres fichiers .dll ciblant des infrastructures cibles spécifiées. La plupart des cibles NLog soutiennent les cadres cibles spécifiés; toutefois, vous devez vous assurer de copier le bon .dll. Par exemple, si vous utilisez NLog.Targets.Splunk, vous devez télécharger le fichier .nupkg, l’ouvrir sous forme de .zip, accéder au dossier lib\) etstandard2.0 et utiliser le fichier .dll depuis ici.

Plugins de magasin d’informations d’identification - CyberArk

Dans les anciennes versions d’Orchestrator, le plugin de magasin d’informations d’identification CyberArk utilisait une bibliothèque qui n’est pas compatible avec .NET Core. Orchestrator utilise maintenant l'outil CLIPasswordSDK64.exe qui est livré avec CyberArk AIM.

Astuce : le plug-in recherche CLIPasswordSDK64.exe dans le chemin d'installation par défaut de CyberArk AIM, à savoir C:\Program Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe. Si CyberArk AIM n'a pas été installé sur le chemin par défaut, une entrée de configuration doit être ajoutée dans UiPath.Orchestrator.dll.config, pointant vers le chemin réel. Le chemin peut être spécifié dans la section appSettings dans web.config avant l'installation ou dans le UiPath.Orchestrator.dll.config après l'installation.

Exemple :

<add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK64.exe" />

Configuration du proxy

Dans .NET Core, il existe deux mécanismes permettant de spécifier le proxy :

Utilisation des variables d’environnement

Les variables d'environnement peuvent être définies dansweb.config en utilisant la syntaxe suivante : <environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, par exemple <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />.

Variable	Description
HTTP_PROXY	Serveur proxy utilisé sur les demandes HTTP.
HTTPS_PROXY	Serveur proxy utilisé sur les demandes HTTPS.
ALL_PROXY	Serveur proxy utilisé sur les demandes HTTP et/ou HTTPS au cas où HTTP_PROXY ou HTTPS_PROXY ne sont pas définis.
NO_PROXY	Une liste de noms d’hôtes séparés par une virgule qui devraient être exclus du proxy.

Exemples :

• Sans authentification : ALL_PROXY=http://localhost:8888
• Avec authentification : ALL_PROXY=http://user:password@localhost:8888

En utilisant le système proxy par défaut (paramètres IE ou paramètres Windows Proxy), si les variables de l’environnement ne sont pas définies

Voir la documentation officielle de Microsoft ici.

La configuration proxy n’est plus configurée dans web.config utilisant la balise <defaultProxy>. Exemple de configuration qui n’est plus prise en charge :

<system.net>  
    <defaultProxy>  
      <proxy usesystemdefault="True" proxyaddress="http://<ip>:<port>" bypassonlocal="True"  />  
    </defaultProxy>  
  </system.net>

Fichiers de configuration

Web.Config

La plupart des paramètres de configuration d’Orchestrator ont été déplacés de web.config à UiPath.Orchestrator.dll.config. Le nouveau fichier conserve la même structure que l'ancien fichier web.config et est situé dans le même répertoire. N’oubliez pas que la modification du fichier UiPath.Orchestrator.dll.config n'entraîne pas le redémarrage d'IIS. Les sections suivantes ont été déplacées :

• chaînes de connexion (Connection Strings)
• Paramètres de l'application
• Configuration NLog
• Configuration Quartz
• la clé de cryptage

web.config a été repensée pour contenir uniquement la configuration utilisée par l’IIS. Lors de la mise à niveau, l’installateur déplacera automatiquement les sections mentionnées ci-dessus vers le nouveau fichier de configuration. Il transformera la configuration laissée en web.config pour la faire correspondre à ce qui est nécessaire pour la dernière version d’Orchestrator. La personnalisation client, y compris les verbes désactivés, les modules activés/désactivés, les règles de réécriture personnalisées, est préservée.

Consultez les documents web.config.

Consultez la documentation UiPath.Orchestrator.dll.config.

IIS Manager

Les chaînes de connexion et les paramètres d’application ne sont plus visibles dans le gestionnaire IIS. L’utilisation du gestionnaire IIS pour modifier les chaînes de connexion Orchestrator ou les paramètres d’application n’est pas prise en charge.

Astuce  Vous devez modifier le fichier de configuration directement.

Cibles NLog

Pour les cibles NLog de type « Base de données », la propriété connectionStringName a été remplacée par connectionString. Sa valeur doit utiliser la syntaxe suivante : connectionString="${ui-connection-strings:item=Default}", où Default est le nom de la chaîne de connexion que vous souhaitez utiliser à partir de la section <connectionStrings>.

Voir les documents sur les cibles des journaux d’exécution Orchestrator.

Astuce : Si vous utilisez des cibles NLog personnalisées de type Database, la propriété connectionStringName est automatiquement remplacée par connectionString lors de la mise à niveau. Si vous insérez manuellement la cible dans le fichier de configuration après l’installation/la mise à niveau, utilisez la nouvelle propriété avec la valeur correcte.

Protocole SignalR

SignalR avec WebSockets

Nous avons mis à jour la bibliothèque SignalR vers une version plus récente qui n’est pas compatible avec les anciens clients Robot. Pour continuer à notifier les robots sans surveillance lorsque des tâches sont disponibles, un mécanisme de compatibilité a été mis en place, simulant l’ancien protocole SignalR sur l'interrogation longue. Les Robots plus anciens que la version 2020.10 se connectent à Orchestrator via l'interrogation longue uniquement.

Astuce : Nous vous recommandons de mettre à niveau vos Robots à la version 2020.10 afin d’utiliser WebSockets, ce qui le rend particulièrement rentable pour les déploiements de Robots de grande taille.

Sessions permanentes SignalR Scaleouts

Les scaleouts SignalR nécessitent des sessions permanentes pour tous les protocoles autres que WebSocket (c.-à-d. SSE et Interrogation longue).

Par défaut, seul le transport WebSocket est activé par défaut, car Orchestrator suppose que les sessions permanentes ne sont pas activées sur l'équilibreur de charge du client.

Astuce : ajoutez la clé <add key="Scalability.SignalR.RequireStickySessions" value="true" /> dans UiPath.Orchestrator.dll.config pour activer les sessions persistantes. Si elles sont configurées sur true, tous les transports sont activés, et Orchestrator suppose que les sessions permanentes sont activées sur l' équilibreur de charge. L’activation de sessions permanentes dans UiPath.Orchestrator.dll.config sans les activer sur l' équilibreur de charge entraînera l'échec des connexions SignalR.

SignalR SQL Server Scaleout

Le mécanisme de mise à l’échelle est passé de SQL Server à Redis pendant l’installation. Le fait de désactiver l’authentification SignalR pour Robots/activités n’est plus prise en charge. À cette fin, le paramètre Scalability.SignalR.AuthenticationEnabled a été déprécié.

Activité d’élément de la file d’attente

Vous pouvez rencontrer des retards allant jusqu’à 30 secondes si vous utilisez une activité Élément de file d’attente antérieure à 2020.10.

Astuce  Passez à la dernière version d’activité pour éviter de tels problèmes.

Infrastructure NuGet

Nous avons mis à jour le protocole interne des flux NuGet de v2 à v3.

Référentiels hérités

Legacy n’est plus un type de référentiel NuGet pris en charge. Lors de la mise à niveau, tous les référentiels de type Legacy sont migrés vers Composite.

Le nouvel emplacement du paquet dépend de la façon dont vous avez configuré les paramètres NuGet.Packages.Path et NuGet.Activities.Path dans web.config pour la version Orchestrator précédente.

• Si vous avez stocké les paquets dans les emplacements par défaut (~/NuGetPackages et ~/NuGetPackages/Activities), le nouvel emplacement du paquet devient RootPath=.\Storage.
• Si vous avez stocké les paquets dans un emplacement personnalisé, pendant l’installation, on vous demande un nouvel emplacement de stockage. Pour les installations silencieuses, les paramètres STORAGE_TYPE et STORAGE_LOCATION deviennent obligatoires, sauf si vous les spécifiez dans web.config avant la mise à niveau.

Dans v2020.10+, l'emplacement du package est configuré à l'aide des paramètres Storage.Type et Storage.Location dans UiPath.Orchestrator.dll.config. Après la mise à niveau, tous les paramètres d'application liés à Legacy deviennent obsolètes et n'ont plus d'effet.

• NuGet.Packages.Path
• NuGet.Activities.Path
• Nuget.EnableRedisNodeCoordination
• Nuget.EnableNugetServerLogging
• NuGet.EnableFileSystemMonitoring
• NuGet.Repository.Type

Attention : L'utilisation des commandes copier-coller dans le dossier dédié aux paquets n'est pas prise en charge sur les référentiels Composite.

Bibliothèque Swagger

Nous avons apporté des changements importants à la façon dont nous générons le fichier swagger.json, qui décrit l’API Orchestrator. Si vous utilisez un générateur de bibliothèque client qui utilise la description de l'API dans le fichier Swagger (par exemple, AutoRest, Swagger Codegen), le code généré sera sensiblement différent.

Astuce : Vous devrez peut-être mettre à jour tous les autres outils personnalisés qui utilisent le client autogénéré.

Changements d’API.

API avec les paramètres du formulaire POST

Le fait de réaliser des demandes POST avec des paramètres dans les objets de données de formulaire ne fonctionne plus.

Astuce : Le seul mécanisme pris en charge pour faire des requêtes POST à Orchestrator est d’inclure les paramètres de requête dans un JSON dans le corps de la requête.