Warteschlangen-Trigger

Wichtig:

• Sie können einen einzelnen Warteschlangentrigger für eine Warteschlange erstellen. Dies gilt auch für Warteschlangen, die für mehrere Ordner freigegeben werden.
• 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.

Wenn eine große Anzahl von Warteschlangenelementen in kurzer Zeit hinzugefügt wird (z. B. mithilfe von AddQueueItem oder BulkAddQueueItems), wird der Prozess möglicherweise nicht sofort gestartet. Um solche Situationen zu handhaben, ist ein erneuter Prüfmechanismus implementiert, der sicherstellt, dass der Prozess ausgelöst wird, sobald Ressourcen verfügbar sind.

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.

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, nachdem die Zielwarteschlange mindestens diese Anzahl neuer Elemente enthält. Zurückgestellte Warteschlangenelemente werden nicht gezählt.
Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge	Die maximale Gesamtanzahl der zulässigen ausstehenden und ausgeführten Aufträge. 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 zwei 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 Warteschlangen – Unbearbeitete Elemente in Warteschlangen prüfen (in Minuten) verwenden, um das standardmäßige Prüfintervall von 30 Minuten 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

Variablen

Variable	Beschreibung
newItems	Anzahl der neuen Warteschlangenelemente, die in der Warteschlange verfügbar sind.
minItemsToTrigger	Die Mindestanzahl der erforderlichen Elemente zum Auslösen des ersten Auftrags. Der erste Auftrag wird nur gestartet, wenn mindestens so viele neue Elemente vorhanden sind.
maxConcurrentJobs	Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge. Dies ist die Obergrenze für parallele Aufträge.
itemsPerJob	Anzahl der zusätzlichen Elemente, die erforderlich sind, um jeden nachfolgenden Auftrag auszulösen. Wenn minItemsToTrigger erreicht ist, wird ein Auftrag gestartet. Für alle zusätzlichen itemsPerJob -Elemente über minItemsToTrigger hinaus wird ein weiterer Auftrag gestartet – bis zu maxConcurrentJobs.
pendingJobs	Anzahl der Aufträge, die sich derzeit im Status „Ausstehend“ befinden.
runningJobs	Anzahl der Aufträge in den Status Fortgesetzt, Wird ausgeführt, Wird angehalten oder Wird beendet.
enablePendingJobsStrategy	Boolesche Einstellung, die bestimmt, ob laufende Aufträge auf die verbleibende Kapazität angerechnet wird.

Die Strategieeinstellung Trigger – Warteschlangentrigger – Aktivieren ausstehender Aufträge bestimmt, wie der Orchestrator die verbleibende Kapazität berechnet – die Anzahl zusätzlicher Aufträge, die er planen darf:

• True – Verbleibende Kapazität = maxConcurrentJobs minus pendingJobs. Verwenden Sie diese Einstellung, wenn ausgeführte Aufträge ihre Warteschlangenelemente voraussichtlich bereits vom Status Neu erhalten haben.
• False – Verbleibende Kapazität = maxConcurrentJobs minus pendingJobs minus runningJobs. Verwenden Sie diese Einstellung, wenn ausgeführte Aufträge ihre Warteschlangenelemente voraussichtlich noch nicht mit dem Status Neu belegt haben.

Der Orchestrator plant den kleineren von zwei Werten: die verbleibende Kapazität und die Anzahl der gewünschten Aufträge, basierend auf der Anzahl der Warteschlangenelemente. Die Einstellung steuert daher, wie konsolidiert oder ag UiPath neue Aufträge geplant werden.

Formeln

1. Verbleibende Kapazität

if enablePendingJobsStrategy = true:
    remainingCapacity = maxConcurrentJobs - pendingJobs

if enablePendingJobsStrategy = false:
    remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs

2. Gewünschte Aufträge (vor der Kapazitätsgrenze)

if newItems < minItemsToTrigger:
    desiredJobs = 0
else:
    desiredJobs = 1 + (newItems - minItemsToTrigger) / itemsPerJob   [integer division]

3. Zu planende Aufträge

jobsToSchedule = min(desiredJobs, remainingCapacity)

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.
  Hinweis:

  Verschobene Elemente werden erst verarbeitet, sobald ihre Verschiebungszeit abgelaufen ist. Der integrierte Auftrag, der verschobene Elemente überprüft, wird alle 30 Minuten ausgeführt. Wenn jedoch ein neues Element zu derselben Warteschlange hinzugefügt wird, nachdem ein verschobenes Element bereits verfügbar ist, wird der Warteschlangentrigger sofort ausgelöst, und das verschobene Element kann aufgenommen werden, ohne auf die nächste geplante Prüfung zu warten.

