Windows-Sitzungen

Der Roboter führt Automatisierungen in einer Windows-Sitzung durch und startet eine Konsole oder eine RDP-Sitzung basierend auf der Einstellung LoginToConsole in Orchestrator. Während alle Roboter eine Verbindung zu beiden Sitzungstypen herstellen können, verwenden High-Density-Roboter nur RDP-Sitzungen.

Wie es funktioniert

Eine Windows-Sitzung wird immer auf der physischen oder virtuellen Maschine erstellt, auf der der Roboter installiert ist. Orchestrator erstellt keine Windows-Sitzungen direkt. Stattdessen läuft beim Start eines Auftrags in Orchestrator folgende Sequenz ab:

1. Orchestrator sendet eine Nachricht mit den Details des Prozesses an den UiPath-Roboterdienst auf der Maschine.

2. Der UiPath-Roboterdienst fordert die Erstellung einer oder den Zugriff auf eine vorhandene Windows-Sitzung auf der Maschine an.

3. Der Roboterdienst startet den Roboter-Executor in der zuvor erstellten Sitzung.

4. Der Roboter-Executor startet dann die Ausführung der Automatisierung in dieser Sitzung.

Der Roboterdienst verbindet den Befehl zur Ausführung einer Automatisierung mit der tatsächlichen Ausführung.

Ohne ausstehende Aufträge geht der Roboterdienst in einen Leerlaufstatus und erfordert keine voll aktive Windows-Sitzung für die Ausführung der Automatisierung.Die zugrunde liegende Dienstsitzung bleibt für die ständige Kommunikation mit Orchestrator über WebSockets (SignalR) aktiv. Dies stellt die sofortige Ausführung bei Empfang eines Befehls sicher.

Konsolensitzung

Dies ist die Standardausführungsumgebung.

In einer Konsolensitzung führt der Roboter Aufträge aus, während ein Benutzer an der Hosting-Maschine angemeldet ist. Dieser Sitzungstyp wird im Allgemeinen empfohlen für:

• Automatisierungen verwenden die Display-Auflösung des Hostcomputers.Sie können zwar eine benutzerdefinierte Auflösung angeben, sie ist aber auf die vom Hostcomputer unterstützten Auflösungen beschränkt.

• Eine sequenzielle Automatisierung wird ausgeführt, da eine neue Ausführung beginnt, sobald die vorherige beendet ist und der ausführende Roboter sich von der aktiven Sitzung trennt.

Wichtig:

Es kann nur eine aktive Konsolensitzung gleichzeitig geben.

RDP-Sitzung

In einer Remote Desktop Protocol (RDP)-Sitzung erstellt der Roboter eine virtuelle Remote-Desktop-Umgebung auf der ausgeführten Maschine oder verbindet sich mit dieser.Dieser Typ wird im Allgemeinen empfohlen für:

• Automatisierungen, die eine benutzerdefinierte Bildschirmauflösung erfordern, indem die Breite, Höhe und Tiefe der Auflösung auf der Registerkarte Robotereinstellungen in Orchestrator festgelegt werden.

• Windows-Workstations führen jeweils eine Automatisierung aus, da eine neue Ausführung beginnt, sobald die vorherige beendet ist und der ausführende Roboter sich von der aktiven Sitzung trennt.

• Windows Server-Maschinen zum gleichzeitigen Ausführen mehrerer Automatisierungen:

  • für denselben Benutzer in seinen verschiedenen RDP-Sitzungen, mit der Einschränkung, dass Prozesse nicht auf Hardwareereignisse wie UIAutomation-Aktivitäten angewiesen sein sollten.

  • für mehrere Benutzer, jeder in seiner RDP-Sitzung

• Ausführungen von Hochdichte-Robotern.

Wichtig:

Wenn ein Auftrag von Orchestrator gestartet wird und bereits eine RDP-Sitzung aktiv ist, wird der Prozess in dieser Sitzung ausgeführt.

Die Option LoginToConsole in Orchestrator

Wenn Sie ein Roboterkonto in Orchestrator definieren oder bearbeiten, können Sie den Sitzungstyp wählen, den Ihre Roboter zum Ausführen von Automatisierungen verwenden. Verwenden Sie dazu die Option Login To Console.

Auf der Seite Mandant > Zugriff verwalten > Roboterkonten > Roboter-Einstellungne in Orchestrator ist die Option Anmeldung an der Konsole standardmäßig deaktiviert.Der Roboter führt jedoch standardmäßig Aufgaben in einer Konsolensitzung aus.

Um die Konsolensitzung zu aktivieren, aktivieren Sie die Option Anmelden an der Konsole und wählen Sie Ja.Wenn ein Auftrag während einer aktiven RDP-Sitzung vom Orchestrator aus gestartet wird, wird die RDP-Sitzung automatisch beendet.

Zur Aktivierung der RDP-Sitzung aktivieren Sie die Option Anmeldung an der Konsole und wählen Sie Nein. Wenn ein Auftrag von Orchestrator aus gestartet wird und eine RDP-Sitzung bereits aktiv ist, führt der Roboter den Auftrag innerhalb der aktiven RDP-Sitzung aus.

Prozessausführung über RDP

Folgende Abbildung fasst die Prozessausführung über RDP zusammen:

1. Der Roboterdienst erhält den Befehl zum Starten einer Ausführung von Orchestrator über das HTTPS-Protokoll namens WebSockets (SignalR).

2. Der Roboterdienst erstellt dann mithilfe von RDP eine Windows-Sitzung auf der Maschine.Diese RDP-Sitzung wird für den dem Roboter zugewiesenen Benutzer erstellt.

3. Sobald die RDP-Sitzung erstellt wurde, generiert der Roboterdienst einen Roboter-Executor innerhalb dieser Sitzung.Der UiPath-Roboterdienst und der Roboter-Executor kommunizieren über benannte Pipes miteinander.Mithilfe dieser Methode weiß der Roboter-Executor genau, welche Aufgaben ausgeführt werden müssen.

4. Die Aufgaben werden innerhalb der generierten Windows-Sitzung ausgeführt.

Hinweis:

• Der Roboterdienst verwendet RDP ausschließlich, um eine Windows-Sitzung auf der Maschine zu starten, auf der der Roboter installiert ist.Er verwendet RDP nicht, um Orchestrator mit der Maschine zu verbinden, auf der der Prozess ausgeführt wird, und um mit anderen Komponenten außerhalb der Maschine zu kommunizieren.

• Um unbeaufsichtigte Automatisierungen in Umgebungen auszuführen, in denen RDP-Sitzungen eine Kerberos-Authentifizierung erfordern, müssen Sie den DNS-Hostnamen für den Wert localhost verwenden. Fügen Sie dazu folgende Umgebungsvariable zu Ihrer Maschine hinzu:

  UIPATH_DNS_MACHINENAME=True

• Ausgeführte Automatisierungen in Umgebungen, die TCP durchsetzen, beeinflussen Ihre RDP-Sitzungen nicht.

Fehlerbehebung bei Windows-Sitzungen

Der Roboterdienst erfasst eine Reihe von Bildschirmfotos von Sitzungen, während Sie Ihre Windows-Sitzung einrichten, und löscht sie, sobald die Sitzung erfolgreich erstellt wurde.Wenn die Einrichtung der Sitzung fehlschlägt, werden die Bildschirmfotos zur zukünftigen Fehlerbehebung im %ProgramData%\UiPath\SessionScreenshotsVerzeichnis gespeichert.