2020.10.16

Release-Datum: 7. April 2022

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

Nach einigem Hin und Her im Bereich der Warteschlangen-Trigger verbessern wir das Starten von Aufträgen durch Warteschlangen-Trigger mit der bisher besten und hoffentlich finalen Implementierung.

Problembeschreibung: Immer wenn Ihre Warteschlangen weniger neue Elemente als Elemente in Bearbeitung enthielten, wurden keine Aufträge gestartet, obwohl Roboter inaktiv waren. Das geschah, weil die Anzahl der ausgeführten Aufträge (aktiv verarbeiteten Warteschlangenelemente) die Anzahl der Zielaufträge (erforderlichen Aufträge zur Verarbeitung der neuen Elemente) überschritten hat.

Ursprüngliche Lösung: Der Orchestrator berücksichtigte bei der Berechnung der Anzahl der Zielaufträge sowohl neue als auch in Bearbeitung befindliche Warteschlangenelemente, anstatt nur neue Elemente. Klang gut. Funktionierte nicht.

Brandneue Lösung: Der Orchestrator berücksichtigt bei der Berechnung der Anzahl der Zielaufträge die neuen Elemente, überprüft aber die Anzahl der ausstehenden Aufträge, wenn er entscheidet, ob ein neuer Auftrag gestartet werden soll oder nicht.

Angenommen, Sie haben 2 neue Elemente in einer Warteschlange und es sind 2 ausstehende Aufträge vorhanden => dann werden keine neuen Aufträge gestartet.
Angenommen, Sie haben 2 neue Elemente und es ist 1 ausstehender Auftrag vorhanden => dann wird 1 neuer Auftrag gestartet.

Dadurch wird sichergestellt, dass der Orchestrator genügend Aufträge startet, um alle neuen Elemente zu verarbeiten, ohne überlastet zu werden.

Fehlerkorrekturen (Bug Fixes)

Es wurde ein Problem behoben, durch das ein Angreifer mit privilegiertem Zugriff auf einen Roboter den LicenseKey (MachineKey) anderer Roboter im gleichen Mandanten abrufen konnte. Dies war mit Brute-Force-API-Aufrufen an den Orchestrator möglich. Theoretisch wäre es dem Angreifer dadurch möglich, auf Ressourcen zuzugreifen, die nur auf diesen Roboter beschränkt sind.

Lesen Sie die Sicherheitsempfehlungen für UiPath – Roboterkontoübernahme.
Es ist gelegentlich vorgekommen, dass Auftragsausführungen von Workflows mit langer Ausführungszeit im Status „Wird ausgeführt“ hängen geblieben sind, ohne in den Status „Angehalten“ überzugehen. Wenn diese Aufträge beendet worden sind, sind sie in den Status „Wird beendet“ übergegangen und dort hängen geblieben. Das zugrundeliegende Problem wurde behoben und Aufträge mit langer Ausführungszeit gehen nun wie erwartet in die verschiedenen Status über und werden ohne Probleme ausgeführt.
Der Abruf der Anmeldeinformations-Assets ist für den CyberArk-Anmeldeinformationsspeicher fehlgeschlagen, wenn Plugins.SecureStores.CyberArk.UsePowerShellCLI auf true in der Datei UiPath.Orchestrator.dll.config vom Orchestrator festgelegt war.
Die Schaltfläche E-Mail-Einstellungen testen konnte nicht verwendet werden, wenn Standardzugangsdaten verwenden ausgewählt war und die Felder SMTP-Benutzername und SMTP-Kennwort leer waren.