Zusammenfassung

  • Das Gesamtergebnis FAILED kann mit erfolgreichen Einzeloperationen zusammenfallen. Das dokumentierte Beispiel mit fünf Objekten enthält drei Änderungen, einen erfolgreichen Vorgang ohne Änderung und einen Fehler.
  • Eine unterbrochene HTTP-Verbindung beendet nicht zwangsläufig die Verarbeitung auf dem Server. Eine fehlende Antwort ist deshalb zunächst ein unbekanntes Ergebnis, kein Beleg für einen unveränderten Datenbestand.
  • Benachrichtigungen bilden den jeweiligen Empfängerkreis ab, nicht notwendig den gesamten Auftrag. Eine gezielte Wiederaufnahme stützt sich auf Einzelresultate und berechtigte Nachprüfungen.

Ein Auftrag, mehrere Ergebnisse

Die Grenze eines Auftrags ist eine Entscheidung des Absenders. Er möchte mehrere Datensätze zusammen bearbeiten und schickt die betreffenden Objekte in einer Nachricht. Daraus folgt noch nicht, dass die Datenbank diese Nachricht als eine unteilbare Zustandsänderung behandelt. Gerade nach einem Fehler wird diese Unterscheidung wichtig: Der Auftrag kann unvollständig sein, obwohl ein Teil der gewünschten Änderungen bereits gespeichert wurde.

Die Dokumentation der Verarbeitungsantworten von RIPE NCC liefert dafür ein anschauliches Zahlenbeispiel. Fünf Objekte werden erkannt. Vier Vorgänge gelten als erfolgreich: ein Anlegen, zwei Änderungen und ein NOOP. Eine weitere Änderung scheitert. Der NOOP bedeutet, dass das eingereichte Objekt bereits mit dem gespeicherten übereinstimmt. Es musste nichts geändert werden.

Vier erfolgreiche Vorgänge sind in diesem Beispiel also drei tatsächliche Änderungen. Die eine gescheiterte Änderung macht aus ihnen nicht nachträglich null. Zugleich erklärt die Seite für die zusammenfassende Antwort im E-Mail-Stil: Schon ein Fehler führt zum Gesamtergebnis FAILED. Die Anzeige für die Nachricht und die Ergebnisse ihrer Objekte haben verschiedene Bezugsgrößen.

Das ist ein Lehrbeispiel, kein beobachteter Betriebsfall. Die getrennten Beispiele für Betreff und Ergebniszählung auf der Seite werden hier auch nicht zu einer vermeintlich aufgezeichneten Nachricht zusammengesetzt. Belegt ist die dokumentierte Bedeutung der Ergebnisse, nicht eine bestimmte fehlgeschlagene Kundenoperation.

Wer aus FAILED trotzdem „nichts geschehen“ macht, erfindet einen Ausgangszustand für den nächsten Versuch. Wer lediglich die erfolgreichen Objekte zählt, kann umgekehrt übersehen, dass der eigentliche Auftrag unerledigt bleibt. Die nützlichere Frage lautet: Welcher Teil der Absicht wurde umgesetzt, welcher nicht, und worüber wissen wir noch zu wenig?

Einzelverarbeitung ist kein Versehen

Nach der Beschreibung der Objektverarbeitung stoppt der Fehler eines Objekts nicht automatisch die Bearbeitung aller folgenden. Die Verarbeitung erfolgt einzeln. Das verhindert nicht, dass ein Fehler weitere Fehler nach sich ziehen kann: Wird ein benötigtes Objekt nicht angelegt, kann eine darauf angewiesene Operation an der referenziellen Integrität scheitern.

Auch eine starre Bearbeitung in exakt der eingereichten Reihenfolge wäre als pauschale Beschreibung falsch. AUTO-n-Bezüge können die Reihenfolge beeinflussen. Daraus folgt wiederum keine Zusage, beliebige vom Absender gedachte Abhängigkeiten aufzulösen. Entscheidend ist, welche Beziehungen das dokumentierte Verfahren tatsächlich berücksichtigt.

Man stelle sich eine geplante Wartung vor, bei der ein vorbereitendes Objekt angelegt und mehrere andere Objekte geändert werden sollen. Die Vorbereitung scheitert, eine davon unabhängige Änderung gelingt. Nun muss die Organisation zwischen dem fehlenden Baustein, den davon abhängigen Operationen und dem bereits brauchbaren Ergebnis unterscheiden. Dies ist ein hypothetischer Ablauf, kein Bericht über einen Geschädigten.

