Orchestrator
2022.4
False
Bannerhintergrundbild
Orchestrator-Anleitung
Letzte Aktualisierung 19. April 2024

Über Trigger

Trigger ermöglichen Ihnen die vorab geplante Ausführung von Aufträgen in regelmäßigen Abständen (Zeit-Trigger) oder immer dann, wenn Ihren Warteschlangen neue Elemente hinzugefügt werden (Warteschlangen-Trigger). Auf der Seite Trigger können Sie neue Trigger erstellen, vorhandene verwalten und sofort einen Auftrag für alle vorhandenen Trigger starten.

Wichtig:

Trigger-Zeitzonen:

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 anderen Zeitzonen festlegen.

Zeittrigger werden gemäß der auf der Triggerebene definierten Zeitzone gestartet. Warteschlangentrigger werden basierend auf der Verarbeitung von Warteschlangenelementen gestartet.

Sowohl Zeit- als auch Warteschlangen-Trigger werden basierend auf der Trigger-Zeitzone deaktiviert.

Wichtig:

Trigger-Deaktivierung:

Standardmäßig wird ein Trigger nach 10 fehlgeschlagenen Starts automatisch deaktiviert, wenn er am letzten Tag nicht erfolgreich gestartet wurde.

Dieser Wert kann mit dem Parameter Triggers.DisableWhenFailedCount angepasst werden.

Zeit-Trigger

Ermöglicht es Ihnen, eine wiederkehrende Uhrzeit für den Start eines Auftrags zu planen.

Nachdem Sie einen Zeittrigger für einen Prozess hinzugefügt haben, können Sie Folgendes erwarten:

  1. Der Trigger erstellt einen Auftrag zum geplanten Zeitpunkt mit den Zuweisungs-, Konto- und Maschinenoptionen Ihrer Wahl. Dies entspricht nicht der tatsächlichen Ausführung des Auftrags.
  2. Der in Schritt 1 erstellte Auftrag wird ausgeführt, sobald ein Roboter verfügbar wird. Wenn der Trigger bereits einen ausstehenden Auftrag hat, werden standardmäßig keine neuen Aufträge erstellt, bis der erste ausgeführt wird.
    • Die Anzahl der ausstehenden Aufträge, die der Trigger erstellen kann, wird durch den Parameter Triggers.JobsCountStrategy gesteuert.

Eingabewerte für Prozesse, die Eingabe- und Ausgabeparameter unterstützen, können auch auf dieser Ebene verwaltet werden.

Ausführungsziel

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

 

Beschreibung

Dynamische Zuteilung

Dynamisch zuordnen

Legen Sie fest, wie oft ein Prozess für den jeweiligen Trigger ausgeführt werden soll. Mit dieser Option können Sie Ihre Ressourcen optimal nutzen. Sobald ein Roboter verfügbar wird, führt er den angegebenen Prozess dem angegebenen Trigger entsprechend aus.

 

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

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: Zum Konfigurieren der Zuordnung können nur Unattended-Runtimes verwendet werden. Stellen Sie sicher, dass die erforderlichen Runtime-Lizenzen zum Ausführen des Auftrags der zugeordneten Maschinenvorlage zugewiesen sind.

Gültige Konto-Maschinen-Zuordnungen auswählen

Der Prozess kann auf mehreren spezifischen Konto-Maschinen-Paaren ausgeführt werden.

Hinweis:
  • Bei der Auswahl eines Hostnamens, der nicht aktiv ist (d. h. mit Status Reagiert nicht oder Getrennt) wird eine Warnung angezeigt.

  • Konten, die Teil von Zuordnungen sind, die in Triggern verwendet werden, können nicht gelöscht oder aus dem Ordner aufgehoben werden, in dem sich der Trigger befindet. Stellen Sie sicher, dass das Konto nicht als Ausführungsziel in einem Trigger festgelegt ist, damit Sie sie löschen können.

Hinweis: Eine Warnung wird angezeigt, wenn ein Hostname ausgewählt wird, der nicht aktiv ist (d. h. mit dem Status Reagiert nicht oder Getrennt). Aufträge, die von der inaktiven Sitzung ausgeführt werden sollen, bleiben im Status Ausstehend, bis die entsprechende Verbindung zum Orchestrator hergestellt wird.
  • Um Ihre Auswahl des inaktiven Hostnamens zu bestätigen, klicken Sie auf Bestätigen.

  • Um zurückzugehen und einen anderen Hostnamen auszuwählen, klicken Sie auf Abbrechen.

