- 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
- Benachrichtigungen
- 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
- 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
- Agent-Gateway
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Aktivieren Sie Live-Streaming und Remotesteuerung für Roboter mit RealVNC, verfügbar für Roboterversionen 2023.12 und höher.
Dies gilt für Roboterversionen 2023.12+.
Die Livestreaming- und Remotesteuerungsfunktionen sind verfügbar für:
- Windows-Roboterversionen 2023.12+
- Automation Cloud Robots – serverlos
- Automation Cloud Robot – VM
- Linux-Roboter
Hinweis:
Diese Funktion kann nicht mit Windows-Hintergrundaufträgen verwendet werden.
Voraussetzung für Windows-Roboter 2023.12 und neuer
Aktivieren Sie Signal R. Weitere Informationen finden Sie im Abschnitt SignalR-Mandanteneinstellung.
Netzwerkanforderungen
Die Mindest-Netzwerkanforderungen für ein reibungsloses Funktionieren einer Livestreaming- und Remotesteuerungssitzung können aufgrund einer Reihe von Faktoren erheblich variieren:
- Die Bildschirmauflösung des Roboters
- Die durch Ihre Automatisierung bedingten Änderungen – je dynamischer die Änderungen bei Bildern und Text sind, desto höher ist das Datenverkehrsvolumen
- Die Latenz zwischen Ihrer Maschine und der Automation Cloud-Region
- Die Latenz zwischen Ihrem Roboter und der Automation Cloud-Region
Angesichts dessen empfehlen wir eine Netzwerkbandbreite von 3 MB/s bei einer Bildschirmauflösung von 1920 x 1080.
Sicherheitsüberlegungen
Die Livestreaming-Verbindung zwischen dem Client und der Zielmaschine wird durch TLS über den VNC-Proxy geführt, was bedeutet, dass der Server gesichert ist. Darüber hinaus wird jedes Mal, wenn eine Livestreaming-Sitzung gestartet wird, ein eindeutiges JWT-Token generiert und zur Authentifizierung der Anforderung verwendet. Die einzige Instanz von ungesichertem Datenverkehr befindet sich auf der Robotermaschine für die localhost-Verbindung.
Auf der Roboterseite wird für jeden Auftrag ein eindeutiges Kennwort generiert und für den VNC-Server festgelegt. Der Server wird nur während der Livestreaming-Sitzung ausgeführt. Wenn der Benutzer die Sitzung trennt, wird auch der VNC-Server geschlossen.
Netzwerkflow
- Wenn Sie über die Orchestrator-Benutzeroberfläche den Start des Live-Streamings anfordern, sendet der Orchestrator einen Befehl an den Roboter, um eine neue Remotesteuerungssitzung zu initiieren.
- Der Roboter startet einen VNC-Server, der einen dynamischen Port überwacht. Der VNC-Server wird nur als Loopback gestartet, wodurch Remoteverbindungen deaktiviert werden. Der Orchestrator-Befehl enthält auch ein Kennwort für die VNC-Authentifizierung, das vom VNC-Server und dem Browser-Client gemeinsam genutzt wird.
- Der Roboter startet daraufhin:
- ein weiteres Programm, das sich mit dem lokalen VNC-Server auf einem dynamischen Port verbindet
- ein UiPath Livestreaming-Proxy
Das Programm leitet den gesamten TCP-Datenverkehr an den Livestreaming-Proxy weiter, indem es in das WebSocket Secure-Protokoll (wss) konvertiert wird. 4. Der Orchestrator VNC-Client stellt eine Verbindung mit demselben Livestreaming-Proxy her, dessen Aufgabe darin besteht, die beiden Websockets zu koppeln: einen vom VNC-Client im Browser und den anderen vom Roboter. Anschließend wird ein Tunnel zwischen den beiden Websockets erstellt und jeglicher Datenverkehr von einem Websocket zum anderen weitergeleitet.
Der VNC-Client verwendet zwei Ports: 443 und 5900.
Port 443 muss geöffnet sein, um eine Verbindung mit einem zusätzlichen Onlinedienst herzustellen.
Port 5900 wird lokal auf derselben Maschine ausgeführt, um den Datenverkehr zwischen zwei Anwendungen zu tunneln.
Damit die Kommunikation funktioniert, müssen diese Ports bidirektional geöffnet werden, um sowohl eingehenden als auch ausgehenden Datenverkehr zuzulassen.
Abbildung 1. Netzwerkflussdiagramm