2021.10.1
Release-Datum: 7. Dezember 2021
In diesem Patch haben wir die Logik hinter Warteschlangen-Triggern geändert, indem wir sowohl „Neue“ als auch „In Bearbeitung“ befindliche Warteschlangenelemente bei der Berechnung der Anzahl der Zielaufträge, die erreicht werden müssen, berücksichtigen. Zuvor wurden nur neue Elemente berücksichtigt, sodass keine Aufträge gestartet wurden, wenn es weniger neue Elemente als Elemente in Bearbeitung gab, 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.
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.
Um einen besseren Einblick in Laufzeitprobleme wie Berechtigungsprobleme oder Verbindungsfehler zu bieten, protokolliert der Orchestrator jetzt Laufzeitausnahmen in Elasticsearch.
Plug-and-Play für Ihren S3-kompatiblen Speicher mit Orchestrator und Vorteile aller einzigartigen Vorteile: Skalierbarkeit, Kosten und Zuverlässigkeit.
Ab dieser Version ist die Integration mit Azure Active Directory (Azure AD) auch auf Organisations-/Mandantenebene verfügbar (jede Organisation besteht aus einem Mandanten).
Eine Integration mit Azure AD war bereits auf Hostebene verfügbar, sodass Sie sie für SSO nutzen können. Mit dieser Änderung profitieren Sie von SSO, aber auch von der Verzeichnissuche und der automatischen Benutzerbereitstellung, wenn die Azure AD-Integration auf Organisations-/Mandantenebene konfiguriert ist.
Weitere Informationen und Anweisungen finden Sie unter Einrichten der Azure AD-Integration.
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.
- Sowohl bei Neuinstallationen als auch bei Upgrades verwendet Update Server jetzt standardmäßig die vorhandene Orchestrator-Datenbank anstelle seiner eigenen Datenbank.
Wir haben die folgenden Änderungen an den Sicherheitseinstellungen auf Host-Ebene vorgenommen (zu finden im Hostportal):
- Jetzt ist es zulässig, dass der Wert des Felds Minimale Kennwortlänge im Bereich von 1 bis 256 liegt. Bisher war der maximal zulässige Wert 14.
- Jetzt darf der Wert des Felds Tage vor Ablauf des Kennworts im Bereich von 0 bis 1000 liegen. Bisher war der maximal zulässige Wert 120.
- Die standardmäßige SignalR-Einstellung im Orchestrator (bei der nur der Websocket-Transport ausgewählt ist) verhindert, dass das entsprechende Remote-Roboter-Dienstprogramm
UiPath.RemoteDebugging.Agent.exe
in Umgebungen mit mehreren Knoten ausgeführt wird (entweder eigenständige oder Automation Suite-Installationen). Um dieses Verhalten zu korrigieren, wählen Sie alle verfügbaren SignalR-Transporte aus – WebSocket (Standardauswahl), vom Server gesendete Ereignisse (SEE) und lange Abfragen – und aktivieren Sie Sticky Sessions auf dem Lastenausgleich.
- Neuigkeiten
- Neuer Mechanismus zum Starten von Aufträgen über Warteschlangen-Trigger
- Protokollieren von Laufzeitausnahmen in Elasticsearch
- S3-kompatibler Speicher
- Azure AD auf Organisations-/Mandantenebene
- Benutzerdefinierter AIMWebserviceName
- Verbesserungen
- Einrichten
- Passwortrichtlinie
- Bekannte Probleme (Known Issues)