WebDriver BiDi क्या है?

Scrapeless Agent Browser ब्राउज़र ऑटोमेशन क्लाइंट्स के लिए प्रलेखित कनेक्शन इंटरफेसेज़ के माध्यम से प्रबंधित ब्राउज़र सेशन्स प्रदान करता है।

WebDriver BiDi ब्राउज़रों को दूरस्थ रूप से नियंत्रित करने और ब्राउज़र इवेंट प्राप्त करने के लिए एक द्विदिशी प्रोटोकॉल है। “BiDi” दोनों दिशाओं में संचार को संदर्भित करता है: एक ऑटोमेशन क्लाइंट कमांड भेजता है, और सब्सक्राइब की गई गतिविधि होने पर ब्राउज़र इवेंट संदेश भेज सकता है। यह इवेंट-चालित मॉडल उन निरीक्षणों का समर्थन करता है जिन्हें केवल बार-बार अनुरोध-और-प्रतिक्रिया क्वेरी के रूप में व्यक्त करना असहज होता है।

WebDriver BiDi एक प्रोटोकॉल है, कोई ब्राउज़र, टेस्ट रनर या होस्टिंग सेवा नहीं। W3C स्पेसिफिकेशन अभी भी प्रगति पर है, और इम्प्लीमेंटेशन समर्थित मॉड्यूल्स और कमांड्स में अलग-अलग हो सकते हैं। इसलिए मूल्यांकन के लिए सामान्य “BiDi सपोर्ट करता है” दावे की बजाय वास्तविक ब्राउज़र, क्लाइंट बाइंडिंग, प्रोटोकॉल क्षमता और कार्य द्वारा आवश्यक ऑपरेशन की ज़रूरत होती है।

द्विदिशी संचार क्या जोड़ता है

द्विदिशी संचार ब्राउज़र को यह सक्षम बनाता है कि वह क्लाइंट के प्रत्येक अलग-अलग होने वाले इवेंट के लिए पूछने की प्रतीक्षा किए बिना प्रासंगिक गतिविधि की रिपोर्ट कर सके। WebDriver BiDi प्रोटोकॉल ब्राउज़र नियंत्रण और ऑब्ज़र्वेशन के लिए कमांड्स, रिस्पॉन्सेस, इवेंट्स, ट्रांसपोर्ट, और मॉड्यूल्स को परिभाषित करता है।

एक पारंपरिक अनुरोध-और-प्रतिक्रिया इंटरैक्शन कई क्रियाओं के लिए पर्याप्त होता है। क्लाइंट नेविगेशन का अनुरोध करता है और परिणाम प्राप्त करता है। इवेंट-आधारित ऑब्ज़र्वेशन तब उपयोगी हो जाता है जब ब्राउज़र उन कमांड्स के बीच में भी गतिविधि उत्पन्न कर सकता है, जैसे कोई डॉक्यूमेंट कॉन्टेक्स्ट बदल देना या कोई स्क्रिप्ट लॉग एंट्री तैयार करना।

महत्वपूर्ण सुधार ऑब्ज़र्वेशन मॉडल है, न कि यह वादा कि हर ब्राउज़र कार्य तेज़ हो जाएगा। यदि किसी कार्य को केवल अंतिम पेज शीर्षक चाहिए, तो इवेंट स्ट्रीम से बहुत कम लाभ होगा। यदि किसी कार्य को किसी विशेष नेविगेशन के साथ कंसोल गतिविधि को जोड़ना है, तो सब्सक्रिप्शन्स समय-समय पर स्नैपशॉट माँगने की तुलना में अधिक प्रासंगिक जानकारी प्रदान कर सकते हैं।

इवेंट्स ज़िम्मेदारियाँ भी पैदा करते हैं। क्लाइंट को यह तय करना होता है कि किस पर सब्सक्राइब करना है, संदेशों को कैसे सहसंबंधित करना है, कौन-से इवेंट्स पूर्णता के लिए मायने रखते हैं, और सब्सक्रिप्शन्स को कब समाप्त करना है। निरीक्षणों का असीमित संग्रह उपयोगी डायग्नॉस्टिक की बजाय स्टोरेज और व्याख्या की समस्या बन सकता है।

कमांड्स, रिस्पॉन्सेस, और इवेंट्स की अलग-अलग भूमिकाएँ होती हैं

कमांड्स किसी ऑपरेशन का अनुरोध करते हैं, रिस्पॉन्सेस उसके परिणाम की रिपोर्ट करते हैं, और इवेंट्स सब्सक्राइब की गई ब्राउज़र गतिविधि का वर्णन करते हैं। इन संदेश प्रकारों को उनकी भूमिका के अनुसार संभाला जाना चाहिए, न कि पूर्ण की गई क्रियाओं की एक क्रमिक सूची के रूप में।

