👨🏾‍🏭 👲🏼 🧓🏿 सूचना प्रणालियों के अनुकूलन के बारे में 🕐 👂🏿 🤱🏻

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

संभव दृष्टिकोण

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

प्रत्येक एक्सटेंशन प्रोजेक्ट के लिए रिपॉजिटरी में अलग ब्रंच

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

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

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

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

गतिशील विशेषताओं (एंटिटी-एट्रिब्यूट-वैल्यू मॉडल) का उपयोग करना

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

इकाई - उस वस्तु का संदर्भ संग्रहीत करता है जिसका क्षेत्र हम बता रहे हैं। यह आमतौर पर एक इकाई पहचानकर्ता है;
विशेषता - विशेषता परिभाषा की एक कड़ी (उस पर अधिक नीचे);
मान - गुण मान ही।

स्कीमा का एक अनिवार्य घटक भी एक तालिका है जो विशेषताओं के लिए मेटाडेटा का विवरण संग्रहीत करता है:

विशेषता प्रकार
प्रतिबंध (क्षेत्र की लंबाई, नियमित अभिव्यक्ति जिसके लिए मूल्य मैच होना चाहिए, आदि);
यूआई में प्रदर्शित करने के लिए घटक;
वह क्रम जिसमें UI में घटक प्रदर्शित होता है।

किसी उत्पाद में इस मॉडल का उपयोग करने के लिए, आपको 2 काम करने होंगे:

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

दृष्टिकोण का सबसे महत्वपूर्ण लाभ एक विस्तार परियोजना बनाने की आवश्यकता की कमी है। आधार उत्पाद को ग्राहक तक पहुंचाया जाता है, और संचालन या यहां तक कि संचालन के चरण में, संस्थाओं में किसी भी प्रकार की गतिशील विशेषताओं की स्थापना की जाती है।

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

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

तीसरा, फिर से, डेटाबेस की संरचना के कारण, रिपोर्ट के लिए डेटा नमूने बनाने में काफी मुश्किल होगा - नियमित एसक्यूएल लिखने के बजाय, रिलेशनल डेटा को बहुत अधिक जटिल प्रश्नों की आवश्यकता होगी।

प्लगइन वास्तुकला

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

कार्यक्षमता के विस्तार के लिए ऐसा अक्सर उपयोग किया जाने वाला विकल्प, जैसे कि बाहरी स्क्रिप्ट में तर्क और घटना संचालकों का वर्णन करना, प्लगइन्स की विविधता के लिए भी जिम्मेदार ठहराया जा सकता है: स्क्रिप्ट्स को प्रोग्राम में कुछ बिंदुओं द्वारा बुलाया और निष्पादित किया जाता है।

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

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

हम इसे कैसे करते हैं

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

एक नए विस्तार पर काम शुरू करते समय, हम अक्सर यह अनुमान भी नहीं लगाते थे कि कौन सा "राक्षस" (शब्द के अच्छे अर्थ में) इस परियोजना में विकसित हो सकता है। एक सामान्य घटना तब होती है जब एक छोटे से अनुकूलन के रूप में शुरू किया गया लगभग पूरी तरह से फिर से लिखा व्यापार प्रक्रियाओं और अतिरिक्त तर्क के साथ स्क्रीन के आधे हिस्से पर समाप्त होता है। इसके अलावा, उत्पाद को नई कार्यक्षमता के साथ विस्तारित किया जा सकता है, जो एक स्वतंत्र प्रणाली के लिए काफी पर्याप्त है। एक उदाहरण के रूप में, एक बड़ी वितरित कंपनी के लिए TESIS के विस्तार परियोजना में, राजकोष के स्वचालन, कर्मचारियों की प्रभावशीलता का आकलन और कुछ अधिक जटिल मॉड्यूल दिखाई दिए।

विभिन्न आवश्यकताओं, उनकी मात्रा और अप्रत्याशितता ने ऊपर वर्णित किसी भी तरीके का उपयोग करने की अनुमति नहीं दी। उस के शीर्ष पर, उत्पाद संस्करण नियमित रूप से बाहर आते हैं। यह उत्पाद के नए संस्करण में विस्तार परियोजना को स्थानांतरित करने की अधिकतम आसानी की आवश्यकता बनाता है।

हम एक्सटेंशन बनाने और समर्थन करने की समस्या को कैसे हल करते हैं?

हमारी विस्तार परियोजना

हमारी कंपनी के अधिकांश प्रोजेक्ट CUBA प्लेटफॉर्म का उपयोग करके बनाए गए हैं। हमने पिछले लेखों में से एक में इसके बारे में पहले ही लिखा था। विस्तार परियोजनाएं कैसे व्यवस्थित की जाती हैं, यह समझने के लिए, आपको सबसे पहले मंच के उपकरण से निपटने की आवश्यकता है।

