Leistungen
Schnittstellenprogrammierung für bestehende Systeme
Wenn dieselben Daten in mehreren Systemen gepflegt, per CSV übertragen oder bei jedem Übergang manuell nachgetragen werden, fehlt häufig keine neue Plattform. Es fehlt ein verlässlicher Datenaustausch.
WIRKLAUF entwickelt individuelle Schnittstellen dort, wo native Integrationen oder Standardconnectoren nicht genügen — mit klarer Datenhoheit, Datenzuordnung, Validierung, Fehlerbehandlung und einem Plan für den produktiven Betrieb.
Typische Systembrüche
- Doppelte Datenpflege
- Kundendaten oder Auftragsstatus werden an mehreren Stellen aktualisiert.
- Export/Import
- CSV ist zum regelmäßigen Betriebsprozess geworden.
- Statusbruch
- System A weiß nicht, was in System B passiert ist.
- Standardconnector zu klein
- Er überträgt nur einen Teil der benötigten Felder oder Regeln.
- Altintegration instabil
- Sie funktioniert, bis API, Feld oder Berechtigung geändert wird.
Der sichtbare Schmerz ist oft „wir müssen kopieren“. Die eigentliche Integrationsarbeit beginnt aber mit der Frage, welches System welche Wahrheit besitzt.
Erst Standard prüfen
Eine individuelle Schnittstelle ist nicht automatisch die beste Lösung. WIRKLAUF prüft zuerst:
- vorhandene native Integration;
- Standardconnector;
- offizielle API/Webhooks;
- Import- und Exportmöglichkeiten;
- vorhandene Middleware/Ablauf-Plattform.
individuelle Integration gewinnt, wenn relevante Datenobjekte, Fachregeln, Zuverlässigkeit oder Betriebsanforderungen damit nicht ausreichend abgedeckt werden.
Machbarkeit vor Versprechen
Nicht jedes System lässt sich in jede Richtung integrieren.
Vor der Umsetzung wird unter anderem geklärt:
- existiert eine offizielle API?
- welche Rechte/Lizenzen werden benötigt?
- lesen und/oder schreiben?
- Webhooks oder Polling?
- Import/Export?
- Testumgebung?
- Herstellerrestriktionen?
- Anfragelimits?
- welche Daten sind überhaupt zugänglich?
Wenn keine belastbare Schnittstelle existiert, kann ein Projekt deutlich riskanter werden oder bewusst nicht empfohlen werden. Oberflächen- oder RPA-Automatisierung ist nur ein möglicher Fallback und bleibt fragiler als eine stabile System-Schnittstelle.
Daten brauchen klare Verantwortung
Vor jeder Synchronisierung wird für relevante Objekte definiert:
- führendes System;
- Schreibrichtung;
- erlaubte Änderungen;
- Konfliktregel;
- Initialabgleich;
- Delta-Verhalten;
- Löschung/Archivierung;
- Statusrückmeldung.
Beispiel: Das ERP besitzt die kaufmännische Auftragsnummer. Die operative Anwendung besitzt den Bearbeitungsstatus. Beide dürfen nicht still dieselbe Bedeutung überschreiben.
Ein Datenfluss hat mehrere Entscheidungen
„System A mit System B verbinden“ ist noch kein technischer Umfang.
Ein sauberer Flow beschreibt:
- OBJEKT
- RICHTUNG
- AUSLÖSER
- DATENZUORDNUNG
- PRÜFUNG
- AUSFÜHRUNG
- RÜCKMELDUNG
- FEHLERPFAD
Dazu kommen Frequenz, Volumen, Konfliktverhalten und Betriebsüberwachung.
Integrationsarchitektur für Betrieb
Zwischen Systemen braucht es mehr als einen API-Aufruf:
- SYSTEM A
- PRÜFUNG/DATENZUORDNUNG
- INTEGRATIONSSCHICHT
- SYSTEM B
Diese Architektur muss nicht groß sein. Aber ihre Verantwortungen müssen klar sein.
Quer dazu:
- Idempotenz;
- Correlation IDs;
- Wiederholversuch;
- Protokollierung;
- Betriebsüberwachung;
- manuelle Klärroute.
Fehler sind Teil des Designs
FACHLICH ABGESCHLOSSEN kann gleichzeitig WIEDERHOLUNG AUSSTEHEND in der Integration bedeuten.
- Prüfung
Pflichtfeld fehlt oder Format ist ungültig. Der Vorgang wird vor Übertragung gestoppt.
- fachliche Ausnahme
Daten sind technisch korrekt, aber fachlich uneindeutig. Beispiel: zwei mögliche Kundenmatches. Wiederholversuch hilft hier nicht — ein Mensch muss entscheiden.
- technischer Fehler
Timeout, Anfragelimit oder temporäre Nichterreichbarkeit. Ein kontrollierter Wiederholversuch kann sinnvoll sein.
- Nach den Wiederholversuchen
Wenn ein technischer Fehler dauerhaft bleibt, wird er sichtbar eskaliert. Kein stilles Verschwinden in einem technischen Protokoll.
Arbeitsliste · 1 Auftrag
A-1042
Technischer Service
Abgeschlossen
Zuständigkeit
Techniker
Zuweisung aktiv seit 09:48
Auftrag A-1042 · Beispielbetrieb
Prüfung und Wiederinbetriebnahme einer Anlage
Zeitfenster
Heute · 10:00–12:00
Fachlicher Status
Abgeschlossen
Integrationsstatus
Wiederholung ausstehend
ERP-Synchronisierung wartet auf Wiederholversuch
SYNC_SERVICE_RESULT · Versuch 2 / 3
Nächster Wiederholversuch in 02:00
JOB
SYNC_SERVICE_RESULT
VERSUCH
2 / 3
NÄCHSTER VERSUCH
in 02:00
Historie
- 09:41FachlichAuftrag aus ERP übernommenBüro / Disposition
- 09:48FachlichTechniker zugewiesenBüro / Disposition
- 10:07FachlichBearbeitung gestartetTechniker
- 11:18PrüfungAbschluss versucht – Pflichtprüfung offenTechniker
- 11:26FachlichDokumentation vervollständigtTechniker
- 11:27TechnischERP-Rückmeldung fehlgeschlagenIntegration
- 11:29TechnischWiederholversuch erfolgreichIntegration
Technikeransicht · A-1042
ERP-Synchronisierung wartet auf Wiederholversuch
Auftragskopf
A-1042
Nächster Schritt
Pflichtprüfung
Funktionsprüfung
Dokumentation
Abschluss
Validierungsfeedback
Integration
SYNC_SERVICE_RESULT
Wiederholversuche erzeugen keine Dubletten
Wiederholen bedeutet nicht, dieselbe Geschäftsaktion blind noch einmal auszuführen.
Eine produktive Integration benötigt Duplikatschutz beziehungsweise Idempotenz. Derselbe fachliche Vorgang muss bei einem technischen Wiederholversuch dieselbe Identität behalten.
Das ist besonders wichtig bei Auftragserstellung, Zahlungen, Versandaktionen oder Statusänderungen.
Datenzuordnung ist Facharbeit
Systeme verwenden unterschiedliche IDs, Statuswerte, Einheiten, Pflichtfelder und Formate.
Ein Status wie "done" kann in einem anderen System nicht automatisch ABGESCHLOSSEN bedeuten. Eine Artikelnummer kann intern anders strukturiert sein. Datums- oder Mengeneinheiten können abweichen.
Datenzuordnung muss fachlich verstanden und getestet werden. Sonst transportiert die Schnittstelle Fehler nur schneller.
Echtzeit ist nicht immer besser
Echtzeit ist sinnvoll, wenn der Betrieb einen sofortigen Zustand benötigt. Zeitgesteuerte Übertragung kann robuster und günstiger sein, wenn Minuten oder Stunden akzeptabel sind. Eine kombinierte Lösung kann Änderungen sofort übertragen und größere Stammdatenbestände zu festen Zeiten abgleichen.
Die richtige Frequenz folgt Betriebsbedarf, Volumen, Fehlerfolge, API-Limits und Kosten.
Aufwand und Wirtschaftlichkeit
Treiber sind:
- Zahl und Komplexität der Datenobjekte;
- ein- oder bidirektional;
- Datenzuordnung/Fachregeln;
- historische Daten/Initialabgleich;
- Fehlerfolge;
- Volumen/Frequenz;
- API- und Lizenzgrenzen;
- Testbarkeit;
- Betriebsüberwachung und Betrieb.
Der Nutzen kann in weniger manueller Pflege, weniger Übergabefehlern, schnellerem Status oder einer erst dadurch möglichen Automatisierung liegen. Wirkung muss projektbezogen belegt werden, nicht mit Standardprozenten.
Betrieb nach Go-live
APIs, Felder, Berechtigungen und Herstellerverhalten ändern sich. Produktive Integrationen brauchen:
- Betriebsüberwachung;
- Alerting;
- Verantwortung;
- technische Protokolle;
- Tests;
- kontrollierte Änderungen;
- dokumentierte Abhängigkeiten.
Eine Schnittstelle ist kein Einmalskript, wenn der Betrieb davon abhängt.
Wann Integration nicht reicht
- Fehlende Fachlogik
- Individualsoftware/Web-App
- Wiederkehrende Ausführung
- Prozessautomatisierung
- Lösung noch offen
- Kernhebel-Check
- Vorhandener Standardconnector reicht
- keine individuelle Umsetzung verkaufen.
FAQ
Können Sie jedes System anbinden?
Nein. Machbarkeit hängt von Zugriffsmöglichkeiten, Herstellerbedingungen, Berechtigungen und Datenqualität ab.
Brauchen beide Systeme eine API?
Nicht zwingend. Import/Export, Webhooks oder andere offizielle Zugänge können reichen. Oberflächenautomatisierung ist ein möglicher, aber fragilerer Ausweichweg.
Echtzeit oder regelmäßig?
So schnell wie betrieblich nötig. Nicht so schnell wie technisch möglich.
Wann reicht eine Schnittstelle – und wann braucht es zusätzlich Automatisierung?
Eine Schnittstelle genügt, wenn die Arbeit selbst in Ordnung ist und nur Daten zwischen Systemen fehlen: Ein Vorgang entsteht an einer Stelle und soll an anderer Stelle verlässlich ankommen. Zusätzliche Automatisierung wird erst nötig, wenn nicht die Übertragung das Problem ist, sondern ein wiederkehrender Arbeitsschritt davor oder danach — etwa Prüfen, Zuordnen, Auslösen oder Benachrichtigen. Datenaustausch bewegt Informationen; Automatisierung übernimmt Arbeit.
Wer wartet die Schnittstelle?
Das muss im Projekt geklärt sein. Betrieb und Herstelleränderungen gehören zum Betrieb und Weiterentwicklung.
Systeme besprechen
Bitte nennen Sie:
- System A;
- System B;
- welche Daten fließen sollen;
- wie der Transfer heute passiert;
- ob API/Zugriff bekannt ist;
- wie aktuell die Daten sein müssen.
„API unbekannt“ ist eine zulässige Antwort.
- hallo@wirklauf.com
- Telefon
- 05921 8198432