ה-API לאופטימיזציה של המסלול חושף שתי שיטות:
OptimizeToursהיא שיטה סינכרונית שמחזירה מסלול אופטימלי בתגובה ל-OptimizeToursRequest. עד לסיום הטיפול בבקשה וההחזרה שלOptimizeToursResponseאו שגיאה, הלקוחות צריכים לשמור על חיבור פתוח ל-Route Optimize API.BatchOptimizeToursהיא שיטה אסינכרונית שמקבלת מזהי URI עבור הודעתOptimizeToursRequestאחת או יותר והודעהOptimizeToursResponseתואמת, שמחזירה את שם המשאב של פעולה ממושכת (LRO) ומשמשת לבדיקת השלמה של אצווה. קובציOptimizeToursRequestמעובדים ברקע, כך שהלקוחות שומרים על חיבורים פתוחים ל-Routivity API רק כדי לשלוח את {BatchOptimizeToursRequest0/status}.gRPCGetOperationBatchOptimizeToursקורא בקשות וכותב תשובות ב-Google Cloud Storage.
תרחישים לדוגמה
OptimizeTours נוח לטפל בבקשות קטנות ופשוטות, או בבקשות עם פתרון של זמנים של כמה דקות או פחות. תחזוקה של חיבורים לטווח ארוך ל-Route Optimize API מגדילה את הסיכון לשיבושים לפני שתקבלו פתרון.
BatchOptimizeTours יכול לטפל בבקשות ובבקשות גדולות יותר עם זמן פתרון ארוך יותר, כי לא נדרש לו חיבור לטווח ארוך ל-RoleOptimization API.
פעולות ממושכות
קוראים את יחידות ה-LRO מ-Route Optimize API באמצעות ה-method GetOperation, כדי לבדוק את סטטוס ההשלמה של קבוצת קבצים. LROs כוללים את המאפיין done שמציין אם העיבוד של כל המקבץ הושלם ושדה error שמדווח על שגיאות שזוהו במהלך העיבוד. אם הערך של done הוא True אבל לא קיים error, הפעולה באצווה הושלמה. הנוכחות של error מציינת שהעיבוד של חלק מהמקבץ או של כולו נכשל.
מחזור החיים הטיפוסי של בקשת BatchOptimizeTours הוא:
- שולחים
BatchOptimizeToursRequestל-Rout Optimize API, שמחזיר את שם המשאב של LRO. - בסקר
GetOperationעם שם המשאב LRO שהוחזר עד שהמאפייניםdoneאוerrorיופיעו בתשובה LRO. - אם הערך של
doneהוא True ולא קיימת שגיאה, צריך לקרוא אתOptimizeToursResponsesממזהי ה-URI של Google Cloud Storage שצוינו בבקשהBatchOptimizeTours. אםerrorקיים, בודקים את השגיאה, מעדכנים את קובצי ה-OptimizeToursRequestבהתאם ב-Google Cloud Storage ומנסים שוב לפי הצורך, בהתאם לשגיאה שזוהתה.
אפשר לשלוח בקשות OptimizeTours ו-BatchOptimizeTours במגוון דרכים, משורת הפקודה או באמצעות ספריית לקוח.