2020.10.14

Release-Datum: 7. Dezember 2021

Neuigkeiten

Neuer Mechanismus zum Starten von Aufträgen über Warteschlangen-Trigger

In diesem Patch haben wir die Logik hinter Warteschlangentriggern geändert, indem wir bei der Berechnung der Anzahl der Zielaufträge, die erreicht werden müssen, sowohl Warteschlangenelemente „Neu“ als auch „In Bearbeitung“ berücksichtigt haben. Zuvor wurden nur neue Elemente berücksichtigt. Wenn also weniger neue Elemente als in Bearbeitung waren, wurden keine Aufträge gestartet, obwohl sich Roboter im Leerlauf befanden. Dies geschah, weil die Anzahl der ausgeführten Aufträge die Anzahl der Zielaufträge überschreiten würde (d. h. Warteschlangenelemente werden aktiv verarbeitet).

Hier ist ein Beispiel, um das Verhalten vor und nach der Änderung besser zu verstehen:

Angenommen, wir haben einen Warteschlangentrigger, der wie folgt definiert ist:

Feld	Wert
Mindestanzahl von Elementen zum Auslösen des ersten Auftrags:	1
Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge	100
Für jede ___ neue(n) Element(e) wird ein anderer Auftrag ausgelöst.	1

Replikationsschritte und -verhalten vor dieser Änderung:

Fügen Sie 3 Warteschlangenelemente zur Warteschlange hinzu. Der Orchestrator berechnet die Anzahl der Zielaufträge basierend auf der Anzahl der neuen Elemente => 3 Zielaufträge sind erforderlich. Der Orchestrator startet 3 Aufträge, um die 3 Warteschlangenelemente zu verarbeiten. Die 3 Elemente werden zu In Bearbeitung verschoben.
Fügen Sie der Warteschlange zwei weitere neue Elemente hinzu. Der Orchestrator berechnet die Anzahl der Aufträge basierend auf der Anzahl der neuen Elemente => 2 Zielaufträge sind erforderlich. Der Orchestrator startet keine anderen neuen Aufträge, da die Anzahl der Zielaufträge niedriger ist als die Anzahl der ausgeführten Aufträge.
Fügen Sie der Warteschlange zwei weitere neue Elemente hinzu. Der Orchestrator berechnet die Anzahl der Aufträge basierend auf der Anzahl der neuen Elemente => 4 (2+2) Zielaufträge sind erforderlich. Der Orchestrator startet 1 Auftrag, um das Ziel von 4 zu erreichen.

Replikationsschritte und Verhalten nach dieser Änderung:

Fügen Sie 3 Warteschlangenelemente zur Warteschlange hinzu. Der Orchestrator berechnet die Anzahl der Zielaufträge basierend auf der Anzahl der neuen und in Bearbeitung befindlichen Elemente => 3 Zielaufträge sind erforderlich. Der Orchestrator startet 3 Aufträge, um die 3 Warteschlangenelemente zu verarbeiten. Die 3 Elemente werden zu In Bearbeitung verschoben.
Fügen Sie der Warteschlange zwei weitere neue Elemente hinzu. Der Orchestrator berechnet die Anzahl der Aufträge basierend auf der Anzahl der neuen und in Bearbeitung befindlichen Elemente => 5 (3+2) Zielaufträge sind erforderlich. Der Orchestrator startet 2 neue Aufträge, um das Ziel von 5 zu erreichen.

Wichtig: Mit diesem Release wurde die Auftragsausführung vom Orchestrator über Warteschlangen-Trigger erheblich verändert. Das neue Verhalten ist standardmäßig aktiviert und kann nicht deaktiviert werden. Lesen Sie sich die Versionshinweise sorgfältig durch, bevor Sie auf 2020.10.14 aktualisieren. Wenn Sie sich nicht sicher sind, warten Sie auf die nächsten Patches, bei denen wir uns weiter mit dem Verhalten befassen werden.

Protokollieren von Laufzeitausnahmen in Elasticsearch

Um einen besseren Einblick in Laufzeitprobleme wie Berechtigungsprobleme oder Verbindungsfehler zu bieten, protokolliert der Orchestrator jetzt Laufzeitausnahmen in Elasticsearch.

Benutzerdefinierter AIMWebserviceName

Von nun an können Sie dem Central Credential Provider-Webdienst einen benutzerdefinierten Namen geben. Zu diesem Zweck ist beim Konfigurieren eines CyberArk CCP-Anmeldeinformationsspeichers ein neues Feld verfügbar, mit dem Sie den DienstnamenWebdienstname festlegen können. Wenn Sie dieses Feld leer lassen, wird der Standardname verwendet: AIMWebService.

