קריאת יומני הבקשות של 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, סיסמאות פרוקסי, טוקנים, קובצי cookie ונתוני לקוחות מהדוח ומכל קובץ מצורף. התמיכה מקבלת מזהי משימות ובקשות וחותמות זמן לאחר הסרת מידע רגיש; אין צורך בטוקן גולמי כדי לזהות את הניסיון.