कमोडिटी अकाउंटिंग सिस्टम के साथ वेब-अनुप्रयोगों का एकीकरण - सम्मेलन DUMP-IT.RU से रिपोर्ट पाठ

30 मई को, हमने DUMP सम्मेलन के विभिन्न वर्गों में कई रिपोर्टें कीं, जो येकातेरिनबर्ग में आयोजित की गई थीं। शुरू में, हमें समग्र विषय "क्यों 1C-Bitrix", बकवास :-) पर संपर्क करने के लिए कहा गया था, लेकिन हमने खुद को बक्से को कस्टमाइज़ करने की समस्याओं को सीमित करने का फैसला किया जब साइट को कमोडिटी अकाउंटिंग सिस्टम के साथ सिंक्रनाइज़ किया गया (बाद में एसटीयू के रूप में संदर्भित)।

तो यह थी रिपोर्ट के बारे में।

Artofte सबसे अक्सर 1C \ Scala \ SuperMAG और ऑनलाइन भुगतान प्रणाली के साथ एक ऑनलाइन स्टोर को एकीकृत करने की चुनौतियों का सामना करता है। हम एक आदेश की स्थिति पर नज़र रखने के लिए सिस्टम भी शुरू करते हैं, लेकिन सीमित नहीं हैं। एकीकृत समाधानों के पूल में अधिक जटिल प्रणालियां शामिल हो सकती हैं, जैसे ग्राहक-पक्ष ऑनलाइन बैंकिंग, बिलिंग सिस्टम के साथ एकीकरण आदि।

समस्या

हम विशेष रूप से सिम्फनी (PHP) और .NET में कस्टम विकास में लगे हुए हैं , और हम अक्सर उन ग्राहकों द्वारा संपर्क किया जाता है जिनके पास पहले से ही सभी प्रकार का अनुभव है।

ग्राहकों से संपर्क करते समय, हम अक्सर निराशा के लिए 3 विकल्प भरते हैं।

• क) ग्राहक के पास स्पष्ट रूप से तैयार कार्य नहीं है और सवाल पूछता है: "क्या होगा यदि आप कोशिश करते हैं?" इस मामले में, हम अनुशंसा करते हैं कि ग्राहक पहले बॉक्स वाले संस्करणों में से एक के साथ खेलें, और पी देखें।
• बी) ग्राहक अपने स्वयं के विकास का फैसला करता है, कम कीमत खंड के निर्णय की ओर मुड़ता है, और अंततः "साइकिल" प्राप्त करता है। और, ऐसा लगता है, सब ठीक है, ग्राहक संतुष्ट है। वह समय-समय पर साइट पर सामान अपलोड करता है, 1 सी में आदेशों को रोक देता है। लेकिन थोड़ी देर बाद यह पता चलता है कि बाइक के पहिए चौकोर हैं, सीट समायोज्य नहीं है, और सिद्धांत में गति स्विच प्रदान नहीं किया गया है। अपने सिस्टम के निर्माता के समर्थन के बिना, ग्राहक एक गतिरोध पर है।
• ग) ग्राहक ने एक "बॉक्सिंग" समाधान चुना। यह ऐतिहासिक रूप से ऐसा हुआ कि STU समाधानों के विभिन्न विक्रेताओं की उपस्थिति के बावजूद, जैसे कि Oracle, Scala, SuperMag, आदि के अधिकांश मामलों में, STU को 1C: Enterprise कॉम्प्लेक्स के रूप में समझा जाता है। इसलिए, जब कमोडिटी अकाउंटिंग सिस्टम या अकाउंटिंग सिस्टम के साथ एक ऑनलाइन स्टोर को एकीकृत करने की बात आती है, तो विचार करने वाली पहली चीजें समाधान हैं जो बॉक्स के बाहर 1 सी के साथ एकीकरण प्रदान करती हैं। और यह तर्कसंगत है कि यह मुख्य रूप से 1C-Enterprise और 1C-Bitrix के एक समूह में आता है। यह समाधान वास्तव में लागू करने के लिए काफी सरल है, और कुछ समय के लिए चीजें पहले संस्करण की तुलना में बहुत बेहतर हैं। वेब एप्लिकेशन को ग्राहक के व्यवसाय की आवश्यकताओं के साथ विकसित किया जाएगा।

लेकिन क्या होगा अगर, एक लिंक के रूप में, एक वैकल्पिक समाधान का उपयोग किया जाता है: एक तरफ सीएमएस या एक कस्टम सिस्टम और दूसरी ओर कमोडिटी अकाउंटिंग के लिए वैकल्पिक सॉफ्टवेयर?

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

एक रास्ता या दूसरा, "पूरा" या सीधे "बॉक्स से बाहर", ऐसा समाधान, अंत में मानक कार्यक्षमता की अपनी सीमा को समाप्त कर देगा। पेटी भरी होगी। मृत अंत।

