Warteschlangen-Trigger

Wichtig:

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.

Warteschlangen-Trigger starten einen Prozess sofort bei der Trigger-Erstellung oder immer dann, wenn Sie ein neues Element zu einer Warteschlange hinzufügen. Der Trigger wird in der Umgebung ausgeführt, die dem ausgewählten Prozess zugeordnet ist.

Wichtig: Die Implementierung von Warteschlangen-Triggern ist für die Verarbeitung von Prozessen optimiert, die eine interne Schleife haben, um alle verfügbaren Warteschlangenelemente zu verarbeiten, bevor sie beendet werden. Wenn ein Prozess diese Strategie nicht umsetzt, ist das Ergebnis suboptimal und erfüllt möglicherweise nicht die gewünschten geschäftlichen Anforderungen.

Es gibt drei Optionen, die Ihnen helfen, 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).

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.

Beachten Sie, dass Sie den Parameter Queue.ProcessActivationSchedule verwenden können, um das standardmäßige 30-Minuten-Prüfintervall anzupassen.

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.

Algorithmus zur Verarbeitung von Warteschlangen-Triggern

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.
Frist ist nützlich, um Aufgaben mit ähnlichen Prioritäten zu ordnen, während Verschieben sicherstellt, dass eine Aufgabe nicht vor der angegebenen Zeit initiiert wird. Die beiden Parameter sollten jedoch nicht zusammen verwendet werden.

Beispiel

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.

Ausführungsziel

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.

Mit UiPath-Aktivitäten erstellte Warteschlangentrigger

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.

Auf dieser Seite