Retry-Handling in SAP CPI mittels JMS-Adapter: Teil 2
In unserem ersten Teil zum Retry-Handling haben wir bereits einen intakten Retry-Prozess erstellt. Doch wie können Sie jetzt wiederholte Nachrichten überwachen? Oder die Messages dynamisch an verschiedene Zielsysteme schicken? Dies und weitere hilfreiche Funktionen erläutere ich Ihnen in den folgenden Schritten.
Das Wichtigste im Überblick
- Wiederholungen lassen sich transparent überwachen, inklusive Status, Retry Count und nächstem Ausführungszeitpunkt.
- Nach Ausschöpfen aller Wiederholungsversuche kann automatisiert eine Benachrichtigung an den IT-Support versendet werden.
- Durch zusätzliche Header ist ein zentrales, dynamisches Retry-Handling für mehrere IFlows und Zielsysteme möglich.
Mit SAP Cloud Integration vereinfachen wir Ihre Integrationslandschaft, schaffen volle Transparenz über alle Datenflüsse und senken Betriebs- und Entwicklungsaufwände um bis zu 50 %.
E-Mail an den IT-Support
Falls die Verbindung nach den gewünschten Wiederholungsversuchen immer noch nicht erreichbar ist, können Sie mit diesem kleinen Zusatz eine E-Mail an den IT-Support verschicken. Dies erfolgt wie abgebildet durch einen Mail-Adapter nach dem „Exception Subprocess“.
Monitoring von Wiederholungen
Im Monitor Message Processing können Sie die Retries überwachen. Während der Wiederholungen ist der Status der Nachricht auf „Retry“ gesetzt. Auf dem folgenden Bild sehen Sie, dass der im ersten Teil beschriebene Retry-Prozess komplett durchgelaufen ist. Die Nachricht wurde zwei Mal wiederholt und als „Completed“ markiert, da das System eine Mail an den IT-Support verschickt hat.

Unter „Manage Stores“ können Sie die Message Queues überwachen und weitere Informationen wie z. B. den „Retry Count“ betrachten. Des Weiteren können Sie hier sehen, wann die nächste Wiederholung ansteht. Wenn alle Wiederholungen durchgelaufen sind, verschwindet die Anzeige aus der Message Queue.

Dynamische Message Queues
Den Retry-Prozess können Sie auch zentral für mehrere IFlows benutzen. Dafür müssen Sie den Nachrichten ein zusätzliches Erkennungsmerkmal für die Adresse geben, bevor diese in die JMS-Queue gelangen. Dies dient dazu, die Nachrichten im Retry-Handling an die richtigen Adressen zu routen.
In unserem Beispiel bekommt die Nachricht den Header „ZAddressA“ mit dem Value „IDoc2“. Den Namen und Wert können Sie beliebig wählen. Diese dienen später nur zur Identifizierung der richtigen Route.
Damit der Header auch im Retry-Handling ankommt, müssen Sie diesen vorerst erlauben. Dafür klicken Sie im IFlow auf den weißen Hintergrund der CPI und lassen unter „Runtime Configuration“ mit einem Stern alle Header zu.
Der IFlow mit dynamischen Routing prüft den vorher gesetzten Header „ZAddressA“ auf die entsprechenden Werte und übermittelt die Message dann an das gewählte Zielsystem.
In der nächsten Abbildung sehen Sie die Einstellungen des Routers „Dynamisches Routing“.
Fazit
Ein sauber aufgebautes Retry-Handling endet nicht beim Wiederholen fehlgeschlagener Nachrichten. Erst durch Monitoring, Benachrichtigungen und dynamisches Routing wird der Prozess wirklich betriebssicher und skalierbar. Die vorgestellten Erweiterungen ermöglichen es, Fehler transparent zu überwachen, den IT-Support gezielt zu informieren und mehrere IFlows zentral über einen gemeinsamen Retry-Mechanismus zu steuern.
Websession: Retry-Handling in SAP CPI

Haben Sie Fragen oder Anmerkungen zum Monitoring des Retry-Handlings oder anderen Funktionen des JMS-Adapters? Vereinbaren Sie gerne einen unverbindlichen Termin!
Dieser Artikel erschien bereits im August 2021. Der Artikel wurde am 06.01.2026 erneut geprüft und mit leichten Anpassungen aktualisiert.
FAQ
Wie kann ich erkennen, ob sich eine Nachricht aktuell im Retry befindet?
Im Monitor Message Processing wird der Status der Nachricht während der Wiederholungen als „Retry“ angezeigt. Zusätzlich lassen sich über die Message Queues detaillierte Informationen wie der Retry Count einsehen.
Was passiert, wenn alle Wiederholungsversuche fehlschlagen?
Nach dem letzten Retry kann automatisiert eine E-Mail an den IT-Support versendet werden. Die Nachricht wird anschließend als „Completed“ markiert, da der definierte Fehlerprozess erfolgreich abgeschlossen wurde.
Warum sind zusätzliche Header für dynamische Message Queues notwendig?
Die Header dienen als Identifikationsmerkmal, um Nachrichten im zentralen Retry-Handling korrekt zu routen. So können mehrere IFlows denselben Retry-Prozess nutzen und dennoch gezielt unterschiedliche Zielsysteme ansprechen.















