solvethree-Anfrageprotokolle bei Integrationsfehlern lesen

Von solvethree4 Min. Lesezeit

Beginnen Sie mit der Task-ID oder requestId des fehlgeschlagenen Versuchs. Suchen Sie die passende Anfrage in der Konsole und vergleichen Sie sie dann mit der HTTP-Antwort und dem Task-Status, die Ihre Integration aufgezeichnet hat.

Auf dieser Seite

Den fehlgeschlagenen Versuch finden

  1. 1.

    Anfrageprotokolle öffnen

    Öffnen Sie in der Konsole /request-logs. Das Suchfeld ist durch seinen Platzhalter gekennzeichnet: „Anfrage-ID, Website, Aktion oder Fehler“. Suchen Sie nach der aufgezeichneten Task-/Anfragekennung; verwenden Sie die Website oder Aktion, um zugehörige Versuche zu finden.

  2. 2.

    Mit „Alle“ beginnen

    Lassen Sie bei der Suche nach der Anfrage den Filter „Alle“ ausgewählt. Grenzen Sie die Ergebnisse anschließend mit „Erfolgreich“, „Fehlgeschlagen“, „In Warteschlange“ oder „Abgelehnt“ ein. Ein von Anfang an engerer Filter kann den untersuchten Versuch ausblenden.

  3. 3.

    Zeitstempel abgleichen

    Die Spalten heißen „Anfrage-ID“, „Website“, „Aktion“, „Abrechnung“, „Latenz“, „Zeit“ und „Ergebnis“. Gleichen Sie „Zeit“, „Website“ und „Aktion“ mit Ihren Anwendungsaufzeichnungen ab, damit Sie nicht einen anderen Versuch mit demselben Ziel untersuchen.

Vergleichen Sie die Latenz der relevanten Zeilen, um langsamere Versuche zu erkennen. Halten Sie daneben die HTTP-Zeitmessungen Ihrer Anwendung bereit. Gehen Sie nicht davon aus, dass ein einzelner Konsolenwert die gesamte vom Client beobachtete Verzögerung erklärt.

„CSV exportieren“ exportiert die gefilterten Zeilen. Stellen Sie Suche und Filter vor dem Export auf die relevanten Versuche ein und prüfen Sie die Datei, bevor Sie sie weitergeben.

HTTP-Fehler, Task-Fehler und Ablehnungen durch die Zielwebsite unterscheiden

Die Konsolenfilter beschreiben die Ergebnisse von Serviceanfragen und Lösungsvorgängen. „Erfolgreich“ bestätigt nicht, dass die nachgelagerte Website Ihr Token akzeptiert hat. Ermitteln Sie anhand der HTTP-Antwort und der Task-Nutzdaten, welcher Teil fehlgeschlagen ist.

Die API hat einen HTTP-Status zurückgegeben, der keinen Erfolg anzeigt.

Lesen Sie den vom Client aufgezeichneten Status und die Fehlerantwort. Behandeln Sie diese nicht als Nutzdaten eines erfolgreichen Tasks.

Probiere Folgendes: Behandeln Sie zuerst den HTTP-Fehler und beheben Sie das gemeldete Problem vor einem erneuten Versuch. Gehen Sie nicht davon aus, dass jeder Fehler auf unzureichendes Guthaben hinweist. Siehe API-Fehlerbehandlung.

Der Task wartet oder wird gerade gelöst.

Das sind nicht abschließende Task-Status, keine verwendbaren Lösungen.

Probiere Folgendes: Fragen Sie diesen Task weiter ab, bis er fertig oder fehlgeschlagen ist. Erstellen Sie nicht allein deshalb einen Ersatz, weil noch keine Lösung verfügbar ist.

Der Task ist fehlgeschlagen.

Lesen Sie sowohl errorCode als auch error. Beispielsweise ist site-unreachable ein Task-Fehlercode.

Probiere Folgendes: Beenden Sie die Statusabfragen für diesen Task und beheben Sie die gemeldete Ursache vor einem weiteren Versuch. Fehlgeschlagene Lösungsvorgänge werden erstattet; unveränderte ungültige Eingaben werden durch erneute Versuche nicht korrigiert.

Bei der Task-Erstellung ist eine Zeitüberschreitung aufgetreten, und Sie wissen nicht, ob sie erfolgreich war.

Bewahren Sie eine eventuell vorhandene Task-ID und die für den Versuch verwendete requestId auf. Eine Verbindungszeitüberschreitung belegt nicht, dass die Erstellung fehlgeschlagen ist.

Probiere Folgendes: Rufen Sie den Task ab, wenn Sie seine ID haben. Falls nicht, Sie aber eine requestId angegeben haben, senden Sie dieselbe Task-Anfrage mit dieser ID erneut, um den vorhandenen Task wieder abzurufen. Verwenden Sie sie nicht mit geänderten Eingaben erneut; das führt zu einem Konflikt.

Der Task ist fertig, aber die Website lehnt die Übermittlung ab.

Prüfen Sie die ausgehende Websiteanfrage. Vergewissern Sie sich, dass sie solution.token enthält und nicht die Task-ID oder ein älteres Token.

Probiere Folgendes: Verwenden Sie die zurückgegebenen Werte userAgent und secChUa mit dem erfolgreichen Proxy und dem vorgesehenen Ziel. Vermischen Sie keine Identitäten und wechseln Sie zwischen Lösungsvorgang und Übermittlung nicht den Proxy. Ein HTTP 403 der Zielwebsite allein zeigt nicht, welcher Schutzmechanismus die Anfrage abgelehnt hat.

Dem Support Kennungen senden, keine Geheimnisse

Wenn die Ursache weiterhin unklar ist, wenden Sie sich an [email protected]. Geben Sie genügend Informationen an, um den Versuch zu finden und einen Servicefehler von einer abgelehnten Übermittlung an die Website zu unterscheiden.

  • Die Task-ID und/oder requestId, das Produkt und den Zeitstempel mit Zeitzone.
  • Den HTTP-Status der API oder errorCode und error des abgeschlossenen Tasks.
  • Den Zielhostnamen und die Aktion.
  • Eine bereinigte Beschreibung der Antwort mit der Angabe, ob sie von solvethree oder der Zielwebsite stammt.
  • Falls hilfreich, relevante gefilterte Protokollzeilen, die vor dem Senden geprüft und bereinigt wurden.

Entfernen Sie API-Schlüssel, Proxy-Passwörter, Tokens, Cookies und Kundendaten aus dem Bericht und allen Anhängen. Der Support akzeptiert bereinigte Task-/Anfrage-IDs und Zeitstempel; ein unverarbeitetes Token ist zur Identifizierung des Versuchs nicht erforderlich.

Noch nicht weitergekommen?

Sende dem Support deine Task-ID und die erhaltene Fehlermeldung.

Support kontaktieren
solvethree-Anfrageprotokolle bei Integrationsfehlern lesen · solvethree