SAP-Schnittstellen im Fehlerfall: Was bei Wiederholungen und Dubletten passieren muss

Die Bestellung wurde gesendet. Das Zielsystem antwortet nicht rechtzeitig. Im Monitoring steht ein Timeout. Soll die Nachricht einfach noch einmal abgeschickt werden?

Die Antwort hängt davon ab, was im Zielsystem tatsächlich passiert ist. Vielleicht wurde die Bestellung nicht angenommen. Vielleicht wurde sie angelegt und nur die Bestätigung ging verloren. Ein erneuter Versand kann den Fehler beheben oder einen zweiten Beleg erzeugen.

Das folgende Bestellbeispiel ist konstruiert. Es steht für eine typische Integrationsfrage und beschreibt keinen konkreten Kundenprozess.

Meine Empfehlung: Den Wiederanlauf einer Schnittstelle schon beim fachlichen Vertrag entwerfen. Ein technischer Retry ist erst sicher, wenn seine fachliche Wirkung geklärt ist.

Ein Timeout sagt nichts über den Geschäftsvorgang

Ein Timeout beschreibt zunächst nur die Sicht des aufrufenden Systems: Innerhalb der erwarteten Zeit kam keine verwertbare Antwort. Daraus lässt sich nicht zuverlässig ableiten, ob der Empfänger die Anfrage verarbeitet hat.

Im Beispiel sind mindestens drei Zustände möglich:

Tatsächlicher Zustand	Was ein erneuter Versand bewirken kann
Das Zielsystem hat die Bestellung nicht erhalten.	Die Wiederholung kann den Vorgang erstmals ausführen.
Das Zielsystem hat die Bestellung angelegt, aber die Antwort ging verloren.	Ohne Dublettenprüfung kann eine zweite Bestellung entstehen.
Das Zielsystem hat die Anfrage angenommen, verarbeitet sie aber noch.	Eine sofortige Wiederholung kann mit der laufenden Verarbeitung kollidieren.

Ich würde deshalb nach einem Timeout zuerst fragen: Woran erkennen beide Systeme denselben fachlichen Auftrag? Und wie lässt sich sein aktueller Zustand im Zielsystem feststellen?

Eine technische Message-ID allein reicht oft nicht

Für die Fehlersuche braucht jede Verarbeitung eine technische Kennung. Für die Frage nach einer Dublette ist zusätzlich ein stabiler fachlicher Schlüssel wichtig: etwa eine externe Bestellnummer oder eine eindeutig vergebene Vorgangs-ID.

Dieser Schlüssel muss bei einer Wiederholung derselbe bleiben. Er darf nicht bei jedem Sendeversuch neu erzeugt werden. Der Empfänger kann dann prüfen, ob der Auftrag bereits verarbeitet wurde und welches Ergebnis dazu gehört.

Die Regel muss fachlich präzise sein. Zwei Nachrichten mit derselben Bestellnummer können eine unerwünschte Dublette sein. Sie können aber auch eine zulässige Änderung oder ein bewusst neuer Geschäftsvorfall sein. Deshalb gehören Vorgangstyp, Schlüssel und Änderungslogik gemeinsam in den Schnittstellenvertrag.

Am zuverlässigsten ist es, wenn das Zielsystem die Dublettenprüfung mit der eigentlichen Buchung zusammenführt. SAP weist darauf hin, dass eine Dublettenerkennung im Integrationsfluss eine Restunsicherheit behält: Hat der Empfänger erfolgreich gebucht, während seine Bestätigung verloren ging, kann die Middleware diesen Zustand nicht sicher erkennen. SAP Help: Receiver Isn’t Idempotent

Retry nur bei einem passenden Fehler

Ein vorübergehend nicht erreichbarer Empfänger ist ein anderer Fall als eine Bestellung mit ungültigen Pflichtdaten. Im ersten Fall kann eine zeitlich begrenzte Wiederholung sinnvoll sein. Im zweiten Fall muss jemand die Daten oder die fachliche Regel korrigieren; derselbe unveränderte Auftrag wird beim nächsten Versuch voraussichtlich wieder scheitern.

