قراءة سجلات طلبات solvethree عند فشل التكامل

1. 1.

   افتح سجلات الطلبات

   في لوحة التحكم، افتح /request-logs. يحمل حقل البحث النص الإرشادي: «معرّف الطلب أو الموقع أو الإجراء أو الخطأ». ابحث عن معرّف المهمة أو الطلب الذي سجّلته؛ واستخدم الموقع أو الإجراء للعثور على المحاولات ذات الصلة.

2. 2.

   ابدأ بخيار الكل

   أبقِ عامل التصفية «الكل» محددًا أثناء البحث عن الطلب. ثم ضيّق النتائج باستخدام «ناجح» أو «فاشل» أو «في قائمة الانتظار» أو «مرفوض». قد يؤدي البدء بعامل تصفية أضيق إلى إخفاء المحاولة التي تتحقّق منها.

3. 3.

   طابق الطابع الزمني

   الأعمدة هي معرّف الطلب، والموقع، والإجراء، والفوترة، وزمن الاستجابة، والوقت، والنتيجة. طابق الوقت والموقع والإجراء مع سجلات تطبيقك حتى لا تتحقّق من محاولة مختلفة على الموقع المستهدف نفسه.

قارن زمن الاستجابة بين الصفوف ذات الصلة لتحديد المحاولات الأبطأ. احتفظ بقياسات توقيت HTTP الخاصة بتطبيقك إلى جانبها؛ ولا تفترض أن قيمة واحدة في لوحة التحكم تفسّر كامل التأخير الذي رصده عميلك.

يصدّر خيار «تصدير CSV» الصفوف المصفّاة. اضبط البحث وعوامل التصفية على المحاولات ذات الصلة قبل التصدير، ثم راجع الملف قبل مشاركته.

تصف عوامل التصفية في لوحة التحكم نتائج طلبات الخدمة وعمليات الحل. لا تؤكد حالة «ناجح» أن الموقع اللاحق قد قبل رمزك. استخدم استجابة HTTP وحمولة المهمة لتحديد الجزء الذي فشل.

أعادت API حالة HTTP لا تدل على النجاح.

اقرأ الحالة واستجابة الخطأ اللتين سجّلهما عميلك. لا تتعامل معها على أنها حمولة مهمة ناجحة.

جرّب هذا: عالج خطأ HTTP أولًا وصحّح المشكلة المبلّغ عنها قبل إعادة المحاولة. لا تفترض أن كل فشل يعني عدم كفاية الرصيد. راجع معالجة أخطاء API.

المهمة قيد الانتظار أو قيد الحل.

هذه حالات غير نهائية للمهمة، وليست حلولًا قابلة للاستخدام.

جرّب هذا: واصل الاستعلام الدوري عن تلك المهمة حتى تصبح جاهزة أو تفشل. لا تنشئ مهمة بديلة لمجرد أن الحل لم يتوفر بعد.

فشلت المهمة.

اقرأ كلًا من errorCode وerror. على سبيل المثال، site-unreachable هو رمز خطأ للمهمة.

جرّب هذا: توقف عن الاستعلام الدوري عن تلك المهمة وعالج السبب المبلّغ عنه قبل محاولة أخرى. تُرد تكلفة عمليات الحل الفاشلة؛ ولن تؤدي إعادة المحاولة بالمدخلات غير الصالحة نفسها إلى إصلاحها.

انتهت مهلة إنشاء المهمة ولا تعرف ما إذا كان قد نجح.

احتفظ بأي معرّف للمهمة وبقيمة requestId المستخدمة للمحاولة. انتهاء مهلة الاتصال لا يثبت فشل الإنشاء.

جرّب هذا: استرجع المهمة إذا كان لديك معرّفها. وإلا، فإذا كنت قد قدّمت requestId، فأعد إرسال طلب المهمة نفسه بذلك المعرّف لاستعادة المهمة الموجودة. لا تعِد استخدامه مع مدخلات معدّلة؛ فهذا يسبب تعارضًا.

المهمة جاهزة، لكن الموقع يرفض الإرسال.

افحص الطلب الصادر إلى الموقع. تأكّد من أنه يحتوي على solution.token بدلًا من معرّف المهمة أو رمز أقدم.

جرّب هذا: استخدم userAgent وsecChUa المُعادين مع الوكيل الناجح والموقع المستهدف المقصود. لا تخلط الهويات أو تبدّل الوكلاء بين الحل والإرسال. لا تكفي استجابة HTTP 403 من الموقع المستهدف وحدها لتحديد آلية الحماية التي رفضت الطلب.

إذا ظل السبب غير واضح، فتواصل مع [email protected] وقدّم معلومات كافية للعثور على المحاولة والتمييز بين فشل الخدمة ورفض الإرسال إلى الموقع.

• معرّف المهمة و/أو requestId، والمنتج، والطابع الزمني مع منطقته الزمنية.
• حالة HTTP من API، أو errorCode وerror للمهمة التي وصلت إلى حالة نهائية.
• اسم مضيف الموقع المستهدف والإجراء.
• وصف منقّح للاستجابة، يوضح ما إذا كانت صادرة عن solvethree أم عن الموقع المستهدف.
• صفوف السجل المصفّاة ذات الصلة، إن كانت مفيدة، بعد مراجعتها وتنقيحها قبل الإرسال.

أزل مفاتيح API وكلمات مرور الوكلاء والرموز وملفات تعريف الارتباط وبيانات العملاء من التقرير وأي مرفقات. يقبل الدعم معرّفات المهام والطلبات والطوابع الزمنية المنقّحة؛ ولا يلزم الرمز الخام لتحديد المحاولة.