- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Verwalten großer Bereitstellungen
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Schreibgeschütztes Orchestrator-Replikat
- Exportieren von Rastern im Hintergrund
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Audit
- Ressourcenkatalogdienst
- Automation Suite Robots
- Ordnerkontext
- Automatisierungen
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Warteschlangen
- Assets
- Speicher-Buckets
- Test Suite - Orchestrator
- Integrationen
- Fehlersuche und ‑behebung
Warteschlangen-Trigger
Triggerzeitzonen: Die für einen Trigger festgelegte Zeitzone ist nicht durch die Zeitzone des Mandanten eingeschränkt.Wenn Sie jedoch Kalender für arbeitsfreie Tage verwenden, können Sie keine unterschiedlichen Zeitzonen einstellen.
Warteschlangentrigger werden gemäß der auf Triggerebene definierten Zeitzone gestartet. Warteschlangentrigger werden basierend auf der Verarbeitung von Warteschlangenelementen gestartet.
Warteschlangentrigger werden basierend auf der Triggerzeitzone deaktiviert.
Diese Optionen helfen Ihnen, die Regeln für die Prozessauslösung mit Parametern zu konfigurieren:
Beschreibung | |
---|---|
Mindestanzahl der Elemente zum Auslösen des ersten Auftrags |
Der Elementverarbeitungsauftrag wird erst gestartet, wenn die Zielwarteschlange mindestens diese Anzahl neuer Elemente enthält. Verschobene Warteschlangenelemente werden nicht gezählt. |
Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge |
Die maximale Anzahl der zulässigen ausstehenden und ausgeführten Aufträge, zusammengezählt. Für 2 oder mehr gleichzeitig zulässige Aufträge muss die dritte Option wie unten beschrieben definiert werden. |
Für alle __ neuen Elemente wird ein weiterer Auftrag ausgelöst. |
Ein neuer Auftrag wird für jede Anzahl neuer Elemente ausgelöst, die zusätzlich zur Anzahl der für die erste Option definierten Elemente hinzugefügt werden. Nur aktiviert, wenn 2 oder mehr Aufträge gleichzeitig zulässig sind (definiert mit der oben beschriebenen Option). |
Nach Abschluss von Aufträgen die Bedingungen neu bewerten und nach Möglichkeit neue Aufträge starten | Wenn diese Option ausgewählt ist, wird der Warteschlangen-Trigger nach jedem Auftragsabschluss überprüft und es werden neue Aufträge gestartet, wenn Roboter verfügbar sind.
Das ergänzt die automatische Überprüfung, die alle 30 Minuten erfolgt, und trägt dazu bei, dass verbleibende Warteschlangenelemente möglichst verzögerungsfrei verarbeitet werden. |
Um Warteschlangenelemente zu verarbeiten, die zum Zeitpunkt der Einreihung in die Warteschlange nicht verarbeitet werden können, einschließlich wiederholter Elemente, wird alle 30 Minuten standardmäßig eine Überprüfung auf nicht verarbeitete Elemente durchgeführt. Wenn die auslösende Bedingung erfüllt ist, wird der Trigger erneut gestartet.
Sie können den Parameter Queue.ProcessActivationSchedule verwenden, um das standardmäßige 30-Minuten-Prüfintervall anzupassen. Anmerkung: Eine Änderung des Wertes von Queue.ProcessActivationSchedule
wirkt sich nicht sofort auf vorhandene Elemente in der Warteschlange aus, die sich in Bearbeitung befinden. Die Änderungen werden wirksam, nachdem der Trigger der Warteschlange aktualisiert wurde.
Diese Prüfung stellt sicher, dass alle Elemente in der Warteschlange in den folgenden Situationen bearbeitet werden:
- Warteschlangenelemente werden der Warteschlange viel schneller hinzugefügt, als sie mit den verfügbaren Ressourcen verarbeitet werden können.
- Warteschlangenelemente werden während arbeitsfreien Tagen einer Warteschlange hinzugefügt, können jedoch nur während der Arbeitszeit verarbeitet werden.
-
Die Verarbeitung von Warteschlangenelementen wird auf einen späteren Zeitpunkt verschoben. Nach Ablauf dieser Zeit können sie verarbeitet werden, sobald sie durch die 30-minütige Überprüfung identifiziert wurden.
Hinweis: Aufgrund der standardmäßigen 30-Minuten-Prüfung besteht die Gefahr von Ressourcenhindernissen außerhalb der Hauptgeschäftszeiten. Um dies zu vermeiden, stellen Sie sicher, dass am Ende des Arbeitstages keine unverarbeiteten Artikel vorhanden sind. Wenn dies nicht möglich ist, stellen Sie sicher, dass der getriggerte Prozess kein menschliches Eingreifen erfordert.
Im Algorithmus verwendete Zahlen
-
Die Anzahl der neuen Warteschlangenelemente, die in der Warteschlange verfügbar sind: N
-
Die Mindestanzahl von Elementen, die zum Auslösen des ersten Auftrags erforderlich sind: x
-
Das bedeutet, dass wir einen Auftrag nur dann auslösen, wenn mindestens x neue Elemente vorhanden sind.
-
-
Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge: y
-
Das bedeutet, dass wir eine Obergrenze (y) für die Anzahl der parallelen Aufträge festlegen.
-
-
Für alle __ neuen Elemente wird ein weiterer Auftrag ausgelöst: z
-
Das bedeutet, dass ein Auftrag gestartet wird, wenn x erreicht ist. Für die verbleibenden N–x Warteschlangenelemente versuchen wir, (N–x)/z Aufträge zu starten. Wenn diese Zahl höher als y wäre, erstellen wir gerade so viele Aufträge, um insgesamt y zu erreichen.
-
Bei der Bewertung, wie viele zusätzliche Aufträge erstellt werden können, berücksichtigen wir die aktuell ausgeführten Aufträge (w). Basierend auf der Strategieeinstellung Trigger – Warteschlangentrigger – Aktivieren ausstehender Aufträge wird diese Zahl wie folgt berechnet:
-
True – Maximale zusätzliche Aufträge, die basierend auf neu verfügbaren Warteschlangenelementen erstellt werden können = y minus der Anzahl der Aufträge im Status Ausstehend . (Diese Option eignet sich am besten für Fälle, in denen der Orchestrator davon ausgehen soll, dass alle ausgeführten Aufträge Warteschlangenelemente bereits aus dem Status Neu verschoben haben.)
-
False – Maximale zusätzliche Aufträge, die basierend auf neu verfügbaren Warteschlangenelementen erstellt werden können = y abzüglich der Anzahl der Aufträge in einem dieser Status: Ausstehend, Fortgesetzt, Wird ausgeführt, Wird angehalten, Wird beendet. (Diese Option eignet sich am besten für Fälle, in denen der Orchestrator davon ausgehen soll, dass alle ausgeführten Aufträge Warteschlangenelemente noch aus dem Status Neu verschieben müssen.)
Wichtige Hinweise
-
Diese Auswertung erfolgt immer dann, wenn ein einzelnes Warteschlangenelement hinzugefügt wird, auch bei massenhaftem Hinzufügen.
-
Um sicherzustellen, dass aufgeschobene (verschobene) Elemente der Warteschlange berücksichtigt werden, hat jeder Trigger der Warteschlange einen zugehörigen Zeitplan, der den gesamten obigen Algorithmus erneut überprüft. Dies geschieht standardmäßig alle 30 Minuten, kann aber über die Mandanteneinstellung Warteschlangen – Häufigkeit der Überprüfung nicht verarbeiteter Warteschlangenelemente (Minuten) auf ein Minimum von 10 reduziert werden.
-
Ursprünglich sollte damit sichergestellt werden, dass ein Auftrag gestartet wird, sobald ein Schwellenwert erreicht ist, und dass bei Überschreiten dieses Schwellenwerts zusätzliche Aufträge gestartet werden, um den erhöhten Rückstand abzuarbeiten. Es geht nicht darum, die Workload gleichmäßig auf die potenziellen Maschinen zu verteilen, sondern zu gewährleisten, dass genügend Aufträge vorhanden sind.
-
Es besteht keine feste Verbindung zwischen den gestarteten Aufträgen und den Warteschlangenelementen, für die sie gestartet wurden, d. h. Auftrag J ist nicht unbedingt für die Warteschlangenelemente a, b, c usw. bestimmt.
-
Die Algorithmusergebnisse unterscheiden sich je nachdem, ob Warteschlangenelemente massenweise oder einzeln hinzugefügt wurden, da dies die Anzahl der durchgeführten Auswertungen beeinflusst.
Szenario 1 – Einzeln hinzugefügte Warteschlangenelemente
Ich habe zwei Aufträge:
- Einer, der 3 Elemente pro Sekunde für 20 Sekunden zur Zielwarteschlange hinzufügt (insgesamt 60 Elemente).
- Einer, der 1 Element pro Sekunde von der Zielwarteschlange verarbeitet.
Ich habe meinen Trigger wie folgt definiert:
- Die Mindestanzahl der Elemente zum Auslösen des ersten Auftrags:
31
. - Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge:
3
- Für alle
10
neuen Elemente wird ein weiterer Auftrag ausgelöst.
Ich starte den Auftrag, der Elemente zu meiner Warteschlange hinzufügt.
- Nach 11 Sekunden (33 Elemente) wird der erste Elementverarbeitungsauftrag ausgelöst.
- Nach weiteren 4 Sekunden (12 Elementen) wird der zweite Elementverarbeitungsauftrag ausgelöst.
- Nach weiteren 4 Sekunden (12 Elementen) wird der dritte Elementverarbeitungsauftrag ausgelöst.
Als das Hinzufügen der Warteschlangenelemente beendet war, hatte der erste Auftrag 9 Elemente verarbeitet, der zweite 5 Elemente, der dritte 1 Element. Das sind 15 Elemente, die in 20 Sekunden von drei Aufträgen verarbeitet wurden.
Das bedeutet ein Rest von 45 zu verarbeitenden Elementen (60–15). Bei drei Aufträgen, die jeweils ein Element pro Sekunde verarbeiten, bedeutet dies 15 Sekunden für den Rest, was zu einer Gesamtzeit von 35 Sekunden führt.
Szenario 2 – Warteschlangenelemente massenweise hinzugefügt
Wenn die im obigen Szenario genannten 60 Warteschlangenelemente mit einem Massenvorgang hinzugefügt werden (wenn kein Auftrag ausgeführt wird oder aussteht), werden drei Aufträge erstellt.
Wenn mindestens ein Auftrag vor dem Neubewertungszeitplan abgeschlossen wird, werden weitere Aufträge erstellt.
Sie können mehrere Regeln konfigurieren, je nachdem, welche Prozesse ausgeführt werden.
Beschreibung | |
---|---|
Konto |
Der Prozess wird unter einem bestimmten Konto ausgeführt. Wenn Sie nur das Konto angeben, weist der Orchestrator die Maschine dynamisch zu. Wenn Sie das Konto und die Maschinenvorlage angeben, wird der Auftrag auf genau diesem Konto-Maschine-Paar gestartet. |
Maschine |
Der Prozess wird auf einer der Hostmaschinen ausgeführt, die der ausgewählten Maschinenvorlage zugeordnet sind. Wenn Sie nur die Maschinenvorlage angeben, weist der Orchestrator das Konto dynamisch zu. Wenn Sie das Konto und die Maschinenvorlage angeben, wird der Auftrag auf genau diesem Konto-Maschine-Paar gestartet. Hinweis: Stellen Sie sicher, dass die erforderlichen Runtime-Lizenzen zum Ausführen des Auftrags der zugeordneten Maschinenvorlage zugewiesen sind.
|
Hostname |
Hostname Nach der Auswahl einer Maschinenvorlage wird die Option Hostname angezeigt, mit der Sie die gewünschte Workstation-/Robotersitzung zum Ausführen des Prozesses auswählen können. Alle verfügbaren Sitzungen im aktiven Ordner werden angezeigt, entweder nicht verbunden, getrennt oder verbunden. Hinweis: Stellen Sie sicher, dass die erforderlichen Runtime-Lizenzen zum Ausführen des Auftrags der zugeordneten Maschinenvorlage zugewiesen sind.
|
Warteschlangentrigger können auch von RPA-Entwicklern zur Entwurfszeit in Studio mithilfe der Aktivität When New Item Added to Queue des Pakets UiPath.Core.Activities erstellt werden.
Der Orchestrator identifiziert diese Triggertypen als Paketanforderungen und die einzige Möglichkeit, sie im Orchestrator hinzuzufügen, ist über die Seite Paketanforderungen.
Jede zur Entwurfszeit festgelegte Konfiguration wird im Orchestrator wiedergegeben und kann nicht geändert werden.
Beispiel: Wenn ein Warteschlangenelement zu meiner Warteschlange hinzugefügt wird, möchte ich seine Metadaten als Protokollnachricht erhalten. Der Unterschied besteht darin, dass der Warteschlangentrigger die Automatisierung anweist, innerhalb des Workflows zu starten, im Gegensatz zu Orchestrator-Warteschlangentriggern, die anweisen, dass die Automatisierung außerhalb des Workflows startet.