Screen Scraping oder API: wann RPA wirklich noch nötig ist

Screen Scraping hat einen schlechten Ruf, und meistens zu Recht. Wenn ein Software-Roboter sich durch Bildschirmmasken klickt, statt Daten über eine Schnittstelle abzuholen, ist das selten die saubere Lösung. Trotzdem gibt es im Mittelstand Prozesse, in denen genau das der einzige Weg ist. Die entscheidende Frage ist nicht, ob die Methode altmodisch wirkt, sondern ob das Zielsystem eine brauchbare Schnittstelle hat.

Was ist Screen Scraping und wie unterscheidet es sich von einer API-Integration?

Screen Scraping bezeichnet das automatisierte Auslesen und Bedienen einer Anwendung über ihre Bildschirmoberfläche: Ein Roboter bewegt den Mauszeiger, füllt Felder aus und liest Werte von der Maske ab, so wie es sonst ein Mensch täte. Eine API-Integration umgeht die Oberfläche und spricht direkt mit der Datenschnittstelle des Systems.

Microsoft bringt den Unterschied in seiner Power-Automate-Dokumentation auf eine knappe Formel: Über eine API sagt man der Anwendung, was sie tun soll, über die Oberfläche zeigt man es ihr (Types of process automation, Microsoft Learn). Nur eines davon ist eine Vereinbarung. Eine Schnittstelle ist ein Versprechen des Herstellers, dass Felder und Formate so bleiben. Eine Bildschirmmaske ist dieses Versprechen nicht.

API oder Screen Scraping: was die Hersteller selbst empfehlen

Die Empfehlung fällt eindeutig aus, und sie kommt von den RPA-Herstellern selbst. Microsoft rät dazu, für jede Anwendung mit verfügbarem API-Connector die API-basierte Automatisierung zu wählen, weil Schnittstellen stabil bleiben sollen, auch wenn sich die Anwendung verändert.

Power Automate deckt nach Herstellerangaben über 380 Anwendungen mit fertigen API-Connectoren ab, dazu kommen selbst gebaute Connectoren für jedes System mit verfügbarer API (Microsoft Learn). Die Automatisierung über die Oberfläche ist damit kein gleichwertiger Gegenentwurf zur API-Integration, sondern der dokumentierte Notausgang. Wer zuerst nach dem Roboter greift, kauft Wartungsaufwand ein, den niemand bestellt hat.

Warum Screen Scraping in der Wartung teurer wird

Der Preis dafür ist Wartungsaufwand, und der ist gut dokumentiert. Automatisierungen über die Oberfläche hängen an Selektoren, also an der technischen Beschreibung, wo ein Bedienelement liegt und wie es heißt. Ändert sich diese Beschreibung, findet der Roboter das Element nicht mehr und der Lauf bricht ab.

Microsoft listet für unbeaufsichtigt laufende Desktop-Flows sechs Faktoren auf, die einen Selektor unbrauchbar machen können: Bildschirmauflösung und DPI-Skalierung, Updates der Anwendung, die Version des Betriebssystems, die Fenstergröße, der Zustand eines Elements und die Berechtigungen des angemeldeten Nutzers (Troubleshooting unattended execution, Microsoft Learn). Keiner dieser Punkte hat mit dem Fachprozess zu tun. Der Prozess ist unverändert richtig, die Automatisierung stolpert über die Verpackung.

UiPath beschreibt dasselbe Problem aus der anderen Richtung: Klassische Selektoren stützen sich auf starre Attribute und Hierarchien, weshalb schon ein geändertes Label, eine dynamische Element-ID oder ein neues Theme die Automatisierung stoppt. Der Hersteller beziffert ihren Wartungsaufwand selbst als hoch (About Semantic Selectors, UiPath Docs). Bei einer API-Integration existiert keiner dieser Punkte. Eine Schnittstelle interessiert sich nicht für die Bildschirmauflösung.

Wann ist Screen Scraping wirklich die richtige Wahl?

Screen Scraping ist dann das richtige Mittel, wenn ein System keine nutzbare Schnittstelle hat und sich ausschließlich über seine Oberfläche bedienen lässt. Microsoft fasst die Bedingung in der Lizenzdokumentation eng: RPA wird für Anwendungen gebraucht, für die weder ein fertiger Connector noch eine API existiert, aus der sich ein eigener Connector bauen ließe.

In der Praxis trifft das auf fünf Konstellationen zu:

