תגובה לאחר פתרון בעיה באופטימיזציה של סיור, שמכילה את המסלולים שבהם כל רכב נוסע, את המשלוחים שנדחו ואת העלות הכוללת של הפתרון.
| ייצוג ב-JSON |
|---|
{ "routes": [ { object ( |
| שדות | |
|---|---|
routes[] |
המסלולים שמחושבים לכל רכב. המסלול ה-i תואם לרכב ה-i במודל. |
requestLabel |
עותק של |
skippedShipments[] |
רשימה של כל המשלוחים שנדחו. |
validationErrors[] |
רשימה של כל שגיאות האימות שהצלחנו לזהות באופן עצמאי. אפשר לעיין בהסבר לגבי 'שגיאות מרובות' לגבי ההודעה |
metrics |
מדדים של משך זמן, מרחק ושימוש בפתרון הזה. |
OptimizeToursValidationError
תיאור שגיאה שנתקלו בה במהלך אימות של OptimizeToursRequest.
| ייצוג ב-JSON |
|---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
| שדות | |
|---|---|
code |
שגיאת אימות מוגדרת על ידי הצמד ( שדות אחרים (בהמשך) מספקים הקשר נוסף לגבי השגיאה. מספר שגיאות: כשיש כמה שגיאות, תהליך האימות מנסה לייצר פלט של כמה מהן. בדומה למה שמתרחש במהלך הידור, זהו תהליך לא מושלם. חלק משגיאות האימות יהיו "קטלניות", כלומר הן יעצור את תהליך האימות כולו. זה המצב, בין היתר, בשגיאות יציבות: הערכים של הפנייה: רשימה של כל הצמדים (code, name):
|
displayName |
השם המוצג של השגיאה. |
fields[] |
הקשר של שגיאה עשוי לכלול 0, 1 (ברוב המקרים) או יותר שדות. לדוגמה, אפשר להתייחס לרכב מס' 4 ולאיסוף הראשון של משלוח מס' 2 באופן הבא: עם זאת, חשוב לזכור שהעוצמה של |
errorMessage |
מחרוזת לתיאור השגיאה, שאנשים יכולים לקרוא. יש מיפוי אחד-לאחד בין יציבות: לא יציבה: הודעת השגיאה שמשויכת ל- |
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 |
שעת ההתחלה המוקדמת ביותר של רכב משומש, מחושבת כערך המינימלי של חותמת זמן בפורמט UTC 'Zulu' של RFC3339, עם רזולוציה של ננו-שנייה ועד תשע ספרות עשרוניות. דוגמאות: |
latestVehicleEndTime |
שעת הסיום האחרונה של רכב משומש, מחושבת כערך המקסימלי של חותמת זמן בפורמט 'Zulu' בפורמט RFC3339 UTC, עם רזולוציה של ננו-שנייה ועד תשע ספרות אחרי הנקודה. דוגמאות: |
costs |
עלות הפתרון, לפי פירוט של שדות הבקשה שקשורים לעלויות. המפתחות הם נתיבים ב-Proto, ביחס ל-OptimizeToursRequest, למשל model.shipments.pickups.cost", והערכים הם העלות הכוללת שנוצרה על ידי שדה העלות התואם, שמצטברת בכל הפתרון. במילים אחרות, costs["model.shipments.pickups.cost"] הוא הסכום של כל עלויות האיסוף בפתרון. כל העלויות שמוגדרות במודל מדווחות כאן בפירוט, למעט עלויות שקשורות ל-TransitionAttributes שמדווחות רק באופן מצטבר החל מינואר 2022. אובייקט שמכיל רשימה של |
totalCost |
העלות הכוללת של הפתרון. הסכום של כל הערכים במפת העלויות. |