In diesem Artikel
Eine Bestellung soll ins ERP übertragen werden. Die Anfrage geht raus, aber die Antwort kommt nicht rechtzeitig zurück. Ist die Bestellung angekommen? Oder muss die Übertragung erneut gestartet werden?
Genau an solchen Übergängen entscheidet sich, ob eine Automatisierung im Alltag hilft. Eine erfolgreiche Demo zeigt den Idealfall. Eine robuste Integration braucht auch einen verständlichen Umgang mit den Fällen dazwischen: vorübergehende Ausfälle, unvollständige Daten und Vorgänge mit unklarem Ergebnis.
Ein Timeout ist noch kein eindeutiger Geschäftszustand
Wenn eine Antwort ausbleibt, weiß der anfragende Teil zunächst nur, dass er keine rechtzeitige Bestätigung erhalten hat. Daraus lässt sich nicht automatisch ableiten, ob die Gegenstelle den Vorgang bereits verarbeitet hat.
Für das Team ist deshalb eine Unterscheidung wichtig: „nicht gesendet“, „gesendet, Ergebnis unbekannt“ und „bestätigt verarbeitet“ sind verschiedene Zustände. Werden sie pauschal als „Fehler“ behandelt, fehlt später die Grundlage für eine sichere Wiederholung oder manuelle Klärung.
Wiederholungen brauchen eine fachliche Bedeutung
Eine erneute Abfrage und ein erneutes Anlegen einer Bestellung sind nicht dasselbe. Bei schreibenden Vorgängen muss klar sein, wie ein System bereits bearbeitete Anforderungen erkennt.
Der Begriff Idempotenz beschreibt, dass die beabsichtigte Wirkung mehrerer gleicher Anfragen der einer einzelnen entspricht. Welche HTTP-Methoden diese Eigenschaft besitzen, erklärt MDN zur Idempotenz. Die Methode allein beantwortet jedoch noch nicht alle Fragen eines konkreten Geschäftsablaufs.
Ein praktisches Beispiel sind Idempotenzschlüssel. Die Stripe-Dokumentation beschreibt, wie eine solche Kennung bei unterstützten Vorgängen kontrollierte Wiederholungen ermöglicht. Dieses Verhalten darf nicht ungeprüft auf eine andere API übertragen werden. Dafür zählen deren Vertrag, Gültigkeitsdauer und Fehlerverhalten.
Drei Dinge vor dem Programmieren vereinbaren
Die Vorgangskennung: Welche Kennung verbindet denselben fachlichen Vorgang über beide Systeme hinweg? Eine Kundenbestellung braucht eine andere Identität als ein einzelner Übertragungsversuch.
Die Bestätigung: Wann gilt eine Übergabe als abgeschlossen? Der Empfang einer Anfrage ist nicht immer gleichbedeutend mit der vollständigen Verarbeitung im Zielsystem.
Die Klärung: Wer übernimmt einen Vorgang, dessen Ergebnis unklar bleibt? Ohne Zuständigkeit kann eine technische Warteschlange zum dauerhaften Ablageort für ungelöste Arbeit werden.
Diese Fragen lassen sich mit einer kurzen Prozessskizze beantworten. Sie sollten für das Fachteam genauso verständlich sein wie für die Entwicklung.
Nicht jeden Fehler gleich behandeln
Ein Tippfehler in einer Pflichtangabe verschwindet nicht durch häufigeres Senden. Ein vorübergehender Verbindungsfehler kann dagegen einen späteren Versuch rechtfertigen. Die Regeln hängen von der konkreten Schnittstelle ab.
| Situation | Was geklärt werden sollte |
|---|---|
| Pflichtangabe fehlt | Wer korrigiert den Datensatz? |
| Antwort bleibt aus | Kann der Status unabhängig abgefragt werden? |
| Zugriff wird abgelehnt | Welche Berechtigung oder Konfiguration fehlt? |
| System begrenzt Anfragen | Welche Warte- und Wiederholungsregeln gelten? |
| Gleicher Vorgang kommt erneut | Wie wird eine doppelte Wirkung vermieden? |
Lege außerdem eine Grenze für automatische Versuche fest. Ein Vorgang sollte nicht endlos zwischen Systemen kreisen. Nach der vereinbarten Grenze braucht es einen sichtbaren Zustand und einen nächsten Bearbeitungsschritt.
Beobachtbarkeit gehört zum Ablauf
Für die Fehlersuche hilft eine gemeinsame technische Vorgangskennung in den beteiligten Schritten. Protokolle sollten beantworten können, wann welcher Übergang versucht wurde und welche Antwort vorlag. Zugangsdaten und unnötige personenbezogene Inhalte gehören dabei nicht in frei zugängliche Logs.
Das Fachteam benötigt oft eine andere Ansicht als die Entwicklung: Welche Vorgänge sind offen, was blockiert sie und wer ist zuständig? Plane diese Information mit ein, statt ausschließlich technische Fehlermeldungen auszugeben.
Eine kleine Abnahmeliste mit großer Wirkung
Teste nicht nur die erfolgreiche Übertragung. Unterbrich auch bewusst die Antwort, sende einen Vorgang erneut und verwende unvollständige Eingaben. Prüfe gemeinsam, ob Ergebnis und nächste Handlung jeweils verständlich bleiben.
Ein guter Testfall benennt Ausgangslage, Aktion, erwarteten Zustand und Verantwortliche. „Der Fehler wird geloggt“ ist noch keine ausreichende Beschreibung dafür, was mit der offenen Bestellung passiert.
Bei einem bestehenden System lohnt es sich, zuerst die tatsächlichen Fehlerfälle zu sammeln. Daraus entsteht ein gezielter Verbesserungsplan statt einer vollständigen Neuentwicklung auf Verdacht.
Von der Schnittstelle zum betreuten Prozess
Eine API-Anbindung besteht nicht nur aus dem Austausch von Feldern. Sie verbindet Identitäten, Zustände und Verantwortung zwischen Teams und Systemen. Werden diese Fragen früh geklärt, lässt sich die technische Umsetzung genauer planen.
Wir entwickeln solche Verbindungen als Teil individueller Software und Branchenlösungen. Im Projektgespräch beginnen wir mit eurem Ablauf, den vorhandenen Schnittstellen und den Fällen, die heute noch manuell geklärt werden müssen.
Häufige Fragen
Soll jede fehlgeschlagene Anfrage automatisch wiederholt werden?
Nein. Ob eine Wiederholung sinnvoll ist, hängt von Fehlerart, Vorgang und Verhalten der Gegenstelle ab. Besonders bei schreibenden Vorgängen muss eine doppelte Wirkung verhindert werden.
Reicht eine erfolgreiche HTTP-Antwort als Abschluss?
Nur wenn der Vertrag der Schnittstelle diesen Abschluss tatsächlich beschreibt. Manche Abläufe bestätigen zunächst den Empfang und verarbeiten danach weiter.
Was sollte vor dem Start feststehen?
Vorgangskennungen, Bestätigungen, Wiederholungsregeln, offene Zustände und Zuständigkeiten. Ein kleiner gemeinsam getesteter Ablauf ist dafür oft der beste Ausgangspunkt.