Installationsüberlegungen

In diesem Artikel werden die wichtigsten Bereiche beschrieben, die von einer neuen Orchestrator-Bereitstellung betroffen sind, die Sie kennen sollten. Einige der in diesem Artikel behandelten Elemente müssen vor einem Upgrade/einer Installation behandelt werden. Einige von ihnen werden vom Installationsprogramm oder vom Plattformkonfigurationstool validiert, wenn Sie es verwenden möchten. Es wird dringend empfohlen, das Plattformkonfigurationstool herunterzuladen und zu verwenden, um Ihre Umgebung vor einem Upgrade zu überprüfen.

.NET Core 6.0.x

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
.NET Standard	1.0	1.1.	1.2.	1.3	1.4	1.5	1.6
.NET Standard	2.0 (empfohlen)	2.1.
.NET Core	6.0	6.0.10

Tipp:

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

Möglicherweise müssen Sie andere .dll-Dateien identifizieren und in das Orchestrator-Verzeichnis kopieren, die auf bestimmte Zielframeworks ausgerichtet sind. Die meisten NLog-Ziele unterstützen die angegebenen Zielframeworks. Sie müssen jedoch sicherstellen, dass Sie die richtige .dll kopieren. Wenn Sie z. B. NLog.Targets.Splunk verwenden, müssen Sie die .nupkg-Datei herunterladen, sie als .zip öffnen, zum Ordner lib\) etstandard2.0 navigieren und die .dll-Datei von dort verwenden.

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: Das Plugin sucht nach CLIPasswordSDK64.exe im standardmäßigen CyberArk AIM-Installationspfad, nämlich C:\Program Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe. Wenn CyberArk AIM nicht am Standardpfad installiert wurde, muss ein Konfigurationseintrag in UiPath.Orchestrator.dll.config hinzugefügt werden, der auf den tatsächlichen Pfad verweist. Der Pfad kann vor der Installation im Abschnitt appSettings in web.config oder nach der Installation in UiPath.Orchestrator.dll.config angegeben werden.

Beispiel:

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

Proxykonfiguration

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>

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.

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.

Lesen Sie die web.config-Dokumente.

Überprüfen Sie die Dokumentation zu UiPath.Orchestrator.dll.config.

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 des Typs Database verwenden, wird die Eigenschaft connectionStringName während des Upgrades 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 true festgelegt ist, sind alle Transporte aktiviert, und Orchestrator geht davon aus, dass Sticky Sessions auf dem Lastenausgleich aktiviert sind. Wenn Sie Sticky Sessions in UiPath.Orchestrator.dll.config aktivieren, ohne sie auf dem Lastenausgleich zu aktivieren, führt dies zu fehlerhaften 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+ wird der Paketspeicherort mit den Parametern Storage.Type und Storage.Location in UiPath.Orchestrator.dll.config konfiguriert. Nach dem Upgrade sind alle Legacy-bezogenen App-Einstellungen veraltet und nicht mehr wirksam.

• 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 den Orchestrator zu stellen, besteht darin, die Anforderungsparameter in einem JSON in den Text der Anforderung aufzunehmen.