कोई कमांड रिस्पॉन्स यह पुष्टि कर सकता है कि समर्थित प्रोटोकॉल ऑपरेशन पूरा हो गया। कोई इवेंट पेज द्वारा शुरू की गई ब्राउज़र गतिविधि या किसी अन्य ऑपरेशन के कारण आ सकता है। क्लाइंट को निरीक्षण को संबंधित डॉक्यूमेंट, कार्य, और नेविगेशन से जोड़ने के लिए पर्याप्त कॉन्टेक्स्ट चाहिए।

किसी इवेंट के अस्तित्व की व्याख्या इस प्रमाण के रूप में न करें कि एप्लिकेशन ने अपना व्यावसायिक लक्ष्य हासिल कर लिया है। नेविगेशन इवेंट केवल नेविगेशन के बारे में कुछ कहता है। कार्य को अभी भी किसी परिणाम क्षेत्र के प्रकट होने, किसी फ़ॉर्म के सक्षम होने, या किसी विशिष्ट आइटम के चुने जाने की आवश्यकता हो सकती है।

कार्य के लिए एक छोटा ऑब्ज़र्वेशन अनुबंध परिभाषित करें। वह कमांड पहचानें जो काम शुरू करता है, वे इवेंट्स जो उपयोगी सबूत प्रदान करते हैं, वह पेज स्थिति जो सफलता स्थापित करती है, और वह क्लीनअप जो ऑब्ज़र्वेशन समाप्त करता है। इससे इवेंट-चालित वर्कफ़्लो की समीक्षा करना संभव हो जाता है, बिना हर कच्चे संदेश को हमेशा के लिए सुरक्षित रखने की आवश्यकता के।

इवेंट-चालित ऑटोमेशन में कॉन्टेक्स्ट पहचान महत्वपूर्ण है

कॉन्टेक्स्ट पहचान यह निर्धारित करती है कि कोई इवेंट किस पेज या एम्बेडेड डॉक्यूमेंट से संबंधित है। ब्राउज़र में कई शीर्ष-स्तरीय पेज और चाइल्ड डॉक्यूमेंट हो सकते हैं, इसलिए एक कनेक्शन किसी एक ही रुचिकर डॉक्यूमेंट का संकेत नहीं देता।

HTML ब्राउज़िंग-कॉन्टेक्स्ट मॉडल ब्राउज़र के डॉक्यूमेंट्स और उनके संबंधों के बीच अंतर्निहित अंतर प्रदान करता है। कोई पॉपअप, नेस्टेड फ़्रेम, और नेविगेशन, प्रत्येक यह प्रभावित कर सकते हैं कि किस डॉक्यूमेंट का ऑब्ज़र्वेशन या नियंत्रण होना चाहिए।

एक व्यावहारिक उदाहरण वह एप्लिकेशन है जो रसीद को एक अलग पेज में खोलता है। आरंभिक क्लिक मूल पेज से संबंधित होता है, लेकिन रसीद की तैयार स्थिति नए कॉन्टेक्स्ट से संबंधित होती है। कोई कार्य जो मूल डॉक्यूमेंट को ही पढ़ता रहता है, यह निष्कर्ष निकाल सकता है कि कोई रसीद नहीं है, जबकि ब्राउज़र ने उसे सफलतापूर्वक खोल दिया होता है।

फ़्रेम पहचान के लिए भी इसी तरह की सावधानी चाहिए। एम्बेडेड विजेट से आया लॉग संदेश अपने-आप पैरेंट एप्लिकेशन को नहीं सौंप देना चाहिए। डायग्नॉस्टिक रिकॉर्ड्स में कॉन्टेक्स्ट पहचान बनाए रखें ताकि निरीक्षणों को उस डॉक्यूमेंट से जोड़ा जा सके जिसने उन्हें उत्पन्न किया।

सब्सक्रिप्शन्स को दायरा और अवधि चाहिए

किसी सब्सक्रिप्शन को केवल उतने ही इवेंट्स और कॉन्टेक्स्ट्स को कवर करना चाहिए जितने किसी कार्य के लिए ज़रूरी हों, और उतनी ही देर तक जितनी देर तक कार्य को उनकी आवश्यकता हो। इससे डायग्नॉस्टिक शोर और असंबंधित पेज जानकारी को बनाए रखने की संभावना, दोनों सीमित रहते हैं।

