OpCon RPA 1.2.0: Automatisierung ohne angemeldeten Windows-Benutzer
Web-Makros und Dokumentaufgaben laufen erstmals ohne interaktive Sitzung; für Desktop-Roboter startet der Agent bei Bedarf eine eigene RDP-Sitzung.
OpCon RPA 1.2.0 löst ein konkretes Problem unbeaufsichtigter Windows-Automatisierung: Web-Makros und Scan-Document-Aufgaben benötigen keinen dauerhaft angemeldeten Benutzer mehr. Der RPA Agent startet den dafür vorgesehenen Hostprozess bei Bedarf selbst. Die Aufgaben können dadurch auch unmittelbar nach einem Neustart beginnen, ohne dass eine interaktive Windows-Sitzung oder ein verbundener RPA Client bereitstehen muss.
Für desktopbasierte Robot Tasks gilt diese Neuerung nicht unverändert. Sie brauchen weiterhin eine interaktive Sitzung, weil ihre aufgezeichneten Maus- und Tastaturaktionen mit einer sichtbaren Desktopoberfläche arbeiten. Version 1.2.0 kann die benötigte Sitzung jedoch über eine RDP-Anmeldung bereitstellen und nach der Ausführung wieder schließen. Das Release führt damit zwei klar getrennte Ausführungsmodelle ein: sitzungslose Hosts für Web- und Dokumentaufgaben sowie automatisch erzeugte Sitzungen für Desktopaktionen.
Web-Makros starten jetzt auch auf einem frisch gebooteten Host
Bislang hing die Ausführung stärker vom Zustand des RPA-Rechners ab: Auf dem Host musste eine geeignete interaktive Umgebung vorhanden sein. Gerade nach einem Neustart konnte das bedeuten, dass ein Konto angemeldet bleiben oder zunächst manuell angemeldet werden musste. Die Ankündigung zu OpCon RPA 1.2.0 nennt dieses dauerhaft angemeldete Konto ausdrücklich als häufig vorgebrachten Kritikpunkt von Kunden.
In Version 1.2.0 startet der Agent für Web Macro und Scan Document einen Hostprozess erst dann, wenn eine entsprechende Aufgabe ansteht. Dieser Prozess ist nicht an eine interaktive Windows-Sitzung gebunden. Auch der RPA Client muss nicht verbunden sein. Ein geplanter Weblauf kann deshalb nach einem nächtlichen Neustart beginnen, ohne dass zuvor jemand den Sperrbildschirm überwinden oder eine Benutzersitzung offenhalten muss.
Ein passendes Beispiel ist das Übertragen von Daten über ein Webformular. Die Anbieterunterlagen führen Webformular-Automatisierung und Dateiübertragungen über Websites als Einsatzmöglichkeiten auf. Liegt eine solche Aufgabe als Web-Makro vor, kann sie nun vom Agenten auf dem unbeaufsichtigten Host gestartet werden. Für das Einlesen eines Dokuments gilt dieselbe Grundidee, wenn die Aufgabe als Scan Document angelegt ist: Der Agent stellt den ausführenden Prozess bereit, nicht ein interaktiv angemeldeter Benutzer.
Ein Ausführungskontext bestimmt das Windows-Konto
Web Macro und Scan Document können mit Version 1.2.0 erstmals ein Ausführungskontext erhalten. Für diese beiden Aufgabentypen besteht es aus Anmeldedaten. Dadurch lässt sich festlegen, unter welchem Windows-Konto eine Aufgabe läuft, anstatt die Identität von der gerade am Rechner vorhandenen Sitzung abzuleiten.
Das ist besonders relevant, wenn Zugriffsrechte an ein bestimmtes Konto gebunden sind. Ein Web-Makro, das Dateien aus einem geschützten Verzeichnis hochlädt, kann mit dem dafür vorgesehenen Windows-Konto ausgeführt werden. Eine Scan-Document-Aufgabe kann unter einer Identität laufen, die Zugriff auf ihren Eingangsordner besitzt. Die Aufgabe bleibt dabei sitzungslos; das Ausführungskontext liefert die Identität, aber keinen sichtbaren Desktop.
Die offiziellen Versionshinweise ordnen Ausführungskontexte und Sitzungswechsel auch in den Betrieb auf Windows-Systemen mit mehreren Benutzern ein. Entscheidend ist die Trennung von Aufgabe und zufällig aktiver Anmeldung: Das hinterlegte Konto wird Teil der Aufgabenkonfiguration und ist nicht mehr davon abhängig, wer zuletzt am Host gearbeitet hat.
Robot Tasks erhalten ihren Desktop per RDP
Robot Tasks zeichnen Bedienhandlungen auf dem Windows-Desktop auf und spielen sie dort wieder ab. Deshalb kann der Agent diesen Aufgabentyp nicht einfach in denselben sitzungslosen Hostprozess verschieben. Eine Desktopanwendung braucht eine interaktive Oberfläche, auf der Fenster, Steuerelemente, Mausbewegungen und Tastatureingaben tatsächlich existieren.
OpCon RPA 1.2.0 automatisiert stattdessen die Bereitstellung dieser Oberfläche. Ist für einen Robot Task keine passende Sitzung verfügbar, kann der Agent mithilfe des Ausführungskontexts eine RDP-Anmeldung vornehmen. Der Task läuft anschließend in dieser Sitzung. Nach der Ausführung kann die Sitzung wieder abgemeldet werden. Das Konto muss damit nicht dauerhaft am RPA-Host angemeldet bleiben, obwohl die eigentliche Desktopaufgabe weiterhin eine Sitzung benötigt.
Ein aufgezeichneter Vorgang in einer Windows-Anwendung passt in dieses Modell: Der Agent meldet das hinterlegte Konto per RDP an, stellt den Desktop bereit, führt die Aufzeichnung aus und beendet danach die Sitzung. Ein Web-Makro für ein browsergestütztes Formular nimmt dagegen den kürzeren Weg über den sitzungslosen Hostprozess. Die Wahl hängt somit nicht nur vom Zielsystem ab, sondern vor allem davon, ob die Aufgabe eine interaktive Desktopoberfläche steuern muss.
Zwei Ausführungswege statt einer pauschalen Unattended-Funktion
Der Begriff „unbeaufsichtigt“ beschreibt in diesem Release zwei technisch unterschiedliche Situationen. Bei Web Macro und Scan Document existiert während der Ausführung keine interaktive Windows-Sitzung. Bei Robot Tasks existiert sie weiterhin, wird aber automatisch und nur für den benötigten Zeitraum erzeugt.
Für die Zuordnung einer Automatisierung hilft eine einfache Unterscheidung. Arbeitet die Aufgabe als Web-Makro oder verarbeitet sie ein Dokument mit Scan Document, kann sie den neuen Hostprozess verwenden. Steuert sie dagegen eine klassische Desktopanwendung über aufgezeichnete Bedienhandlungen, bleibt sie ein Robot Task und nutzt bei Bedarf die RDP-Sitzung. Ein Robot Task wird durch das Update also nicht automatisch zu einer sitzungslosen Aufgabe.
Diese Trennung verhindert eine falsche Erwartung an Desktopautomatisierung. OpCon entfernt die manuelle Anmeldung als dauerhafte Betriebsbedingung, aber nicht den Desktop als technische Voraussetzung für aufgezeichnete Desktopaktionen. Für Web- und Dokumentaufgaben fällt beides weg; für Robot Tasks wird die Sitzung dynamisch bereitgestellt.
Aufzeichnungen zwischen Umgebungen übertragen
Neben den neuen Ausführungsmodellen unterstützt Version 1.2.0 den Export und Import von Aufzeichnungen. Damit können erstellte Automatisierungen zwischen RPA-Installationen übertragen werden. Das ergänzt die Entwicklung aus OpCon RPA 1.1.0: Seit dieser Vorversion lassen sich Aufgaben lokal beim RPA Agent speichern und auch ohne eine OpCon-Umgebung betreiben.
In einer eigenständigen Installation wird eine Aufzeichnung zunächst mit dem RPA Client erstellt und beim Agenten gespeichert. Der neue Export macht sie transportierbar; der Import bringt sie in die andere Installation. Das eignet sich beispielsweise, wenn eine Aufzeichnung zunächst auf einem getrennten Rechner vorbereitet und anschließend auf den vorgesehenen RPA-Host übertragen wird.
Version 1.1.0 hatte bereits das Kopieren von Aufzeichnungen einschließlich ausgewählter Versionsstände sowie getrennte Regeln für das Löschen von Entwürfen und veröffentlichten Aufgaben eingeführt. Export und Import erweitern diese lokale Verwaltung nun über die einzelne Installation hinaus. Der eigenständige RPA Client bleibt dabei das Werkzeug zum Erstellen und Verwalten der aufgezeichneten Bedienhandlungen; die fertigen Aufzeichnungen können weiterhin in OpCon eingebunden und zentral orchestriert werden.
Native Mausklicks helfen bei anspruchsvollen Webseiten
Web-Makros erhalten außerdem eine Option für native Mausklicks. Sie ist für Webseiten gedacht, bei denen die bisherige Art des Klickens ein Element nicht zuverlässig auslöst. Statt die gesamte Aufzeichnung als Desktop-Robot auszuführen, kann das Web-Makro für die betreffende Interaktion einen nativen Mausklick verwenden.
Praktisch bietet sich die Option an, wenn ein Webelement zwar erkannt wird, aber auf den üblichen automatisierten Klick nicht wie erwartet reagiert. Dann lässt sich die Klickart innerhalb des Web-Makros ändern. Die Aufgabe bleibt ein Web-Makro und profitiert weiterhin von der sitzungslosen Ausführung; die neue Einstellung ersetzt nicht das gesamte Ausführungsmodell.
Das ist ein wichtiger Unterschied zum Robot Task. Ein einzelner schwieriger Klick auf einer Website macht nicht automatisch eine vollständige Desktopaufzeichnung erforderlich. Erst wenn der Vorgang tatsächlich eine interaktive Desktopanwendung oder umfassende Maus- und Tastatursteuerung benötigt, ist der sitzungsgebundene Robot Task das passende Format.
Was nach einem Neustart tatsächlich passiert
Ein typischer unbeaufsichtigter Einsatz beginnt mit einem Windows-Host, auf dem RPA Agent und die lokal gespeicherten Aufgaben vorhanden sind. Nach dem Neustart wartet der Agent auf die anstehende Ausführung. Für ein Web-Makro oder eine Scan-Document-Aufgabe startet er den Hostprozess ohne Benutzeranmeldung. Ist ein Ausführungskontext hinterlegt, läuft die Aufgabe unter dem dort bestimmten Windows-Konto.
Bei einem Robot Task prüft das Ausführungsmodell dagegen die benötigte interaktive Umgebung. Der Agent verwendet die Anmeldedaten des Ausführungskontexts, um die RDP-Sitzung für dieses Konto zu erzeugen. Die Aufzeichnung erhält damit den Desktop, den sie für ihre Bedienhandlungen benötigt. Nach dem Lauf wird die Sitzung wieder geschlossen. Beide Wege beginnen unbeaufsichtigt, unterscheiden sich aber darin, ob während der Ausführung ein Desktop existiert.
Das Update eignet sich deshalb vor allem für RPA-Hosts, die neu starten dürfen, ohne anschließend auf einen manuellen Login zu warten. Webbasierte Übertragungen, Formulare und Dokumentaufgaben profitieren vom vollständig sitzungslosen Start. Aufgezeichnete Windows-Bedienhandlungen profitieren vom automatischen Aufbau ihrer RDP-Sitzung.
Beim Wechsel auf Version 1.2.0 zählt das Datenbankformat
Die Versionshinweise nennen eine technische Schutzmaßnahme für Downgrades: Erkennt ein älterer Agent das neuere Datenbankformat von Version 1.2.0, beendet er seinen Start. Dadurch soll verhindert werden, dass eine nicht kompatible Version die gespeicherten Daten beschädigt. Ein Wechsel zurück ist daher nicht einfach mit dem Start eines älteren Agenten erledigt.
Für bestehende Installationen ist außerdem die Aufgabenart entscheidend. Web Macro und Scan Document lassen sich dem sitzungslosen Modell und bei Bedarf einem neuen Ausführungskontext zuordnen. Robot Tasks behalten ihre interaktive Ausführung und können das RDP-Bootstrapping verwenden. Bereits seit Version 1.1.0 liegen eigenständig betriebene Aufgaben lokal beim Agenten; Version 1.2.0 baut auf diesem Speichermodell auf.
Die Lizenzierung bleibt maschinenbezogen: Laut OpCon RPA Q&A benötigt jede Maschine mit installiertem RPA Client beziehungsweise Server eine Aktivierungslizenz. Die Zahl der Bots oder Aufgaben ist danach nicht fest begrenzt, während das tägliche Ausführungsvolumen im Abonnement berücksichtigt wird. OpCon RPA benötigt eine separate Lizenz; Preise stellt der Anbieter auf Anfrage bereit.
Das passende Einsatzprofil für die neue Version
Der größte Sprung von OpCon RPA 1.2.0 liegt nicht in einem neuen Aufzeichnungstyp, sondern in der Entkopplung der Ausführung von einer dauerhaft offenen Benutzersitzung. Web-Makros und Scan-Document-Aufgaben können vollständig ohne interaktiven Login arbeiten. Robot Tasks behalten ihren Desktop, erhalten ihn aber automatisch über eine temporäre RDP-Anmeldung.
Damit lässt sich die Aufgabe nach ihrer tatsächlichen technischen Abhängigkeit auswählen: Web- und Dokumentautomatisierung läuft sitzungslos, klassische Desktopsteuerung in einer dynamisch erzeugten Sitzung. Ausführungskontexte geben beiden Varianten eine festgelegte Windows-Identität. Export und Import erleichtern zusätzlich den Transfer von Aufzeichnungen, während native Mausklicks den Einsatzbereich von Web-Makros bei schwierig reagierenden Seitenelementen erweitern.
Das Ergebnis ist ein präziseres Unattended-Modell: nicht jede Aufgabe wird auf dieselbe Weise ausgeführt, aber keine der beschriebenen Varianten verlangt mehr ein Konto, das vorsorglich und dauerhaft am RPA-Host angemeldet bleibt.