Warteschlangen-Trigger

Erstellen und verwalten Sie Warteschlangentrigger, einschließlich Zeitzonen- und Kalenderbeschränkungen für arbeitsfreie Tage.

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	Mindestanzahl der Elemente zum Auslösen des ersten Auftrags Der erste Auftrag startet erst, 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 zum Auslösen jedes weiteren Auftrags erforderlich sind.Wenn minItemsToTrigger erreicht ist, startet ein Auftrag. Für jedes zusätzliche itemsPerJob Element über minItemsToTrigger hinaus, startet ein weiterer Auftrag – bis zu maxConcurrentJobs.
pendingJobs	Anzahl der Aufträge, die sich derzeit im Status „Ausstehend“ befinden.
runningJobs	Anzahl der Aufträge im Status „Fortgesetzt“, Ausgeführt“, Wird angehalten“ oder „Wird beendet“.
enablePendingJobsStrategy	Boolesche Einstellung, die bestimmt, ob laufende Aufträge auf die verbleibende Kapazität angerechnet werden.

Die Einstellung Trigger – Warteschlangentrigger – Strategie zum 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 laufende Aufträge voraussichtlich noch keine Warteschlangenelemente aus dem Status Neu übernommen haben.

Der Orchestrator plant den kleineren von zwei Werten: der verbleibenden Kapazität und der Anzahl der gewünschten Aufträge basierend auf der Anzahl der Warteschlangenelemente. Die Einstellung steuert daher, wie konservativ oder aggressiv 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.

Queue triggers on Maestro

Queue triggers on Maestro processes have fixed batch settings to ensure 1 Queue Item = 1 Maestro process instance. This prevents queue item batching and guarantees one-to-one mapping between queue items and Maestro workflow instances.

Batch settings for Maestro queue triggers

For queue triggers targeting Maestro processes, the following settings are read-only and fixed to 1:

• Minimum number of items to trigger the first job: Fixed to 1
• Another job is triggered for each __ new item(s): Fixed to 1

This enforces a batching mode where:

• Each queue item triggers exactly one Maestro process instance
• Multiple jobs can run concurrently (controlled by Maximum number of pending and running jobs allowed simultaneously)
• No queue item batching occurs within a single job

Why queue item batching is disabled for Maestro

Maestro processes are designed to handle one business case or workflow instance at a time. Batching multiple queue items into a single job execution would prevent individual case tracking and compromise the case-driven nature of Maestro workflows.

Comparison with non-Maestro queue triggers

For RPA and other process types, batch settings are fully configurable, allowing you to optimize throughput by processing multiple queue items in a single job execution.

Example: Maestro queue trigger configuration

When configuring a queue trigger for a Maestro process:

1. Minimum number of items to trigger the first job: 1 (read-only, cannot be changed)
2. Maximum number of pending and running jobs allowed simultaneously: Set to your desired concurrency limit (for example, 5 for 5 concurrent Maestro instances)
3. Another job is triggered for each __ new item(s): 1 (read-only, cannot be changed)

This configuration ensures that if 10 queue items are added, up to 5 Maestro process instances start concurrently, each processing exactly 1 queue item.

• Es gibt 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 gestartet wurde, der Elemente zur Warteschlange hinzufügt:

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 mit jeweils 1 Element pro Sekunde verarbeitet und in weiteren 15 Sekunden abgeschlossen. Gesamtverarbeitungszeit: 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 Einstellung Strategie für ausstehende Aufträge aktivieren zu Überplanung führen kann, wenn sie aktiviert ist, und zu Unterplanung, wenn sie deaktiviert ist.

Triggerkonfiguration

Einstellung	Wert
Mindestanzahl der Warteschlangenelemente zum Auslösen	1
Maximale Anzahl ausstehender und laufender Aufträge	1.000
Für jeden wird ein weiterer Auftrag ausgelöst	1 neues Element
Nach Abschluss des Auftrags neu bewerten	True
Strategie für ausstehende Aufträge aktivieren	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 massenhaft zur Warteschlange hinzugefügt, wodurch 1.000 Aufträge ausgelöst werden.

Schritt 2: Es sind nur 200 Roboter 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 neu bewerten aktiviert ist, wird der Trigger innerhalb von Sekunden erneut ausgeführt. Wenn Strategie für ausstehende Aufträge aktivieren aktiviert ist, geht Orchestrator davon aus, dass alle 200 laufenden 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 laufenden Aufträge ihre Elemente jedoch noch nicht aus dem Status Neu verschoben haben (dies dauert 30 Sekunden), behandelt der Orchestrator 700 neue Elemente als nicht abgedeckt, während tatsächlich nur ca. 500 neue Aufträge benötigt werden. Das Ergebnis sind ungefähr 100 übergeplante Aufträge.

Hinweis:

Der Orchestrator verfolgt die Beziehung zwischen einzelnen Aufträgen und einzelnen Warteschlangenelementen nicht, sodass er eine Überplanung nicht selbstständig erkennen kann. Das Erkennen von Überplanung erfordert eine externe Statusüberwachung.