जिस गतिविधि के प्रमाण की आपको ज़रूरत है, उससे पहले ऑब्ज़र्वेशन स्थापित करें। यदि कोई पेज किसी क्रिया के तुरंत बाद प्रासंगिक इवेंट पैदा कर सकता है, तो बाद में ऑब्ज़र्वर लगाना एक गैप छोड़ सकता है। यह मानने की बजाय कि क्रम अपने-आप संभल जाएगा, वास्तविक क्लाइंट बाइंडिंग के लाइफसाइकल व्यवहार की जाँच करें।

संग्रह के बाद क्या संग्रहीत करना है, यह चुनें। इवेंट के प्रकार, कॉन्टेक्स्ट आइडेंटिफ़ायर, और प्रासंगिक परिणाम का संक्षिप्त रिकॉर्ड किसी जॉब सारांश के लिए पर्याप्त हो सकता है। संपूर्ण लॉग संदेश या नेटवर्क विवरण में संवेदनशील एप्लिकेशन डेटा हो सकता है, इसलिए सुरक्षित रखा गया रिकॉर्ड ट्रबलशूटिंग की आवश्यकता के अनुरूप होना चाहिए।

जब उनका ओनर समाप्त हो जाए, तो सब्सक्रिप्शन्स को बंद करें। कई कार्यों को नियंत्रित करने वाला दीर्घकालिक क्लाइंट गलती से किसी पिछले कार्य के ऑब्ज़र्वर को बाद वाले कार्य से नहीं जोड़ दे। स्पष्ट ओनरशिप से गायब ऑब्ज़र्वेशन और गलत जॉब में दिखाई देने वाले ऑब्ज़र्वेशन, दोनों को समझाना आसान हो जाता है।

WebDriver BiDi, Classic WebDriver, और CDP

WebDriver BiDi, classic WebDriver, और Chrome DevTools Protocol अलग-अलग नियंत्रण इंटरफेस हैं। ब्राउज़र ऑटोमेशन या WebSocket ट्रांसपोर्ट के साझा उपयोग से वे एक-दूसरे के बदले इस्तेमाल करने योग्य नहीं हो जाते।

यह क्लासिक WebDriver कमांड मॉडल अपने मानकीकृत इंटरफेस के माध्यम से रिमोट ब्राउज़र ऑपरेशन परिभाषित करता है। BiDi एक द्विदिश प्रोटोकॉल मॉडल जोड़ता है। CDP का अपना कमांड और इवेंट सतह है जो Chromium टूलिंग से संबद्ध है। अपने एप्लिकेशन की ज़रूरत के वास्तविक ब्राउज़र कवरेज और ऑपरेशनों के आधार पर चयन करें।

माइग्रेशन को एक बार में हर ऑपरेशन को बदलने की ज़रूरत नहीं होती। उस ऑब्ज़र्वेशन की पहचान करें जिसे BiDi की आवश्यकता है, फिर देखें कि चुना गया क्लाइंट उसे मौजूदा ब्राउज़र कंट्रोल के साथ कैसे जोड़ता है। जब आवश्यकता केवल सीमित डाइग्नोस्टिक क्षमता की हो तो पूरे प्रोटोकॉल का पुनर्लेखन करने से बचें।

ब्राउज़र सपोर्ट का मूल्यांकन प्रत्येक ऑपरेशन के लिए किया जाना चाहिए

WebDriver BiDi के लिए ब्राउज़र सपोर्ट का मूल्यांकन प्रत्येक ऑपरेशन और पर्यावरण के लिए किया जाना चाहिए। सफल कनेक्शन ट्रांसपोर्ट स्थापित करता है, जबकि समर्थित सब्सक्रिप्शन या कमांड अधिक संकीर्ण क्षमता स्थापित करता है।

यह Selenium BiDi क्लाइंट सतह Selenium का उपयोग करने वाले एप्लिकेशनों के लिए इम्प्लीमेंटेशन संदर्भ प्रदान करती है। यह वास्तविक लैंग्वेज बाइंडिंग और ब्राउज़र संयोजन की जाँच की आवश्यकता को समाप्त नहीं करती। किसी एक भाषा में प्रदर्शित फीचर का इंटरफेस या सपोर्ट स्टेट किसी दूसरी भाषा में भिन्न हो सकता है।

काम से जुड़ी एक क्षमता चेकलिस्ट बनाएँ। प्रत्येक आवश्यक ऑपरेशन के लिए ब्राउज़र पर्यावरण, क्लाइंट मेथड, अपेक्षित प्रोटोकॉल व्यवहार, और वह स्थिति निर्दिष्ट करें जो साबित करेगी कि यह काम करता है। असमर्थित क्षमताओं को स्पष्ट रूप से दर्ज करें ताकि अनुपस्थित ईवेंट को खाली एप्लिकेशन परिणाम के रूप में गलत निदान न किया जाए।