• Alte Fachverfahren ohne API: gewachsene Branchensoftware, die nie für Integration gedacht war.
• Terminal- und Citrix-Anwendungen: wenn nur ein Bildschirmabbild ankommt, gibt es technisch nichts zu greifen außer der Maske.
• Die Schnittstelle ist gesperrt: manche Hersteller lizenzieren das API-Modul separat oder geben es kleinen Kunden gar nicht frei. Dann ist die Frage kaufmännisch, nicht technisch.
• Die API deckt den Vorgang nicht ab: eine Schnittstelle, die nur liest, hilft beim nötigen Schreibvorgang nicht weiter.
• Die Übergangszeit vor einer Ablösung: wird das System in ein bis zwei Jahren ersetzt, rechnet sich eine saubere Integration oft nicht mehr. Ein Roboter, der bewusst als Wegwerflösung gebaut wird, ist dann die ehrlichere Investition.

Der letzte Punkt wird regelmäßig übersehen: Der Ansatz ist eine legitime Brückentechnologie. Zum Problem wird er erst, wenn die Brücke zum Dauerzustand wird und niemand mehr weiß, warum sie steht. Die Werkzeugfrage selbst haben wir im Praxistest von n8n und Power Automate durchgerechnet.

Dann gehören auch die Lizenzkosten in die Rechnung, die bei der API-Variante entfallen. Bei Power Automate braucht jede Maschine, die Desktop-Flows unbeaufsichtigt ausführt, eine Process-Lizenz, und für Microsoft 365 zusätzlich eine Unattended-Lizenz (Microsoft Learn). Aus Lizenzsicht ist der Roboter ein weiterer Nutzer. Die UiPath-Bausteine haben wir in den UiPath-Lizenzen für den Mittelstand aufgeschlüsselt.

Wie prüft man, ob wirklich keine Schnittstelle da ist?

Vor jeder RPA-Entscheidung steht eine Prüfung, die meist eine halbe Stunde kostet und regelmäßig den Roboter überflüssig macht. Häufig gibt es eine Schnittstelle, sie heißt nur anders. Vier Fragen klären das:

• Was sagt die Herstellerdokumentation? API-Module tauchen oft in der technischen Doku auf, lange bevor sie im Angebot stehen.
• Gibt es einen Datenexport? die unspektakulärste Schnittstelle ist ein geplanter CSV- oder XML-Export. Er ist stabil, dokumentiert und kostet nichts.
• Ist ein lesender Datenbankzugriff möglich? für Auswertungen reicht er oft völlig aus.
• Was kostet das Schnittstellenmodul? einmalig ist es häufig günstiger als drei Jahre Roboterwartung.

Fällt die Entscheidung doch auf den Roboter, gehört die Begründung schriftlich festgehalten. Für eine kommunale Verwaltung haben wir im Juli 2026 genau diese Prüfung vorgelegt und davon abgeraten, RPA zum Fundament der Automatisierungsstrategie zu machen: als punktuelle Ergänzung ja, als Basis nein. Das Werkzeug war nicht schlecht, es passte nur nicht zur Aufgabe. Diese Prüfung ist der eigentliche Inhalt einer Schnittstellen- und Integrationsberatung.

Häufige Fragen

Was ist der Unterschied zwischen Screen Scraping und Web Scraping?

Web Scraping liest Inhalte aus Webseiten aus, meist über den HTML-Quelltext, und braucht dafür keine sichtbare Oberfläche. Screen Scraping bedient die Anwendung so, wie ein Mensch sie sieht, und schließt Desktop-Programme, Terminal- und Citrix-Sitzungen mit ein.

Ist Screen Scraping erlaubt?

Technisch ja, vertraglich kommt es darauf an. Manche Softwarehersteller schließen die automatisierte Bedienung in ihren Nutzungsbedingungen aus oder binden sie an zusätzliche Lizenzen. Vor dem Bau eines Roboters gehören die Lizenzbedingungen des Zielsystems geprüft, im Zweifel mit Rechtsrat.

Bricht Screen Scraping wirklich bei jedem Update?

Nein, aber das Risiko lässt sich nicht wegprogrammieren. Ein Update, das nur die Fachlogik ändert, lässt den Roboter unberührt. Sobald sich Beschriftungen, Fensteraufbau oder Element-IDs verschieben, greifen die Selektoren ins Leere. Wer RPA einsetzt, plant Wartung deshalb fest ein, statt sie als Störfall zu behandeln.

Lösen KI-gestützte Selektoren das Problem?

Sie entschärfen es, sie beseitigen es nicht. Hersteller wie UiPath arbeiten an Selektoren, die ein Element über seine Bedeutung statt über seine Position erkennen. Das senkt den Wartungsaufwand, ändert aber nichts daran, dass die Automatisierung von einer Oberfläche abhängt, die niemand vertraglich stabil hält.