מגבלת API היא אילוץ בתהליך העבודה, לא רק שגיאה שמנסים שוב. מגדירים תקציב בקשות משותף, מתעדפים עבודה שמותר לבצע, מציגים כמה זמן הרשומות ממתינות ומסכימים מה קורה כשאי אפשר לעמוד במועד עסקי.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
מתחילים במשימה העסקית שמתעכבת
ייבוא לילי עדיין רץ כשהצוות מתחיל לקבל את פניות הלקוחות של היום. שניהם משתמשים באותו API חיצוני, ועבודה חדשה מתחילה להמתין מאחורי רשומות היסטוריות. הוספת תהליך עיבוד נוסף עלולה להגדיל את התחרות על הקיבולת במקום לסיים מהר יותר את העבודה הדחופה. זהו תרחיש תכנון להמחשה, לא אירוע של לקוח או טענה על מערכת ש־AgenticShip מסרה.
RFC 6585 מגדיר HTTP 429 כתשובה על חריגה ממגבלת קצב ומאפשר לכלול כותרת Retry-After. הוא אינו קובע שיטת ספירה אוניברסלית אחת. מוודאים את ההיקף אצל הספק בפועל: אילו בקשות חולקות את המגבלה, על איזה חשבון או יישום היא חלה והאם קיימות מגבלות נפרדות לעבודה במקביל. לא מעתיקים מספר מתוכנית של מוצר לא קשור.
מתקצבים בקשות, לא רק רשומות של לקוחות
רשומה עשויה לדרוש חיפוש, כתיבה ואישור. סופרים את הפעולות בפועל בתהליך המוצע, כולל חלוקה לעמודים וכללי החיוב של הספק. שואלים אילו יישומים נוספים משתמשים באותה מכסה. תקציב שמתעלם מהם הוא הנחה, לא הבטחת קיבולת.
נבחן דוגמה פשוטה במכוון: תקציב משותף מוסכם של 60 בקשות בדקה, עם 12 העברות חדשות של פניות לקוח בדקה שדורשות שתי קריאות כל אחת. אלה 24 בקשות, ונשארות לכל היותר 36 לעבודת רקע. צבר של 180 פעולות בעלות קריאה אחת ידרוש לפחות חמש דקות בקצב הפנוי הקבוע הזה. אלה נתוני תכנון שהומצאו להמחשה, לא מכסת ספק, תפוקה שנמדדה או התחייבות שירות; השהיות, ניסיונות חוזרים ויישומים נוספים יכולים להאריך את ההמתנה.
אם מספר ההעברות החדשות עולה ל־30 בדקה בשתי קריאות לכל העברה, הן צורכות את כל תקציב הדוגמה. תור הרקע אינו יכול להדביק את הפער תחת ההנחות האלה. מציגים את הפשרה לפני שמבטיחים סנכרון בזמן אמת. בזמן האפיון מחליפים את נתוני הדוגמה בספירת בקשות מייצגת שנמדדה.
בוחרים סדרי עדיפות בלי לעקוף את הספק
זהו דף עבודה מוצע שלנו לאפיון, לא תקן API. סוגי עבודה שונים יכולים להמתין בתורים נפרדים, אבל בקשות שחולקות מגבלת ספק עדיין דורשות בקרה מתואמת. עדיפות קובעת איזו בקשה שמותר לבצע תרוץ הבאה; היא אינה מבטלת המתנה שהספק הורה עליה ואינה מעניקה קיבולת נוספת.
| סוג העבודה | כלל תזמון מוצע | מה הצוות חייב לראות |
|---|---|---|
| העברת פניית לקוח מהיום | מעדיפים עבודה עדכנית שמותר לבצע במסגרת התקציב המשותף; שומרים על הסדר הנדרש בתוך אותו מקרה. | זמן הפנייה המקורית, הצעד הממתין ביעד והסיכון לחריגה מהמועד. |
| סיכום פנימי מתוזמן | מאפשרים עיכוב מוגבל שסוכם עם האחראי לדוח. | עד איזה מועד הנתונים הושלמו לאחרונה, לא תווית הצלחה שנראית עדכנית. |
| ייבוא היסטורי | משתמשים בקיבולת פנויה מוסכמת ובנקודת בקרה שמורה; משהים כשעבודה עדכנית זקוקה לה. | הטווח שהושלם, העבודה שנותרה והניסיון הבא שמותר לבצע. |
מגדירים במפורש מי אחראי לניסיון החוזר
Microsoft Graph ממליצה לכבד את Retry-After כשמופעלת הגבלת קצב ולהשתמש בהמתנה מעריכית כשהכותרת חסרה. ההנחיות גם מזהירות מפני סריקות מלאות חוזרות כשקיימים מנגנונים נתמכים למעקב אחר שינויים או להתראות. ההמלצות מתייחסות לפלטפורמה הזאת; מוודאים את הכללים של נקודת הקצה שבה באמת משתמשים.
מחליטים איזו שכבה מתזמנת ניסיונות חוזרים, כדי שה־SDK, תהליך העיבוד והמפעיל לא יחזרו כולם על אותה פעולה בנפרד. שומרים את ההפניה העסקית המקורית ובודקים אם מערכת היעד כבר פעלה כשהתוצאה אינה ודאית. מגדירים מדיניות מוגבלת לניסיונות אוטומטיים ואחראי להסלמה בהתאם לתהליך. לא יוצרים חשבונות נוספים ולא מחליפים מפתחות כדי לעקוף את מגבלות הספק.
מציגים זמן המתנה ושלמות, לא רק גודל תור
תצוגת המפעיל המזערית שאנחנו מציעים כוללת את הפריט שממתין הכי הרבה זמן, המועד העסקי שלו, נקודת הבקרה האחרונה שהושלמה והסיבה להשהיה. תור קטן עם משימת שילוח באיחור עשוי להיות חשוב יותר מתור גדול של הערות היסטוריות. שומרים הפניות אבחון שימושיות בלי להעתיק תוכן לקוח מיותר ליומנים.
מגדירים מי מחליט מתי להשהות ייבוא, ליידע את הצוות הפנימי או להשתמש בחלופה ידנית מאושרת. משימה שממתינה לקיבולת אינה משימה שהושלמה. אם הצוות מסיים אותה ידנית, מתאימים את התוצאה לפני שהתור ממשיך, כדי שההתאוששות לא תיצור הקצאה נוספת. הערכה לזמן סגירת הפער צריכה לציין את הנחותיה ולהשתנות כשהן כבר אינן מתקיימות.
בודקים את תקופת העומס לפני שמבטיחים זמן תגובה
משתמשים בסביבה מבודדת או בספק מדומה, כששליחה אמיתית וכתיבות בעלות השפעה עסקית מושבתות. בודקים גל עבודה חדשה בזמן ייבוא, תשובת הגבלת קצב עם הוראת המתנה, הגבלה חוזרת, היעדר זמן לניסיון הבא, הפעלה מחדש של תהליך עיבוד והשלמה ידנית של משימה בתור. מוודאים שנקודת הבקרה השמורה, התקציב המשותף וזהות הפעולה נשמרים בכל מקרה.
בדיקות הקבלה צריכות להדגים עבודה עדכנית מועילה, עיכובים מובנים והתאוששות בלי השפעות עסקיות כפולות. מתעדים את זמן ההמתנה בפועל ואת המשימה הפתוחה הוותיקה ביותר; הודעת הצלחה בחיבור אינה מספיקה. אם הקיבולת שנבדקה אינה עומדת במועד שסוכם, משנים היקף או תזמון לפני שדנים בשדרוג חשבון שדורש אישור נפרד. המדריך מציע תרגיל תכנון, לא מחבר מוכן או נתון תפוקה מובטח.
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.