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.

👍

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\netstandard2.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.

👍

Das Plugin sucht im standardmäßigen CyberArk AIM-Installationspfad nach CLIPasswordSDK64.exe, 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" />.

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.

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.

👍

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.
See docs on Targets of the Orchestrator Execution Logs.

👍

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.

👍

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.

👍

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.

👍

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 Speicherort des Pakets mit den Parametern Storage.Type und Storage.Location in UiPath.Orchestrator.dll.config konfiguriert. Nach dem Upgrade werden alle Legacy-bezogenen App-Einstellungen veraltet und haben keinen Effekt mehr.

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

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.

👍

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.

👍

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.