Schritt 6: Wenn die Strategie für ausstehende Aufträge aktivieren deaktiviert ist, tritt dieselbe Situation auf:

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

Es werden keine zusätzlichen Aufträge geplant – was in diesem Szenario eher dem korrekten Verhalten entspricht.

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 sind 100 nach 60 Sekunden abgeschlossen und die anderen 100 nach 90 Sekunden.

Schritt 2: Die ersten 100 Aufträge sind abgeschlossen, was 100 weitere Aufträge auslöst.

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 neu bewerten 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: Mit der Strategie für ausstehende Aufträge deaktiviert:

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

Auch hier sind keine zusätzlichen Aufträge geplant. Wenn es jedoch weniger ausstehende Aufträge gäbe, würde die Formel zu einer Unterplanung führen: Es wird davon ausgegangen, dass die 200 laufenden Aufträge ihre Elemente noch nicht aus dem Status Neu übernommen haben, obwohl 100 von ihnen dies bereits getan haben.

Schritt 6: Aufträge, die aufgrund der Unterplanung nicht eingeplant wurden, werden schließlich berücksichtigt, wenn die Prüfung auf unverarbeitete Warteschlangenelemente gemäß dem periodischen Zeitplan ausgeführt wird. Dies ist der Zweck dieser Überprüfung.

Zusammenfassung

Einstellung	Annahme über laufende Aufträge	Folge
Aktiviert (true)	Ihre Warteschlangenelemente bereits in Anspruch genommen	Überplanung möglich
Deaktiviert (false)	Haben ihre Warteschlangenelemente noch nicht in Anspruch genommen	Unterplanung möglich (durch regelmäßige erneute Überprüfungen begrenzt)

Warteschlangentrigger mit BPMN-Prozessen von Maestro

Warteschlangentrigger können Maestro BPMN-Prozesse starten, wenn neue Elemente zu einer Warteschlange hinzugefügt werden. Im Gegensatz zu RPA-Prozessen, die komplexe Batching-Logik implementieren können, werden BPMN-Warteschlangentrigger von Maestro mit festen Einschränkungen konfiguriert, um eine 1:1-Zuordnung zwischen Warteschlangenelementen und Prozessinstanzen zu erzwingen.

Konfigurationsbeschränkungen für Maestro BPMN

Beim Erstellen eines Warteschlangentriggers für einen BPMN-Prozess von Maestro werden die folgenden Felder automatisch auf ihre erforderlichen Werte gesperrt und können nicht geändert werden:

Feld	Wert	Grund
Mindestanzahl der Elemente zum Auslösen des ersten Auftrags	1	Jedes Warteschlangenelement löst genau eine Prozessinstanz aus
Für alle __ neuen Elemente wird ein weiterer Auftrag ausgelöst.	1	Gewährleistet eine 1:1-Zuordnung zwischen Elementen und Prozessinstanzen

Diese Einschränkungen stellen sicher, dass jedes Warteschlangenelement von genau einer Maestro-Prozessinstanz verarbeitet wird. Im Gegensatz zu RPA-Prozessen verarbeitet jede Maestro BPMN-Instanz jeweils ein Warteschlangenelement und delegiert die Verwaltung des Elementlebenszyklus an die Aufgaben des Warteschlangenbetriebs von Maestro BPMN.

Warteschlangenelement-Lebenszyklus mit Maestro BPMN

Wenn ein Maestro BPMN-Prozess durch ein Warteschlangenobjekt ausgelöst wird, durchläuft das Objekt folgende Status:

• Neu: Das Element wird der Warteschlange hinzugefügt und wartet auf die Verarbeitung
• In Bearbeitung: Der BPMN-Prozess von Maestro hat die Ausführung gestartet
• Erfolgreich oder Fehlgeschlagen: Der Maestro-BPMN-Prozess wurde abgeschlossen und der endgültige Status wird festgelegt

Maestro BPMN-Prozesse verwenden dedizierte Warteschlangenaktivitätsaufgaben, um Warteschlangenelemente zu verwalten:

• Delete queue items
• Bulk add queue items
• Transaktionsstatus festlegen (Erfolgreich/Fehlgeschlagen)
• Set transaction progress
• Transaktionselemente verschieben

Hinweis:

Wenn Sie vorhandene Warteschlangentrigger für RPA-Prozesse mit unterschiedlichen Batching-Regeln konfiguriert haben, bleiben diese Konfigurationen unverändert. Die Einschränkungen für den Warteschlangentrigger gelten nur, wenn es sich bei dem ausgelösten Prozess um einen BPMN-Prozess von Maestro handelt.

Ausführungsziel

Sie können mehrere Regeln konfigurieren, je nachdem, welche Prozesse ausgeführt werden.

Beschreibung
Konto	Der Prozess wird unter einem spezifischen Konto ausgeführt. Wenn Sie nur das Konto angeben, weist 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 mit der ausgewählten Maschinenvorlage verbunden sind. Wenn Sie nur die Maschinenvorlage angeben, weist 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.