• Der Algorithmus wurde entwickelt, um sicherzustellen, dass ein Auftrag startet, sobald ein Schwellenwert erreicht ist, und dass bei Überschreiten des Schwellenwerts zusätzliche Aufträge gestartet werden, um den erhöhten Rückstand abzuarbeiten. Es wurde nicht entwickelt, um die Workload gleichmäßig auf die Maschinen zu verteilen, sondern sicherzustellen, dass genügend Aufträge vorhanden sind.
• Es besteht keine feste Verbindung zwischen den gestarteten Aufträgen und den von ihnen verarbeiteten Warteschlangenelementen. Auftrag J ist nicht unbedingt den Warteschlangenelementen a, b oder c zugeordnet.
• Die Algorithmusergebnisse unterscheiden sich je nachdem, ob Warteschlangenelemente massenweise oder einzeln hinzugefügt wurden, da dies die Anzahl der durchgeführten Auswertungen beeinflusst.
• Bei der Verwendung von Warteschlangentriggern wird gelegentlich folgende Warnung angezeigt: The trigger could not create a job as the maximum number of jobs has been reached. Diese Warnung ist informativ und bedeutet in der Regel, dass ein Auftrag bereits ausgeführt wurde, als Orchestrator versuchte, einen anderen zu starten. Wenn Sie mit Ihrer aktuellen Auftragskapazität zufrieden sind, können Sie diese problemlos ignorieren.

Beispiel

Szenario 1 – Einzeln hinzugefügte Warteschlangenelemente

Für dieses Szenario wird der Parameter Strategie zum Aktivieren ausstehender Aufträge auf False festgelegt. Weitere Informationen zum Aktualisieren des Werts finden Sie unter Mandanteneinstellungen.

In diesem Szenario werden zwei Aufträge verwendet:

• Man fügt 3 Elemente pro Sekunde für 20 Sekunden zur Zielwarteschlange hinzu (instanz 60 Elemente).
• Einer verarbeitet 1 Element pro Sekunde von der Zielwarteschlange.

Der Trigger ist wie folgt konfiguriert:

• Mindestanzahl von Elementen zum Auslösen des ersten Auftrags: 31
• Maximale Anzahl der gleichzeitig zulässigen ausstehenden und ausgeführten Aufträge: 3
• Für alle: 10 neue(s) Element(e) wird ein weiterer Auftrag ausgelöst.

Nachdem der Auftrag, der Elemente zur Warteschlange hinzufügt, gestartet wurde:

1. Nach 11 Sekunden (33 Elemente) wird der erste Elementverarbeitungsauftrag ausgelöst.
2. Nach weiteren 4 Sekunden (12 Elementen) wird der zweite Elementverarbeitungsauftrag ausgelöst.
3. Nach weiteren 4 Sekunden (12 Elemente) wird der dritte Elementverarbeitungsauftrag ausgelöst.

Als das Hinzufügen der Warteschlangenelemente beendet war, hatte der erste Auftrag 9 Elemente verarbeitet, die zweiten 5 Elemente und der dritte 1 Element – 15 Elemente in 20 Sekunden von drei Aufträgen verarbeitet.

Die verbleibenden 45 Elemente (60 – 15) werden von 3 Aufträgen bei jeweils 1 Element pro Sekunde verarbeitet und in weiteren 15 Sekunden abgeschlossen. Gesamte Verarbeitungszeit: 35 Sekunden.

Szenario 2 – Warteschlangenelemente massenweise hinzugefügt

Für dieses Szenario wird der Parameter Strategie zum Aktivieren ausstehender Aufträge auf False festgelegt. Weitere Informationen zum Aktualisieren des Werts finden Sie unter Mandanteneinstellungen.

Wenn die 60 Warteschlangenelemente aus Szenario 1 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.

Beispiele für Strategien zum Aktivieren ausstehender Aufträge

Diese Beispiele zeigen, wie die Strategieeinstellung Ausstehende Aufträge aktivieren zu einer Überplanung führen kann, wenn sie aktiviert ist, und zu einer Unterplanung, wenn sie deaktiviert ist.

Triggerkonfiguration

Einstellung	Wert
Mindestens auszulösende Warteschlangenelemente	1
Maximale Anzahl von ausstehenden und ausgeführten Aufträgen	1.000
Für jeden wird ein weiterer Auftrag ausgelöst	1 neues Element
Nach Abschluss des Auftrags neu bewerten	True
Strategie zum Aktivieren ausstehender Aufträge	True (Teil 1)

Annahme: Es dauert 30 Sekunden, bis ein Auftrag ein Warteschlangenelement aus dem Status Neu verschiebt.

Teil 1: Überplanung mit aktivierter Strategie zum Aktivieren ausstehender Aufträge

Schritt 1: 1.100 Elemente werden massenweise zur Warteschlange hinzugefügt, wodurch 1.000 Aufträge ausgelöst werden.

Schritt 2: Nur 200 Roboter sind verfügbar. 200 Aufträge werden ausgeführt und 800 bleiben ausstehend.

Jobs	Anzahl
Running (Wird ausgeführt)	200
Anstehende	800

Warteschlangenelemente	Status
200	In Bearbeitung
900	Neu (New)

Schritt 3: Die 200 laufenden Aufträge werden abgeschlossen, wodurch 200 weitere Aufträge ausgeführt werden.