Ich würde Fehler mindestens so unterscheiden:

• Vorübergehender technischer Fehler: Verbindung gestört oder Dienst zeitweise nicht verfügbar. Nach einer definierten Pause erneut versuchen, sofern die Verarbeitung wiederholbar ist.
• Fachlicher Fehler: Daten, Status oder Berechtigung verhindern die Verarbeitung. Ursache klären und nach Korrektur gezielt erneut starten.
• Unklarer Ausgang: Die Antwort fehlt, aber eine Buchung im Zielsystem ist möglich. Zuerst anhand des fachlichen Schlüssels abgleichen.

Für asynchrone Abläufe bietet SAP Cloud Integration mit JMS-Queues ein Retry-Muster. Die Queue löst aber die fachliche Dublettenfrage nicht von selbst. Sie sorgt für erneute Zustellversuche; der Empfänger oder ein abgestimmter Integrationsprozess muss deren Wirkung beherrschen. SAP Help: Apply the Retry Pattern, SAP Help: Define Idempotent Process Call

Monitoring muss vom Fehler zum Beleg führen

Im Support reicht „Nachricht fehlgeschlagen“ nicht. Wer einen Vorgang klären soll, braucht die Verbindung zwischen technischer Nachricht und Geschäftsvorfall.

Für das Bestellbeispiel wären das mindestens: fachliche Vorgangs-ID, technische Korrelations-ID, Zeitpunkt, Verarbeitungsschritt, Fehlerkategorie, Zahl der Versuche und – soweit vorhanden – die Belegnummer im Zielsystem. Daraus muss erkennbar sein, ob ein erneuter Versuch zulässig ist oder zunächst ein Abgleich nötig wird.

SAP Cloud Integration kann Geschäftskennungen als Application ID oder über eigene Header-Eigenschaften im Message Processing Log suchbar machen. Welche Informationen dafür gespeichert werden, sollte zum Datenschutz und zum Supportbedarf passen; eine vollständige Nutzlast ist dafür häufig nicht nötig. SAP Help: Use Custom Header Properties to Search for Message Processing Logs

Ebenso wichtig ist ein klarer Verantwortlicher für die Klärung. Das Integrationsteam kann einen Timeout erkennen. Ob eine Bestellung fachlich bereits angelegt wurde oder erneut angelegt werden darf, muss gegebenenfalls der zuständige Prozessverantwortliche entscheiden können.

Den Fehlerfall vor dem Produktivstart testen

Ein erfolgreicher Test mit einer gültigen Nachricht beweist noch wenig über den Betrieb. Ich würde für eine relevante Schnittstelle mindestens diese Fälle durchspielen:

1. Derselbe Auftrag wird zweimal mit demselben fachlichen Schlüssel gesendet.
2. Die Antwort des Empfängers fehlt nach erfolgreicher Verarbeitung.
3. Der Empfänger ist vorübergehend nicht erreichbar.
4. Die Daten sind fachlich ungültig und dürfen nicht automatisch erneut verarbeitet werden.
5. Ein Supportmitarbeiter muss den Vorgang anhand der Geschäftskennung finden und sicher wiederaufnehmen.

Die erwarteten Ergebnisse gehören in Abnahmekriterien: Wie viele Belege dürfen entstehen? Welche Meldung sieht der Sender? Wo liegt ein nicht abgeschlossener Vorgang? Wer kann ihn nach welcher Prüfung erneut starten?

Mein Fazit

Eine Schnittstelle ist erst dann betriebssicher, wenn ihr Verhalten bei unklaren Ergebnissen beschrieben und getestet ist. Retry, Dublettenprüfung und Monitoring sind keine nachträglichen technischen Zusätze. Sie bestimmen, ob ein Geschäftsvorgang nach einem Fehler kontrolliert weiterläuft.

Ich würde keine automatische Wiederholung für eine belegwirksame Nachricht freigeben, bevor klar ist, wie eine bereits erfolgte Buchung erkannt und eine zweite fachliche Wirkung verhindert wird.