Setup-Verbesserungen

Wir haben vier neue Befehlszeilenparameter eingeführt, um Ihnen Flexibilität beim Konfigurieren und Anpassen der Verbindungen zu Ihren Orchestrator-Datenbanken zu geben. Fügen Sie sie in einen Orchestrator-Befehl zur Installation im Hintergrund ein, entweder bei Neuinstallationen oder Upgrades. Sie können die neuen Parameter auch in der Datei parameters.JSON hinzufügen.

Erfahren Sie mehr über die neuen Parameter und sehen Sie sich einige Beispiele für deren Verwendung in unserem Installationshandbuch an.

Bekannte Probleme (Known Issues)

Wenn Sie den Mechanismus hinter GenerateReportsJob (die Statistiken zur Hintergrundauftragsverarbeitung auf der Seite „Warteschlangen“) von inkrementell zu Partitionswechsel ändern, tritt der folgende Fehler auf: „Die Eigenschaft ‚LastQueueItemEventProcessed‘ in ‚UiQueueProcessingRecordBase‘ konnte nicht auf einen ‚null‘-Wert festgelegt werden.“ Als Workaround legen Sie das Feld QueueProcessingRecords.LastQueueItemEventProcessedd in der Datenbank mithilfe der folgenden Abfrage auf 0 fest: UPDATE [dbo].[QueueProcessingRecords] SET [LastQueueItemEventProcessed] = 0 WHERE [LastQueueItemEventProcessed] IS NULL.

Fehlerkorrekturen (Bug Fixes)

Der GetPassword-Befehl funktionierte nicht ordnungsgemäß, wenn die Plugins.SecureStores.CyberArk.UsePowerShellCLI-Anwendungseinstellung aktiviert war – die Ausgabe wurde nicht korrekt formatiert. Das Problem wurde behoben und die Ausgabefelder für den GetPassword-Befehl sind nun richtig formatiert.
Die Verwendung von CyberArk AAM-Anmeldeinformationsspeichern mit Pfadauthentifizierung (Plugins.SecureStores.CyberArk.UsePowershellCLI auf true festgelegt) ist mit der folgenden Fehlermeldung fehlgeschlagen: Failed to retrieve robot password from UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: Could not find password! Reason: '.\GetCredential.bat : The term '.\GetCredential.bat' is not recognized as the name of a cmdlet, function, script file, or operable program.

Dies geschah, weil die Datei GetCredentials.bat im Orchestrator-Installationsordner und nicht im Plugins-Ordner veröffentlicht wurde. Die Datei wird jetzt im Plugins-Ordner veröffentlicht.
Deadlocks traten in Orchestrator 2020.10.10-Umgebungen auf, wenn die Verarbeitung von Warteschlangenelementen weniger als eine Sekunde pro Warteschlangenelement dauerte. Prozesse haben in diesem Fall mehrere Fehler „Ein Fehler ist aufgetreten. Fehlercode: 0“ ausgegeben und sind dann abgestürzt. Das Problem wurde behoben und Sie können jetzt Warteschlangenelemente verarbeiten, ohne dass Deadlocks auftreten.
Das Löschen von Ausführungsmedien mithilfe von POST-Anforderungen an den /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId-Endpunkt erfordert jetzt Berechtigungen zum Löschen für Ausführungsmedien, während Sie zuvor Berechtigungen zum Anzeigen benötigt haben.
Bei den Aktivitäten Set Asset und Set Credential ist eine Zeitüberschreitung für Assets aufgetreten, die auf eine große Anzahl von Robotern abzielen. Es gibt einen neuen verbesserten Mechanismus zum Festlegen von Roboterwerten, der einen neuen API-Endpunkt beinhaltet: /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey.
Es gab ein Problem bei der Entschlüsselung der Orchestrator-Verbindungszeichenfolge, das dazu führte, dass der Webhooks-Client nicht funktionierte. Das Problem wurde behoben.
In Umgebungen mit mehreren Knoten muss die Verbindungszeichenfolge aller Knoten identisch sein. Stellen Sie sicher, dass es keine Inkonsistenzen gibt, da die Knoten dadurch unterschiedliche Verbindungszeichenfolgen haben und Fehler ausgelöst werden können. Beachten Sie, dass selbst kleine Abweichungen wie ein zusätzliches Leerzeichen zu einem Problem führen würden.