Jobs	Anzahl
Running (Wird ausgeführt)	200
Anstehende	600

Warteschlangenelemente	Status
200	Erfolgreich
200	In Bearbeitung
700	Neu (New)

Schritt 4: Da nach Abschluss des Auftrags die Neubewertung aktiviert ist, wird der Trigger innerhalb von Sekunden erneut ausgeführt. Wenn Strategie zum Aktivieren ausstehender Aufträge aktiviert ist, geht der Orchestrator davon aus, dass alle 200 ausgeführten Aufträge ihre Warteschlangenelemente bereits aus dem Status Neu verschoben haben – obwohl dies tatsächlich 30 Sekunden dauert.

Schritt 5: Die Triggerberechnung zu diesem Zeitpunkt:

remainingCapacity = maxConcurrentJobs - pendingJobs = 1000 - 600 = 400
desiredJobs       = newItems - pendingJobs          = 700 - 600  = 100
jobsToSchedule    = min(100, 400)                               = 100

100 weitere Aufträge sind geplant. Da die 200 ausgeführten Aufträge ihre Elemente jedoch noch nicht aus dem Status „Neu“ entfernt haben (Dauert 30 Sekunden), behandelt der Orchestrator 700 neue Elemente als nicht abgedeckt, während nur ca. 500 wirklich neue Aufträge benötigt werden. Das Ergebnis ist ungefähr 100 übergeplante Aufträge.

Hinweis:

Der Orchestrator verfolgt nicht die Beziehung zwischen einzelnen Aufträgen und einzelnen Warteschlangenelementen, sodass er keine Überplanung selbst erkennen kann. Das Erkennen von Überplanung erfordert eine externe Statusnachverfolgung.

Schritt 6: Wenn die Strategie zum Aktivieren ausstehender Aufträge deaktiviert ist, führt die gleiche Situation zu:

remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs = 1000 - 600 - 200 = 200
desiredJobs       = newItems - pendingJobs - runningJobs           = 700 - 600 - 200 = -100 → 0
jobsToSchedule    = min(0, 200)                                                      = 0

Es sind keine zusätzlichen Aufträge geplant – was in diesem Szenario eher korrekt ist.

Teil 2: Unterplanung mit deaktivierter Strategie zum Aktivieren ausstehender Aufträge

Schritt 1: In diesem Szenario werden Aufträge nicht gleichzeitig fertiggestellt. Von den ersten 200 Aufträgen werden 100 nach 60 Sekunden und die anderen 100 nach 90 Sekunden abgeschlossen.

Schritt 2: Die ersten 100 Aufträge werden abgeschlossen, wodurch 100 weitere Aufträge ausgelöst werden.

Jobs	Anzahl
Running (Wird ausgeführt)	200
Anstehende	700

Warteschlangenelemente	Status
100	Erfolgreich
200	In Bearbeitung
700	Neu (New)

Schritt 3: Da nach Abschluss des Auftrags die Neubewertung aktiviert ist, wird der Trigger innerhalb von Sekunden erneut ausgeführt.

Schritt 4: Wenn die Strategie zum Aktivieren ausstehender Aufträge aktiviert ist:

remainingCapacity = maxConcurrentJobs - pendingJobs          = 1000 - 700 = 300
desiredJobs       = newItems - pendingJobs                   = 700 - 700  = 0
jobsToSchedule    = min(0, 300)                                           = 0

Es sind keine zusätzlichen Aufträge geplant. Das ist korrekt – es gibt 700 ausstehende Aufträge für 700 Neue Elemente.

Schritt 5: Bei deaktivierter Strategie zum Aktivieren ausstehender Aufträge :

remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs = 1000 - 700 - 200 = 100
desiredJobs       = newItems - pendingJobs - runningJobs           = 700 - 700 - 200 = -200 → 0
jobsToSchedule    = min(0, 100)                                                       = 0

Hier sind auch keine zusätzlichen Aufträge geplant. Wenn es jedoch weniger ausstehende Aufträge gab, wäre die Formel zu unten: Es wird davon ausgegangen, dass die 200 ausgeführten Aufträge ihre Elemente noch nicht im Status Neu angefordert haben, obwohl 100 von ihnen dies bereits haben.

Schritt 6: Aufträge, die aufgrund von Unterplanung nicht geplant sind, werden schließlich aufgenommen, wenn die Prüfung der nicht verarbeiteten Warteschlangenelemente in ihrem periodischen Zeitplan ausgeführt wird. Das ist der Zweck dieser Überprüfung.

Zusammenfassung

Einstellung	Annahme über die Ausführung von Aufträgen	Folge
Aktiviert (true)	Ihre Warteschlangenelemente bereits in Anspruch genommen	Kann überplanen
Deaktiviert (false)	Die Warteschlangenelemente haben sie noch nicht in Anspruch genommen	Mai unter dem Zeitplan (entschärfet sich durch regelmäßige erneute Überprüfungen)

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.