Datenmodelle
Teil von API-Limits und Leistung
Datensätze ohne Verlust einzelner Fehler bündeln
Batch-Antworten je Datensatz zuordnen, Teilfehler erkennen und nur geklärte Einträge erneut verarbeiten.
Ordnen Sie vor einem Batch-Aufruf jedem Datensatz eine stabile Quellkennung und eine Teilanfrage zu. Werten Sie danach jede Teilantwort nach der Dokumentation der konkreten API aus. Ein äußerer HTTP-Erfolg bestätigt bei manchen Diensten weder jeden Eintrag noch dessen späteres Geschäftsergebnis.
Die Batch-Regel der Operation prüfen
Microsoft Graph nutzt in JSON-Batches IDs, um Anfragen und Antworten zuzuordnen; die Antworten können in abweichender Reihenfolge eintreffen. Eine gedrosselte Teilanfrage kann 429 melden.
Beim SQS-Aufruf SendMessageBatch listet die Antwort erfolgreiche und fehlgeschlagene Einträge getrennt. Auch hier sind Fehler trotz HTTP 200 möglich. Ein bestätigter SQS-Sendeerfolg bedeutet, dass die Nachricht eingereiht wurde; die spätere Verarbeitung ist damit nicht belegt.
Google Sheets spreadsheets.batchUpdate ist eine weitere Batch-Methode. Prüfen Sie Antworten und aktuelle Datenstände jeweils anhand der API-Dokumentation und Ihres konkreten Ablaufs.
Kritische API-Statuscodes und deren Bedeutung
- HTTP 200 (OK)
- Anfrage empfangen und in Warteschlange gestellt – aber nicht unbedingt verarbeitet
- HTTP 429 (Too Many Requests)
- Drosselung durch API; erneuter Versuch mit Backoff
- Fehler in Batch-Antwort (z. B. SQS)
- Einzelne Einträge können fehlschlagen, trotz Erfolg des gesamten Aufrufs
Einträge vor und nach dem Versand zuordnen
Angenommen, fünf Materialpositionen sollen übertragen werden. Halten Sie vor dem Versand für jede Position Quellkennung, beabsichtigte Operation und Batch-ID fest. Die Batch-ID verbindet Anfrage und Teilantwort; die fachliche Kennung bleibt über spätere Versuche hinweg gleich.
| Befund für einen Eintrag | Nächster Schritt |
|---|---|
| API-Erfolg bestätigt | Gelieferte Zielkennung speichern; eine spätere fachliche Übernahme gegebenenfalls gesondert prüfen. |
| Eindeutiger Teilfehler | Ursache auswerten und nur diesen Eintrag nach passender Regel korrigieren oder erneut versuchen. |
| Gesamte Anforderung atomar abgewiesen | Keinen enthaltenen Eintrag als angewendet markieren; Ursache beheben. |
| Antwort fehlt oder ist nicht zuordenbar | Zielzustand prüfen; bis dahin weder Erfolg noch Fehlschlag behaupten. |
Fehlt eine erwartete Teilantwort oder erscheint eine unbekannte ID, bleibt die Zuordnung ungeklärt. Markieren Sie solche Einträge nicht still als erfolgreich. Beachten Sie bei voneinander abhängigen Teilanfragen außerdem die dokumentierte Reihenfolge und Abhängigkeitsregel der API.
Gezielte Wiederaufnahme sichern
Speichern Sie offene Teilfehler so, dass sie nach einem Neustart auffindbar bleiben. Ein erneuter Versuch verwendet dieselbe fachliche Zuordnung und lässt bestätigte Einträge aus. Ging die Antwort auf einen möglicherweise wirksamen Schreibvorgang verloren, klären Sie dessen Ausgang vor einem neuen Versand.
Beim Empfang von SQS-Nachrichten durch AWS Lambda gibt es eine andere Batch-Funktion: Mit konfiguriertem ReportBatchItemFailures und einer passenden Funktionsantwort können nur fehlgeschlagene Nachrichten erneut sichtbar werden. Wirft die Funktion eine Ausnahme, gilt der ganze Batch als fehlgeschlagen. Diese Empfangsregel ist nicht SendMessageBatch.
Ein brauchbarer Prüfsatz umfasst einen vollständigen Erfolg, einen Teilfehler, eine atomar abgewiesene Anforderung und eine verlorene Antwort. Entscheidend ist der bekannte Zustand jeder Quellkennung, nicht allein der Status des Batch-Aufrufs.
Sichere Wiederaufnahme von fehlgeschlagenen Batch-Operationen
- Offene Teilfehler persistent speichern
- Erneuter Versuch mit gleicher fachlicher Zuordnung, bereits bestätigte Einträge auslassen
- Bei verlorener AntwortZielzustand prüfen, bevor erneut versendet wird
- AWS LambdaReportBatchItemFailures nutzen, um nur fehlgeschlagene Nachrichten wieder sichtbar zu machen
