فهرستی از تمام خطاهای اعتبار سنجی که توانستیم به طور مستقل شناسایی کنیم. توضیحات "MULTIPLE ERRORS" را برای پیام OptimizeToursValidationError ببینید. به جای خطا، این شامل اخطارهایی در حالت solvingModeDEFAULT_SOLVE است.
یک خطای اعتبارسنجی توسط جفت ( code ، displayName ) که همیشه وجود دارد، تعریف میشود.
سایر فیلدها (در زیر) زمینه بیشتری را در مورد خطا ارائه می دهند.
خطاهای چندگانه : هنگامی که چندین خطا وجود دارد، فرآیند اعتبارسنجی سعی می کند چندین مورد از آنها را خروجی دهد. بسیار شبیه یک کامپایلر، این یک فرآیند ناقص است. برخی از خطاهای اعتبارسنجی "کشنده" خواهند بود، به این معنی که کل فرآیند اعتبار سنجی را متوقف می کنند. این مورد برای خطاهای displayName="UNSPECIFIED" در میان سایر موارد است. برخی ممکن است باعث شوند که فرآیند اعتبارسنجی از سایر خطاها عبور کند.
STABILITY : code و displayName باید بسیار پایدار باشند. اما کدها و نامهای نمایشی جدید ممکن است در طول زمان ظاهر شوند، که ممکن است باعث شود یک درخواست داده شده (نامعتبر) یک جفت متفاوت ( code ، displayName ) ایجاد کند، زیرا خطای جدید خطای قدیمی را پنهان کرده است (به "خطاهای متعدد" مراجعه کنید).
مرجع : لیستی از همه جفت ها (کد، نام):
نامشخص = 0;
VALIDATION_TIMEOUT_ERROR = 10; اعتبارسنجی در مهلت مقرر تکمیل نشد.
زمینه خطا ممکن است شامل 0، 1 (بیشتر اوقات) یا بیشتر فیلد باشد. به عنوان مثال، مراجعه به وسیله نقلیه شماره 4 و اولین پیکاپ محموله شماره 2 را می توان به صورت زیر انجام داد:
البته توجه داشته باشید که کاردینالیته fields نباید برای یک کد خطای مشخص تغییر کند.
errorMessage
string
رشته قابل خواندن توسط انسان که خطا را توصیف می کند. یک نگاشت 1:1 بین code و errorMessage وجود دارد (وقتی کد != "نامشخص" است).
پایداری : پایدار نیست: پیام خطای مرتبط با code معین ممکن است در طول زمان تغییر کند (امیدواریم که آن را روشن کنیم). لطفاً به جای آن به displayName و code تکیه کنید.
offendingValues
string
ممکن است حاوی مقدار(های) فیلد(ها) باشد. این همیشه در دسترس نیست. شما مطلقاً نباید به آن تکیه کنید و فقط برای اشکال زدایی مدل دستی از آن استفاده کنید.
مرجع فیلد
زمینه ای را برای خطای اعتبارسنجی مشخص می کند. یک FieldReference همیشه به یک فیلد معین در این فایل اشاره دارد و از همان ساختار سلسله مراتبی پیروی می کند. برای مثال، ممکن است عنصر شماره 2 از startTimeWindows وسیله نقلیه شماره 5 را با استفاده از:
با این حال، ما نهادهای سطح بالا مانند OptimizeToursRequest یا ShipmentModel را حذف می کنیم تا از شلوغ شدن پیام جلوگیری کنیم.
نمایندگی JSON
{"name": string,"subField": {object (FieldReference)},// Union field index_or_key can be only one of the following:"index": integer,"key": string// End of list of possible types for union field index_or_key.}
در مسیرها جمع شده است. هر متریک مجموع (یا حداکثر، برای بارها) در تمام فیلدهای ShipmentRoute.metrics با همان نام است.
skippedMandatoryShipmentCount
integer
تعداد محموله های اجباری حذف شده
usedVehicleCount
integer
تعداد وسایل نقلیه استفاده شده توجه: اگر مسیر وسیله نقلیه خالی باشد و Vehicle.used_if_route_is_empty درست باشد، وسیله نقلیه استفاده شده در نظر گرفته می شود.
آخرین زمان پایان برای یک وسیله نقلیه کارکرده، که به عنوان حداکثر برای همه وسایل نقلیه استفاده شده ShipmentRoute.vehicle_end_time محاسبه می شود.
مهر زمانی در قالب RFC3339 UTC "Zulu"، با وضوح نانوثانیه و حداکثر نه رقم کسری. مثالها: "2014-10-02T15:01:23Z" و "2014-10-02T15:01:23.045123456Z" .
costs
map (key: string, value: number)
هزینه راه حل، به تفکیک فیلدهای درخواست مربوط به هزینه. کلیدها مسیرهای اولیه هستند، نسبت به ورودی OptimizeToursRequest، به عنوان مثال "model.shipments.pickups.cost"، و مقادیر کل هزینه تولید شده توسط فیلد هزینه مربوطه هستند که در کل راه حل جمع می شوند. به عبارت دیگر، هزینهها ["model.shipments.picups.cost"] مجموع تمام هزینههای برداشت بیش از راهحل است. تمام هزینههای تعریفشده در مدل در اینجا بهجز هزینههای مربوط به TransitionAttributes که فقط به صورت تجمیع شده از سال 2022/01 گزارش شدهاند، در اینجا گزارش میشوند.
یک شی حاوی لیستی از "key": value . مثال: { "name": "wrench", "mass": "1.3kg", "count": "3" } .
totalCost
number
هزینه کل راه حل مجموع تمام مقادیر در نقشه هزینه ها.