Installationsüberlegungen

This article identifies the main affected areas you should be aware of in a new Orchestrator deployment. Some of the items addressed in this article must be taken care of prior to an upgrade/installation. Several of them are validated by the installer or by the Platform Configuration Tool if you choose to use it. We highly recommend that you download and use the Platform Configuration Tool to validate your environment prior to an upgrade.

.NET Core 3.1

Ziel-Framework

Um Anmeldeinformationsspeicher-Plugins und NLog-Erweiterungsfunktionen beizubehalten, muss TargetFramework von der vorherigen .NET-Framework-Version 4.7.2 auf ein unterstütztes Ziel-Framework aktualisiert werden. Das Ziel-Framework für sowohl Anmeldeinformationsspeicher als auch NLog-Erweiterungen wird vom Installationsprogramm UiPathOrchestrator.msi überprüft.

Diese Einschränkung gilt auch für alle Verweise, die ein Plugin oder eine NLog-Erweiterung haben könnte.

Unterstützte Zielframeworks	Unterstützte Versionen
.NET Standard	1.0 - 1.6
.NET Standard	2.0 (empfohlen)
.NET	8.0

Tipp:

Möglicherweise müssen Sie alle Credential Store-Plugins und NLog-Erweiterungen, die Sie intern entwickelt haben, neu kompilieren.

You may need to identify and copy to the Orchestrator directory other .dll files targeting specified target frameworks. Most NLog targets support the specified target frameworks; however, you must ensure you copy the right .dll. For example, if you use NLog.Targets.Splunk, you need to download the .nupkg file, open it as a .zip, navigate to the folder lib\) etstandard2.0 and use the .dll file from there.

Anmeldeinformationsspeicher-Plugins - CyberArk

In älteren Versionen von Orchestrator verwendete das CyberArk-Anmeldeinformationsspeicher-Plugin eine Bibliothek, die nicht mit .NET Core kompatibel ist. Orchestrator verwendet jetzt das CLIPasswordSDK64.exe-Tool, das mit CyberArk AIM kommt.

Tipp:

The plugin searches for CLIPasswordSDK64.exe in the default CyberArk AIM installation path, namely C:\Program Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe. If CyberArk AIM was not installed at the default path, a configuration entry must be added in UiPath.Orchestrator.dll.config, pointing to the actual path. The path can be specified in the appSettings section in web.config prior to the installation or in the UiPath.Orchestrator.dll.config after the installation.

Beispiel:

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

Proxykonfiguration

In .NET Core gibt es zwei Mechanismen zum Angeben des Proxys:

Verwenden von Umgebungsvariablen.

Umgebungsvariablen können in web.config mit der folgenden Syntax festgelegt werden: <environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, z. B. <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />.

Variable	Beschreibung
HTTP_PROXY	Der Proxyserver, der für HTTP-Anforderungen verwendet wird.
HTTPS_PROXY	Der Proxyserver, der für HTTPS-Anforderungen verwendet wird.
ALL_PROXY	Der Proxyserver, der für HTTP- und/oder HTTPS-Anforderungen verwendet wird, falls HTTP_PROXY oder HTTPS_PROXY nicht definiert sind.
NO_PROXY	Eine durch Kommas getrennte Liste von Hostnamen, die vom Proxying ausgeschlossen werden sollen.

Beispiele:

• Ohne Authentifizierung: ALL_PROXY=http://localhost:8888
• Mit Authentifizierung: ALL_PROXY=http://user:password@localhost:8888

Verwenden des Standardproxysystems (IE-Einstellungen oder Windows-Proxyeinstellungen), wenn die Umgebungsvariablen nicht festgelegt sind

Siehe offizielle Microsoft-Dokumentation hier.

Die Proxykonfiguration wird in web.config mit dem <defaultProxy>-Tag nicht mehr konfiguriert. Beispiel für Konfigurationen, die nicht mehr unterstützt werden:

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

Konfigurationsdateien

Web.Config

Die meisten Konfigurationseinstellungen von Orchestrator wurden von web.config nach UiPath.Orchestrator.dll.configverschoben. Die neue Datei behält die gleiche Struktur wie die alte web.config-Datei bei und befindet sich im selben Verzeichnis. Bitte denken Sie daran, dass das Ändern der UiPath.Orchestrator.dll.config-Datei IIS nicht neu startet. Die folgenden Abschnitte wurden verschoben:

• Verbindungszeichenfolge
• App-Einstellungen
• NLog-Konfiguration
• Quarzkonfiguration
• Der Verschlüsselungsschlüssel

web.config wurde so umfunktioniert, dass nur die von IIS verwendete Konfiguration enthalten ist. Nach dem Upgrade verschiebt das Installationsprogramm automatisch die oben genannten Abschnitte in die neue Konfigurationsdatei. Die in web.config verbleibende Konfiguration wird so transformiert, dass sie den Anforderungen der aktuellen Version von Orchestrator entspricht. Die Kundenanpassung, einschließlich deaktivierter Verben, aktivierter/deaktivierter Module, benutzerdefinierter Neuschreibungsregeln, bleibt erhalten.

Check web.config docs.

Check UiPath.Orchestrator.dll.config docs.

IIS-Manager

Verbindungszeichenfolgen und Anwendungseinstellungen sind in IIS Manager nicht mehr sichtbar. Die Verwendung von IIS Manager zum Bearbeiten von Orchestrator-Verbindungszeichenfolgen oder Anwendungseinstellungen wird nicht unterstützt.

Tipp:

Sie müssen die Konfigurationsdatei direkt bearbeiten.

NLog-Ziele