ऊपर वर्णित परिदृश्य, प्रति se एकीकरण समस्याओं के अलावा, ग्राहक के लिए "दुष्प्रभाव" हो सकते हैं।

एक वक्र एकीकरण के कारण होने वाली समस्याओं का एक उदाहरण:

1. मामला "detsad.ru"

हमारी seo-unit एक अन्य कंपनी द्वारा विकसित साइट detsad.ru के प्रचार में लगी हुई थी। यह साइट एक सरल ऑनलाइन स्टोर है जिसमें तीन-स्तरीय निर्देशिका पदानुक्रम और 1 सी-अकाउंटिंग के साथ कॉन्फ़िगर सिंक्रनाइज़ेशन है, सीएमएस के माध्यम से मैन्युअल रूप से सीएसवी फ़ाइल डाउनलोड करके।

कैटलॉग पेज का रास्ता (इस मामले में, घोंसले के शिकार के अधिकतम स्तर के साथ एक लिंक प्रदान किया गया है) इस तरह दिखता है: www.detsad.ru/catalogue/200/3598 , जहां अंतिम दो संख्या क्रमशः श्रेणी और उत्पाद संख्याएं हैं।

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

2. केस "स्टार"

यहाँ एक और उदाहरण है। मान लीजिए कि मेरे दोस्तों और मैंने बीयर पीने का फैसला किया है। हम हुगार्डन से प्यार करते हैं, और एक बॉक्स ऑर्डर करने का फैसला किया। हम "स्टार" सुपरमार्केट में खरीदना पसंद करते हैं, लेकिन हम इसके लिए बहुत आलसी हैं। इसलिए, हमने Zvezdny ऑनलाइन स्टोर पर बीयर ऑर्डर करने का फैसला किया। ऑनलाइन स्टोर के मुख्य पृष्ठ पर एक बार, हम चुनते हैं: "बीयर", "सैन इनबेव", "एसबी", ... क्या नरक है? "सैन इनबेव" और क्या है? "एसबी", "प्रबलित कंक्रीट", "पीबी" किस तरह का है? प्रबलित कंक्रीट या क्या?


मैं सीधे खुद को स्टोर में जाने और विशाल संकेत को देखने की कल्पना करता हूं: "बीयर"। मैं इसे "सन इनबेव" अनुभाग में लपेटता हूं, "एसबी" रैक की तलाश करता हूं, और उस पर ... अरे नहीं, बीयर भी मिल गई है। मैं पीने का पानी खरीदने के लिए बेहतर होगा। उसके लिए इतना गहरा नहीं है।

परिणामस्वरूप, ग्राहक समझता है कि उसे एक नए समाधान की आवश्यकता है, जो न केवल पूरी तरह से व्यावसायिक तर्क को ध्यान में रखेगा, बल्कि अपने व्यवसाय के साथ-साथ सुधार भी करेगा।

हमारे अनुभव के आधार पर, हम संभावना के एक उच्च स्तर के साथ मान सकते हैं कि एसटीयू और वेब फ्रंटेंड के एकीकरण के दौरान, डेवलपर एसटीयू से निर्देशिका संरचना की प्रतिलिपि बनाता है।

परिणाम कम रूपांतरण है।

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

इस मॉडल का आरेख इस प्रकार है:

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

लेकिन तुरंत एक विस्तृत विश्लेषण के साथ कार्यान्वयन क्यों नहीं शुरू करें और तुरंत एक कस्टम समाधान पर न आएं?

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

प्रमुख कारकों में से एक होने के नाते, सिस्टम को शुरू करने की कम लागत का मतलब यह नहीं है कि हमने बचाया है, और समाधान चुनते समय, हमें एक व्यापक पहलू में मूल्यांकन करना चाहिए, उदाहरण के लिए, एक एकीकृत समाधान के स्वामित्व की लागत की गणना करें, और इसमें शामिल होगा

• दरअसल, मुख्य सॉफ्टवेयर घटकों की लागत
• यदि आवश्यक हो, तो सॉफ्टवेयर घटकों को लागू करने की लागत
• एक एकीकरण समाधान को लागू करने की लागत
• एकीकरण समाधान के बाद के अनुकूलन के लिए लागत

अंतिम आइटम अक्सर प्रोजेक्ट बजट का आधार बन जाता है।

रखरखाव की लागत के उल्लेख के वाणिज्यिक प्रस्ताव में अनुपस्थिति ग्राहक के लिए एक गुलाबी तस्वीर बनाता है। बात यह है कि बॉक्सिंग समाधान कार्यान्वयन के मामले में वास्तव में सस्ता होगा।

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

एकीकरण मॉडल:

तो आप वेब एप्लिकेशन के साथ "मित्र कैसे बना सकते हैं" एसटीयू? इस प्रश्न का उत्तर देने के लिए, हम पहले संभव एकीकरण मॉडल पर विचार करते हैं।

पश्चिमी मॉडल

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

एक विशिष्ट इंटरैक्शन आरेख नीचे दिए गए आरेख की तरह दिखता है:

