Können auch Programme ohne API automatisiert werden?

Die kurze Antwort lautet: Ja. Moderne REST-APIs (Application Programming Interfaces) sind der "Goldstandard" für den Datenaustausch zwischen Softwaresystemen. Viele etablierte mittelständische Unternehmen in Deutschland arbeiten jedoch mit gewachsenen, branchenspezifischen "Legacy-Systemen" (Altsystemen), die vor 10 oder 15 Jahren entwickelt wurden – lange bevor Cloud-APIs zum Standard wurden.

Für solche monolithischen Architektur-Inseln gibt es bewährte ingenieurtechnische Lösungsansätze, um Systembrüche zu überwinden und Datenabgleich (Datensynchronisation) herzustellen, ohne die Kernsoftware sofort kostenintensiv austauschen zu müssen.

Lösungsarchitekturen für systemübergreifende Automatisierung

Ebene 1: Datenbank-Direktzugriff (Database Level Integration)

Viele ältere On-Premise-Anwendungen haben zwar keine Webschnittstelle, speichern ihre Daten jedoch in standardisierten relationalen Datenbanken (z.B. Microsoft SQL Server, MySQL, Oracle oder PostgreSQL).

Wenn direkter Zugriff auf den Server (oft ein lokaler Server im Unternehmensnetzwerk) besteht, können wir Middleware-Skripte (z.B. in Python oder Node.js) entwickeln. Diese Skripte lesen Änderungen ("Deltas") direkt auf Datenbankebene aus und synchronisieren sie über eine sichere Verbindung mit neuen Cloud-Systemen oder Dashboards.

• Vorteil: Sehr schnell (Echtzeit-nah), robust und unsichtbar für den Endnutzer.
• Nachteil: Erfordert tiefes Verständnis des (oft undokumentierten) Datenbankschemas der Altsoftware.

Ebene 2: Automatisierter Export & Datei-Parsing (ETL-Prozesse)

Wenn die Datenbank verschlüsselt oder gesperrt ist, greifen wir auf Exportfunktionen (ETL: Extract, Transform, Load) zurück. Das Altsystem wird so konfiguriert (oft via Windows Task Scheduler oder Makros), dass es nachts oder stündlich strukturierte Dateien (CSV, XML, JSON) generiert.

Ein auf einem sicheren Server laufender File-Watcher-Prozess (oft per n8n-Workflow oder eigenem Microservice orchestriert) registriert die neue Datei, liest sie aus, transformiert die Daten ("Data Mapping") und pusht sie automatisiert in das Zielsystem.

• Vorteil: Extrem stabil, technisch wenig invasiv.
• Nachteil: Asynchrone Datenverarbeitung (keine absolute Echtzeit); Skalierungsgrenzen bei riesigen Datenmengen.

Ebene 3: Robotic Process Automation (RPA)

Dies ist die "Ultima Ratio" (letzte Instanz), wenn Systeme sich komplett abschotten. RPA ist im Grunde ein virtueller, unsichtbarer Mitarbeiter (Software-Roboter). Der Bot wird programmiert, um die grafische Benutzeroberfläche (GUI) exakt so zu bedienen wie ein Mensch.

Er öffnet ein Fenster, liest Werte per OCR (Texterkennung) aus Bildschirmen ("Screen Scraping"), klickt auf Buttons und simuliert Tastatureingaben.

• Beispiel-Szenario: Eingehende E-Mail-Bestellungen werden vom Bot ausgelesen; der Bot öffnet das alte ERP-System (z.B. eine AS/400 Terminal-Emulation), navigiert per Tabulatortaste durch die Maske und speichert den Auftrag.
• Vorteil: Funktioniert mit absolut jedem Programm, für das ein Mensch einen Monitor und eine Tastatur nutzen kann.
• Nachteil: Pflegeaufwändig (Fragilität). Ändert sich ein Button im Layout minimal, bricht der Roboterprozess ab und muss vom IT-Dienstleister neu justiert werden. Zudem ist die Verarbeitungsgeschwindigkeit naturgemäß langsam, da GUI-Ladezeiten abgewartet werden müssen.

Praxisbeispiel aus Hannover: Buchhaltungsintegration

Ein technischer Großhandel in der Region Hannover nutzte ein hochspezialisiertes Warenwirtschaftssystem (WWS), für das der Hersteller keine API anbot. Gleichzeitig verlangte die Buchhaltungsabteilung eine Echtzeit-Integration in DATEV.

Die Lösung (Hybrid-Ansatz): Wir implementierten ein Zwischensystem (Data Lake). Ein Python-Skript fragte die lokale SQL-Datenbank des WWS direkt ab (Ebene 1), filterte ausschließlich fakturierte Aufträge heraus und transferierte diese über eine moderne API direkt an DATEV-Unternehmen online. Monatliche Zeiteinsparung: Über 40 Stunden manuelles Abtippen. Investitions-Amortisation (ROI): unter 4 Monaten.

Wann lohnt sich welcher Weg?

Die strategische Reihenfolge (Best Practice) in der Evaluierung lautet:

1. Prüfung auf versteckte API / Webhooks: Oft existieren undokumentierte Schnittstellen, die Fachabteilungen nicht kennen.
2. Datenbank-Integration: Der bevorzugte Weg für performanten Datenaustausch.
3. Dateibasierter Export/Import: Die pragmatische, kosteneffiziente "Low-Hanging-Fruit".
4. RPA / UI-Automation: Nur bei kritischen "Insellösungen", bei denen alle anderen Optionen scheitern.

Das Fazit: Keine Insellösung ist endgültig isoliert

"Das Programm hat keine Schnittstelle" ist im B2B-Umfeld meistens nur eine Aussage über die Bequemlichkeit der Softwarekonfiguration, aber kein technisches Todesurteil. Bevor Software millionenschwer ausgetauscht ("Replatforming") wird, ist die Entwicklung einer cleveren Integrationsbrücke (Middleware) fast immer die wirtschaftlichste Zwischenlösung, um den Lebenszyklus des Systems (TCO) zu maximieren.

Als Systemhaus aus Hannover analysieren wir für norddeutsche Betriebe regelmäßig geschlossene IT-Landschaften. Wir decken Integrationswege auf und programmieren exakt die Middleware-Komponenten, die Ihre isolierten Systeme miteinander verknüpft – auch ohne API.