- 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
- SmartCard-Authentifizierung
- Konfigurieren von Automatisierungsfunktionen
- Audit
- Einstellungen – Mandantenebene
- Ressourcenkatalogdienst
- Ordnerkontext
- Automatisierungen
- Prozesse
- Jobs
- Auslöser
- Protokolle
- Überwachung
- Warteschlangen
- Assets
- Speicher-Buckets
- Test Suite - Orchestrator
- Sonstige Konfigurationen
- Integrationen
- Hostverwaltung
- Über die Hostebene
- Verwalten von Systemadministratoren
- Verwalten von Mandanten
- Konfigurieren von System-E-Mail-Benachrichtigungen
- Prüfungsprotokolle für das Hostportal
- Wartungsmodus
- Organisationsadministration
- Fehlersuche und ‑behebung
Zeit-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.
Zeit-Trigger werden entsprechend der auf Triggerebene definierten Zeitzone gestartet.
Zeittrigger werden basierend auf der Triggerzeitzone deaktiviert.
Zeit-Trigger, die für die wiederkehrende Ausführung konfiguriert sind, berücksichtigen die Sekunde ihrer Erstellung. So sieht die Änderung in CRON-Ausdrücken aus:
-
Für einen Zeittrigger, der um 12:23:34 Uhr mit dem CRON-Ausdruck 0 * * ? * * (d. h. Ausführung jede Minute) erstellt wird, ist die nächste Ausführungszeit um 12:24:34 Uhr.
-
Für einen Zeittrigger, der um 12:23:34 Uhr mit dem CRON-Ausdruck 1 * * ? * * (d. h. Ausführung 1 Sekunde nach jeder Minute) erstellt wird, ist die nächste Ausführungszeit um 12:24:01 Uhr.
Standardmäßig wird ein Trigger automatisch deaktiviert, wenn er 10 Fehlstarts in Folge hat und in den letzten 24 Stunden nicht erfolgreich gestartet wurde. Wenn jedoch eine dieser Bedingungen nicht erfüllt ist, also wenn der Trigger mindestens einmal am Tag erfolgreich ausgelöst wurde oder noch keine 10 Fehlstarts in Folge erreicht wurden, bleibt er aktiv.
Dieser Wert kann mit dem Parameter Triggers.DisableWhenFailedCount angepasst werden.
Empfehlungen
-
Wenn ein Trigger deaktiviert ist, überprüfen Sie die Prüfungsprotokolle auf Gründe für Auftragsfehler.
-
Wenn Sie Aufträge mit langer Ausführungszeit haben, versuchen Sie, den Trigger so zu konfigurieren, dass mehr ausstehende Aufträge möglich sind, oder den Trigger so zu planen, dass die Aufträge seltener ausgeführt werden.
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. Weitere Informationen zu Konto-Maschinen-Zuordnungen. Hinweis:
|
-
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.
-
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.
- 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.
-
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.
-
-
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.
-
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 löst zuerst aus – 20 Aufträge 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.
- Wird B während der Ausführung von A ausgelöst, wird der Umgebung eine Anzahl von bis zu 20 Aufträgen hinzugefügt, je nachdem, wie viele Aufträge von A in Bearbeitung sind oder ausgeführt wurden. Beispiel: Sechs Aufträge sind ausgeführt worden. Wenn B auslöst, werden 13 Aufträge hinzugefügt, so dass das Maximum von 20 erreicht ist.
-
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.
Zeittrigger können auch von RPA-Entwicklern zur Entwurfszeit in Studio erstellt werden, indem die Aktivität Time Trigger des UiPath.Core.Activities-Pakets verwendet wird.
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: Ich möchte jeden Arbeitstag um 18:00 Uhr alle neuen Excel-Dateien automatisch auf ein Cloud-Laufwerk hochladen.Der Unterschied besteht darin, dass der Zeittrigger die Automatisierung anweist, innerhalb des Workflows zu starten, im Gegensatz zu Orchestrator-Zeittriggern, die die Automatisierung anweisen, außerhalb des Workflows zu starten.