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