अनुप्रयोगों के साथ व्यापक डेटा इंटीग्रेटर मिडलवेयर इंटरैक्शन का आर्किटेक्चर।

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

वेब सेवा प्रौद्योगिकी और प्रोटोकॉल

• सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल (एसओएपी) - एक्सएमएल-आरपीसी का एक विस्तार है और एक्सएमएल प्रारूप में मनमाने संदेशों का आदान-प्रदान करने की क्षमता प्रदान करता है। प्रारंभ में दूरस्थ प्रक्रिया कॉल (RPC) को लागू करने के लिए उपयोग किया जाता है। पुन: प्रयोज्य घटकों को प्रदान करने के लिए वेब सेवा की अनुमति देता है। पाठ प्रोटोकॉल के शीर्ष पर प्रयुक्त, ज्यादातर HTML
• प्रतिनिधि राज्य हस्तांतरण (आरईएसटी) - इस मामले में, डेटा को मानक प्रारूपों की एक छोटी संख्या का उपयोग करके प्रेषित किया जाता है - HTML, XML, JSON। नेटवर्क ट्रांसफर प्रोटोकॉल को कैशिंग का समर्थन करना चाहिए और राज्य की जानकारी संग्रहीत नहीं करनी चाहिए। डेटा एक्सचेंज अनुरोध-प्रतिक्रिया के रूप में बनाया गया है। कुछ मामलों में, इसका उपयोग SOAP वस्तुओं को स्थानांतरित करने के लिए किया जा सकता है।
• XML का उपयोग आमतौर पर संदेश और वस्तुओं को व्यक्त करने के लिए किया जाता है। इसमें एक पदानुक्रमित संरचना और महान लचीलापन है।
• संदेश पंक्तिबद्ध करना - एक संदेश पूल है, वे प्रसंस्करण तक संग्रहीत होते हैं।
• कॉमर्सल 1 सी के साथ सिंक्रनाइज़ेशन के लिए रूसी मानक है: 1 सी और अन्य मास्टोडोन द्वारा सक्रिय रूप से पदोन्नत किए गए बहीखाता, बिल्कुल बेवकूफ हैं क्योंकि यह अंतरराष्ट्रीय नहीं हो सकता है और परिणामस्वरूप, बड़े ईआरपी द्वारा समर्थित नहीं है, हालांकि, यह 1 सी v8 में मूल कार्यान्वयन के कारण योग्य है।

इन प्रोटोकॉल के माध्यम से डेटा ट्रांसफर आमतौर पर HTTP / S और FTP / S ट्रांसपोर्ट द्वारा प्रदान किया जाता है।

आवश्यक उपकरण होने के बाद, यह अक्सर डेटा संरचनाओं का वर्णन करने और सबसे उपयुक्त विनिमय प्रोटोकॉल चुनने के लिए पर्याप्त है।

रूस में वेब और कमोडिटी अकाउंटिंग

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

• 1 सी से नामकरण का एकतरफा संचार और साइट के वेब-विंडो के लिए इसका निष्कर्ष
• एक साइट और एक व्यक्तिगत खाते के वेब-शोकेस के साथ 1 सी से नामकरण और समकक्षों का दो-तरफ़ा संचार
• एक साइट और एक व्यक्तिगत खाते के वेब-शोकेस के साथ 1 सी से नामकरण, समकक्षों और आदेशों का दो-तरफ़ा संचार

उनके बारे में यहाँ और अधिक

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

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

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

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

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

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

• XML फ़ाइल पर अपलोड करें और इसे FTP के माध्यम से स्थानांतरित करें
• पहल-श्रोता मॉडल

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

आरंभकर्ता-श्रोता मॉडल में, वेब एप्लिकेशन एक श्रोता के रूप में कार्य करता है, और STU इंटरफ़ेस मॉड्यूल वेब एप्लिकेशन को अनुरोध भेजता है, जिसके परिणामस्वरूप जानकारी को वेब एप्लिकेशन में भेजने या प्राप्त करने के लिए कार्रवाई शुरू होती है। इस मॉडल को किसी भी तृतीय-पक्ष सर्वर की आवश्यकता नहीं है, क्योंकि इसके कार्य वेब एप्लिकेशन द्वारा किए जाते हैं, लेकिन इसके लिए STU इंटरफ़ेस मॉड्यूल में वेब क्लाइंट फ़ंक्शन की आवश्यकता होती है। इस तरह के कार्य, उदाहरण के लिए, 1C v8 में हैं।

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

अनुकूलन

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

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

एक कस्टम उत्पाद विकसित करते समय, हम अपने निर्णयों में व्यावहारिक रूप से असीमित हैं, क्योंकि हम अपने आप को या तो एक वास्तुशिल्प ढांचे या एक साधन के रूप में नहीं लगाते हैं। हमारे पास अपना स्वयं का घटक आधार है, और हम जो चाहें कर सकते हैं।

खैर, यह बात है! =)