- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Verwalten großer Bereitstellungen
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Mandant
- Aktionen
- Ordnerkontext
- Automatisierungen
- Prozesse
- Jobs
- Auslöser
- Protokolle
- Überwachung
- Warteschlangen
- Assets
- Speicher-Buckets
- Test Suite - Orchestrator
- Aktionskataloge
- Profil
- Systemadministrator
- Identity Server
- Authentication
- Konfigurieren der Active Directory-Integration
- Konfigurieren von SSO: Google
- Konfigurieren von SSO: Azure Active Directory
- SmartCard-Authentifizierung
- Einrichtung einer automatischen Anmeldung für Benutzer einer Active-Directory-Gruppe
- Konfigurieren des SMTP-Servers
- Ändern des Windows-Authentifizierungsprotokolls
- Sonstige Konfigurationen
- Integrationen
- Klassische Roboter
- Fehlersuche und ‑behebung
Beste Praktiken für die Automatisierung (Automation Best Practices)
Der Orchestrator bietet eine Mehr-Mandanten-Option. Durch die Verwendung von mehr als einem Mandanten können Benutzer eine einzelne Instanz des Orchestrators auf mehrere Umgebungen verteilen, von denen jede ihre Robots, Prozesse, Protokolle und so weiter hat. Alle Mandanten teilen dieselbe Orchestrator-Datenbank.
Dies aktiviert die Isolierung der gewünschten Ressourcen vom Rest der Organisation. Auf Automatisierungsressourcen kann nur innerhalb dieses Mandanten zugegriffen werden.
Ordner ermöglichen es Ihnen, den Zugriff auf die Verwaltung der Automatisierung zu beschränken (d. h. wer Roboter erstellen kann, auf bestimmte Prozesse zugreifen kann usw.). Gleichzeitig gewähren Ordner den entsprechenden Abteilungen Ihrer Organisation Zugriff auf die Automatisierungen.
Verwenden Sie aussagekräftige Namen und Beschreibungen für jeden bereitgestellten Roboter. Jedes Mal, wenn ein neuer Roboter bereitgestellt wird, sollte der Typ des Roboters entsprechend gewählt werden.
- Für Unattended-Roboter werden die Windows-Anmeldedaten benötigt, um Unattended-Aufträge auf ihnen auszuführen.
- Attended Robots: Für Attended-Roboter werden keine Anmeldedaten benötigt, weil die Aufträge manuell von menschlichen Agenten direkt auf der Maschine ausgelöst werden, auf der die Roboter installiert sind.
Der nächste Schritt nach der Registrierung des Attended-Roboters beim Orchestrator ist die Überprüfung, ob der Status auf der Seite Roboter verfügbar ist.
Alte Versionen von Prozessen, die nicht mehr verwendet werden, sollten gelegentlich gelöscht werden. Versionen können einzeln durch ihre manuelle Auswahl und durch Klicken auf die Schaltfläche Löschen oder die Schaltfläche Inaktiv löschen gelöscht werden. Letztere löscht alle Prozessversionen, die von keinem Prozess verwendet werden.
Wenn der Roboter mehrere Prozesse ohne Unterbrechung ausführen muss, sollten alle Aufträge nacheinander ausgelöst werden, auch wenn der Robot beschäftigt ist. Diese Aufträge werden in eine Warteschlange mit dem Status „Ausstehend“ eingereiht; wenn der Roboter wieder verfügbar ist, löst der Orchestrator den nächsten Auftrag aus.
Es ist besser, einen Job anzuhalten, als ihn abzubrechen.
Um einen Auftrag anhalten zu können, wird die Aktivität Soll anhalten im Prozess-Workflow benötigt. Diese Aktivität gibt ein boolesches Ergebnis zurück, das angibt, dass die Schaltfläche Stopp angeklickt wurde.
Die Schaltfläche Abbrechen sendet einen Abbrechen-Befehl an den Roboter. Sie sollte nur im Bedarfsfall verwendet werden, weil der Roboter sich mitten in einer Aktion befinden könnte.
Neben der offensichtlichen Funktion können Trigger festlegen, dass der jeweilige Roboter rund um die Uhr läuft. Die Aufträge können einer nach dem anderen geplant werden (mit mindestens einer Minute Abstand). Ist der Roboter nicht verfügbar, wenn ein Prozess starten sollte, wird der Prozess zur Auftragswarteschlange hinzugefügt und ausgeführt, sobald ein Roboter verfügbar wird.
Verwenden Sie einen bedeutungsvollen Namen und eine Beschreibung für jede erstellte Warteschlange.
Am Ende des Lebenszyklus jeder Transaktion muss jedes Ergebnis der Objektverarbeitung eingestellt werden. Ansonsten werden Transaktionen, die den Status Neu haben, automatisch nach 24 Stunden auf Aufgegeben geändert.
Mit der Aktivität Set Transaction Status kann der Status eines Warteschlangenobjekts auf Erfolgreich oder Fehlgeschlagen festgelegt werden. Denken Sie daran, dass nur die fehlgeschlagenen Elemente mit Anwendungsfehlertyp erneut ausprobiert werden, sofern sie konfiguriert sind.
Wenn dieselben Roboter zwei oder mehr Arten von Elementen verarbeiten sollen, gibt es mindestens zwei Möglichkeiten, sie mithilfe von Warteschlangen zu verwalten:
- Erstellen Sie mehrere Warteschlangen, einen für jeden Objekttyp, und erstellen Sie einen Prozess, der alle Warteschlangen in einer Sequence prüft, und der mit neuen Objekten sollte den spezifischen Prozess auslösen.
- Erstellen Sie eine einzelne Warteschlange für alle Objekte und für jedes Objekt ein Argument „Typ“ oder „Prozess“. Der Roboter sollte, wenn er diesen Parameter kennt, entscheiden, welcher Prozess aufgerufen werden soll.
Mit der Aktivität Add Transaction Item stehen Ihnen alle Transaktionsfunktionalitäten ohne Verwendung einer Warteschlange zur Verfügung (wobei trotzdem eine zuvor erstellt werden sollte). Diese Aktivität fügt ein Objekt zur Warteschlange hinzu und setzt den Status auf In Bearbeitung. Fangen Sie direkt damit an, das Objekt zu verwenden, und vergessen Sie nicht die, Aktivität Set Transaction Status am Ende Ihres Prozesses zu verwenden.