orchestrator
2021.10
false
  • Versionshinweise
    • 2021.10
    • 2021.10.1
    • 2021.10.2
    • 2021.10.4
    • 2021.10.6
    • 2021.10.8
    • 2021.10.9
    • 2021.10.10
    • 2021.10.11
    • 2021.10.12
    • 2021.10.14
    • 2021.10.15
Wichtig :
Bitte beachten Sie, dass dieser Inhalt teilweise mithilfe von maschineller Übersetzung lokalisiert wurde. Es kann 1–2 Wochen dauern, bis die Lokalisierung neu veröffentlichter Inhalte verfügbar ist.
UiPath logo, featuring letters U and I in white
Kein Support

Versionshinweise zum Orchestrator

Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Letzte Aktualisierung 11. Nov. 2024

2021.10.1

Release-Datum: 7. Dezember 2021

Neuigkeiten

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

Wichtig: Mit diesem Release wurde die Auftragsausführung vom Orchestrator über Warteschlangen-Trigger erheblich verändert. Das neue Verhalten ist standardmäßig aktiviert und kann nicht deaktiviert werden. Lesen Sie sich die Versionshinweise sorgfältig durch, bevor Sie auf 2021.10.1 aktualisieren. Wenn Sie sich nicht sicher sind, warten Sie auf die nächsten Patches, bei denen wir uns weiter mit dem Verhalten befassen werden.

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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. 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.

Protokollieren von Laufzeitausnahmen in Elasticsearch

Um einen besseren Einblick in Laufzeitprobleme wie Berechtigungsprobleme oder Verbindungsfehler zu bieten, protokolliert der Orchestrator jetzt Laufzeitausnahmen in Elasticsearch.

S3-kompatibler Speicher

Plug-and-Play für Ihren S3-kompatiblen Speicher mit Orchestrator und Vorteile aller einzigartigen Vorteile: Skalierbarkeit, Kosten und Zuverlässigkeit.



Azure AD auf Organisations-/Mandantenebene

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.

Benutzerdefinierter AIMWebserviceName

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.



Verbesserungen

Einrichten

  • Sowohl bei Neuinstallationen als auch bei Upgrades verwendet Update Server jetzt standardmäßig die vorhandene Orchestrator-Datenbank anstelle seiner eigenen Datenbank.

Passwortrichtlinie

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.

Bekannte Probleme (Known Issues)

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

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
Uipath Logo White
Vertrauen und Sicherheit
© 2005–2024 UiPath. Alle Rechte vorbehalten