संक्षेप में, CUBA मॉड्यूल का एक सेट है, जिनमें से प्रत्येक एक निश्चित कार्यक्षमता प्रदान करता है:

क्यूबा - अनुप्रयोग का मूल, संपूर्ण बुनियादी ढाँचा, व्यावसायिक तर्क को व्यवस्थित करने के लिए उपकरण, दृश्य घटकों का एक पुस्तकालय, एक सुरक्षा प्रणाली, आदि।
रिपोर्ट - रिपोर्ट जनरेशन सबसिस्टम
fts - पूर्ण-पाठ खोज सबसिस्टम
चार्ट - चार्ट आउटपुट सबसिस्टम
वर्कफ़्लो - व्यवसाय प्रक्रिया प्रबंधन सबसिस्टम
ccpayments - क्रेडिट कार्ड सबसिस्टम

प्रत्येक सबसिस्टम में व्यावसायिक तर्क के साथ लगातार इकाइयाँ, स्क्रीन और सेवाएँ हो सकती हैं।

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

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

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

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

किसी उत्पाद के नए संस्करण में एक्सटेंशन का अनुवाद करने की प्रक्रिया इस प्रकार है:

आप स्क्रिप्ट बनाने और एक्सटेंशन के पुनर्निर्माण में उत्पाद के नए संस्करण को निर्दिष्ट करते हैं;
यदि एक्सटेंशन केवल एक स्थिर उत्पाद API का उपयोग करता है, तो वह यह है - अपना उन्नत उत्पाद शुरू करें और जाएं;
यदि उत्पाद ने आपके द्वारा विस्तारित किए गए बिंदुओं पर महत्वपूर्ण परिवर्तन किए हैं, तो आपको एक्सटेंशन कोड को बदलने की आवश्यकता हो सकती है। एक नियम के रूप में, यह बार-बार होता है, और समस्या का स्थानीयकरण करना सरल है। Bugfix उत्पाद रिलीज़ हमेशा एक्सटेंशन के साथ संगत रहते हैं।

यह स्पष्ट है कि विस्तार में आप आसानी से उनके लिए नई इकाइयां, व्यावसायिक तर्क और स्क्रीन बना सकते हैं। लेकिन उत्पाद में पहले से ही क्या बदलना है? उदाहरण के लिए, किसी उत्पाद इकाई में एक फ़ील्ड जोड़ें और इसे मौजूदा स्क्रीन में प्रदर्शित करें?

