- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- 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
- Konfigurieren von Automatisierungsfunktionen
- Solutions (Lösungen)
- Audit
- Einstellungen
- Registrierung
- Cloud Robots
- Übersicht über Cloud Robots
- Ausführen von Unattended-Automatisierungen mit Cloud Robot – VM
- Hochladen Ihres eigenen Image
- Wiederverwenden von benutzerdefinierten Maschinen-Images (für manuelle Pools)
- Zurücksetzen der Anmeldeinformationen für eine Maschine (für manuelle Pools)
- Überwachung
- Sicherheitsupdates
- Testversion anfordern
- Häufig gestellte Fragen
- Konfigurieren einer VPN für Cloud-Roboter
- Konfigurieren einer ExpressRoute-Verbindung
- Live-Streaming und Remotesteuerung
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Automation Suite-Roboter
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- MCP-Server
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Übersicht über Zeit- und Ereignistrigger für das Planen und Starten von Automatisierungsaufträgen in Orchestrator.
Mit Triggern können Sie Aufträge nach einem bestimmten Schema ausführen. Auf der Seite Trigger können Sie neue Trigger erstellen, vorhandene verwalten oder sofort einen Auftrag basierend auf einem vorhandenen Prozess starten.
Triggertypen
Basierend auf ihrem Scope:
- Zeittrigger – Weisen die Automatisierung an, in regelmäßigen Abständen zu starten.Weiterlesen …
- Warteschlangentrigger – Sie weisen die Automatisierung an, immer dann zu starten, wenn neue Elemente zu Ihren Warteschlangen hinzugefügt werden. Weiterlesen…
- Ereignistrigger – Sie weisen die Automatisierung an, jedes Mal zu starten, wenn ein bestimmtes Ereignis eintritt (Ereignistrigger).Weiterlesen…
- API-Trigger – sie ermöglichen es Ihnen, einen Auftrag in einer externen Anwendung zu starten.Weitere Informationen …
Basierend darauf, wo Sie sie erstellen:
- Außerhalb des Workflows – in Orchestrator erstellte getrennte Ereignistrigger.
- Innerhalb des Workflows – Erstellt zur Entwurfszeit von RPA-Entwicklern mithilfe von Triggeraktivitäten.
Hinweis:
- Es ist nur eine Triggeraktivität pro Workflow zulässig.
- Trigger, die zur Entwurfszeit in Studio erstellt wurden, sind die einzigen Triggertypen, die Orchestrator als Paketanforderungen validiert. Sie funktionieren nur, wenn sie zum Zeitpunkt der Prozesserstellung auf der Seite Paketanforderungen hinzugefügt werden.
Arbeitsfreie Tage
This enables you to define multiple lists of non-business days, per tenant, each with its own set of dates, on which you can configure your triggers to not run if needed. This means that, during public holidays, weekends, or any other day on which normal business activities are not being carried out, your long-run triggers can be configured such that they don't get launched.
You can define or upload such calendars on the Non-Working Days tab, in the Settings page. A BankHoliday calendar is created by default, to help you define your first non-working days easier. Once the non-business days defined in the selected calendar are over, the trigger is launched as usual.
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.
Ausführliche Informationen zur Verwaltung von Nicht-Arbeitstagen finden Sie hier.
Beachten Sie, dass das Hinzufügen und Entfernen von arbeitsfreien Tagen auf Mandantenebene geprüft wird. Ausführliche Informationen zur Überprüfung finden Sie hier.
Auftragsausführungseinstellungen
Auftragsausführungsregeln werden über eine Reihe von Einstellungen auf Mandantenebene konfiguriert, die im Abschnitt Ausführungseinstellungen auf der Registerkarte Allgemein beschrieben sind.