2021.10.4

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.

Verbesserungen

• Wir wissen, dass Ihre Ledger-Datenbanktabellen ziemlich voll werden können, sodass sie häufig bereinigt werden müssen. Dazu stellen wir Ihnen ein neues Bereinigungsskript bereit, mit dem Sie Ledger-Daten alle 7 Tage löschen und eine Batchgröße von 1.000 Einträgen anwenden können. Entdecken Sie das neue Skript in unserer Dokumentation:

  • Eigenständige Orchestrator-Installation
  • Automation Suite-Installation.

Bekannte Probleme (Known Issues)

• Als Host kann der Versuch, ein Wartungszeitfenster über die Swagger-Benutzeroberfläche zu beenden, fehlschlagen. Das geschieht, weil die Swagger-Benutzeroberfläche bei der Authentifizierung Cookies verwendet, die beim Schließen des Browsers verlorengehen.

  Um den Wartungsmodus über die API zu beenden, verwenden Sie einen der folgenden Workarounds:

  • Schließen Sie den Browser nicht und führen Sie die POST-Anforderung an /api/Maintenance/End über die Swagger-Benutzeroberfläche aus.

  • Verwenden Sie eine API-Testanwendung (z. B. Postman) für Folgendes:

    • rufen Sie ein Zugriffstoken ab, indem Sie Ihre Anmeldeinformationen mit dem /api.Account/Authenticate -Endpunkt austauschen, und dann
    • eine POST-Anforderung an den /api/Maintenance/End-Endpunkt senden, indem Sie den Authorization: Bearer {access_token}-Header verwenden.

  • Führen Sie das folgende PowerShell-Skript aus:

$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

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.
• Bei der englischen Version des Fensters Einem Roboterkonto Rollen zuweisen gab es einen Vertipper. Anstatt Search for a robot account wurde das Feld Seach for a robot account genannt. Der Feldname ist nun richtig geschrieben.
• Die Namen der manuell hochgeladenen Pakete wurden nicht in den Prüfungsdetails angezeigt. Dieses Problem betraf einzeln sowie massenweise hochgeladene Pakete. Jetzt werden die Namen aller hochgeladenen Pakete erfolgreich in den Prüfungsdetails protokolliert.
• Benutzer ohne „Nachname“ in Active Directory konnten sich nicht anmelden.