कॉन्टेंट कनेक्टर एक सॉफ़्टवेयर प्रोग्राम होता है. इसका इस्तेमाल, किसी एंटरप्राइज़ के रिपॉज़िटरी (डेटा स्टोर करने की जगह) में मौजूद डेटा को दिखाने और किसी डेटा सोर्स में अपने-आप जानकारी भरने के लिए किया जाता है. Google, कॉन्टेंट कनेक्टर बनाने के लिए ये विकल्प उपलब्ध कराता है:
कॉन्टेंट कनेक्टर SDK टूल. अगर आपको Java में प्रोग्रामिंग करनी है, तो यह एक अच्छा विकल्प है. कॉन्टेंट कनेक्टर SDK टूल, REST API के लिए एक रैपर है. इससे फटाफट कनेक्टर बनाए जा सकते हैं. SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, Content Connector SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना देखें.
लो-लेवल का REST API या एपीआई लाइब्रेरी. अगर आपको Java में प्रोग्राम नहीं करना है या आपके कोडबेस में REST API या लाइब्रेरी में बेहतर सुविधा मिलती है, तो इन विकल्पों का इस्तेमाल करें. REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना देखें.
सामान्य कॉन्टेंट कनेक्टर ये काम करता है:
- कॉन्फ़िगरेशन पैरामीटर को पढ़ता और प्रोसेस करता है.
- तीसरे पक्ष के कॉन्टेंट रिपॉज़िटरी से, इंडेक्स किए जा सकने वाले डेटा के अलग-अलग हिस्से इकट्ठा करता है, जिन्हें "items" कहा जाता है.
- एसीएल, मेटाडेटा, और कॉन्टेंट डेटा को इंडेक्स किए जा सकने वाले आइटम में जोड़ता है.
- Cloud Search डेटा सोर्स में आइटम इंडेक्स करता है.
- (ज़रूरी नहीं) तीसरे पक्ष के कॉन्टेंट को स्टोर करने की जगह से मिलने वाली सूचनाओं में होने वाले बदलाव को सुनता है. बदलाव की सूचनाओं को इंडेक्स करने के अनुरोधों में बदल दिया जाता है, ताकि Cloud Search के डेटा सोर्स को तीसरे पक्ष के डेटा सोर्स के साथ सिंक रखा जा सके. कनेक्टर यह काम सिर्फ़ तब करता है, जब रिपॉज़िटरी में बदलाव का पता लगाने की सुविधा काम करती हो.
कॉन्टेंट कनेक्टर SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना
यहां दिए गए सेक्शन में, Content Connector SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने का तरीका बताया गया है.
डिपेंडेंसी सेट अप करें
SDK टूल का इस्तेमाल करने के लिए, आपको अपनी बिल्ड फ़ाइल में कुछ डिपेंडेंसी शामिल करनी होंगी. अपने बिल्ड एनवायरमेंट की डिपेंडेंसी देखने के लिए, नीचे दिए गए टैब पर क्लिक करें:
Maven
<dependency>
<groupId>com.google.enterprise.cloudsearch</groupId>
<artifactId>google-cloudsearch-indexing-connector-sdk</artifactId>
<version>v1-0.0.3</version>
</dependency>
ग्रेडल
compile group: 'com.google.enterprise.cloudsearch',
name: 'google-cloudsearch-indexing-connector-sdk',
version: 'v1-0.0.3'
अपना कनेक्टर कॉन्फ़िगरेशन बनाएं
हर कनेक्टर में एक कॉन्फ़िगरेशन फ़ाइल होती है जिसमें, कनेक्टर के इस्तेमाल किए जाने वाले पैरामीटर मौजूद होते हैं.
जैसे, रिपॉज़िटरी की आपकी आईडी. पैरामीटर को
कुंजी-वैल्यू पेयर के तौर पर परिभाषित किया जाता है, जैसे कि
api.sourceId=1234567890abcdef
.
Google Cloud Search SDK टूल में, Google के ऐसे कई कॉन्फ़िगरेशन पैरामीटर शामिल हैं जिनका इस्तेमाल सभी कनेक्टर करते हैं. आपको अपनी कॉन्फ़िगरेशन फ़ाइल में Google के दिए गए इन पैरामीटर के बारे में जानकारी देनी होगी:
- कॉन्टेंट कनेक्टर के लिए, आपको
api.sourceId
औरapi.serviceAccountPrivateKeyFile
के बारे में एलान करना होगा, क्योंकि ये पैरामीटर आपके रिपॉज़िटरी और निजी पासकोड की जगह की पहचान करते हैं, जो रिपॉज़िटरी को ऐक्सेस करने के लिए ज़रूरी है.
- आइडेंटिटी कनेक्टर के लिए, आपको
api.identitySourceId
का एलान करना होगा, क्योंकि यह पैरामीटर आपके बाहरी आइडेंटिटी सोर्स की लोकेशन की पहचान करता है. अगर उपयोगकर्ताओं को सिंक किया जा रहा है, तो आपको अपने एंटरप्राइज़ के Google Workspace खाते के लिए,api.customerId
को भी यूनीक आईडी के तौर पर बताना होगा.
जब तक आपको Google के उपलब्ध कराए गए अन्य पैरामीटर की डिफ़ॉल्ट वैल्यू को बदलना न हो, तब तक आपको उन्हें अपनी कॉन्फ़िगरेशन फ़ाइल में बताने की ज़रूरत नहीं है. Google के दिए गए कॉन्फ़िगरेशन पैरामीटर के बारे में ज़्यादा जानकारी, जैसे कि कुछ आईडी और कुंजियों को जनरेट करने का तरीका जानने के लिए, Google के उपलब्ध कराए गए कॉन्फ़िगरेशन पैरामीटर देखें.
अपनी कॉन्फ़िगरेशन फ़ाइल में इस्तेमाल के लिए, रिपॉज़िटरी के अपने खास पैरामीटर भी तय किए जा सकते हैं.
कॉन्फ़िगरेशन फ़ाइल को कनेक्टर पर पास करें
कॉन्फ़िगरेशन फ़ाइल को अपने कनेक्टर में भेजने के लिए, सिस्टम प्रॉपर्टी config
को सेट करें. कनेक्टर शुरू करते समय, -D
आर्ग्युमेंट का इस्तेमाल करके, प्रॉपर्टी को सेट किया जा सकता है. उदाहरण के लिए, यह कमांड, कनेक्टर को MyConfig.properties
कॉन्फ़िगरेशन फ़ाइल के साथ शुरू करता है:
java -classpath myconnector.jar;... -Dconfig=MyConfig.properties MyConnector
अगर यह आर्ग्युमेंट मौजूद नहीं है, तो SDK टूल, connector-config.properties
नाम की डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल को ऐक्सेस करने की कोशिश करता है.
अपनी ट्रैवर्सल रणनीति तय करना
कॉन्टेंट कनेक्टर का मुख्य काम, किसी रिपॉज़िटरी (डेटा स्टोर करने की जगह) को एक्सप्लोर करना और उसके डेटा को इंडेक्स करना होता है. आपको अपनी रिपॉज़िटरी में डेटा के साइज़ और लेआउट के आधार पर ट्रैवर्सल रणनीति लागू करनी होगी. अपनी रणनीति खुद डिज़ाइन की जा सकती है या SDK टूल में लागू की गई इन रणनीतियों में से किसी एक को चुना जा सकता है:
- ट्रैवर्सल की पूरी रणनीति
एक फ़ुल ट्रैवर्सल स्ट्रेटजी, डेटा स्टोर करने की पूरी जगह को स्कैन करती है और बिना सोचे-समझे हर आइटम को इंडेक्स करती है. आम तौर पर इस रणनीति का इस्तेमाल तब किया जाता है, जब आपके पास एक छोटा डेटा स्टोर होता है. साथ ही, आपके पास हर बार इंडेक्स करने पर एक पूरा ट्रैवर्सल करने का खर्च भी हो सकता है.
यह ट्रैवर्सल रणनीति, डेटा स्टोर करने की ऐसी छोटी जगहों के लिए सही है जिनमें ज़्यादातर स्टैटिक, बिना हैरारकी वाला डेटा हो. इस ट्रैवर्सल रणनीति का इस्तेमाल तब भी किया जा सकता है, जब बदलाव का पता लगाना मुश्किल हो या रिपॉज़िटरी के साथ काम न करता हो.
- ट्रैवर्सल की रणनीति की सूची बनाएं
लिस्ट ट्रैवर्सल रणनीति, सभी चाइल्ड नोड के साथ पूरे रिपॉज़िटरी को स्कैन करती है. इसमें हर आइटम की स्थिति तय की जाती है. इसके बाद, कनेक्टर एक सेकंड पास लेता है और सिर्फ़ उन आइटम को इंडेक्स करता है जो नए हैं या जिन्हें पिछली बार इंडेक्स किए जाने के बाद अपडेट किया गया है. आम तौर पर, इस रणनीति का इस्तेमाल किसी मौजूदा इंडेक्स को अपडेट करने के लिए किया जाता है. इसका इस्तेमाल इंडेक्स को अपडेट करने के लिए, हर बार पूरा ट्रैवर्सल करने की ज़रूरत नहीं होती.
यह ट्रैवर्सल रणनीति तब सही होती है, जब बदलाव का पता लगाना मुश्किल हो या डेटा स्टोर करने की जगह के साथ काम न करता हो, आपके पास बिना हैरारकी वाला डेटा हो, और बहुत बड़े डेटा सेट के साथ काम किया जा रहा हो.
- ग्राफ़ ट्रैवर्सल
ग्राफ़ ट्रैवर्सल रणनीति, हर आइटम की स्थिति तय करने के लिए पूरे पैरंट नोड को स्कैन करती है. इसके बाद, कनेक्टर दूसरा पास लेता है और सिर्फ़ रूट नोड में मौजूद आइटम इंडेक्स करता है. इसके अलावा, यह भी हो सकता है कि वे नए आइटम हों या उन्हें पिछली बार इंडेक्स किए जाने के बाद अपडेट किया गया हो. आखिर में, कनेक्टर किसी भी चाइल्ड आईडी को पास करता है और फिर चाइल्ड नोड में नए या अपडेट किए गए आइटम को इंडेक्स करता है. जब तक सभी आइटम ठीक नहीं हो जाते, तब तक कनेक्टर सभी चाइल्ड नोड में बार-बार होता रहता है. आम तौर पर, ऐसे ट्रैवर्सल का इस्तेमाल हैरारकी के रिपॉज़िटरी के लिए किया जाता है, जहां सभी आईडी की लिस्टिंग करना सही नहीं होता.
अगर आपके पास क्रम के हिसाब से डेटा है, जिसे क्रॉल करने की ज़रूरत है, तो यह रणनीति सही है. जैसे, डायरेक्ट्री या वेब पेजों की सीरीज़.
इनमें से हर ट्रैवर्सल रणनीति, SDK टूल में टेंप्लेट कनेक्टर क्लास की मदद से लागू की जाती है. हालांकि, खुद की ट्रैवर्सल रणनीति लागू की जा सकती है, लेकिन इन टेंप्लेट की मदद से आपके कनेक्टर के डेवलपमेंट की प्रोसेस बहुत तेज़ी से होती है. किसी टेंप्लेट का इस्तेमाल करके कनेक्टर बनाने के लिए, अपनी ट्रैवर्सल रणनीति से जुड़े सेक्शन पर जाएं:
- टेंप्लेट क्लास का इस्तेमाल करके, पूरा ट्रैवर्सल कनेक्टर बनाना
- टेंप्लेट क्लास का इस्तेमाल करके, लिस्ट ट्रैवर्सल कनेक्टर बनाना
- टेंप्लेट क्लास का इस्तेमाल करके, ग्राफ़ ट्रैवर्सल कनेक्टर बनाना
टेंप्लेट क्लास का इस्तेमाल करके, पूरा ट्रैवर्सल कनेक्टर बनाना
दस्तावेज़ का यह सेक्शन, FullTraversalSample उदाहरण में दिए गए कोड स्निपेट के बारे में बताता है.
कनेक्टर का एंट्री पॉइंट लागू करना
किसी कनेक्टर का एंट्री पॉइंट, main()
तरीका होता है. इस तरीके का मुख्य टास्क है, Application
क्लास का इंस्टेंस बनाना और कनेक्टर को चलाने के लिए इसके start()
तरीके को शुरू करना.
application.start()
को कॉल करने से पहले, FullTraversalConnector
टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder
क्लास का इस्तेमाल करें. FullTraversalConnector
,
Repository
ऑब्जेक्ट को स्वीकार करता है, जिसके मेथड को लागू किया जाता है. यहां दिया गया कोड स्निपेट, main()
तरीके को लागू
करने का तरीका दिखाता है:
हालांकि, कनेक्टर के main()
तरीके के कॉल Application.build
होने के बाद, SDK टूल initConfig()
तरीके को कॉल करता है.
initConfig()
वाला तरीका
ये काम करता है:
- यह
Configuation.isInitialized()
तरीके को कॉल करता है, ताकि यह पक्का किया जा सके किConfiguration
को शुरू नहीं किया गया है. - Google के उपलब्ध कराए गए की-वैल्यू पेयर के साथ,
Configuration
ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर कोConfiguration
ऑब्जेक्ट मेंConfigValue
ऑब्जेक्ट में स्टोर किया जाता है.
Repository
इंटरफ़ेस को लागू करें
Repository
ऑब्जेक्ट का एकमात्र मकसद, रिपॉज़िटरी में मौजूद आइटम को ट्रैवर्सल और इंडेक्स करना होता है. किसी टेंप्लेट का इस्तेमाल
करते समय, आपको कॉन्टेंट कनेक्टर बनाने के लिए Repository
इंटरफ़ेस में सिर्फ़ कुछ तरीकों को बदलना होगा. ओवरराइड किए जाने वाले तरीके, आपकी इस्तेमाल की जाने वाली टेंप्लेट और
ट्रैवर्सल रणनीति पर निर्भर करते हैं. FullTraversalConnector
के लिए, इन तरीकों को बदलें:
init()
तरीका. डेटा रिपॉज़िटरी को सेट-अप और शुरू करने के लिए,init()
वाला तरीका बदलें.getAllDocs()
तरीका. डेटा रिपॉज़िटरी में मौजूद सभी आइटम को ट्रैवर्स और इंडेक्स करने के लिए,getAllDocs()
तरीके को बदलें. शेड्यूल किए गए हर ट्रैवर्सल के लिए, इस तरीके को एक बार कॉल किया जाता है (जैसा कि आपके कॉन्फ़िगरेशन से तय होता है).(ज़रूरी नहीं)
getChanges()
तरीका. अगर आपके डेटा स्टोर करने की जगह में बदलाव का पता लगाने की सुविधा काम करती है, तोgetChanges()
तरीका बदलें. बदले गए आइटम को फिर से पाने और उन्हें इंडेक्स करने के लिए, इस तरीके को हर शेड्यूल किए गए इंक्रीमेंटल (जैसा कि कॉन्फ़िगरेशन में बताया गया है) के लिए एक बार कॉल किया जाता है.(ज़रूरी नहीं)
close()
तरीका. अगर आपको डेटा स्टोर करने की जगह को क्लीनअप करना है, तोclose()
तरीके को बदलें. कनेक्टर के शटडाउन के दौरान, इस तरीके को एक बार कॉल किया जाता है.
Repository
ऑब्जेक्ट का हर तरीका, किसी खास तरह का ApiOperation
ऑब्जेक्ट दिखाता है. ApiOperation
ऑब्जेक्ट, डेटा स्टोर करने की आपकी जगह को इंडेक्स करने के लिए, एक या एक से ज़्यादा IndexingService.indexItem()
कॉल के रूप में कार्रवाई करता है.
कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं
अपने कनेक्टर के कॉन्फ़िगरेशन को हैंडल करने के दौरान, आपको Configuration
ऑब्जेक्ट से सभी कस्टम पैरामीटर लेने होंगे. आम तौर पर, यह टास्क Repository
क्लास के init()
तरीके से किया जाता है.
Configuration
क्लास में किसी कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके होते हैं. हर तरीका एक ConfigValue
ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू का पता लगाने के लिए, ConfigValue
ऑब्जेक्ट के get()
तरीके का इस्तेमाल किया जाएगा.
FullTraversalSample
का यह स्निपेट दिखाता है कि किसी Configuration
ऑब्जेक्ट से, कस्टम पूर्णांक की एक वैल्यू कैसे हासिल की जा सकती है:
कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration
क्लास के किसी एक तरह के पार्सर का इस्तेमाल करें.
ट्यूटोरियल कनेक्टर का यह स्निपेट, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए getMultiValue
तरीके का इस्तेमाल करता है:
पूरा ट्रैवर्सल करना
पूरा ट्रैवर्सल करने और डेटा स्टोर करने की जगह को इंडेक्स करने के लिए, getAllDocs()
को बदलें. getAllDocs()
वाला तरीका, एक चेकपॉइंट स्वीकार करता है. चेकपॉइंट का इस्तेमाल किसी खास आइटम को फिर से इंडेक्स करने के लिए किया जाता है, ताकि प्रोसेस में रुकावट आने पर उसे फिर से शुरू किया जा सके. अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए, getAllDocs()
तरीका में यह तरीका अपनाएं:
- अनुमतियां सेट करें.
- उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
- मेटाडेटा और आइटम को आपस में मिलाकर, एक इंडेक्स करने लायक आइटम बनाएं
RepositoryDoc
. - इंडेक्स किए जा सकने वाले हर आइटम को,
getAllDocs()
तरीके से दिखाए गए इटरेटर में पैकेज करें. ध्यान दें किgetAllDocs()
असल में एकCheckpointCloseableIterable
दिखाता है, जोApiOperation
ऑब्जेक्ट का इटरेशन है. हर ऑब्जेक्ट,RepositoryDoc
पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि उसे इंडेक्स करना.
अगर आइटम का सेट बहुत बड़ा है, तो इसे एक कॉल में प्रोसेस नहीं किया जा सकता. ऐसे में, एक चेकपॉइंट शामिल करें और hasMore(true)
पर सेट करें, ताकि यह पता चल सके कि इंडेक्स करने के लिए और आइटम उपलब्ध हैं.
किसी आइटम के लिए अनुमतियां सेट करना
किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ताओं या ग्रुप की पहचान करने के लिए, आपकी रिपॉज़िटरी (डेटा स्टोर करने की जगह) ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करती है. ACL ऐसे समूहों या उपयोगकर्ताओं के लिए आईडी की सूची होता है जो आइटम ऐक्सेस कर सकते हैं.
आपको अपने रिपॉज़िटरी में इस्तेमाल किए गए ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही खोज नतीजे में उस आइटम को देख सकें. किसी आइटम को इंडेक्स करते समय उसका ACL शामिल करना ज़रूरी है, ताकि Google Cloud Search के पास वह जानकारी हो जो आइटम का सही लेवल ऐक्सेस करने के लिए ज़रूरी है.
कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर डेटा स्टोर करने की जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट देता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए संबंधित ACL बनाना होगा. अगर आपके रिपॉज़िटरी के ACL में ACL इनहेरिटेंस जैसे सिद्धांत लागू हैं, तो ऐसी स्थिति को मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.
ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, एक डोमेन वाले ACL के साथ काम करता है. यह क्रॉस-डोमेन ACL
के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यह कोड स्निपेट,
पूरे ट्रैवर्सल सैंपल से लिया गया है. इससे खोज करते समय
सभी उपयोगकर्ता या "प्रिंसिपल" (getCustomerPrincipal()
)
सभी आइटम के "रीडर" बन सकते हैं (.setReaders()
).
आपको रिपॉज़िटरी के लिए ACL को सही तरीके से मॉडल करने के लिए ACL को समझना होगा. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो किसी तरह का इनहेरिटेंस मॉडल इस्तेमाल करता है. इसमें चाइल्ड फ़ोल्डर, पैरंट फ़ोल्डर की अनुमतियां इनहेरिट करते हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search ACL में शामिल की गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को Item
ऑब्जेक्ट में सेव किया जाता है. Item
बनाने के लिए, आपके पास आइटम का कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए.
नीचे दिया गया कोड स्निपेट, IndexingItemBuilder
हेल्पर क्लास का इस्तेमाल करके Item
बनाने का तरीका बताता है.
इंडेक्स करने लायक आइटम बनाना
आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder
क्लास का इस्तेमाल करके, इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. नीचे दिए गए उदाहरण में, इंडेक्स करने लायक एक आइटम बनाने का तरीका बताया गया है.
RepositoryDoc
, एक तरह का ApiOperation
है, जो IndexingService.indexItem()
से किए जाने वाले असली अनुरोध को पूरा करता है.
इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS
या SYNCHRONOUS
के तौर पर करने के लिए, RepositoryDoc.Builder
क्लास के setRequestMode()
तरीके का भी इस्तेमाल किया जा सकता है:
ASYNCHRONOUS
- एसिंक्रोनस मोड में, इंडेक्स करने के लिए इंतज़ार का समय ज़्यादा होता है. साथ ही, इससे इंडेक्स करने के अनुरोधों के लिए ज़्यादा थ्रूपुट कोटा तय होता है. डेटा स्टोर करने की पूरी जगह को शुरुआती इंडेक्स (बैकफ़िल) के तौर पर उपलब्ध कराने के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
- सिंक्रोनस मोड की वजह से, इंडेक्स करने के लिए इंतज़ार का समय कम हो जाता है. साथ ही, यह सीमित थ्रूपुट कोटा को शामिल करता है. डेटा स्टोर करने की जगह में अपडेट और बदलावों को इंडेक्स करने के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर यह जानकारी नहीं दी गई है, तो अनुरोध मोड डिफ़ॉल्ट रूप से
SYNCHRONOUS
पर सेट हो जाता है.
इंडेक्स किए जा सकने वाले हर आइटम को इटरेटर में पैकेज करें
इस getAllDocs()
तरीके से, Iterator
खास तौर पर RepositoryDoc
ऑब्जेक्ट के
CheckpointCloseableIterable
ऑब्जेक्ट दिखाए जाते हैं. एक इटरेटर बनाने और उसे दिखाने के लिए, CheckpointClosableIterableImpl.Builder
क्लास का इस्तेमाल किया जा सकता है. नीचे दिया गया कोड स्निपेट, इटरेटर को बनाने और उसे लौटाने का तरीका दिखाता है.
SDK टूल, इंडेक्स करने वाले हर कॉल को इटरेटर के अंदर करता है.
अगले चरण
यहां कुछ ऐसे तरीके बताए गए हैं जिन्हें आज़माया जा सकता है:
- (ज़रूरी नहीं) अगर आपको इंडेक्स करने की प्रोसेस धीमी लगती है, तो
FullTraversalConnector
के लिए इंडेक्स करने की दर बढ़ाएं देखें. - (ज़रूरी नहीं) बंद होने से पहले किसी भी संसाधन को रिलीज़ करने के लिए,
close()
तरीका लागू करें. - (ज़रूरी नहीं) Content Connector SDK टूल का इस्तेमाल करके आइडेंटिटी कनेक्टर बनाएं.
टेंप्लेट क्लास का इस्तेमाल करके, लिस्ट ट्रैवर्सल कनेक्टर बनाना
Cloud Search इंडेक्स करने की सूची का इस्तेमाल, रिपॉज़िटरी में हर आइटम के लिए आईडी और वैकल्पिक हैश वैल्यू को होल्ड करने के लिए किया जाता है. सूची ट्रैवर्सल कनेक्टर, आइटम आईडी को Google Cloud Search की इंडेक्स करने की सूची में पुश करता है और इंडेक्स करने के लिए उन्हें एक बार में एक फ़ेच करता है. Google Cloud Search, आइटम की स्थिति तय करने के लिए सूची का रखरखाव करता है और सूची के कॉन्टेंट की तुलना करता है. जैसे, डेटा स्टोर करने की जगह से किसी आइटम को मिटाया गया है या नहीं. Cloud Search की इंडेक्स करने की सूची के बारे में ज़्यादा जानकारी के लिए, Cloud Search इंडेक्स करने की सूची देखें.
दस्तावेज़ों का यह सेक्शन ListTraversalSample उदाहरण में दिए गए कोड स्निपेट से जुड़ा होता है.
कनेक्टर का एंट्री पॉइंट लागू करना
किसी कनेक्टर का एंट्री पॉइंट, main()
तरीका होता है. इस तरीके का मुख्य टास्क है, Application
क्लास का इंस्टेंस बनाना और कनेक्टर को चलाने के लिए इसके start()
तरीके को शुरू करना.
application.start()
को कॉल करने से पहले, ListingConnector
टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder
क्लास का इस्तेमाल करें. ListingConnector
,
Repository
ऑब्जेक्ट को स्वीकार करता है, जिसके तरीके लागू किए जाते हैं. इस स्निपेट में ListingConnector
और इससे जुड़े Repository
को इंस्टैंशिएट करने का तरीका बताया गया है:
हालांकि, कनेक्टर के main()
तरीके के कॉल Application.build
होने के बाद, SDK टूल initConfig()
तरीके को कॉल करता है.
initConfig()
तरीका:
- यह
Configuation.isInitialized()
तरीके को कॉल करता है, ताकि यह पक्का किया जा सके किConfiguration
को शुरू नहीं किया गया है. - Google के उपलब्ध कराए गए की-वैल्यू पेयर के साथ,
Configuration
ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर कोConfiguration
ऑब्जेक्ट मेंConfigValue
ऑब्जेक्ट में स्टोर किया जाता है.
Repository
इंटरफ़ेस को लागू करें
Repository
ऑब्जेक्ट का एकमात्र मकसद, रिपॉज़िटरी में मौजूद आइटम को ट्रैवर्सल और इंडेक्स करना होता है. टेंप्लेट का इस्तेमाल करते समय आपको कॉन्टेंट कनेक्टर बनाने के लिए, Repository
इंटरफ़ेस में सिर्फ़ कुछ तरीकों को बदलना होगा.
ओवरराइड किए जाने वाले तरीके, आपकी इस्तेमाल की जाने वाली टेंप्लेट और ट्रैवर्सल रणनीति पर निर्भर करते हैं. ListingConnector
के लिए, ये तरीके बदलें:
init()
तरीका. डेटा रिपॉज़िटरी को सेट-अप और शुरू करने के लिए,init()
वाला तरीका बदलें.getIds()
तरीका. रिपॉज़िटरी में सभी रिकॉर्ड के आईडी और हैश वैल्यू पाने के लिए,getIds()
वाला तरीका बदलें.getDoc()
तरीका. इंडेक्स में नया आइटम जोड़ने, आइटम अपडेट करने, उसमें बदलाव करने या मिटाने के लिए,getDoc()
वाला तरीका बदलें.(ज़रूरी नहीं)
getChanges()
तरीका. अगर आपके डेटा स्टोर करने की जगह में बदलाव का पता लगाने की सुविधा काम करती है, तोgetChanges()
तरीका बदलें. बदले गए आइटम को फिर से पाने और उन्हें इंडेक्स करने के लिए, इस तरीके को हर शेड्यूल किए गए इंक्रीमेंटल (जैसा कि कॉन्फ़िगरेशन में बताया गया है) के लिए एक बार कॉल किया जाता है.(ज़रूरी नहीं)
close()
तरीका. अगर आपको डेटा स्टोर करने की जगह को क्लीनअप करना है, तोclose()
तरीके को बदलें. कनेक्टर के शटडाउन के दौरान, इस तरीके को एक बार कॉल किया जाता है.
Repository
ऑब्जेक्ट का हर तरीका, किसी खास तरह के
ApiOperation
ऑब्जेक्ट को दिखाता है. ApiOperation
ऑब्जेक्ट, डेटा स्टोर करने की आपकी जगह को इंडेक्स करने के लिए, एक या एक से ज़्यादा IndexingService.indexItem()
कॉल के रूप में कार्रवाई करता है.
कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं
अपने कनेक्टर के कॉन्फ़िगरेशन को हैंडल करने के दौरान, आपको Configuration
ऑब्जेक्ट से सभी कस्टम पैरामीटर लेने होंगे. आम तौर पर, यह टास्क Repository
क्लास के init()
तरीके से किया जाता है.
Configuration
क्लास में किसी कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके होते हैं. हर तरीका एक ConfigValue
ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू का पता लगाने के लिए, ConfigValue
ऑब्जेक्ट के get()
तरीके का इस्तेमाल किया जाएगा.
FullTraversalSample
का यह स्निपेट दिखाता है कि किसी Configuration
ऑब्जेक्ट से, कस्टम पूर्णांक की एक वैल्यू कैसे हासिल की जा सकती है:
कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration
क्लास के किसी एक तरह के पार्सर का इस्तेमाल करें.
ट्यूटोरियल कनेक्टर का यह स्निपेट, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए getMultiValue
तरीके का इस्तेमाल करता है:
सूची ट्रैवर्सल करना
ओवरराइड करें
getIds()
रिपॉज़िटरी में सभी रिकॉर्ड के लिए आईडी और हैश वैल्यू पाने का तरीका.
getIds()
वाला तरीका चेकपॉइंट स्वीकार करता है. चेकपॉइंट का इस्तेमाल किसी खास आइटम को फिर से इंडेक्स
करने के लिए किया जाता है, ताकि प्रोसेस में रुकावट आने पर उसे ठीक किया जा सके.
इसके बाद, Cloud Search इंडेक्स करने की सूची में हर आइटम को मैनेज करने के लिए, getDoc()
तरीका बदलें.
आइटम आईडी और हैश वैल्यू को पुश करें
डेटा स्टोर करने की जगह से आइटम आईडी और उनसे जुड़े कॉन्टेंट की हैश वैल्यू फ़ेच करने के लिए, getIds()
को बदलें. इसके बाद आईडी और हैश वैल्यू के पेयर को Cloud Search इंडेक्स करने की सूची में पुश ऑपरेशन अनुरोध में पैक किया जाता है. आम तौर पर, रूट या पैरंट आईडी को
पहले चाइल्ड आईडी के बाद पुश किया जाता है. ऐसा तब तक होता है, जब तक आइटम का पूरा क्रम
प्रोसेस नहीं हो जाता.
getIds()
वाला तरीका ऐसे चेकपॉइंट को स्वीकार करता है जिससे इंडेक्स किए जाने वाले आखिरी आइटम की जानकारी मिलती है. अगर प्रोसेस में रुकावट आती है, तो किसी खास आइटम को फिर से इंडेक्स करने के लिए चेकपॉइंट का इस्तेमाल किया जा सकता है. अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए, getIds()
तरीके में यह तरीका अपनाएं:
- डेटा स्टोर करने की जगह से, हर आइटम आईडी और उससे जुड़ी हैश वैल्यू पाएं.
- हर आईडी और हैश वैल्यू के जोड़े को
PushItems
में पैकेज करें. - हर
PushItems
कोgetIds()
तरीके से दिखाए गए इटरेटर में जोड़ें. ध्यान दें किgetIds()
असल मेंCheckpointCloseableIterable
दिखाता है, जोApiOperation
ऑब्जेक्ट का इटरेशन है. हर ऑब्जेक्ट,RepositoryDoc
पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि आइटम को सूची में भेजना.
नीचे दिए गए कोड स्निपेट में बताया गया है कि हर आइटम आईडी और हैश वैल्यू को कैसे पाया जाए और उन्हें PushItems
में कैसे डाला जाए.
किसी आइटम को Cloud Search की इंडेक्स करने की सूची में भेजने के लिए, PushItems
एक ApiOperation
अनुरोध होता है.
नीचे दिए गए कोड स्निपेट में बताया गया है कि आईडी और हैश वैल्यू को एक ही पुश में पैकेज करने के लिए, PushItems.Builder
क्लास का इस्तेमाल कैसे किया जाता है.ApiOperation
आइटम को आगे की प्रक्रिया के लिए, Cloud Search को इंडेक्स करने की सूची में पुश कर दिया जाता है.
हर आइटम को वापस पाएं और मैनेज करें
Cloud Search की इंडेक्स करने की सूची में हर आइटम को मैनेज करने के लिए,
getDoc()
को बदलें.
कोई आइटम नया हो सकता है, उसमें बदलाव किया जा सकता है या उसमें कोई बदलाव नहीं किया जा सकता. इसके अलावा, यह भी हो सकता है कि अब वह सोर्स को स्टोर करने की जगह में मौजूद न हो. नए या बदले गए हर आइटम को वापस पाएं और इंडेक्स करें. इंडेक्स से वे आइटम हटाएं जो अब सोर्स रिपॉज़िटरी में मौजूद नहीं हैं.
getDoc()
वाला तरीका, Google Cloud Search की इंडेक्स करने की सूची से किसी आइटम को स्वीकार करता है. सूची में मौजूद हर आइटम के लिए, getDoc()
तरीके में यह तरीका अपनाएं:
देखें कि Cloud Search इंडेक्स करने की सूची में आइटम का आईडी, डेटा स्टोर करने की जगह में मौजूद है या नहीं. अगर नहीं, तो इंडेक्स से आइटम मिटाएं.
आइटम की स्थिति के लिए इंडेक्स पोल करें. अगर किसी आइटम में बदलाव नहीं हुआ है (
ACCEPTED
), तो कुछ न करें.इंडेक्स में बदलाव किया गया या नए आइटम:
- अनुमतियां सेट करें.
- उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
- मेटाडेटा और आइटम को आपस में मिलाकर, एक इंडेक्स करने लायक आइटम बनाएं
RepositoryDoc
. RepositoryDoc
वापस करें.
ध्यान दें: ListingConnector
टेंप्लेट में, getDoc()
तरीके पर null
को
दिखाने की सुविधा नहीं है. null
के नतीजे दिखाने से NullPointerException.
के नतीजे मिलते हैं
मिटाए गए आइटम मैनेज करना
नीचे दिए गए कोड स्निपेट में यह पता लगाने का तरीका बताया गया है कि डेटा स्टोर करने की जगह में कोई आइटम मौजूद है या नहीं. अगर ऐसा नहीं है, तो उसे मिटा दें.
ध्यान दें कि documents
एक डेटा स्ट्रक्चर है, जो रिपॉज़िटरी को दिखाता है. अगर documents
में documentID
नहीं मिलता है, तो इंडेक्स से आइटम मिटाने के लिए, APIOperations.deleteItem(resourceName)
वापस जाएं.
बदलाव नहीं किए गए आइटम मैनेज करना
नीचे दिया गया कोड स्निपेट, Cloud Search इंडेक्स करने की सूची में आइटम की स्थिति को पोल कराने और उस आइटम को मैनेज करने का तरीका बताता है जिसमें बदलाव नहीं किया गया है.
यह पता लगाने के लिए कि आइटम में बदलाव नहीं किया गया है, आइटम की स्थिति और साथ ही ऐसे दूसरे मेटाडेटा की जांच करें जो बदलाव के बारे में बता सकते हैं. इस उदाहरण में, मेटाडेटा हैश का इस्तेमाल यह तय करने के लिए किया जाता है कि आइटम में बदलाव किया गया है या नहीं.
किसी आइटम के लिए अनुमतियां सेट करना
किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ताओं या ग्रुप की पहचान करने के लिए, आपकी रिपॉज़िटरी (डेटा स्टोर करने की जगह) ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करती है. ACL ऐसे समूहों या उपयोगकर्ताओं के लिए आईडी की सूची होता है जो आइटम ऐक्सेस कर सकते हैं.
आपको अपने रिपॉज़िटरी में इस्तेमाल किए गए ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही खोज नतीजे में उस आइटम को देख सकें. किसी आइटम को इंडेक्स करते समय उसका ACL शामिल करना ज़रूरी है, ताकि Google Cloud Search के पास वह जानकारी हो जो आइटम का सही लेवल ऐक्सेस करने के लिए ज़रूरी है.
कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर डेटा स्टोर करने की जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट देता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए संबंधित ACL बनाना होगा. अगर आपके रिपॉज़िटरी के ACL में ACL इनहेरिटेंस जैसे सिद्धांत लागू हैं, तो ऐसी स्थिति को मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.
ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, एक डोमेन वाले ACL के साथ काम करता है. यह क्रॉस-डोमेन ACL
के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यह कोड स्निपेट,
पूरे ट्रैवर्सल सैंपल से लिया गया है. इससे खोज करते समय
सभी उपयोगकर्ता या "प्रिंसिपल" (getCustomerPrincipal()
)
सभी आइटम के "रीडर" बन सकते हैं (.setReaders()
).
आपको रिपॉज़िटरी के लिए ACL को सही तरीके से मॉडल करने के लिए ACL को समझना होगा. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो किसी तरह का इनहेरिटेंस मॉडल इस्तेमाल करता है. इसमें चाइल्ड फ़ोल्डर, पैरंट फ़ोल्डर की अनुमतियां इनहेरिट करते हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search ACL में शामिल की गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को Item
ऑब्जेक्ट में सेव किया जाता है. Item
बनाने के लिए, आपके पास आइटम का कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए.
नीचे दिया गया कोड स्निपेट, IndexingItemBuilder
हेल्पर क्लास का इस्तेमाल करके Item
बनाने का तरीका बताता है.
इंडेक्स करने लायक आइटम बनाना
आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder
का इस्तेमाल करके, इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है.
नीचे दिए गए उदाहरण में, इंडेक्स करने लायक एक आइटम बनाने का तरीका बताया गया है.
RepositoryDoc
एक तरह का ApiOperation
है जो असली IndexingService.indexItem()
अनुरोध को पूरा करता है.
इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS
या SYNCHRONOUS
के तौर पर करने के लिए, RepositoryDoc.Builder
क्लास के setRequestMode()
तरीके का भी इस्तेमाल किया जा सकता है:
ASYNCHRONOUS
- एसिंक्रोनस मोड में, इंडेक्स करने के लिए इंतज़ार का समय ज़्यादा होता है. साथ ही, इससे इंडेक्स करने के अनुरोधों के लिए ज़्यादा थ्रूपुट कोटा तय होता है. डेटा स्टोर करने की पूरी जगह को शुरुआती इंडेक्स (बैकफ़िल) के तौर पर उपलब्ध कराने के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
- सिंक्रोनस मोड की वजह से, इंडेक्स करने के लिए इंतज़ार का समय कम हो जाता है. साथ ही, यह सीमित थ्रूपुट कोटा को शामिल करता है. डेटा स्टोर करने की जगह में अपडेट और बदलावों को इंडेक्स करने के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर यह जानकारी नहीं दी गई है, तो अनुरोध मोड डिफ़ॉल्ट रूप से
SYNCHRONOUS
पर सेट हो जाता है.
अगले चरण
यहां कुछ ऐसे तरीके बताए गए हैं जिन्हें आज़माया जा सकता है:
- (ज़रूरी नहीं) बंद होने से पहले किसी भी संसाधन को रिलीज़ करने के लिए,
close()
तरीका लागू करें. - (ज़रूरी नहीं) Content Connector SDK टूल का इस्तेमाल करके आइडेंटिटी कनेक्टर बनाएं.
टेंप्लेट क्लास का इस्तेमाल करके, ग्राफ़ ट्रैवर्सल कनेक्टर बनाना
Cloud Search इंडेक्स करने की सूची का इस्तेमाल, रिपॉज़िटरी में हर आइटम के लिए आईडी और वैकल्पिक हैश वैल्यू को होल्ड करने के लिए किया जाता है. ग्राफ़ ट्रैवर्सल कनेक्टर, आइटम आईडी को Google Cloud Search इंडेक्स करने की सूची में भेजता है. साथ ही, इंडेक्स करने के लिए उन्हें एक-एक करके दिखाता है. Google Cloud Search, सूची का रखरखाव करता है और सूची के कॉन्टेंट की तुलना करता है, ताकि आइटम की स्थिति तय की जा सके. जैसे, आइटम को डेटा स्टोर करने की जगह से मिटाया गया है या नहीं. Cloud Search इंडेक्स करने की सूची के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search की इंडेक्स करने की सूची देखें.
इंडेक्स करने के दौरान, आइटम का कॉन्टेंट, डेटा रिपॉज़िटरी से फ़ेच किया जाता है. साथ ही, बच्चों के किसी भी आइटम आईडी को सूची में भेजा जाता है. कनेक्टर, पैरंट और चाइल्ड आईडी को बार-बार प्रोसेस करता है. ऐसा तब तक होता है, जब तक सभी आइटम हैंडल नहीं हो जाते.
दस्तावेज़ों का यह सेक्शन GraphTraversalSample उदाहरण में दिए गए कोड स्निपेट से जुड़ा है.
कनेक्टर का एंट्री पॉइंट लागू करना
किसी कनेक्टर का एंट्री पॉइंट, main()
तरीका होता है. इस तरीके का मुख्य टास्क है, Application
क्लास का इंस्टेंस बनाना और कनेक्टर को चलाने के लिए इसके start()
तरीके को शुरू करना.
application.start()
को कॉल करने से पहले, ListingConnector
टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder
क्लास का इस्तेमाल करें. ListingConnector
,
Repository
ऑब्जेक्ट को स्वीकार करता है, जिसके मेथड को लागू किया जाता है.
इस स्निपेट में ListingConnector
और इससे जुड़े Repository
को इंस्टैंशिएट करने का तरीका बताया गया है:
हालांकि, कनेक्टर के main()
तरीके के कॉल Application.build
होने के बाद, SDK टूल initConfig()
तरीके को कॉल करता है.
initConfig()
तरीका:
- यह
Configuation.isInitialized()
तरीके को कॉल करता है, ताकि यह पक्का किया जा सके किConfiguration
को शुरू नहीं किया गया है. - Google के उपलब्ध कराए गए की-वैल्यू पेयर के साथ,
Configuration
ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर कोConfiguration
ऑब्जेक्ट मेंConfigValue
ऑब्जेक्ट में स्टोर किया जाता है.
Repository
इंटरफ़ेस को लागू करें
Repository
ऑब्जेक्ट का एकमात्र मकसद, रिपॉज़िटरी में मौजूद आइटम को ट्रैवर्सल और इंडेक्स करना होता है. टेंप्लेट का इस्तेमाल करते समय, आपको कॉन्टेंट कनेक्टर बनाने के लिए Repository
इंटरफ़ेस में सिर्फ़ कुछ तरीकों को बदलना होगा. ओवरराइड किए जाने वाले तरीके
आपकी इस्तेमाल की गई टेंप्लेट और ट्रैवर्सल रणनीति पर निर्भर करते हैं. ListingConnector
के लिए, इन तरीकों को बदला जा सकता है:
init()
तरीका. डेटा रिपॉज़िटरी को सेट-अप और शुरू करने के लिए,init()
वाला तरीका बदलें.getIds()
तरीका. रिपॉज़िटरी में सभी रिकॉर्ड के आईडी और हैश वैल्यू पाने के लिए,getIds()
वाला तरीका बदलें.getDoc()
तरीका. इंडेक्स में नया आइटम जोड़ने, आइटम अपडेट करने, उसमें बदलाव करने या मिटाने के लिए,getDoc()
वाला तरीका बदलें.(ज़रूरी नहीं)
getChanges()
तरीका. अगर आपके डेटा स्टोर करने की जगह में बदलाव का पता लगाने की सुविधा काम करती है, तोgetChanges()
तरीका बदलें. बदले गए आइटम को फिर से पाने और उन्हें इंडेक्स करने के लिए, इस तरीके को हर शेड्यूल किए गए इंक्रीमेंटल (जैसा कि कॉन्फ़िगरेशन में बताया गया है) के लिए एक बार कॉल किया जाता है.(ज़रूरी नहीं)
close()
तरीका. अगर आपको डेटा स्टोर करने की जगह को क्लीनअप करना है, तोclose()
तरीके को बदलें. कनेक्टर के शटडाउन के दौरान, इस तरीके को एक बार कॉल किया जाता है.
Repository
ऑब्जेक्ट का हर तरीका, कुछ खास तरह का ApiOperation
ऑब्जेक्ट दिखाता है. ApiOperation
ऑब्जेक्ट, डेटा स्टोर करने की जगह को इंडेक्स करने के लिए, एक या शायद एक से ज़्यादा
IndexingService.indexItem()
कॉल के रूप में कार्रवाई करता है.
कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं
अपने कनेक्टर के कॉन्फ़िगरेशन को हैंडल करने के दौरान, आपको Configuration
ऑब्जेक्ट से सभी कस्टम पैरामीटर लेने होंगे. आम तौर पर, यह टास्क Repository
क्लास के init()
तरीके से किया जाता है.
Configuration
क्लास में किसी कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके होते हैं. हर तरीका एक ConfigValue
ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू का पता लगाने के लिए, ConfigValue
ऑब्जेक्ट के get()
तरीके का इस्तेमाल किया जाएगा.
FullTraversalSample
का यह स्निपेट दिखाता है कि किसी Configuration
ऑब्जेक्ट से, कस्टम पूर्णांक की एक वैल्यू कैसे हासिल की जा सकती है:
कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration
क्लास के किसी एक तरह के पार्सर का इस्तेमाल करें.
ट्यूटोरियल कनेक्टर का यह स्निपेट, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए getMultiValue
तरीके का इस्तेमाल करता है:
ग्राफ़ ट्रैवर्सल करना
ओवरराइड करें
getIds()
रिपॉज़िटरी में सभी रिकॉर्ड के लिए आईडी और हैश वैल्यू पाने का तरीका.
getIds()
वाला तरीका चेकपॉइंट स्वीकार करता है. चेकपॉइंट का इस्तेमाल किसी खास आइटम को फिर से इंडेक्स
करने के लिए किया जाता है, ताकि प्रोसेस में रुकावट आने पर उसे ठीक किया जा सके.
इसके बाद, Cloud Search इंडेक्स करने की सूची में हर आइटम को मैनेज करने के लिए, getDoc()
तरीका बदलें.
आइटम आईडी और हैश वैल्यू को पुश करें
डेटा स्टोर करने की जगह से आइटम आईडी और उनसे जुड़े कॉन्टेंट की हैश वैल्यू फ़ेच करने के लिए, getIds()
को बदलें. इसके बाद आईडी और हैश वैल्यू के पेयर को Cloud Search इंडेक्स करने की सूची में पुश ऑपरेशन अनुरोध में पैक किया जाता है. आम तौर पर, रूट या पैरंट आईडी को
पहले चाइल्ड आईडी के बाद पुश किया जाता है. ऐसा तब तक होता है, जब तक आइटम का पूरा क्रम
प्रोसेस नहीं हो जाता.
getIds()
वाला तरीका ऐसे चेकपॉइंट को स्वीकार करता है जिससे इंडेक्स किए जाने वाले आखिरी आइटम की जानकारी मिलती है. अगर प्रोसेस में रुकावट आती है, तो किसी खास आइटम को फिर से इंडेक्स करने के लिए चेकपॉइंट का इस्तेमाल किया जा सकता है. अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए, getIds()
तरीके में यह तरीका अपनाएं:
- डेटा स्टोर करने की जगह से, हर आइटम आईडी और उससे जुड़ी हैश वैल्यू पाएं.
- हर आईडी और हैश वैल्यू के जोड़े को
PushItems
में पैकेज करें. - हर
PushItems
कोgetIds()
तरीके से दिखाए गए इटरेटर में जोड़ें. ध्यान दें किgetIds()
असल मेंCheckpointCloseableIterable
दिखाता है, जोApiOperation
ऑब्जेक्ट का इटरेशन है. हर ऑब्जेक्ट,RepositoryDoc
पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि आइटम को सूची में भेजना.
नीचे दिया गया कोड स्निपेट, हर आइटम आईडी और हैश वैल्यू को पाने और उन्हें PushItems
में डालने का तरीका बताता है. PushItems
एक ApiOperation
अनुरोध है, जो किसी आइटम को Cloud Search इंडेक्स करने की सूची में भेजने के लिए किया जाता है.
नीचे दिए गए कोड स्निपेट में बताया गया है कि आईडी और हैश वैल्यू को एक ही पुश में पैकेज करने के लिए, PushItems.Builder
क्लास का इस्तेमाल कैसे किया जाता है. ApiOperation
.
आइटम को आगे की प्रक्रिया के लिए, Cloud Search को इंडेक्स करने की सूची में पुश कर दिया जाता है.
हर आइटम को वापस पाएं और मैनेज करें
Cloud Search की इंडेक्स करने की सूची में हर आइटम को मैनेज करने के लिए,
getDoc()
को बदलें.
कोई आइटम नया हो सकता है, उसमें बदलाव किया जा सकता है या उसमें कोई बदलाव नहीं किया जा सकता. इसके अलावा, यह भी हो सकता है कि अब वह सोर्स को स्टोर करने की जगह में मौजूद न हो. नए या बदले गए हर आइटम को वापस पाएं और इंडेक्स करें. इंडेक्स से वे आइटम हटाएं जो अब सोर्स रिपॉज़िटरी में मौजूद नहीं हैं.
getDoc()
वाला तरीका, Cloud Search इंडेक्स करने की सूची से किसी आइटम को स्वीकार करता है. सूची में मौजूद हर आइटम के लिए, getDoc()
तरीके में यह तरीका अपनाएं:
देखें कि Cloud Search इंडेक्स करने की सूची में आइटम का आईडी, डेटा स्टोर करने की जगह में मौजूद है या नहीं. अगर नहीं, तो इंडेक्स से आइटम मिटाएं. अगर आइटम मौजूद है, तो अगले चरण के साथ जारी रखें.
इंडेक्स में बदलाव किया गया या नए आइटम:
- अनुमतियां सेट करें.
- उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
- मेटाडेटा और आइटम को आपस में मिलाकर, एक इंडेक्स करने लायक आइटम बनाएं
RepositoryDoc
. - आगे की प्रोसेस के लिए, चाइल्ड आईडी को Cloud Search इंडेक्स करने की सूची में रखें.
RepositoryDoc
वापस करें.
मिटाए गए आइटम मैनेज करना
इस कोड स्निपेट में यह पता लगाने का तरीका बताया गया है कि इंडेक्स में आइटम मौजूद है या नहीं. अगर आइटम को मिटाया नहीं जाता, तो उसे कैसे मिटाया जाता है.
किसी आइटम के लिए अनुमतियां सेट करना
किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ताओं या ग्रुप की पहचान करने के लिए, आपकी रिपॉज़िटरी (डेटा स्टोर करने की जगह) ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करती है. ACL ऐसे समूहों या उपयोगकर्ताओं के लिए आईडी की सूची होता है जो आइटम ऐक्सेस कर सकते हैं.
आपको अपने रिपॉज़िटरी में इस्तेमाल किए गए ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही खोज नतीजे में उस आइटम को देख सकें. किसी आइटम को इंडेक्स करते समय उसका ACL शामिल करना ज़रूरी है, ताकि Google Cloud Search के पास वह जानकारी हो जो आइटम का सही लेवल ऐक्सेस करने के लिए ज़रूरी है.
कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर डेटा स्टोर करने की जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट देता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए संबंधित ACL बनाना होगा. अगर आपके रिपॉज़िटरी के ACL में ACL इनहेरिटेंस जैसे सिद्धांत लागू हैं, तो ऐसी स्थिति को मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.
ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, एक डोमेन वाले ACL के साथ काम करता है. यह क्रॉस-डोमेन ACL
के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यह कोड स्निपेट,
पूरे ट्रैवर्सल सैंपल से लिया गया है. इससे खोज करते समय
सभी उपयोगकर्ता या "प्रिंसिपल" (getCustomerPrincipal()
)
सभी आइटम के "रीडर" बन सकते हैं (.setReaders()
).
आपको रिपॉज़िटरी के लिए ACL को सही तरीके से मॉडल करने के लिए ACL को समझना होगा. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो किसी तरह का इनहेरिटेंस मॉडल इस्तेमाल करता है. इसमें चाइल्ड फ़ोल्डर, पैरंट फ़ोल्डर की अनुमतियां इनहेरिट करते हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search ACL में शामिल की गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को Item
ऑब्जेक्ट में सेव किया जाता है. Item
बनाने के लिए, आपके पास आइटम का कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए.
नीचे दिया गया कोड स्निपेट, IndexingItemBuilder
हेल्पर क्लास का इस्तेमाल करके Item
बनाने का तरीका बताता है.
इंडेक्स करने लायक आइटम बनाना
आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder
का इस्तेमाल करके, इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है.
नीचे दिए गए उदाहरण में, इंडेक्स करने लायक एक आइटम बनाने का तरीका बताया गया है.
RepositoryDoc
, एक तरह का ApiOperation
है, जो IndexingService.indexItem()
से किए जाने वाले असली अनुरोध को पूरा करता है.
इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS
या SYNCHRONOUS
के तौर पर करने के लिए, RepositoryDoc.Builder
क्लास के setRequestMode()
तरीके का भी इस्तेमाल किया जा सकता है:
ASYNCHRONOUS
- एसिंक्रोनस मोड में, इंडेक्स करने के लिए इंतज़ार का समय ज़्यादा होता है. साथ ही, इससे इंडेक्स करने के अनुरोधों के लिए ज़्यादा थ्रूपुट कोटा तय होता है. डेटा स्टोर करने की पूरी जगह को शुरुआती इंडेक्स (बैकफ़िल) के तौर पर उपलब्ध कराने के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
- सिंक्रोनस मोड की वजह से, इंडेक्स करने के लिए इंतज़ार का समय कम हो जाता है. साथ ही, यह सीमित थ्रूपुट कोटा को शामिल करता है. डेटा स्टोर करने की जगह में अपडेट और बदलावों को इंडेक्स करने के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर यह जानकारी नहीं दी गई है, तो अनुरोध मोड डिफ़ॉल्ट रूप से
SYNCHRONOUS
पर सेट हो जाता है.
चाइल्ड आईडी को Cloud Search इंडेक्स करने की सूची में डालें
नीचे दिए गए कोड स्निपेट में बताया गया है कि अभी प्रोसेस किए जा रहे पैरंट आइटम के लिए, चाइल्ड आईडी को सूची में कैसे शामिल किया जाए. पैरंट आइटम को इंडेक्स करने के बाद, इन आईडी को प्रोसेस किया जाता है.
अगले चरण
यहां कुछ ऐसे तरीके बताए गए हैं जिन्हें आज़माया जा सकता है:
- (ज़रूरी नहीं) बंद होने से पहले किसी भी संसाधन को रिलीज़ करने के लिए,
close()
तरीका लागू करें. - (ज़रूरी नहीं) Identity Connector SDK टूल का इस्तेमाल करके, एक आइडेंटिटी कनेक्टर बनाएं.
REST API का इस्तेमाल करके, कॉन्टेंट कनेक्टर बनाना
REST API का इस्तेमाल करके, कॉन्टेंट कनेक्टर बनाने का तरीका नीचे दिए गए सेक्शन में बताया गया है.
अपनी ट्रैवर्सल रणनीति तय करना
कॉन्टेंट कनेक्टर का मुख्य काम, किसी रिपॉज़िटरी (डेटा स्टोर करने की जगह) को एक्सप्लोर करना और उसके डेटा को इंडेक्स करना होता है. आपको अपनी रिपॉज़िटरी में डेटा के साइज़ और लेआउट के आधार पर ट्रैवर्सल रणनीति लागू करनी होगी. ट्रैवर्सल की तीन सामान्य रणनीतियां नीचे दी गई हैं:
- ट्रैवर्सल की पूरी रणनीति
एक फ़ुल ट्रैवर्सल स्ट्रेटजी, डेटा स्टोर करने की पूरी जगह को स्कैन करती है और बिना सोचे-समझे हर आइटम को इंडेक्स करती है. आम तौर पर इस रणनीति का इस्तेमाल तब किया जाता है, जब आपके पास एक छोटा डेटा स्टोर होता है. साथ ही, आपके पास हर बार इंडेक्स करने पर एक पूरा ट्रैवर्सल करने का खर्च भी हो सकता है.
यह ट्रैवर्सल रणनीति, डेटा स्टोर करने की ऐसी छोटी जगहों के लिए सही है जिनमें ज़्यादातर स्टैटिक, बिना हैरारकी वाला डेटा हो. इस ट्रैवर्सल रणनीति का इस्तेमाल तब भी किया जा सकता है, जब बदलाव का पता लगाना मुश्किल हो या रिपॉज़िटरी के साथ काम न करता हो.
- ट्रैवर्सल की रणनीति की सूची बनाएं
लिस्ट ट्रैवर्सल रणनीति, सभी चाइल्ड नोड के साथ पूरे रिपॉज़िटरी को स्कैन करती है. इसमें हर आइटम की स्थिति तय की जाती है. इसके बाद, कनेक्टर एक सेकंड पास लेता है और सिर्फ़ उन आइटम को इंडेक्स करता है जो नए हैं या जिन्हें पिछली बार इंडेक्स किए जाने के बाद अपडेट किया गया है. आम तौर पर, इस रणनीति का इस्तेमाल किसी मौजूदा इंडेक्स को अपडेट करने के लिए किया जाता है. इसका इस्तेमाल इंडेक्स को अपडेट करने के लिए, हर बार पूरा ट्रैवर्सल करने की ज़रूरत नहीं होती.
यह ट्रैवर्सल रणनीति तब सही होती है, जब बदलाव का पता लगाना मुश्किल हो या डेटा स्टोर करने की जगह के साथ काम न करता हो, आपके पास बिना हैरारकी वाला डेटा हो, और बहुत बड़े डेटा सेट के साथ काम किया जा रहा हो.
- ग्राफ़ ट्रैवर्सल
ग्राफ़ ट्रैवर्सल रणनीति, हर आइटम की स्थिति तय करने के लिए पूरे पैरंट नोड को स्कैन करती है. इसके बाद, कनेक्टर दूसरा पास लेता है और सिर्फ़ रूट नोड में मौजूद आइटम इंडेक्स करता है. इसके अलावा, यह भी हो सकता है कि वे नए आइटम हों या उन्हें पिछली बार इंडेक्स किए जाने के बाद अपडेट किया गया हो. आखिर में, कनेक्टर किसी भी चाइल्ड आईडी को पास करता है और फिर चाइल्ड नोड में नए या अपडेट किए गए आइटम को इंडेक्स करता है. जब तक सभी आइटम ठीक नहीं हो जाते, तब तक कनेक्टर सभी चाइल्ड नोड में बार-बार होता रहता है. आम तौर पर, ऐसे ट्रैवर्सल का इस्तेमाल हैरारकी के रिपॉज़िटरी के लिए किया जाता है, जहां सभी आईडी की लिस्टिंग करना सही नहीं होता.
यह रणनीति तब सही होती है, जब आपके पास हैरारकी वाला ऐसा डेटा हो जिसे क्रॉल करने की ज़रूरत होती है, जैसे कि सीरीज़ की डायरेक्ट्री या वेब पेज.
अपनी ट्रैवर्सल रणनीति और इंडेक्स आइटम लागू करें
Cloud Search के लिए इंडेक्स किए जा सकने वाले हर एलिमेंट को Cloud Search API में, आइटम के तौर पर दिखाया जाता है. आइटम कोई फ़ाइल, फ़ोल्डर, CSV फ़ाइल की कोई लाइन या कोई डेटाबेस रिकॉर्ड हो सकता है.
स्कीमा रजिस्टर हो जाने के बाद, इंडेक्स को इस तरह से भरा जा सकता है:
(ज़रूरी नहीं) इंडेक्स करने के लिए 100KiB से बड़ी फ़ाइलों को अपलोड करने के लिए,
items.upload
का इस्तेमाल करना. छोटी फ़ाइलों के लिए,items.index
का इस्तेमाल करके, कॉन्टेंट को inlineContent के तौर पर एम्बेड करें.(ज़रूरी नहीं) इंडेक्स करने के लिए मीडिया फ़ाइलें अपलोड करने के लिए,
media.upload
का इस्तेमाल करना.आइटम को इंडेक्स करने के लिए,
items.index
का इस्तेमाल करना. उदाहरण के लिए, अगर आपका स्कीमा, मूवी स्कीमा में ऑब्जेक्ट की परिभाषा का इस्तेमाल करता है, तो किसी एक आइटम के लिए इंडेक्स करने का अनुरोध ऐसा दिखेगा:{ "name": "datasource/<data_source_id>/items/titanic", "acl": { "readers": [ { "gsuitePrincipal": { "gsuiteDomain": true } } ] }, "metadata": { "title": "Titanic", "viewUrl": "http://www.imdb.com/title/tt2234155/?ref_=nv_sr_1", "objectType": "movie" }, "structuredData": { "object": { "properties": [ { "name": "movieTitle", "textValues": { "values": [ "Titanic" ] } }, { "name": "releaseDate", "dateValues": { "values": [ { "year": 1997, "month": 12, "day": 19 } ] } }, { "name": "actorName", "textValues": { "values": [ "Leonardo DiCaprio", "Kate Winslet", "Billy Zane" ] } }, { "name": "genre", "enumValues": { "values": [ "Drama", "Action" ] } }, { "name": "userRating", "integerValues": { "values": [ 8 ] } }, { "name": "mpaaRating", "textValues": { "values": [ "PG-13" ] } }, { "name": "duration", "textValues": { "values": [ "3 h 14 min" ] } } ] } }, "content": { "inlineContent": "A seventeen-year-old aristocrat falls in love with a kind but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.", "contentFormat": "TEXT" }, "version": "01", "itemType": "CONTENT_ITEM" }
(ज़रूरी नहीं) किसी आइटम की पुष्टि करने के लिए, items.get कॉल का इस्तेमाल करके इंडेक्स किया गया.
पूरा ट्रैवर्सल करने के लिए, आपको समय-समय पर पूरे डेटा स्टोर करने की जगह को फिर से इंडेक्स करना होगा. सूची या ग्राफ़ ट्रैवर्सल लागू करने के लिए, आपको रिपॉज़िटरी के बदलावों को मैनेज करने के लिए कोड लागू करना होगा.
डेटा स्टोर करने की जगह के बदलावों को मैनेज करना
आप समय-समय पर, डेटा स्टोर करने की जगह से हर आइटम को इकट्ठा और इंडेक्स कर सकते हैं, ताकि आप उसे पूरी तरह इंडेक्स कर सकें. यह पक्का करने में असरदार होते हैं कि आपका इंडेक्स अप-टू-डेट है, लेकिन बड़े या हैरारकी वाले रिपॉज़िटरी के साथ काम करते समय, पूरी तरह इंडेक्स करना महंगा हो सकता है.
एक पूरे रिपॉज़िटरी को बार-बार इंडेक्स करने के लिए, इंडेक्स कॉल का इस्तेमाल करने के बजाय, Google Cloud इंडेक्स करने की सूची का इस्तेमाल भी किया जा सकता है. इससे, बदलावों को ट्रैक किया जा सकता है और सिर्फ़ उन आइटम को इंडेक्स किया जा सकता है जिनमें बदलाव हुआ है. बाद में पोलिंग और अपडेट करने के लिए, आइटम को सूची में डालने के लिए items.push अनुरोधों का इस्तेमाल किया जा सकता है. Google Cloud इंडेक्स करने की सूची के बारे में ज़्यादा जानकारी के लिए, Google Cloud इंडेक्स करने की सूची देखें.
Google Cloud Search API के बारे में ज़्यादा जानकारी के लिए, Cloud Search API देखें.