תגובה אחרי פתרון בעיה של אופטימיזציית סיור, שמכילה את המסלולים שאחריהם של כל רכב, את המשלוחים שדילגת עליהם והעלות הכוללת של הפתרון.
ייצוג JSON |
---|
{ "routes": [ { object ( |
שדות | |
---|---|
routes[] |
המסלולים שמחושבים לכל רכב. המסלול ה-i תואם לרכב ה-i במודל. |
requestLabel |
עותק של |
skippedShipments[] |
רשימת כל המשלוחים שדילגת עליה. |
validationErrors[] |
רשימה של כל שגיאות האימות שזיהינו באופן עצמאי. אפשר לעיין בהסבר לגבי 'שגיאות מרובות' לגבי ההודעה |
metrics |
מדדי משך זמן, מרחק ושימוש של הפתרון הזה. |
OptimizeToursValidationError
מיועד לתיאור שגיאה או אזהרה שהתרחשה במהלך האימות של OptimizeToursRequest
.
ייצוג JSON |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
שדות | |
---|---|
code |
שגיאת אימות מוגדרת על ידי הצמד ( שדות אחרים (בהמשך) מספקים הקשר נוסף לגבי השגיאה. מספר שגיאות: כשיש כמה שגיאות, תהליך האימות מנסה לייצר פלט של כמה מהן. בדומה למה שמתרחש במהלך הידור, זהו תהליך לא מושלם. חלק משגיאות האימות יהיו 'קריטיות', כלומר הן יעצרו את כל תהליך האימות. זה המצב, בין היתר, בשגיאות יציבות: הערכים של קובץ עזר: רשימה של כל הצמדים (קוד, שם):
|
displayName |
השם המוצג של השגיאה. |
fields[] |
הקשר של שגיאה יכול לכלול 0, 1 (בדרך כלל) או יותר שדות. לדוגמה, אפשר להפנות לכלי הרכב מס' 4 ולאיסוף הראשון של משלוח מס' 2 באופן הבא:
עם זאת, חשוב לזכור שהעוצמה של |
errorMessage |
מחרוזת לתיאור השגיאה, שאנשים יכולים לקרוא. יש מיפוי של 1:1 בין יציבות: לא יציבה: הודעת השגיאה שמשויכת ל- |
offendingValues |
עשוי להכיל את הערכים של השדות. האפשרות הזו לא תמיד זמינה. אין להסתמך עליו בשום אופן, וצריך להשתמש בו רק לניפוי באגים ידני של מודלים. |
FieldReference
הקשר של שגיאת האימות. השדה FieldReference
תמיד מתייחס לשדה נתון בקובץ הזה, והמבנה ההיררכי שלו זהה. לדוגמה, אפשר לציין את רכיב מס' 2 של startTimeWindows
ברכב מס' 5 באמצעות:
name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }
עם זאת, אנחנו משמיטים ישויות ברמה עליונה כמו OptimizeToursRequest
או ShipmentModel
כדי למנוע צפיפות של ההודעה.
ייצוג JSON |
---|
{ "name": string, "subField": { object ( |
שדות | |
---|---|
name |
שם השדה, למשל "vehicles". |
subField |
שדה משנה בתצוגת עץ רפלקטיבית, אם יש צורך. |
שדה האיחוד הערך של |
|
index |
האינדקס של השדה אם הוא חוזר. |
key |
מקישים אם השדה הוא מפה. |
מדדים
מדדים כלליים, שמצטברים מכל המסלולים.
ייצוג JSON |
---|
{
"aggregatedRouteMetrics": {
object ( |
שדות | |
---|---|
aggregatedRouteMetrics |
נתונים מצטברים לאורך המסלולים. כל מדד הוא הסכום (או הערך המקסימלי, עבור עומסי עבודה) של כל השדות |
skippedMandatoryShipmentCount |
מספר משלוחי החובה שהמערכת דילגה עליהם. |
usedVehicleCount |
מספר כלי הרכב שבהם נעשה שימוש. הערה: אם מסלול של רכב ריק ו- |
earliestVehicleStartTime |
שעת ההתחלה המוקדמת ביותר של רכב משומש, המחושב כמינימום על כל כלי הרכב משומשים ( חותמת זמן בפורמט 'Zulu' בפורמט RFC3339 UTC, עם רזולוציה של ננו-שנייה ועד תשע ספרות אחרי הנקודה. דוגמאות: |
latestVehicleEndTime |
שעת הסיום האחרונה של רכב משומש, מחושבת בתור חותמת זמן בפורמט 'Zulu' בפורמט RFC3339 UTC, עם רזולוציה של ננו-שנייה ועד תשע ספרות אחרי הנקודה. דוגמאות: |
costs |
עלות הפתרון, בחלוקה לפי שדות של בקשות שקשורים לעלויות. המפתחות הם נתיבים של פרוטו, ביחס לקלט OptimizeToursRequest, למשל 'model.shipments.pickups.cost', והערכים הם העלות הכוללת שנוצרה על ידי שדה העלות התואם, שנצברה לאורך כל הפתרון. במילים אחרות, העלויות["model.shipments.pickups.cost"] הן הסכום של כל עלויות האיסוף במסגרת הפתרון. כל העלויות שמוגדרות במודל מדווחות כאן בפירוט, למעט עלויות שקשורות למאפייני מעבר, שמדווחות רק באופן מצטבר נכון ל-2022. אובייקט שמכיל רשימה של |
totalCost |
העלות הכוללת של הפתרון. סכום כל הערכים במפת העלויות. |