Retry-Strategie
Eine Retry-Strategie legt fest, bei welchen Fehlern, mit welchen Pausen und bis zu welcher Grenze erneut versucht wird.
Eine Retry-Strategie bestimmt, wann eine fehlgeschlagene oder unbeantwortete Operation erneut versucht wird. Sie unterscheidet vorübergehende Störungen von Fehlern, die zuerst eine Korrektur brauchen, und begrenzt Versuche oder Gesamtdauer.
In einem fiktiven Beispiel wartet eine Integration vor drei weiteren Versuchen jeweils 2, 4 und 8 Sekunden. Das sind Beispielwerte, keine allgemeine Vorgabe. Zusätzliche Zufallsanteile können verhindern, dass viele Empfänger gleichzeitig erneut senden. Vorgaben des Zielsystems sind zu berücksichtigen.
Ein unverändert fehlender Artikelcode wird durch Warten nicht gültig. Und eine verlorene Antwort kann einen bereits ausgeführten Auftrag verbergen. Vor einer Wiederholung muss deshalb die sichere Wirkung geklärt sein, etwa über Idempotenz oder Ergebnisabgleich. Wiederholung allein ist keine Fehlerbehebung.
Quellen
Verwandte Begriffe
- IdempotenzEine idempotente Operation hat bei identischer Wiederholung dieselbe beabsichtigte Wirkung auf den Zustand wie beim ersten Mal.
- Rate LimitingRate Limiting begrenzt, wie viele Anfragen ein Client nach einer bestimmten Regel in einem Zeitraum stellen darf.
- Server-Sent EventsServer-Sent Events übertragen über eine HTTP-Verbindung Textmeldungen vom Server zum Client, etwa zum Fortschritt eines Hintergrundauftrags.
- Entity TagEin ETag kennzeichnet eine bestimmte Darstellungsversion einer HTTP-Ressource und ermöglicht bedingte Abrufe oder Änderungen.
- Cross-Origin Resource SharingCORS steuert im Browser die Freigabe von Antworten über Origin-Grenzen. Es ersetzt weder die Anmeldung noch die Berechtigungsprüfung einer API.
- Electronic Data InterchangeEDI überträgt strukturierte Geschäftsdokumente zwischen Systemen. Format, Partnerprofil, Datenzuordnung und Rückmeldungen müssen zusammenpassen.
Ihr Vorhaben mit ASES
Beschreiben Sie uns Ihr Vorhaben. Wir melden uns mit einer ersten Einschätzung.