कॉन्टेंट कनेक्टर एक सॉफ़्टवेयर प्रोग्राम है. इसका इस्तेमाल, किसी एंटरप्राइज़ की रिपॉज़िटरी में मौजूद डेटा को ट्रैवर्स करने और डेटा सोर्स को पॉप्युलेट करने के लिए किया जाता है. Google, कॉन्टेंट कनेक्टर बनाने के लिए ये विकल्प उपलब्ध कराता है:
Content Connector SDK. अगर Java में प्रोग्रामिंग की जा रही है, तो यह एक अच्छा विकल्प है. Content Connector SDK टूल, REST API के आस-पास का एक रैपर है. इसकी मदद से, तुरंत कनेक्टर बनाए जा सकते हैं. SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, Content Connector SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना लेख पढ़ें.
लो-लेवल REST API या एपीआई लाइब्रेरी. अगर Java में प्रोग्रामिंग नहीं की जा रही है या आपके कोडबेस में किसी REST API या लाइब्रेरी को बेहतर तरीके से शामिल किया जा सकता है, तो इन विकल्पों का इस्तेमाल करें. REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना लेख पढ़ें.
आम तौर पर, कॉन्टेंट कनेक्टर ये काम करता है:
- कॉन्फ़िगरेशन पैरामीटर को पढ़ता और प्रोसेस करता है.
- तीसरे पक्ष के कॉन्टेंट डेटा स्टोर करने की जगह से, इंडेक्स किए जा सकने वाले डेटा के अलग-अलग हिस्से खींचता है. इन्हें "आइटम" कहा जाता है.
- यह एसीएल, मेटाडेटा, और कॉन्टेंट डेटा को इंडेक्स किए जा सकने वाले आइटम में जोड़ता है.
- Cloud Search के डेटा सोर्स में आइटम को इंडेक्स करता है.
- (ज़रूरी नहीं) तीसरे पक्ष की कॉन्टेंट रिपॉज़िटरी से, बदलाव की सूचनाएं सुनता है. बदलाव की सूचनाओं को इंडेक्स करने के अनुरोधों में बदल दिया जाता है, ताकि Cloud Search के डेटा सोर्स को तीसरे पक्ष के डेटा स्टोर करने की जगह के साथ सिंक किया जा सके. कनेक्टर सिर्फ़ तब यह काम करता है, जब डेटा स्टोर में बदलाव का पता लगाने की सुविधा काम करती हो.
Content Connector 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
नाम की डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल को ऐक्सेस करने की कोशिश करता है.
डेटा ट्रैवल की रणनीति तय करना
कॉन्टेंट कनेक्टर का मुख्य फ़ंक्शन, किसी रिपॉज़िटरी को ट्रैवर्स करना और उसके डेटा को इंडेक्स करना है. आपको अपने डेटा स्टोर में मौजूद डेटा के साइज़ और लेआउट के आधार पर, डेटा को ट्रैवर्स करने की रणनीति लागू करनी होगी. आपके पास अपनी रणनीति बनाने या एसडीके में लागू की गई इन रणनीतियों में से किसी को चुनने का विकल्प है:
- पूरी स्ट्रैवल रणनीति
पूरे ट्रैवल की रणनीति, पूरे रिपॉज़िटरी को स्कैन करती है और हर आइटम को इंडेक्स करती है. आम तौर पर, इस रणनीति का इस्तेमाल तब किया जाता है, जब आपके पास छोटा डेटाबेस हो और हर बार इंडेक्स करते समय, पूरे डेटाबेस को ट्रैवर्स करने का समय हो.
डेटा को ट्रैवर्स करने की यह रणनीति, उन छोटे डेटा स्टोर के लिए सही है जिनमें ज़्यादातर स्टैटिक और बिना हैरारकी वाला डेटा होता है. ट्रैवर्सल की इस रणनीति का इस्तेमाल तब भी किया जा सकता है, जब बदलाव का पता लगाना मुश्किल हो या रिपॉज़िटरी में यह सुविधा काम न करती हो.
- सूची को ट्रैवर्स करने की रणनीति
सूची को ट्रैवर्स करने की रणनीति, पूरे डेटा स्टोर को स्कैन करती है. इसमें सभी चाइल्ड नोड भी शामिल होते हैं. इससे हर आइटम की स्थिति का पता चलता है. इसके बाद, कनेक्टर एक दूसरा पास लेता है और सिर्फ़ उन आइटम को इंडेक्स करता है जो नए हैं या जिन्हें पिछली बार इंडेक्स करने के बाद अपडेट किया गया है. इस रणनीति का इस्तेमाल आम तौर पर, किसी मौजूदा इंडेक्स में इंक्रीमेंटल अपडेट करने के लिए किया जाता है. ऐसा करने से, इंडेक्स को हर बार अपडेट करने के बजाय, सिर्फ़ नए डेटा को अपडेट किया जाता है.
डेटा को ट्रैवर्स करने की यह रणनीति तब कारगर होती है, जब बदलाव का पता लगाना मुश्किल हो या रिपॉज़िटरी में यह सुविधा काम न करती हो. साथ ही, आपके पास बिना हैरारकी वाला डेटा हो और बहुत बड़े डेटा सेट के साथ काम किया जा रहा हो.
- ग्राफ़ को ट्रैवर्स करना
ग्राफ़ ट्रैवर्सल की रणनीति, हर आइटम की स्थिति तय करने के लिए पूरे पैरंट नोड को स्कैन करती है. इसके बाद, कनेक्टर एक दूसरा पास लेता है और सिर्फ़ रूट नोड में मौजूद उन आइटम को इंडेक्स करता है जो नए हैं या जिन्हें पिछली बार इंडेक्स करने के बाद अपडेट किया गया है. आखिर में, कनेक्टर किसी भी चाइल्ड आईडी को पास करता है. इसके बाद, चाइल्ड नोड में उन आइटम को इंडेक्स करता है जो नए हैं या जिन्हें अपडेट किया गया है. कनेक्टर, सभी चाइल्ड नोड में तब तक बार-बार काम करता रहता है, जब तक सभी आइटम को पूरा नहीं कर लिया जाता. आम तौर पर, इस तरह के ट्रैवर्स का इस्तेमाल, हैरारकी वाले उन रिपॉज़िटरी के लिए किया जाता है जहां सभी आईडी की सूची बनाना मुमकिन नहीं होता.
यह रणनीति तब सही होती है, जब आपके पास हैरारकी वाला ऐसा डेटा हो जिसे क्रॉल करना ज़रूरी हो. जैसे, डायरेक्ट्री या वेब पेजों की सीरीज़.
ट्रैवर्सल की इन सभी रणनीतियों को एसडीके में टेंप्लेट कनेक्टर क्लास से लागू किया जाता है. आपके पास ट्रैवर्सल की अपनी रणनीति लागू करने का विकल्प है. हालांकि, इन टेंप्लेट की मदद से, कनेक्टर को तेज़ी से डेवलप किया जा सकता है. टेंप्लेट का इस्तेमाल करके कनेक्टर बनाने के लिए, अपनी ट्रैवर्सल रणनीति से जुड़े सेक्शन पर जाएं:
- टेंप्लेट क्लास का इस्तेमाल करके, पूरा ट्रैवर्सल कनेक्टर बनाना
- टेंप्लेट क्लास का इस्तेमाल करके, सूची के लिए ट्रैवलर कनेक्टर बनाना
- टेंप्लेट क्लास का इस्तेमाल करके, ग्राफ़ ट्रैवर्सल कनेक्टर बनाना
टेंप्लेट क्लास का इस्तेमाल करके, फ़ुल ट्रैवर्सल कनेक्टर बनाना
दस्तावेज़ों के इस सेक्शन में, 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()
method में यह तरीका अपनाएं:
- अनुमतियां सेट करें.
- जिस आइटम को इंडेक्स किया जा रहा है उसके लिए मेटाडेटा सेट करें.
- मेटाडेटा और आइटम को इंडेक्स किए जा सकने वाले एक
RepositoryDoc
में जोड़ें. - इंडेक्स किए जा सकने वाले हर आइटम को,
getAllDocs()
method से दिखाए गए आइटर में पैकेज करें. ध्यान दें किgetAllDocs()
असल में एकCheckpointCloseableIterable
दिखाता है, जोApiOperation
ऑब्जेक्ट का एक क्रम है. हर ऑब्जेक्ट, किसीRepositoryDoc
पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि उसे इंडेक्स करना.
अगर आइटम का सेट एक कॉल में प्रोसेस करने के लिए बहुत बड़ा है, तो एक जांच बिंदु शामिल करें और इंडेक्स करने के लिए ज़्यादा आइटम उपलब्ध हैं, यह बताने के लिए hasMore(true)
सेट करें.
किसी आइटम के लिए अनुमतियां सेट करना
आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करके, उन उपयोगकर्ताओं या ग्रुप की पहचान करता है जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.
आपको अपनी रिपॉज़िटरी में इस्तेमाल किए गए एसीएल का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही उसे खोज के नतीजों में देख सकें. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल को शामिल करना ज़रूरी है. इससे Google Cloud Search के पास, आइटम को सही लेवल का ऐक्सेस देने के लिए ज़रूरी जानकारी होती है.
Content Connector SDK, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए, एसीएल क्लास और तरीकों का एक बेहतर सेट उपलब्ध कराता है. आपको अपनी रिपॉज़िटरी में मौजूद हर आइटम के लिए, एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा एसीएल बनाना होगा. अगर आपके डेटा स्टोरेज की एसीएल में, एसीएल के इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल किया जाता है, तो उस एसीएल को मॉडल करना मुश्किल हो सकता है. Google Cloud Search के एसीएल के बारे में ज़्यादा जानने के लिए, Google Cloud Search के एसीएल लेख पढ़ें.
ध्यान दें: Cloud Search Indexing API, सिंगल-डोमेन एसीएल के साथ काम करता है. यह क्रॉस-डोमेन एसीएल के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यहां दिया गया कोड स्निपेट, पूरे ट्रैवल के सैंपल से लिया गया है. इससे सभी उपयोगकर्ताओं या “प्रिंसिपल” (getCustomerPrincipal()
) को खोज करते समय, सभी आइटम (.setReaders()
) के “रीडर” बनने की अनुमति मिलती है.
आपको एसीएल को समझना होगा, ताकि आप रिपॉज़िटरी के लिए एसीएल को सही तरीके से मॉडल कर सकें. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो इनहेरिटेंस मॉडल का इस्तेमाल करता हो. इस मॉडल में, चाइल्ड फ़ोल्डर (सब-फ़ोल्डर) को पैरंट फ़ोल्डर से अनुमतियां मिलती हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search के एसीएल में दी गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को Item
ऑब्जेक्ट में सेव किया जाता है. Item
बनाने के लिए, आपके पास आइटम के लिए कम से कम यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए.
नीचे दिए गए कोड स्निपेट में, IndexingItemBuilder
हेल्पर क्लास का इस्तेमाल करके Item
बनाने का तरीका बताया गया है.
इंडेक्स किया जा सकने वाला आइटम बनाना
आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder
क्लास का इस्तेमाल करके, इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. इस उदाहरण में, इंडेक्स किया जा सकने वाला एक आइटम बनाने का तरीका बताया गया है.
RepositoryDoc
एक तरह का ApiOperation
है, जो असल IndexingService.indexItem()
अनुरोध को पूरा करता है.
इंडेक्स करने के अनुरोध को ASYNCHRONOUS
या SYNCHRONOUS
के तौर पर पहचानने के लिए, RepositoryDoc.Builder
क्लास के setRequestMode()
तरीके का भी इस्तेमाल किया जा सकता है:
ASYNCHRONOUS
- असिंक्रोनस मोड की वजह से, इंडेक्स करने से लेकर दिखाने में ज़्यादा समय लगता है. साथ ही, इंडेक्स करने के अनुरोधों के लिए ज़्यादा थ्रूपुट कोटा उपलब्ध होता है. पूरे रिपॉज़िटरी को शुरुआती इंडेक्स करने (बैकफ़िल) के लिए, असाइनोक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
- सिंक्रोनस मोड की मदद से, इंडेक्स करने से लेकर विज्ञापन दिखाने में लगने वाला समय कम हो जाता है. साथ ही, इसमें सीमित थ्रुपुट कोटा भी शामिल होता है. हमारा सुझाव है कि डेटा को सिंक करने वाले मोड का इस्तेमाल करके, डेटा को अपडेट करें और डेटा स्टोर करने की जगह में बदलाव करें. अगर कोई वैल्यू नहीं दी गई है, तो अनुरोध मोड डिफ़ॉल्ट रूप से
SYNCHRONOUS
पर सेट होता है.
इंडेक्स किए जा सकने वाले हर आइटम को किसी आइटरेटर में पैकेज करना
getAllDocs()
वाला तरीका, RepositoryDoc
ऑब्जेक्ट का Iterator
, खास तौर पर CheckpointCloseableIterable
दिखाता है. CheckpointClosableIterableImpl.Builder
क्लास का इस्तेमाल करके, कोई आइटरेटर बनाया जा सकता है और उसे दिखाया जा सकता है. यहां दिया गया कोड स्निपेट, किसी iterator को बनाने और उसे दिखाने का तरीका दिखाता है.
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()
तरीके से दिखाए गए iterator में जोड़ें. ध्यान दें किgetIds()
असल में एकCheckpointCloseableIterable
दिखाता है, जोApiOperation
ऑब्जेक्ट का एक क्रम है. हर ऑब्जेक्ट,RepositoryDoc
पर किए गए एपीआई अनुरोध को दिखाता है. जैसे, आइटम को सूची में जोड़ना.
नीचे दिए गए कोड स्निपेट में, हर आइटम आईडी और हैश वैल्यू पाने और उन्हें PushItems
में डालने का तरीका बताया गया है.
PushItems
, Cloud Search की इंडेक्स करने की सूची में किसी आइटम को शामिल करने के लिए किया गया 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
, डेटा का ऐसा स्ट्रक्चर है जो रिपॉज़िटरी को दिखाता है. अगर documentID
, documents
में नहीं मिलता है, तो इंडेक्स से आइटम मिटाने के लिए, APIOperations.deleteItem(resourceName)
पर वापस जाएं.
बदलाव नहीं किए गए आइटम मैनेज करना
नीचे दिए गए कोड स्निपेट में, Cloud Search के इंडेक्स करने की सूची में आइटम के स्टेटस को पोल करने और बिना बदलाव वाले आइटम को मैनेज करने का तरीका बताया गया है.
यह पता लगाने के लिए कि आइटम में कोई बदलाव नहीं हुआ है, आइटम के स्टेटस के साथ-साथ ऐसे अन्य मेटाडेटा की जांच करें जिनसे बदलाव का पता चल सकता है. उदाहरण में, मेटाडेटा के हैश का इस्तेमाल यह पता लगाने के लिए किया जाता है कि आइटम में बदलाव हुआ है या नहीं.
किसी आइटम के लिए अनुमतियां सेट करना
आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करके, उन उपयोगकर्ताओं या ग्रुप की पहचान करता है जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.
आपको अपनी रिपॉज़िटरी में इस्तेमाल किए गए एसीएल का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही उसे खोज के नतीजों में देख सकें. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल को शामिल करना ज़रूरी है. इससे Google Cloud Search के पास, आइटम को सही लेवल का ऐक्सेस देने के लिए ज़रूरी जानकारी होती है.
Content Connector SDK, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए, एसीएल क्लास और तरीकों का एक बेहतर सेट उपलब्ध कराता है. आपको अपनी रिपॉज़िटरी में मौजूद हर आइटम के लिए, एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा एसीएल बनाना होगा. अगर आपके डेटा स्टोरेज की एसीएल में, एसीएल के इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल किया जाता है, तो उस एसीएल को मॉडल करना मुश्किल हो सकता है. Google Cloud Search के एसीएल के बारे में ज़्यादा जानने के लिए, Google Cloud Search के एसीएल लेख पढ़ें.
ध्यान दें: Cloud Search Indexing API, सिंगल-डोमेन एसीएल के साथ काम करता है. यह क्रॉस-डोमेन एसीएल के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यहां दिया गया कोड स्निपेट, पूरे ट्रैवल के सैंपल से लिया गया है. इससे सभी उपयोगकर्ताओं या “प्रिंसिपल” (getCustomerPrincipal()
) को खोज करते समय, सभी आइटम (.setReaders()
) के “रीडर” बनने की अनुमति मिलती है.
आपको एसीएल को समझना होगा, ताकि आप रिपॉज़िटरी के लिए एसीएल को सही तरीके से मॉडल कर सकें. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो इनहेरिटेंस मॉडल का इस्तेमाल करता हो. इस मॉडल में, चाइल्ड फ़ोल्डर (सब-फ़ोल्डर) को पैरंट फ़ोल्डर से अनुमतियां मिलती हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search के एसीएल में दी गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को 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
, किसी आइटम को Cloud Search की इंडेक्स करने की सूची में शामिल करने का ApiOperation
अनुरोध है.
यहां दिए गए कोड स्निपेट में, आईडी और हैश वैल्यू को एक ही पुश ApiOperation
में पैकेज करने के लिए, PushItems.Builder
क्लास का इस्तेमाल करने का तरीका बताया गया है.
आगे की प्रोसेसिंग के लिए, आइटम को Cloud Search के इंडेक्स करने की सूची में भेज दिया जाता है.
हर आइटम को वापस लाना और उसे मैनेज करना
Cloud Search इंडेक्स करने की सूची में मौजूद हर आइटम को मैनेज करने के लिए, बदलाव करें
getDoc()
.
कोई आइटम नया, बदला गया, अपरिवर्तित या सोर्स रिपॉज़िटरी में मौजूद न हो सकता. नए या बदले गए हर आइटम को वापस पाएं और इंडेक्स करें. इंडेक्स से ऐसे आइटम हटाएं जो अब सोर्स रिपॉज़िटरी में मौजूद नहीं हैं.
getDoc()
तरीका, Cloud Search की इंडेक्स करने वाली सूची से आइटम स्वीकार करता है. सूची में मौजूद हर आइटम के लिए, getDoc()
तरीके में यह तरीका अपनाएं:
देखें कि Cloud Search की इंडेक्स करने की सूची में मौजूद आइटम का आईडी, रिपॉज़िटरी में मौजूद है या नहीं. अगर ऐसा नहीं है, तो इंडेक्स से आइटम मिटाएं. अगर आइटम मौजूद है, तो अगले चरण पर जाएं.
इंडेक्स में बदलाव या नए आइटम:
- अनुमतियां सेट करें.
- जिस आइटम को इंडेक्स किया जा रहा है उसके लिए मेटाडेटा सेट करें.
- मेटाडेटा और आइटम को इंडेक्स किए जा सकने वाले एक
RepositoryDoc
में जोड़ें. - आगे की प्रोसेसिंग के लिए, चाइल्ड आईडी को Cloud Search के इंडेक्स करने की सूची में डालें.
RepositoryDoc
को वापस लाएं.
मिटाए गए आइटम मैनेज करना
यहां दिए गए कोड स्निपेट में, यह पता लगाने का तरीका बताया गया है कि इंडेक्स में कोई आइटम मौजूद है या नहीं. अगर नहीं है, तो उसे मिटाएं.
किसी आइटम के लिए अनुमतियां सेट करना
आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करके, उन उपयोगकर्ताओं या ग्रुप की पहचान करता है जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.
आपको अपनी रिपॉज़िटरी में इस्तेमाल किए गए एसीएल का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि किसी आइटम का ऐक्सेस रखने वाले उपयोगकर्ता ही उसे खोज के नतीजों में देख सकें. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल को शामिल करना ज़रूरी है. इससे Google Cloud Search के पास, आइटम को सही लेवल का ऐक्सेस देने के लिए ज़रूरी जानकारी होती है.
Content Connector SDK, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए, एसीएल क्लास और तरीकों का एक बेहतर सेट उपलब्ध कराता है. आपको अपनी रिपॉज़िटरी में मौजूद हर आइटम के लिए, एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा एसीएल बनाना होगा. अगर आपके डेटा स्टोरेज की एसीएल में, एसीएल के इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल किया जाता है, तो उस एसीएल को मॉडल करना मुश्किल हो सकता है. Google Cloud Search के एसीएल के बारे में ज़्यादा जानने के लिए, Google Cloud Search के एसीएल लेख पढ़ें.
ध्यान दें: Cloud Search Indexing API, सिंगल-डोमेन एसीएल के साथ काम करता है. यह क्रॉस-डोमेन एसीएल के साथ काम नहीं करता. एसीएल का इस्तेमाल करके, हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder
क्लास का इस्तेमाल करें. यहां दिया गया कोड स्निपेट, पूरे ट्रैवल के सैंपल से लिया गया है. इससे सभी उपयोगकर्ताओं या “प्रिंसिपल” (getCustomerPrincipal()
) को खोज करते समय, सभी आइटम (.setReaders()
) के “रीडर” बनने की अनुमति मिलती है.
आपको एसीएल को समझना होगा, ताकि आप रिपॉज़िटरी के लिए एसीएल को सही तरीके से मॉडल कर सकें. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स कर रहे हों जो इनहेरिटेंस मॉडल का इस्तेमाल करता हो. इस मॉडल में, चाइल्ड फ़ोल्डर (सब-फ़ोल्डर) को पैरंट फ़ोल्डर से अनुमतियां मिलती हैं. एसीएल इनहेरिटेंस को मॉडलिंग करने के लिए, Google Cloud Search के एसीएल में दी गई अतिरिक्त जानकारी की ज़रूरत होती है
किसी आइटम के लिए मेटाडेटा सेट करना
मेटाडेटा को 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 फ़ाइल में मौजूद लाइन या डेटाबेस रिकॉर्ड हो सकता है.
स्कीमा रजिस्टर होने के बाद, इंडेक्स को पॉप्युलेट करने के लिए:
(ज़रूरी नहीं) इंडेक्स करने के लिए, 100 केबी से बड़ी फ़ाइलें अपलोड करने के लिए
items.upload
का इस्तेमाल करना. छोटी फ़ाइलों के लिए,items.index
का इस्तेमाल करके, कॉन्टेंट को inlineContent के तौर पर एम्बेड करें.(ज़रूरी नहीं) इंडेक्स करने के लिए मीडिया फ़ाइलें अपलोड करने के लिए,
media.upload
का इस्तेमाल करना.आइटम को इंडेक्स करने के लिए,
items.index
का इस्तेमाल करना. उदाहरण के लिए, अगर आपका स्कीमा movie schema में ऑब्जेक्ट की परिभाषा का इस्तेमाल करता है, तो किसी एक आइटम को इंडेक्स करने का अनुरोध इस तरह दिखेगा:{ "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 कॉल का इस्तेमाल करके, यह पुष्टि करना कि item को इंडेक्स किया गया है.
पूरे ट्रैवल को पूरा करने के लिए, आपको समय-समय पर पूरी रिपॉज़िटरी को फिर से इंडेक्स करना होगा. सूची या ग्राफ़ को ट्रैवर्स करने के लिए, आपको रिपॉज़िटरी में हुए बदलावों को मैनेज करने के लिए कोड लागू करना होगा.
डेटा स्टोर करने की जगह में होने वाले बदलावों को हैंडल करना
पूरी तरह से इंडेक्स करने के लिए, समय-समय पर किसी रिपॉज़िटरी से हर आइटम को इकट्ठा और इंडेक्स किया जा सकता है. यह पक्का करने में मदद मिलती है कि आपका इंडेक्स अप-टू-डेट है. हालांकि, बड़े या हैरारकी वाले रिपॉज़िटरी के साथ काम करते समय, पूरा इंडेक्स करना महंगा हो सकता है.
पूरी रिपॉज़िटरी को हर बार इंडेक्स करने के लिए, इंडेक्स कॉल का इस्तेमाल करने के बजाय, Google Cloud इंडेक्स करने की सूची का इस्तेमाल भी किया जा सकता है. इस सूची का इस्तेमाल, बदलावों को ट्रैक करने और सिर्फ़ उन आइटम को इंडेक्स करने के लिए किया जा सकता है जिनमें बदलाव हुए हैं. बाद में पोलिंग और अपडेट करने के लिए, आइटम को सूची में डालने के लिए, items.push अनुरोधों का इस्तेमाल किया जा सकता है. Google Cloud की इंडेक्स करने की सूची के बारे में ज़्यादा जानकारी के लिए, Google Cloud की इंडेक्स करने की सूची देखें.
Google Cloud Search API के बारे में ज़्यादा जानकारी के लिए, Cloud Search API देखें.