ERP-CRM-Middleware: Wiederholungen und Ausfälle beherrschen

Punkt-zu-Punkt-Schnittstellen sind bei wenigen klaren Datenflüssen oft ausreichend. Werden mehrere Anwendungen, Gesellschaften und Sonderregeln verbunden, verteilen sich Übersetzungen und Fehlerbehandlungen jedoch auf viele Stellen. Eine Middleware schafft einen gemeinsamen Ort für diese Aufgaben. Ihre Einführung sollte sich an konkreten Problemen orientieren: unklare Datenstände, mehrfach verarbeitete Aufträge, schwer nachvollziehbare Ausfälle oder Änderungen, die mehrere Systeme gleichzeitig betreffen.

Ausgangslage und Projektgrenzen

• Bestimmen Sie für jeden Datenfluss Auslöser, Quelle und Ziel.
• Ordnen Sie fachliche Verantwortliche zu, die widersprüchliche Kunden-, Artikel- oder Auftragsdaten verbindlich klären können.
• Erfassen Sie bestehende Direktverbindungen und manuelle Exporte, bevor eine zusätzliche Middleware die Systemlandschaft erweitert.

Die Middleware sollte Nachrichten eindeutig identifizieren, fachliche Zustände protokollieren und Wiederholungen begrenzen. Idempotente Verarbeitung verhindert, dass ein erneut gesendeter Vorgang unbeabsichtigt eine zweite Wirkung erzeugt. Nicht jeder Fehler lässt sich automatisch beheben: Ein temporär nicht erreichbares Ziel erfordert eine andere Behandlung als eine ungültige Kundennummer. Fehlerwarteschlangen benötigen Verantwortliche und einen kontrollierten Wiedereinstieg. Regelmäßige Abgleiche erkennen Unterschiede, die trotz erfolgreicher Einzelübertragung entstehen können.

Architektur, Risiken und Aufwandstreiber

• Eine Warteschlange entkoppelt Verfügbarkeit, garantiert aber allein keine einmalige fachliche Ausführung.

Empfänger müssen Wiederholungen erkennen.

• Definieren Sie externe Identitäten, Ereignisversionen und Regeln für verspätete Änderungen, damit alte Nachrichten neue Zustände nicht überschreiben.
• Trennen Sie technische Wiederholung von fachlicher Korrektur.

Unverarbeitbare Vorgänge benötigen einen sichtbaren Fehlerbestand mit Verantwortlichem.

Die veröffentlichte GSWE-Referenz GRÜN Itex beschreibt eine Metadatenplattform für Verlage mit rund 40 angebundenen Schnittstellen. GSWE übernahm Betrieb, Stabilisierung und Weiterentwicklung und verbesserte Monitoring sowie Fehleranalyse. Das belegt Erfahrung mit einer komplexen Integrationslandschaft. Es ist keine Referenz für eine bestimmte ERP-CRM-Produktkombination; diese wird im jeweiligen Projekt separat geprüft.

Konkrete Prüffälle für den ersten Release

• Die Quellanwendung sendet dieselbe Auftragsmeldung zweimal. Das Ziel erhält einen Auftrag und die erneute Zustellung bleibt nachvollziehbar.
• Eine ältere Kundenänderung trifft nach einer neueren ein. Die Verarbeitung erkennt die Reihenfolge oder führt den Fall einer kontrollierten Klärung zu.
• Das ERP fällt für eine Stunde aus. Nach der Wiederkehr wird der Rückstau begrenzt abgearbeitet, ohne die Gegenstelle erneut zu überlasten.

Ein belastbarer Integrationsauftrag nennt Quell- und Zielsystem, Datenverantwortliche, Übertragungsvolumen, tolerierbare Verzögerung und Wiederanlaufverfahren. Prüfen Sie außerdem Versionierung, Secrets-Verwaltung, Berechtigungen sowie die Sichtbarkeit personenbezogener Daten in Protokollen. Fachlich relevante Prüffälle sind eine verspätete Nachricht, ein mehrfach übertragenes Ereignis und ein Zielsystem, das nach einer Unterbrechung wieder erreichbar wird.

Prüfen Sie mit dem Dienstleister die Wiederanlaufstrategie: Welche Nachrichten werden nach einem Ausfall erneut verarbeitet, welche Reihenfolge muss erhalten bleiben und welche Vorgänge benötigen eine manuelle Freigabe? Fordern Sie einen nachvollziehbaren Test mit absichtlich doppelten und fehlerhaften Nachrichten. Zum Leistungsumfang gehören außerdem Aufbewahrungsfristen für technische Protokolle und ein Verfahren, mit dem Support-Mitarbeiter Fehler bearbeiten können, ohne unbeschränkten Zugriff auf Geschäftsdaten zu erhalten.

Prüfen Sie neben dem erfolgreichen Datentransfer auch den Umgang mit fehlerhaften Nachrichten. Zuständige Teams müssen erkennen, welche Vorgänge warten, welche korrigiert werden müssen und welche sicher erneut gestartet werden können. Eine Middleware sollte diese Entscheidungen unterstützen, ohne manuelle Änderungen direkt in produktiven Datenbanken vorauszusetzen.

Entscheidungshilfe für die Beauftragung

• Lassen Sie Nachrichtenweg, Aufbewahrung, Wiederholungsgrenzen und manuelle Freigabe einer erneuten Verarbeitung dokumentieren.
• Prüfen Sie die Übergabe einer Korrelationskennung durch alle beteiligten Systeme, damit ein Supportfall nicht in getrennten Protokollen gesucht werden muss.
• Fordern Sie einen Abgleich zwischen Quell- und Zielbestand; erfolgreiche HTTP-Antworten allein beweisen keine fachlich vollständige Übernahme.

Middleware ist sinnvoll, wenn sie die Beherrschbarkeit Ihrer Prozesse verbessert. Eine zusätzliche technische Plattform ohne klare Zuständigkeiten verlagert Probleme lediglich. Beginnen Sie mit einem kritischen Datenfluss und messen Sie beispielsweise manuelle Korrekturen und Zeit bis zur Fehlerklärung. Dieses Vorgehen liefert eine belastbare Grundlage für den Ausbau weiterer Integrationen.

Nutzen bewerten und den Ausbau begrenzen

• Vergleichen Sie die Zahl dauerhaft ungeklärter Vorgänge und die Zeit bis zur Wiederherstellung eines unterbrochenen Datenflusses.
• Bewerten Sie, ob weitere Systeme mit einem nachvollziehbaren Vertrag angebunden werden können oder neue Sonderfälle die Kopplung erhöhen.

Senden Sie uns eine Übersicht Ihrer Systeme und einen Datenfluss, der aktuell besonders aufwendig oder störanfällig ist.

Leistungsumfang ansehen und Projekt besprechen

• Nennen Sie die beteiligten ERP-, CRM- und Fachsysteme sowie heutige Übertragungswege, Datenmengen und Häufigkeiten.
• Beschreiben Sie einen häufigen Fehlerfall einschließlich seiner aktuellen Bearbeitung und der zuständigen Teams.
• Teilen Sie mit, welche Daten zeitnah benötigt werden und bei welchen Prozessen eine spätere Verarbeitung zulässig ist.