Bei NLog-Zielen vom Typ „Datenbank“ wurde die connectionStringName-Eigenschaft durch connectionString ersetzt. Der Wert muss die folgende Syntax verwenden: connectionString="${ui-connection-strings:item=Default}", wobei Default der Name der Verbindungszeichenfolge aus dem <connectionStrings>-Abschnitt ist, die Sie verwenden möchten.

Siehe Dokumentation zu Zielen der Orchestrator-Ausführungsprotokolle.

Tipp:

Wenn Sie benutzerdefinierte NLog-Ziele vom Typ Database verwenden, wird die Eigenschaft connectionStringName während der Aktualisierung automatisch in connectionString geändert. Wenn Sie das Ziel nach der Installation/Aktualisierung manuell in die Konfigurationsdatei einfügen, verwenden Sie die neue Eigenschaft mit dem richtigen Wert.

SignalR-Protokoll

SignalR mit WebSockets

Wir haben die SignalR-Bibliothek auf eine neuere Version aktualisiert, die nicht mit älteren Roboter-Clients kompatibel ist. Um Unattended-Roboter weiterhin zu benachrichtigen, wenn Aufträge verfügbar sind, wurde ein Kompatibilitätsmechanismus implementiert, der das alte SignalR-Protokoll über Long Polling simuliert. Roboter, die älter als 2020.10 sind, verbinden sich nur über Long Polling mit Orchestrator.

Tipp:

Wir empfehlen Ihnen, Ihre Roboter auf 2020.10 zu aktualisieren, um WebSockets zu verwenden, was sie besonders kostengünstig für große Roboterbereitstellungen macht.

Sticky-Sitzungen für SignalR-Scaleouts

SignalR-Scaleouts erfordern Sticky Sessions für alle Protokolle außer WebSocket (z. B. SSE und Long Polling).

Standardmäßig ist nur der WebSocket-Transport standardmäßig aktiviert, da Orchestrator davon ausgeht, dass Sticky Sessions auf dem Lastenausgleich des Kunden nicht aktiviert sind.

Tipp:

Fügen Sie den <add key="Scalability.SignalR.RequireStickySessions" value="true" />-Schlüssel in UiPath.Orchestrator.dll.config hinzu, um Sticky-Sitzungen zu aktivieren. Wenn Transporte auf true festgelegt sind, sind alle aktiviert, und Orchestrator geht davon aus, dass Sticky-Sitzungen auf dem Load Balancer aktiviert sind. Wenn Sie Sticky-Sitzungen in UiPath.Orchestrator.dll.config aktivieren, ohne sie auf dem Load Balancer zu aktivieren, führt dies zu fehlgeschlagenen SignalR-Verbindungen.

SignalR SQL Server Scaleout

Der Scale-Out-Mechanismus wird während der Installation von SQL Server auf Redis umgestellt. Das Deaktivieren der SignalR-Authentifizierung für Roboter/Aktivitäten wird nicht mehr unterstützt. Zu diesem Zweck wurde der Parameter Scalability.SignalR.AuthenticationEnabled als veraltet gekennzeichnet.

Aktivität „Wait Queue Item“

Wenn Sie eine Warteschlangenelement -Aktivität verwenden, die älter als 2020.10 ist, kann es zu Verzögerungen von bis zu 30 Sekunden kommen.

Tipp:

Aktualisieren Sie auf die neueste Aktivitätsversion, um solche Probleme zu vermeiden.

NuGet-Infrastruktur

Wir haben das interne NuGet-Feedprotokoll von v2 auf v3 aktualisiert.

Legacy-Repositorys

Legacy ist kein unterstützter NuGet-Repository-Typ mehr. Nach dem Upgrade werden alle Repositorys vom Typ Legacy zu Composite migriert.

Der neue Paketspeicherort hängt davon ab, wie Sie die Parameter NuGet.Packages.Path und NuGet.Activities.Path in web.config für die vorherige Orchestrator-Version konfiguriert haben.

• Wenn Sie die Pakete an den Standardspeicherorten (~/NuGetPackages und ~/NuGetPackages/Activities) gespeichert haben, wird RootPath=.\Storage der neue Paketspeicherort.
• Wenn Sie die Pakete an einem benutzerdefinierten Speicherort gespeichert haben, werden Sie während der Installation nach einem neuen Speicherort gefragt. Bei unbeaufsichtigten Installationen werden die Parameter STORAGE_TYPE und STORAGE_LOCATION obligatorisch, es sei denn, Sie geben sie vor dem Upgrade in web.config an.

In v2020.10+, package location is configured using the Storage.Type and Storage.Location parameters in UiPath.Orchestrator.dll.config. After the upgrade, all Legacy-related app settings become deprecated and no longer have an effect.

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

Wichtig:

Die Verwendung von Kopieren-Einfügen-Befehlen im für Pakete dedizierten Ordner wird für Composite -Repositorys nicht unterstützt.

Swagger-Bibliothek

Wir haben wesentliche Änderungen an der Art und Weise vorgenommen, wie die swagger.json-Datei generiert wird, die die Orchestrator-API beschreibt. Wenn Sie sich auf einen Clientbibliotheksgenerator verlassen, der die API-Beschreibung in der Swagger-Datei verwendet (z. B. AutoRest, Swagger Codegen), wird der generierte Code erheblich anders sein.

Tipp:

Möglicherweise müssen Sie alle anderen benutzerdefinierten Tools aktualisieren, die den automatisch generierten Client verwenden.

API-Änderungen

APIs mit POST-Formularparametern

Das Stellen von POST-Anforderungen mit Parametern in Formulardatenobjekten funktioniert nicht mehr.

Tipp:

Der einzige unterstützte Mechanismus, um POST-Anforderungen an Orchestrator zu stellen, besteht darin, die Anforderungsparameter in einem JSON in den Text der Anforderung aufzunehmen.