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.

Azure AD-Authentifizierung für SQL Server

Hinweis: Hinzugefügt am 20. April 2022

Es gibt wieder Neuigkeiten für Kunden, die den Orchestrator auf einer Azure VM oder einem Azure App Service installiert haben: Wir unterstützen jetzt Azure AD. Sie können diese Authentifizierungsmethode verwenden, um den Orchestrator mit SQL Server zu verbinden. Weitere Informationen finden Sie in unserer Dokumentation.

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.
• Das Plattform-Konfigurationstool überprüft den Zertifikathostnamen nicht mehr, wenn es von einer Version vor 2020.4 aktualisiert wird. Diese Änderung liegt daran, dass die Prüfung in diesem Aktualisierungsszenario nicht durchgeführt wird.
• Beim Aktualisieren vom Orchestrator wird Ihnen jetzt eine Warnung angezeigt, wenn eine Insights-Version vor 2021.10 aktiviert ist. Diese Meldung soll Sie daran erinnern, dass sich die Insights-Hardwareanforderungen ab Version 2021.10 erheblich verändert haben. Vor einem Orchestrator-Upgrade müssen Sie sicherstellen, dass Sie die neuen Insights-Anforderungen erfüllen.

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.
• 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.
• Wenn die Orchestrator- und Identity-Datenbanken eine türkische Sortierung verwendet haben, sind Upgrades von Version 2020.10 auf 2021.10 fehlgeschlagen. Wenn Sie eine Latin1-basierte SQL-Sortierung ausgewählt haben und die türkische Kultur (tr-tr) auf dem Anwendungsserver verwendet wurde, trat das gleiche Verhalten auf. Um dieses Problem zu beheben, wechseln Sie zur Kultur en-us und versuchen Sie die Installation erneut.