כשל API באוטומציה: למה צריך לבדוק אם הפעולה כבר בוצעה
מאת איתי דילן זריהן זיונץ· הבעלים של POCAST
היעדר תשובה אינו מוכיח שהפעולה לא התבצעה במערכת היעד. ניסיון חוזר בלי בירור יכול ליצור פעולה נוספת.
התשובה בקצרה
היעדר תשובה אינו מוכיח שהפעולה לא התבצעה במערכת היעד. ניסיון חוזר בלי בירור יכול ליצור פעולה נוספת. תכנון כשל צריך להבחין בין שגיאה ידועה, חוסר זמינות ותוצאה שאינה ידועה.
החלטות ותהליך עבודה
רשמו אילו פעולות משנות מידע ואיך אפשר לזהות אותן בשני הצדדים. קבעו מתי מותר לנסות שוב, כמה פעמים ומי מטפל כשאין ודאות. השתמשו במנגנון מניעת כפילות או בבדיקת מצב לפי יכולות החיבור, ולא רק בהמתנה ארוכה יותר. שמרו מצב ״לבירור״ כאשר אי אפשר לקבוע תוצאה. בדיקות הכשל יבוצעו עם יעד מדומה כדי שלא ליצור הזמנות או הודעות אמיתיות.
| תוצאה | מה יודעים | צעד הבא |
|---|---|---|
| דחייה מפורשת | הבקשה נדחתה לפי התשובה | בדיקת הסיבה והקלט |
| פעולה מאושרת | היעד מאשר ביצוע | שמירת התוצאה והמשך |
| אין תשובה | לא ידוע אם בוצעה | בירור מצב לפני ניסיון חוזר |
תרחיש להמחשה
בחיבור לדוגמה נשלחה בקשת יצירת משימה אך לא חזרה תשובה. המערכת בודקת לפי מזהה הבקשה אם המשימה קיימת לפני שליחה חוזרת. אם אין אפשרות לבדוק, המקרה מועבר לטיפול במקום לסמן כישלון סופי.
רשימת בדיקה
- פעולות משנות מידע מזוהות.
- מזהה בקשה מאפשר בירור.
- ניסיונות חוזרים מוגבלים.
- תוצאה לא ידועה מקבלת מצב נפרד.
- בדיקות נעשות מול יעד מדומה.
בדיקת החלטה לפני שממשיכים
דמו מצב שבו היעד ביצע פעולה אך לא החזיר תשובה. לפני ניסיון נוסף צריך לברר את התוצאה או להשתמש במנגנון מתאים למניעת כפילות.
שאלה שכדאי להכניס לבריף
איך מזהים פעולה שכבר בוצעה כאשר התשובה לא הגיעה למערכת המקור?
המוצר והתכולה לבירור
תכנון טיפול בכשל API — מסלול ניסיון חוזר וטיפול. השירות כפוף להצעת מחיר מותאמת לאחר בירור החומרים, ההיקף ונקודות האישור.
לעריכת בריף ולפנייה בנושא המוצר.
לכל המוצרים בתחום אוטומציות וחיבור בין מערכות.
הכנת בריף
כלי לתכנון הפרויקט — אפשר להכין סיכום ולערוך אותו לפני פנייה.