Entegrasyon başarısız olduğunda solvethree istek günlüklerini okuyun

1. 1.

   İstek günlüklerini açın

   Konsolda /request-logs sayfasını açın. Arama alanının yer tutucu metni şöyledir: “İstek kimliği, site, eylem veya hata”. Kaydettiğiniz görev/istek kimliğini arayın; ilgili denemeleri bulmak için siteyi veya eylemi kullanın.

2. 2.

   Tümü ile başlayın

   İsteği bulurken Tümü filtresini seçili tutun. Ardından Başarılı, Başarısız, Kuyrukta veya Reddedildi ile sonuçları daraltın. Daha dar bir filtreyle başlamak, araştırdığınız denemeyi gizleyebilir.

3. 3.

   Zaman damgasını eşleştirin

   Sütunlar İstek Kimliği, Site, Eylem, Faturalandırma, Gecikme, Zaman ve Sonuç'tur. Aynı hedefteki başka bir denemeyi araştırmamak için Zaman, Site ve Eylem değerlerini uygulama kayıtlarınızla eşleştirin.

Daha yavaş denemeleri belirlemek için ilgili satırlardaki Gecikme değerlerini karşılaştırın. Uygulamanızın HTTP sürelerini de bunların yanında tutun; konsoldaki tek bir değerin istemcinizin gözlemlediği gecikmenin tamamını açıkladığını varsaymayın.

CSV olarak dışa aktar, filtrelenmiş satırları dışa aktarır. Dışa aktarmadan önce aramayı ve filtreleri ilgili denemelere göre ayarlayın, ardından paylaşmadan önce dosyayı inceleyin.

Konsol filtreleri, hizmetin istek/çözüm sonuçlarını tanımlar. Başarılı durumu, hedef web sitesinin token'ınızı kabul ettiğini doğrulamaz. Hangi kısmın başarısız olduğunu belirlemek için HTTP yanıtını ve görev verilerini kullanın.

API, başarı belirtmeyen bir HTTP durumu döndürdü.

İstemcinizin kaydettiği durumu ve hata yanıtını okuyun. Bunu başarılı bir görevin yanıt verisi olarak değerlendirmeyin.

Şunu deneyin: Önce HTTP hatasını ele alın ve yeniden denemeden önce bildirilen sorunu düzeltin. Her başarısızlığın yetersiz bakiye anlamına geldiğini varsaymayın. API hata yönetimine bakın.

Görev beklemede veya çözülüyor.

Bunlar görevin henüz sonlanmadığını belirten durumlardır; kullanılabilir çözümler değildir.

Şunu deneyin: Görev hazır veya başarısız duruma gelene kadar durumunu sorgulamaya devam edin. Yalnızca çözüm henüz mevcut değil diye yerine yeni bir görev oluşturmayın.

Görev başarısız oldu.

Hem errorCode hem de error alanını okuyun. Örneğin site-unreachable bir görev hata kodudur.

Şunu deneyin: Bu görevin durumunu sorgulamayı durdurun ve başka bir denemeden önce bildirilen nedeni giderin. Başarısız çözümlerin ücreti iade edilir; geçersiz girdileri değiştirmeden yeniden denemek bunları düzeltmez.

Görev oluşturma zaman aşımına uğradı ve başarılı olup olmadığını bilmiyorsunuz.

Varsa görev kimliğini ve denemede kullanılan requestId değerini saklayın. Bağlantının zaman aşımına uğraması, oluşturmanın başarısız olduğunu kanıtlamaz.

Şunu deneyin: Kimliği varsa görevi alın. Yoksa ve bir requestId sağladıysanız mevcut göreve yeniden erişmek için aynı görev isteğini bu kimlikle tekrar gönderin. Değiştirilmiş girdilerle aynı kimliği yeniden kullanmayın; bu, çakışmaya yol açar.

Görev hazır, ancak web sitesi gönderimi reddediyor.

Web sitesine giden isteği inceleyin. Görev kimliği veya eski bir token yerine solution.token içerdiğini doğrulayın.

Şunu deneyin: Döndürülen userAgent ve secChUa değerlerini başarılı proxy ve amaçlanan hedefle birlikte kullanın. Çözüm ile gönderim arasında kimlikleri karıştırmayın veya proxy değiştirmeyin. Hedeften gelen bir HTTP 403 yanıtı tek başına isteği hangi korumanın reddettiğini göstermez.

Neden hâlâ net değilse denemeyi bulmaya ve hizmet hatasını web sitesinin reddettiği bir gönderimden ayırmaya yetecek bilgilerle [email protected] adresine ulaşın.

• Görev kimliği ve/veya requestId, ürün ve saat dilimiyle birlikte zaman damgası.
• API'nin HTTP durumu veya sonlanan görevin errorCode ve error değerleri.
• Hedef ana makine adı ve eylem.
• Yanıtın solvethree'den mi yoksa hedef web sitesinden mi geldiğini belirten, hassas bilgilerden arındırılmış bir açıklaması.
• Yararlı olacaksa, gönderilmeden önce incelenmiş ve hassas bilgilerden arındırılmış ilgili filtrelenmiş günlük satırları.

Rapordan ve tüm eklerden API anahtarlarını, proxy parolalarını, token'ları, çerezleri ve müşteri verilerini kaldırın. Destek, hassas bilgilerden arındırılmış görev/istek kimliklerini ve zaman damgalarını kabul eder; denemeyi belirlemek için ham token gerekmez.