Wenn Sie den gleichen Trigger mit der gleichen Konto-Maschine-Zuordnung, aber der zusätzlichen Hostnamenauswahl konfigurieren, wird die Anzahl der auszuführenden Aufträge verdoppelt.
  • Angenommen Sie haben einen Trigger T1 mit dem Konto K1 konfiguriert, das der Maschinenvorlage MV1 zugeordnet ist. In dieser Konfiguration werden zehn Aufträge in die Warteschlange eingereiht.

    Später konfigurieren Sie den gleichen Trigger T1 mit dem Konto K1, das der Maschinenvorlage MV1 zugeordnet ist, aber jetzt wählen Sie außerdem einen Hostnamen H1 aus. Die gleichen zehn Aufträge werden für diesen Fall erneut in die Warteschlange eingereiht, da der Orchestrator die Konfiguration als neu interpretiert.

Hinweis: Wenn die Verbindung zur SQL-Datenbank unterbrochen werden sollte, werden die Trigger, die zu diesem Zeitpunkt ausgelöst werden sollten, falsch ausgelöst, und es wird eine Warnung der Stufe Error generiert.

Szenarien mit Warteschlangenjobs

  1. Wenn Sie mehrere Trigger für den gleichen Roboter festlegen und sich ihre Ausführungszeit mindestens einmal überschneidet, werden die Aufträge in einem ausstehenden Status in die Warteschlange eingereiht. Der Roboter führt die in die Warteschlange gesetzten Aufträge in chronologischer Reihenfolge aus.
  2. Wenn der gleiche Prozess auf dem gleichen Roboter mehrmals geplant ist und sich die Ausführungszeiten überschneiden, wird nur ein einziger Prozess in einem ausstehenden Status in die Warteschlange gesetzt. Wenn z. B. Prozess A auf Roboter X um 11:20, 11:21 und 11:25 ausgeführt werden soll, ist das Verhalten wie folgt:

    • um 11:20 wird der erste Prozess ausgeführt.
    • Wenn die erste Ausführung vor dem zweiten Trigger abgeschlossen wird, geschieht Folgendes:

      • Der zweite Trigger wird verarbeitet.

        • Wenn diese Ausführung vor dem 11:25-Trigger abgeschlossen wird, wird auch letztere ausgeführt.
        • Wenn die Ausführung des 11:21-Triggers nicht vor dem 11:25-Trigger abgeschlossen wird, wird der letztere in einem ausstehenden Status zu einer Warteschlange hinzugefügt.
    • Wenn die erste Ausführung NICHT vor dem zweiten Trigger abgeschlossen wird:
      • Der 11:21-Trigger wird in einem ausstehenden Status in eine Warteschlange gesetzt.

        • Wenn die Ausführung des 11:21-Triggers vor dem 11:25-Trigger abgeschlossen wird, wird auch der letztere ausgeführt.
        • Wenn die Ausführung des 11:21-Triggers startet, aber nicht vor dem 11:25-Trigger abgeschossen wird, wird der letzte Trigger in einem ausstehenden Status in eine Warteschlange gesetzt.
        • Wenn der 11:21-Trigger noch aussteht, während der 11:25-Trigger gestartet werden sollte, wird der letztere nicht mehr ausgeführt oder einer Warteschlange hinzugefügt, und die folgende Meldung wird angezeigt: Die Roboter haben bereits anstehende Aufträge für diesen Prozess.
  3. Wenn Sie einen Prozess mehrmals auf verfügbaren Robotern ausführen möchten, haben Sie die Möglichkeit, genau dies zu tun, indem Sie die Option Dynamisch zuweisen auf der Registerkarte Ausführungsziel verwenden. Die Aufträge werden in der entsprechenden Umgebung im ausstehenden Status in die Warteschlange eingereiht, und jedes Mal, wenn ein Roboter verfügbar wird, wird der nächste Auftrag in der Reihe ausgeführt. Dadurch ist niemals ein Roboter verfügbar, solange Aufträge ausstehen.

    Nehmen wir an, Sie möchten einen Prozess sieben Mal ausführen. In gleichen Moment, in dem Ihr Trigger ausgelöst wird, werden sieben anstehende Jobs zur Workload der Umgebung hinzugefügt, ohne dass sie bestimmten Robotern zugeordnet werden. Verschiedene Szenarien sind möglich:

    • Zum Zeitpunkt des Auslösens sind mindestens 7 Roboter verfügbar - einem Roboter wird ein Job zugeordnet, sodass alle Jobs in einem Durchgang ausgeführt werden.
    • Zum Zeitpunkt des Auslösens sind weniger als 7 Roboter verfügbar, sagen wir 4. Jedem dieser 4 Roboter wird ein Job zugeordnet. Wird ein neuer Roboter verfügbar, übernimmt dieser einen weiteren Job der verbleibenden drei. Dies geschieht für jeden verfügbaren Roboter, bis keine Jobs mehr übrig sind.
  4. Wenn zwei oder mehr Trigger denselben Prozess mit einer unterschiedlichen Anzahl von Wiederholungen ausführen, wird beim nächsten Trigger die maximale Anzahl von Aufträgen zwischen ihnen zur Umgebungs-Workload hinzugefügt. sie kumulieren nicht. Stellen Sie sich die folgende Situation vor: Trigger A führt einen Prozess 13 Mal aus und Trigger B führt ihn 20 Mal aus. Es können folgende Szenarien auftreten:

    • A und B werden geichzeitig ausgelöst - 20 Jobs (das Maximum zwischen 13 und 20) werden in der Umgebungs-Workload in die Warteschlange gestellt.
    • B wird zuerst ausgelöst - 20 Jobs werden in die Warteschlange gestellt.

      • Wurden zwischen der Auslösezeit B und der Auslösezeit A 7 oder mehr Jobs ausgeführt, etwa 9 (11 verbleibende anstehende Jobs, dann werden 13 Jobs (die maximale Anzahl zwischen 11 und 13) in der Umgebungs-Workload in die Warteschlange gestellt.
      • Wurden zwischen der Auslösezeit B und der Auslösezeit A weniger als 7 Jobs ausgeführt, etwa 5 (15 verbleibende anstehende Jobs, dann werden keine weiteren Jobs in die Warteschlange gestellt, da bereits mehr als 13 Jobs anstehen. Überdies wird folgende Meldung angezeigt. Die Roboter haben bereits anstehende Jobs für diesen Prozess.
    • A wird zuerst ausgelöst - 13 Jobs werden in die Warteschlange gestellt.

      • Immer, wenn B während der Ausführung von A ausgelöst wird, werden der Umgebung je nachdem, wie viele Jobs von A in Bearbeitung sind oder ausgeführt wurden, bis zu 20 Jobs hinzugefügt. Sagen wir, 6 Jobs wurden ausgeführt. Wird B ausgelöst, werden 14 Jobs hinzugefügt, sodass das Maximum von 20 erreicht ist.
  5. Wenn ein Trigger den gleichen Prozess mehrmals ausführt, werden die entsprechenden Aufträge in der Warteschlange auf die Anzahl der Ausführungen beschränkt, die Sie beim Definieren des Triggers auf der Registerkarte Ausführungsziel angegeben haben. Sie kumulieren nicht mit jedem Start des Triggers.

    Angenommen Sie möchten alle 30 Minuten den gleichen Prozess 10 Mal ausführen. Beim ersten Start Ihres Triggers werden 10 Aufträge in die Warteschlange eingereiht. Wenn zwischen den Auslösungen weniger als 10 Aufträge ausgeführt werden (z. B. 4), werden zum Zeitpunkt der nächsten Auslösung nur 6 neue Aufträge in die Warteschlange eingereiht, da die Anzahl der ausstehenden Aufträge für diesen Prozess maximal 10 betragen kann.

Warteschlangen-Trigger

Kann sofort einen Prozess bei der Trigger-Erstellung oder immer dann starten, 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. 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.
    Hinweis: Beachten Sie, dass Sie den Parameter Queue.ProcessActivationSchedule verwenden können, um das standardmäßige 30-Minuten-Prüfintervall anzupassen.

Beispiel

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.

  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 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 ergibt einen Rest von 45 zu verarbeitenden Elementen (60-15). Mit 3 Aufträgen, die jeweils 1 Element pro Sekunde verarbeiten, bedeutet dies 15 Sekunden für den Rest, der verarbeitet werden soll.

Insgesamt 35 Sekunden.

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.

Job Count Strategien

Mit dem Parameter Triggers.JobsCountStrategy können Sie die Strategie zum Starten von Aufträgen über Trigger auswählen. Die folgenden Optionen sind verfügbar:

  • PerProcess ‑ Ein Trigger startet die erforderliche Anzahl von Aufträgen unter Berücksichtigung jeglicher ausstehender Aufträge für den angegebenen Prozess. Beispielsweise starten zwei Trigger, die für denselben Prozess definiert sind, 3 bzw. 5 Aufträge. Falls der erste Trigger 3 Aufträge zu einem bestimmten Zeitpunkt startet, wenn der zweite Trigger ausgelöst wird, werden 2 Aufträge gestartet, um die 5 erforderlichen Aufträge zu erreichen.
  • PerTrigger ‑ Ein Trigger startet die erforderliche Anzahl von Aufträgen unter Berücksichtigung vorhandener Aufträge, die zuvor von demselben Trigger gestartet wurden. Beispielsweise wird ein Trigger definiert, um 9 Aufträge zu einem bestimmten Zeitpunkt zu starten. Wenn 2 Aufträge bis zum erneuten Auslösen dieses Triggers erfolgreich abgeschlossen wurden, startet der Orchestrator weitere 2 Aufträge, um die erforderlichen 9 Aufträge zu erreichen.
  • NoLimit ‑ Der Trigger startet die erforderliche Anzahl von Aufträgen unabhängig von vorhandenen, ausstehenden Aufträgen. Beispielsweise wird ein Trigger definiert, um 5 Aufträge zu einem bestimmten Zeitpunkt zu starten. Beim zweiten Auslösen des Triggers werden weitere 5 Aufträge gestartet.

Nicht-Arbeitstage

Dadurch können Sie mehrere Listen von arbeitsfreien Tagen pro Mandant mit jeweils eigenem Datumssatz definieren, für den Sie Ihre Trigger bei Bedarf so konfigurieren können, dass sie nicht ausgeführt werden. Das bedeutet, dass Ihre langfristigen Trigger für Feiertage, Wochenenden oder andere Tage ohne normale Geschäftsaktivitäten so konfiguriert werden können, dass sie nicht gestartet werden. Sie können solche Kalender auf der Registerkarte Arbeitsfreie Tage auf der Seite Einstellungen definieren oder hochladen. Standardmäßig wird ein BankHoliday-Kalender erstellt, damit Sie Ihre ersten arbeitsfreien Tage einfacher definieren können. Sobald die im ausgewählten Kalender definierten arbeitsfreien Tage vorbei sind, wird der Trigger wie gewohnt ausgelöst.

Um eine dieser Einschränkungen auf Ihre Trigger anzuwenden, müssen Sie den gewünschten Kalender aus dem Dropdown-Menü Einschränkungen für Nicht-Arbeitstage auswählen, wenn Sie einen neuen Trigger erstellen oder einen vorhandenen bearbeiten. Sie können nur einen einzigen Kalender für einen Trigger auswählen. Beachten Sie, dass sich das Bearbeiten eines Kalenders auf der Registerkarte Arbeitsfreie Tage auch auf Trigger auswirkt, bei denen dieser Kalender bereits im Dropdown-Menü Einschränkungen für Nicht-Arbeitstage ausgewählt ist.

Hinweis: Wenn es bei Ihnen arbeitsfreie Tage gibt, muss die Trigger-Zeitzone mit der Zeitzone des Mandanten übereinstimmen (Mandant > Einstellungen > Allgemein), da Kalendereinschränkungen nicht in verschiedenen Zeitzonen angewendet werden können. Ein Mandant ohne explizit definierte Zeitzone erbt sie vom Host.

Beachten Sie, dass das Hinzufügen und Entfernen von arbeitsfreien Tagen auf Mandantenebene geprüft wird.

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
UiPath Logo weiß
Vertrauen und Sicherheit
© 2005-2024 UiPath. All rights reserved.