आधार उत्पाद इकाई में एक नई विशेषता जोड़ना

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

 @Entity(name = "product$User") @Table(name = "PRODUCT_USER") public class User extends StandardEntity { @Column(name = "LOGIN") protected String login; @Column(name = "PASSWORD") protected String password; //getters and setters }

जैसा कि आप देख सकते हैं, यह इकाई का एक मानक विवरण है और जेपीए के लिए तालिका और डेटाबेस कॉलम के लिए मैपिंग है।

विस्तार परियोजना में एक इकाई वारिस बनाएँ:

 @Entity(name = "ext$User") @Extends(User.class) public class ExtUser extends User { @Column(name = "ADDRESS", length = 100) private String address; public String getAddress() { return address; } public void setAddress(String address) { this.address = address; } }

@Extends एनोटेशन के अपवाद के साथ OpenJPA के लिए विरासत तंत्र मानक है, जो कि सबसे अधिक रुचि है। यह वह है जो घोषित करता है कि ExtUser वर्ग का उपयोग उपयोगकर्ता वर्ग के बजाय सार्वभौमिक रूप से किया जाएगा।

अब User इकाई बनाने के सभी संचालन विस्तारित इकाई का एक उदाहरण बनाएंगे:

 User user = metadata.create(User.class); //  ExtUser

डेटाबेस से डेटा निष्कर्षण संचालन नई इकाई के उदाहरण भी लौटाएगा। उदाहरण के लिए, आधार उत्पाद में, नाम से एक उपयोगकर्ता खोज सेवा लौटा दी जाती है जो निम्नलिखित JPQL क्वेरी का परिणाम देती है:

 select u from product$User u where u.name = :name

@Extends एनोटेशन के बिना @Extends हमारे पास आउटपुट पर User वस्तुओं का एक संग्रह होगा, और ExtUser से पता प्राप्त करने के लिए ExtUser डेटाबेस से पिछले अनुरोध के परिणाम को फिर से पढ़ना होगा। लेकिन @Extends एनोटेशन द्वारा प्रदान की गई पुनर्परिभाषित जानकारी का उपयोग करते हुए, प्लेटफ़ॉर्म तंत्र प्रारंभिक रूप से अनुरोध को रूपांतरित कर देगा और हमें विस्तारित ExtUser इकाई की वस्तुओं का संग्रह लौटा देगा। इसके अलावा, अगर कुछ अन्य संस्थाओं के User लिंक थे, तो जब एक्सटेंशन जुड़ा होता है, तो ये लिंक स्रोत कोड में कोई बदलाव किए बिना, ExtUser की वस्तुओं को वापस कर देंगे।

इकाई को फिर से परिभाषित किया गया है। अब उपयोगकर्ता को नए क्षेत्र को प्रदर्शित करना अच्छा होगा।

प्लेटफ़ॉर्म स्क्रीन XML + Java का एक गुच्छा है। XML यूआई के बारे में घोषित करता है, जावा नियंत्रक घटनाओं के प्रति प्रतिक्रिया को निर्धारित करता है। यह स्पष्ट है कि जावा नियंत्रक को फिर से परिभाषित करने से कोई विशेष समस्या नहीं होगी, लेकिन एक्सएमएल एक्सटेंशन के साथ यह थोड़ा अधिक जटिल है। User इकाई में address फ़ील्ड जोड़कर पिछले उदाहरण पर वापस जाते हैं।
एक साधारण स्क्रीन के लेआउट का वर्णन इस तरह दिखता है:

 <window datasource="userDs" caption="msg://caption" class="com.haulmont.cuba.gui.app.security.user.edit.UserEditor" messagesPack="com.haulmont.cuba.gui.app.security.user.edit" > <dsContext> <datasource id="userDs" class="com.haulmont.cuba.security.entity.User" view="user.edit"> </datasource> </dsContext> <layout spacing="true"> <fieldGroup id="fieldGroup" datasource="userDs"> <column width="250px"> <field id="login"/> <field id="password"/> </column> </fieldGroup> <iframe id="windowActions" screen="editWindowActions"/> </layout> </window>

हम UserEditor स्क्रीन कंट्रोलर, डेटा सोर्स डिक्लेरेशन (डेटासोर्स), फ़ील्डग्रुप कंपोनेंट, जो यूनिट फील्ड्स को प्रदर्शित करता है, और स्टैंडर्ड एक्शन "ओके" और "कैंसिलेशन" (विंडोअक्टेशन) के साथ एक लिंक देखते हैं।

मैं विस्तार परियोजना में आधार स्क्रीन कोड को डुप्लिकेट नहीं करना चाहता, इसलिए हमने XML स्क्रीन डिस्क्रिप्टर को प्लेटफ़ॉर्म पर इनहेरिट करने की क्षमता जोड़ी। आधार परियोजना से यह स्क्रीन वारिस की तरह दिखता है:

 <window extends="/com/haulmont/cuba/gui/app/security/user/edit/user-edit.xml"> <layout> <fieldGroup id="fieldGroup"> <column> <field id="address"/> </column> </fieldGroup> </layout> </window>

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

 <screen id="sec$User.edit" template="com/sample/sales/gui/extuser/extuser-edit.xml"/>

परिणाम:

ओवरराइडिंग बिजनेस लॉजिक

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

 @ManagedBean("product_PriceCalculator") public class PriceCalculator { public void BigDecimal calculatePrice() { //price calculation } }

विस्तार परियोजना में मूल्य निर्धारण एल्गोरिथ्म को बदलने के लिए, हम 2 सरल कदम उठाते हैं:

पुनर्निर्धारित घटक का वारिस बनाएँ:

 public class ExtPriceCalculator extends PriceCalcuator { @Override public void BigDecimal calculatePrice() { //modified logic goes here } }

हम आधार उत्पाद से बिन पहचानकर्ता के साथ स्प्रिंग कॉन्फ़िगरेशन फ़ाइल में कक्षा को पंजीकृत करते हैं:

 <bean id="product_PriceCalculator" class="com.sample.extension.core.ExtPriceCalculator"/>

अब स्प्रिंग कंटेनर हमेशा हमारे लिए ExtPriceCalculator का एक उदाहरण लौटाएगा।

विषय का पुन: निर्धारण

संस्थाओं के संशोधन, स्क्रीन और व्यावसायिक तर्क के घटकों के साथ, हमें पता चला। लाइन में अगला एक दृश्य विषय है।

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

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

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

विस्तार परियोजना में, डेवलपर नए विज़ुअल घटकों को कनेक्ट कर सकता है। वाडिन ऐड-ऑन रिपॉजिटरी में बड़ी संख्या में तैयार घटक उपलब्ध हैं। यदि आवश्यक घटक वहां नहीं मिला, तो आप इसे स्वयं लिख सकते हैं।

विभिन्न दृश्य विषयों के उदाहरण:

निष्कर्ष

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

PS शीर्षक फोटो के लेखक इल्या वरलामोव हैं। आप उनके ब्लॉग पर और भी अधिक पॉश पाकिस्तानी ट्रक पा सकते हैं।

सूचना प्रणालियों के अनुकूलन के बारे में