ה-API לאופטימיזציה של המסלול חושף שתי שיטות:
OptimizeTours
היא שיטה סינכרונית שמחזירה מסלול אופטימלי בתגובה ל-OptimizeToursRequest
. עד לסיום הטיפול בבקשה וההחזרה שלOptimizeToursResponse
או שגיאה, הלקוחות צריכים לשמור על חיבור פתוח ל-Route Optimize API.BatchOptimizeTours
היא שיטה אסינכרונית שמקבלת מזהי URI עבור הודעתOptimizeToursRequest
אחת או יותר והודעהOptimizeToursResponse
תואמת, שמחזירה את שם המשאב של פעולה ממושכת (LRO) ומשמשת לבדיקת השלמה של אצווה. קובציOptimizeToursRequest
מעובדים ברקע, כך שהלקוחות שומרים על חיבורים פתוחים ל-Routivity API רק כדי לשלוח את {BatchOptimizeToursRequest
0/status}.gRPCGetOperation
BatchOptimizeTours
קורא בקשות וכותב תשובות ב-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
במגוון דרכים, משורת הפקודה או באמצעות ספריית לקוח.