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.

  Read the security advisory for UiPath - Robot Account Takeover.

• Occasionally, job executions of long running workflows would get stuck in a Running status without being transitioned to a Suspended state. Upon killing those jobs, the jobs transitioned to and got stuck in a Terminating state. The underlying issue has been fixed and long running jobs are now transitioned to the different states as expected and are executed without issues.

• 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.

• The Test Email Settings button could not be used when Use Default Credentials was selected if the SMTP Username and SMTP Password fields were blank.