Für diese Unabhängigkeit gibt es ein vernünftiges Argument. Ein fehlerhaftes oder nicht ausreichend autorisiertes Objekt sollte nicht zwingend jede sachlich unabhängige, zulässige Wartung verhindern. Die Kontrollen je Objekt bleiben sinnvoll, auch wenn der Absender die Operationen gemeinsam verpackt. Ebenso kann ein NOOP den gewünschten Zustand bestätigen, statt einen Mangel zu markieren.

Eine Forderung nach universeller Atomarität würde daher zu kurz greifen. Für manche Vorhaben ist Alles-oder-nichts wichtig; für andere ist es hilfreich, unabhängige gültige Arbeiten weiterzuführen. Das Problem beginnt dort, wo der Client einen Vertrag voraussetzt, den die verwendete Schnittstelle nicht bietet. Ein einziges rotes oder grünes Signal darf die feineren Ergebnisse nicht verschlucken.

Die vorhandene Antwort unterscheidet bereits gescheiterte Vorgänge, erfolgreiche Vorgänge und nicht erkannte Absätze. Es fehlt also nicht grundsätzlich an einer Ausdrucksmöglichkeit für gemischte Ergebnisse. Die praktische Frage ist, ob die Anwendung diese Informationen bis zu der Person bewahrt, die über die Wiederaufnahme entscheidet.

Was die Verbindung nicht verrät

Eine weitere Unterscheidung betrifft HTTP. Für Syncupdates beschreibt RIPE NCC, dass HTTP 200 auch bei verarbeiteten Anfragen mit Objektfehlern vorkommen kann. Ein Transportstatus ersetzt deshalb nicht die Auswertung des Antwortinhalts. Diese Aussage bezieht sich auf den dokumentierten Syncupdates-Fall und ist keine allgemeine Behauptung über sämtliche HTTP-Schnittstellen von RIPE NCC.

Bei einer fehlenden Antwort ist die Lage anders. Die Dokumentation von Syncupdates und der Objektverarbeitung erklärt, dass eine geschlossene Verbindung die serverseitige Arbeit nicht für sich genommen beendet. Die Verarbeitung kann bis zu ihrem Abschluss weiterlaufen. Nur lässt sich die Antwort nicht mehr über die geschlossene Verbindung zustellen.

Abgeschlossen heißt dabei nicht ausnahmslos erfolgreich. Es heißt, dass die Bewertung der Operationen zu Ende geführt werden kann. Der Aufrufer hat möglicherweise weder die erfolgreichen Änderungen noch die Ablehnungen gesehen. Ein Timeout muss deshalb als ungeklärtes Ergebnis behandelt werden, bis zusätzliche Informationen eine genauere Einordnung erlauben. Es ist weder eine gewöhnliche Ablehnung noch eine stillschweigende Erfolgsmeldung.

Die Wahl einer anderen Schnittstelle löst dieses Erkenntnisproblem nicht automatisch. Syncupdates kann mehrere Objekte in einer Nachricht führen. Die REST-API arbeitet mit Objektoperationen und einem eigenen XML- beziehungsweise JSON-Antwortmodell. Mehrere getrennte REST-Anfragen werden aber nicht dadurch atomar, dass sie zur selben Wartungsaufgabe gehören. Der Zusammenhang des Auftrags bleibt eine Aufgabe des Clients und seiner Betreiber.

Für diese Analyse wurden weder Timeouts ausgelöst noch echte Aktualisierungen vorgenommen. Es gibt hier keine gemessene Fehlerquote oder Bearbeitungsdauer. Die engere Schlussfolgerung reicht aus: Solange der Server weiterarbeiten kann, ist das Ende der Verbindung kein verlässlicher Ersatz für das Ergebnis der einzelnen Operation.

Der Empfänger sieht seinen Ausschnitt

Auch E-Mail-Benachrichtigungen sind kein allgemeiner Abschlussbericht. Die Benachrichtigungsregeln ergeben Empfänger aus Attributen und Verweisen der jeweiligen Objekte. Verschiedene Empfänger können unterschiedliche Teilmengen sehen. Wer eine Nachricht über einen geänderten Eintrag erhält, weiß damit nicht, ob sämtliche übrigen Schritte des Absenders funktioniert haben.

