Fleet Engine में वाहन कैसे काम करते हैं, इस बारे में सामान्य जानकारी पाने के लिए, Fleet Engine के ज़रूरी सेक्शन में ये गाइड देखें:
इस सेक्शन में दिए गए दस्तावेज़ में, Fleet Engine में वाहन बनाने और उन्हें मैनेज करने का तरीका बताया गया है. असल दुनिया में इस्तेमाल होने वाले वाहनों को दिखाने के लिए, Fleet Engine के सर्वर एनवायरमेंट में वाहन बनाए जाते हैं. आपके फ़्लीट इंजन के वाहन, आपके बैकएंड सिस्टम में इस्तेमाल किए गए वाहनों से मेल खाने चाहिए. इनका इस्तेमाल, वाहन असाइन करने और रूटिंग के लिए किया जाता है.
वाहन का संसाधन बनाने के लिए, gRPC या REST में से किसी एक का इस्तेमाल करके, 'बनाएं' तरीके का इस्तेमाल किया जाता है. इस गाइड में फ़ील्ड के नामों के लिए, आसानी से समझने के लिए gRPC नोटेशन का इस्तेमाल किया गया है.
मांग पर यात्राएं
CreateVehicleRequest(gRPC)providers.vehicle.create(REST)Vehicleरिसॉर्स (REST, gRPC)
शेड्यूल किए गए टास्क
CreateDeliveryVehicleRequest(gRPC)providers.deliveryVehicles.create(REST)DeliveryVehicle(REST, gRPC)
वाहन के लिए अनुरोध
मांग पर और शेड्यूल किए गए टास्क, दोनों के लिए वाहन बनाया और अपडेट किया जा सकता है. इसके लिए, फ़ील्ड के साथ अनुरोध मैसेज भेजा जाता है. इस मैसेज में ये फ़ील्ड शामिल होते हैं:
- पैरंट: यह आपके Google Cloud प्रोजेक्ट आईडी से जुड़ी एक स्ट्रिंग है. इसका इस्तेमाल, वाहन के इंस्टेंस के नाम वाले फ़ील्ड को पॉप्युलेट करने के लिए किया जाता है.
वाहन का आईडी: यह एक यूनीक स्ट्रिंग है, जिसका इस्तेमाल वाहन के
nameफ़ील्ड को पॉप्युलेट करने के लिए किया जाता है.ज़रूरी फ़ील्ड के साथ वाहन का एक इंस्टेंस. ये फ़ील्ड, आपके इस्तेमाल किए जा रहे Fleet Engine की सुविधा पर निर्भर करते हैं.
अनुरोध के मुख्य हिस्से में दी गई जानकारी, अनुरोध के टाइप के हिसाब से अलग-अलग होती है. इनके बारे में जानकारी पाने के लिए, उनकी गाइड देखें.
पुष्टि करने और अनुमति देने वाले टोकन
Fleet Engine को किए जाने वाले अनुरोधों में, ऐक्सेस के सही क्रेडेंशियल भी देने होंगे. इस गाइड में दिए गए उदाहरणों के लिए, ये बातें मानी गई हैं:
- gRPC के उदाहरणों में, Java के लिए अनुमति लाइब्रेरी का इस्तेमाल किया गया है.
- REST के उदाहरणों में, एचटीटीपी अनुरोध हेडर दिखाया गया है. इसमें
Authorizationफ़ील्ड होना चाहिए, जिसकी वैल्यूBearer <token>हो. यहां<token>, आपका जारी किया गया JSON वेब टोकन है.
ज़्यादा जानकारी के लिए, Fleet Engine सेट अप करने से जुड़ी गाइड देखें.
वाहन के संसाधन फ़ील्ड
वाहन के रिसॉर्स में ये फ़ील्ड होते हैं:
- सिर्फ़ आउटपुट के लिए फ़ील्ड. ऐसे फ़ील्ड जिन्हें सेवा किसी दूसरे तरीके के आउटपुट के तौर पर सेट करती है और उन्हें सीधे तौर पर सेट नहीं किया जा सकता. इस तरह का एक अहम फ़ील्ड,
nameफ़ील्ड है. Fleet Engine, उपयोगकर्ता के तय किए गए आईडी के लिए, Google AIP के दिशा-निर्देशों के मुताबिक वाहन केnameफ़ील्ड के लिए दी गई किसी भी वैल्यू को अनदेखा करता है. इन फ़ील्ड के लिए वैल्यू देने पर, Fleet Engine एक गड़बड़ी दिखाता है. - ज़रूरी फ़ील्ड. मांग पर यात्रा की सेवा में बनाए गए वाहनों के लिए, कुछ फ़ील्ड को बनाते समय सेट करना ज़रूरी है. शेड्यूल किए गए टास्क की सेवा में बनाए गए वाहनों में, वाहन के ज़रूरी संसाधन फ़ील्ड नहीं होते.
- ज़रूरी नहीं हैं. दोनों सेवाओं में ऐसे फ़ील्ड होते हैं जिन्हें बनाने के बाद या पहले सेट किया जा सकता है. ये आपको अपनी इस्तेमाल की जा रही सेवा की रेफ़रंस गाइड में मिल सकते हैं.
वाहन का नाम (सिर्फ़ आउटपुट के लिए)
ऑन-डिमांड यात्राओं और शेड्यूल किए गए टास्क की सेवाओं के लिए, name फ़ील्ड एक जैसा ही होता है. वाहन बनाते समय, Fleet Engine इन दो फ़ील्ड के आधार पर फ़ील्ड तय करता है:
माता-पिता: यह
providers/{provider}फ़ॉर्मैट में आपके Google Cloud प्रोजेक्ट आईडी से जुड़ी एक स्ट्रिंग है. इसमें{provider}आपके Cloud प्रोजेक्ट का आईडी है. किसी प्रोजेक्ट के लिए बनाए गए हर वाहन का पैरंट पाथ एक ही होगा.यहां जिस Cloud प्रोजेक्ट का रेफ़रंस दिया गया है उसमें, इस्तेमाल की जा रही सेवा के लिए Fleet Engine के सेवा खाते की भूमिकाएं भी होनी चाहिए. उन सेवा खातों की सूची के लिए, सेवा खाते देखें. Fleet Engine, एक से ज़्यादा Google Cloud प्रोजेक्ट से ऐक्सेस करने की सुविधा नहीं देता.
वाहन का आईडी, जो आपके फ़्लीट में मौजूद सभी वाहनों के लिए यूनीक होना चाहिए. साथ ही, यह एक मान्य यूनिकोड स्ट्रिंग होनी चाहिए. यह वाहन का रिसॉर्स आईडी है. ऑन-डिमांड यात्राएं और शेड्यूल किए गए स्टॉप, दोनों इस एट्रिब्यूट का इस्तेमाल करके, किसी यात्रा या टास्क को उस वाहन से जोड़ते हैं जिससे वह पूरा होता है.
Google Cloud पर आधारित सेवाओं में, सभी एपीआई को संसाधनों को स्ट्रिंग के तौर पर दिखाना चाहिए. ज़्यादा जानकारी के लिए, Fleet Engine में संसाधन का नाम तय करना लेख पढ़ें.
इकाई के यूनीक आइडेंटिफ़ायर
रिसॉर्स कॉल में इस्तेमाल किए गए यूनीक इकाई आइडेंटिफ़ायर का फ़ॉर्मैट और वैल्यू, Fleet Engine के लिए साफ़ तौर पर नहीं दिखती. पक्का करें कि आइडेंटिफ़ायर में व्यक्तिगत पहचान से जुड़ी कोई जानकारी (पीआईआई) शामिल न हो. जैसे, ड्राइवर का फ़ोन नंबर.
वाहन का फिर से इस्तेमाल करना
किसी यात्रा की योजना के लिए तय किए गए सभी स्टॉप पर पहुंचने के बाद, वाहन को सात दिनों तक Fleet Engine में फिर से इस्तेमाल किया जा सकता है. इसका मतलब है कि अगले कामकाजी दिनों में, वाहन को फिर से इस्तेमाल किया जा सकता है. इसके लिए, आपको नया वाहन बनाने की ज़रूरत नहीं है. जब भी किसी वाहन का फिर से इस्तेमाल किया जाता है, तो Fleet Engine उसकी उपलब्धता को रीसेट कर देता है. इसके बाद, सात दिन का काउंटडाउन फिर से शुरू हो जाता है.
हमारा सुझाव है कि किसी वाहन को फ़्लीट इंजन में उपलब्ध रखने के लिए, समय-समय पर उसकी जगह की जानकारी अपडेट करते रहें. Vehicle इकाई के ज़्यादातर अन्य फ़ील्ड में किए गए अपडेट से भी, उसकी लाइफ़ बढ़ जाएगी. हालांकि, इसके लिए ज़रूरी है कि फ़ील्ड की नई वैल्यू, मौजूदा वैल्यू से अलग हो.
ध्यान दें: device_settings जैसी Vehicle इकाई के कुछ फ़ील्ड में, सिर्फ़ डीबग करने से जुड़ी जानकारी होती है. इसे Fleet Engine सेव नहीं करता. इन्हें अपडेट करने से, Vehicle इकाई की लाइफ़ नहीं बढ़ती.
सिस्टम के बेहतर आंकड़ों के लिए, हर दिन ड्राइवर और गाड़ी के आईडी के जोड़े का फिर से इस्तेमाल करना सबसे अच्छा होता है. ऐसा करने के लिए, ड्राइवर से जुड़े उसी वाहन आईडी का इस्तेमाल करें जिसका इस्तेमाल, शेड्यूल किए गए पिछले स्टॉप या मांग पर की जाने वाली यात्राओं के लिए किया गया था.