बिना वर्तमान डॉक्यूमेंटेशन जाँचे पुराने प्रायोगिक फ्लैग या कनेक्शन उदाहरणों की कॉपी करने से बचें। प्रोटोकॉल कार्य विकसित होता रहता है, और जो कॉन्फ़िगरेशन कभी प्रीव्यू फीचर सक्षम करता था वह अब समर्थित पथ का वर्णन न कर सके। यह शब्दावली जानबूझकर कोई अनएक्सीक्यूटेड कनेक्शन कोड या सार्वभौमिक सपोर्ट तालिका प्रदान नहीं करती।

एक उपयोगी BiDi स्वीकृति परिदृश्य

एक उपयोगी स्वीकृति परिदृश्य किसी ईवेंट को दृश्य पेज परिणाम से जोड़ता है। एक नियंत्रित टेस्ट एप्लिकेशन पर, ऐसा पेज एक्शन व्यवस्थित करें जो एक ज्ञात दस्तावेज़ खोले और पहचानी जाने वाली डाइग्नोस्टिक संदेश उत्पन्न करे।

एक्शन शुरू करने से पहले आवश्यक ईवेंट श्रेणी और स्कोप को सब्सक्राइब करें। एक्शन करें, नए दस्तावेज़ संदर्भ की पहचान करें, और लक्ष्य पेज की स्थिति जाँचें। टेस्ट सिर्फ तभी पास होता है जब अपेक्षित ऑब्ज़र्वेशन अपेक्षित संदर्भ से संबंधित हो और एप्लिकेशन परिणाम सही हो।

सफाई प्रक्रिया का भी अभ्यास करें। ऑब्ज़र्वेशन समाप्त करें, असंबंधित काम करें, और पुष्टि करें कि पुराना कार्य सबूत इकट्ठा करना जारी नहीं रखता। यह सब्सक्रिप्शन ओनरशिप की जाँच करता है, जिसे अक्सर खुशहाल मार्ग वाले उदाहरण में नहीं परखा जाता।

अंतिम रिपोर्ट में प्रोटोकॉल और व्यावसायिक परिणामों को अलग रखें। असफल सब्सक्रिप्शन, बंद संदर्भ, और गायब पेज रिकॉर्ड के अलग-अलग स्पष्टीकरण होने चाहिए। यह भेद खासकर रिमोट निष्पादन में मूल्यवान है, जहाँ कई इंफ्रास्ट्रक्चर और एप्लिकेशन लेयर स्वतंत्र रूप से विफल हो सकती हैं।

Scrapeless के साथ BiDi अवधारणाओं का उपयोग

BiDi अवधारणाएँ ईवेंट-चालित ऑटोमेशन को समझाने में मदद करती हैं, लेकिन Scrapeless एंडपॉइंट का उपयोग उसके प्रलेखित प्रोटोकॉल के माध्यम से ही किया जाना चाहिए। Agent Browser CDP सतह CDP ऑपरेशनों को डॉक्यूमेंट करती है; यह WebDriver BiDi एंडपॉइंट का प्रमाण नहीं है।

यह Agent Browser प्लेटफ़ॉर्म प्रबंधित ब्राउज़र एक्जीक्यूशन और ऑब्ज़र्वेशन फीचर्स प्रदान करता है। ब्राउज़र कंसोल और सेशन डाइग्नोस्टिक्स पर चर्चा संबंधित परिचालन संदर्भ देती है, जबकि Scrapeless प्राइसिंग वर्कलोड योजना का समर्थन करती है। किसी प्रोटोकॉल अवधारणा को प्रोडक्ट इंटीग्रेशन में बदलने से पहले आवश्यक इंटरफेस की पुष्टि करें।

निष्कर्ष

WebDriver BiDi ब्राउज़र ईवेंट्स को कंट्रोल वार्तालाप का हिस्सा बना देता है। इसे तब उपयोग करें जब ईवेंट-आधारित ऑब्ज़र्वेशन किसी परिभाषित आवश्यकता को हल करे, और संदर्भ पहचान, सब्सक्रिप्शन स्कोप, पूर्णता शर्तें, और सफाई को साथ में डिज़ाइन करें। कम्पैटिबिलिटी उस ऑपरेशन से स्थापित होती है जिसे आपका वास्तविक ब्राउज़र और क्लाइंट कर सकते हैं, न कि केवल किसी प्रोटोकॉल नाम से।