Bei einer Änderung werden die notify-Adressen des alten Objekts verwendet. Andere Attribute oder Verweise können weitere Empfänger ergeben. Daraus darf man nicht die stärkere Behauptung ableiten, dass eine neu eingetragene Adresse über keinen anderen Zusammenhang eine Nachricht erhalten könnte. Entscheidend ist die objektbezogene Reichweite der Mitteilung.

Außerdem unterscheiden sich die Anlässe: Eine gewöhnliche Benachrichtigung über eine erfolgreiche Änderung ist etwas anderes als eine upd-to-Mitteilung wegen fehlgeschlagener Authentifizierung. Der Eingang einer Nachricht beweist nicht den Erfolg des gesamten Pakets. Ihr Ausbleiben in einem einzelnen Postfach beweist ebenso wenig, dass nichts geändert wurde. Die Zustellung von E-Mails wurde für diesen Beitrag nicht untersucht.

Für die Zusammenarbeit folgt daraus eine schlichte Grenze. Berichte verschiedener Empfänger können nützlich sein, sollten aber nicht ohne Weiteres als vollständige Abdeckung aller Objekte gelten. Ein Ergebnis an den Absender und eine Empfängerbenachrichtigung sind unterschiedliche Beobachtungen. Ihre Aussagekraft wächst nicht allein dadurch, dass sie in derselben Besprechung erwähnt werden.

Vom Befund zum nächsten Versuch

Die Wiederaufnahme sollte dort ansetzen, wo sich Aussagen belegen lassen. Für jedes beabsichtigte Objekt kann die Organisation zwischen bestätigter Änderung, ausdrücklicher Ablehnung, erfolgreicher Nichtänderung und ungeklärtem Ausgang unterscheiden. Dazu gehören die ursprüngliche Operation, der Zeitpunkt, die Schnittstelle und eine spätere berechtigte Beobachtung. Dies ist eine aus dem dokumentierten Verhalten abgeleitete Arbeitsweise, kein neu vorgeschriebenes RIPE-Formular.

Auch Nachlesen verlangt Geduld und Kontext. Die REST-Dokumentation trennt die Antwort auf die Aktualisierung von der anschließenden Sichtbarkeit in Abfragen und Suchen. Eine unmittelbar noch alte Antwort belegt für sich genommen kein Rollback. Der Beitrag nennt deshalb keinen vermeintlich gemessenen Wartewert und empfiehlt kein hektisches Abfragen. Solange die Beobachtung nicht eindeutig ist, bleibt ihr Status offen.

Ein Dry-run kann schon vor der eigentlichen Änderung Syntax, Geschäftsregeln, Autorisierung und referenzielle Integrität prüfen, ohne Daten zu ändern. Er liefert eine Verarbeitungsantwort, nicht die gewöhnlichen Änderungsbenachrichtigungen. Damit wird eine Absicht geprüft, aber kein künftiger Zustand reserviert. Ein bestandener Probelauf garantiert nicht das Ergebnis einer späteren Ausführung. Für diese Recherche wurde kein solcher Aufruf an die RIPE-Datenbank gesendet.

Die Historienfunktion eröffnet den Blick auf frühere Objektversionen, allerdings nicht auf historische personenbezogene Daten. Diese Grenze der Abfrage beweist keine Abwesenheit interner Aufzeichnungen. Sie ist auch kein Anlass, Kontaktinformationen oder Zugangsdaten in frei zugängliche Arbeitsprotokolle zu kopieren. Originalantworten gehören in einen angemessen beschränkten Zugriff; für operative Auszüge ist nur das Erforderliche nötig.

Ein erneuter Versuch ist keineswegs grundsätzlich schädlich. Ein weiterhin autorisiertes, unverändertes und bereits identisches Objekt kann erneut ohne Änderung enden. Nur lässt sich diese Möglichkeit nicht als pauschale Garantie auf eine ungeklärte Objektgruppe übertragen. FAILED ist ein Anlass, genauer hinzusehen. Es ist weder der Befehl, alles rückgängig zu machen, noch die Erlaubnis, blind von vorn zu beginnen.

Quellen

  1. RIPE NCC — Verarbeitungsantworten
  2. RIPE NCC — Objektverarbeitung
  3. RIPE NCC — Syncupdates
  4. RIPE NCC — Benachrichtigungen
  5. RIPE NCC — REST-API der RIPE-Datenbank
  6. RIPE NCC — Prüfung ohne Datenänderung
  7. RIPE NCC — Historische Daten