Aufträge & Fortschritt
Aufträge verfolgen, Statusmeldungen einordnen, laufende Verarbeitung stoppen und fehlgeschlagene Datensätze erneut versuchen.
Aufträge wiederfinden
Die Auftragsliste der Anreicherung trennt Konsolenaufträge von Aufträgen, die mit einem API-Schlüssel erstellt
wurden. Durchläufe des Impressum-Scrapers und der E-Mail-Prüfung stehen auf den jeweiligen Werkzeugseiten. In der
API hat jedes Produkt einen eigenen Auftragslistenpfad; mit via_api=true oder false
filtern Sie nach dem Zugangsweg.
Auftragsstatus
| API-Status | Bedeutung | Nächster Schritt |
|---|---|---|
validating |
Eingaben werden geprüft. | Warten oder den Auftrag stoppen. |
queued |
Der Auftrag wartet, bis die Verarbeitung seines ersten Datensatzes beginnt. | Status später erneut abrufen. |
processing |
Datensätze werden verarbeitet; started_at nennt den Beginn. |
Fortschritt verfolgen. |
completed |
Alle Datensätze sind abgeschlossen oder teilweise abgeschlossen; keiner ist vollständig fehlgeschlagen. | Ergebnisse und Zahlungsstatus prüfen, anschließend exportieren. |
partially_completed |
Die Verarbeitung ist beendet. Einige Datensätze sind abgeschlossen, andere fehlgeschlagen. | Vorhandene Ergebnisse verwenden und Fehler prüfen. |
failed |
Kein Datensatz wurde erfolgreich abgeschlossen. | Fehlerursache prüfen; ein Ergebnisexport ist nicht verfügbar. |
cancelled |
Der Auftrag wurde gestoppt. | Bereits abgeschlossene Ergebnisse können exportiert werden. |
Die letzten vier Statuswerte sind Endzustände. Beenden Sie dann das regelmäßige Statuspolling. completed
beschreibt den Verarbeitungszustand, nicht die Vollständigkeit aller Datenfelder.
Status einzelner Datensätze
Datensätze beginnen mit pending, wechseln zu processing und enden als
completed, partially_completed oder failed. Bei einem Teilergebnis haben
einzelne Verarbeitungsschritte funktioniert und andere sind fehlgeschlagen. Nicht abgefragte Quellen
(skipped) zählen dabei nicht: Ist jede abgefragte Quelle fehlgeschlagen, endet der Datensatz als
failed und wird bei einem Neustart erneut aufgenommen. Gefundene Daten können trotzdem verwendbar und
kostenpflichtig sein.
Nach dem Stoppen eines Auftrags werden noch offene Datensätze als failed geführt. Ein Datensatz hat
keinen eigenen Status cancelled. In normalisierten API-Antworten liefert error bei Fehlern
oder Teilergebnissen zusätzliche Hinweise.
Fortschritt und Restzeit
| Feld | Interpretation |
|---|---|
total_records |
Gesamtzahl der Eingabedatensätze. |
pending_records, processing_records |
Noch nicht begonnene bzw. gerade bearbeitete Datensätze, jeweils Stand des zuletzt abgeschlossenen Datensatzes. |
completed_records |
Abgeschlossene und teilweise abgeschlossene Datensätze zusammen. |
failed_records |
Fehlgeschlagene Datensätze, einschließlich nach einem Stopp abgebrochener Verarbeitung. |
progress_percent |
Anteil abgeschlossener und fehlgeschlagener Datensätze an der Gesamtzahl. 100 % ist keine Trefferquote. |
eta_seconds_remaining |
Geschätzte Restzeit in Sekunden; null, wenn keine Schätzung vorliegt. |
billing_paused, uncharged_records |
Hinweis auf Ergebnisse, die noch nicht bezahlt werden konnten. Dies ist vom Verarbeitungsstatus getrennt. |
Quellen können zeitweise langsam sein oder Anfragen begrenzen. Deshalb kann sich die Restzeit ändern. Ein API-Auftrag bleibt asynchron, auch wenn er nur einen Datensatz enthält.
Stoppen und erneut versuchen
Ein Auftrag kann in validating, queued oder processing gestoppt werden.
Bereits abgeschlossene Datensätze und ihre Abrechnung bleiben bestehen. Der CSV-Export eines gestoppten Auftrags
enthält die bis dahin abgeschlossenen Datensätze.
Ein Neustart ist für cancelled, failed und partially_completed möglich. Er
nimmt nur Datensätze mit Status failed erneut auf. Bereits abgeschlossene oder teilweise abgeschlossene
Datensätze werden nicht erneut verarbeitet. Gibt es keine fehlgeschlagenen Datensätze, ändert der Neustart nichts.
Nach Ablauf der Aufbewahrungsfrist ist kein Neustart mehr möglich, da die Datensätze gelöscht sind; die API
antwortet dann mit 410.
Nach einem Neustart steht der Auftrag wieder auf queued, bis sein erster Datensatz erneut verarbeitet
wird. started_at und completed_at beschreiben dann den neuen Durchlauf.
Ein Neustart verwendet dieselben Eingaben. Müssen Sie eine falsche Domain oder eine fehlende Stadt korrigieren, erstellen Sie einen neuen Auftrag mit korrigierten Daten. Für reine Zahlungsprobleme verwenden Sie die nachträgliche Abrechnung; ein Neustart ist dafür nicht erforderlich.
Fortschritt über die API
Rufen Sie GET /api/v1/{produkt}/batches/{batch_id}/ beispielsweise alle fünf Sekunden ab. Alternativ
liefert GET /api/v1/{produkt}/batches/{batch_id}/progress/ einen Ereignisstrom (SSE). Setzen Sie für
{produkt} den zum Auftrag gehörenden Präfix aus der Endpunktreferenz ein. Der Stream sendet
beim Verbindungsaufbau den aktuellen Zustand und schließt bei einem Endzustand.
Bei einem Verbindungsabbruch rufen Sie den aktuellen Auftragsstatus erneut ab, bevor Sie die Verbindung wiederherstellen. Beispiele stehen in der Endpunktreferenz.