सभी को नमस्कार! मेरा नाम तान्या है, मैं लमोडा में एक्सपट्टा विकास टीम की टीम लीड हूं। यह आलेख Microsoft Dynamics 365 For Finance और ऑपरेशन प्लेटफ़ॉर्म पर हमारी पहली परियोजना के विकास पर चर्चा करेगा।

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

यह Mycrosoft Dynamics 365 और Power Platform Meetup मीटिंग से रिपोर्ट का एक मुफ्त प्रतिलेख है ।

परियोजना लक्ष्य और तकनीकी मूल बातें

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

हम चाहते थे कि लेखांकन प्रणाली जर्मन शाखा को रिपोर्ट प्रस्तुत करने, करों का भुगतान करने और ऑडिट पास करने में मदद करे। पिछले ईआरपी ने शायद ही इन समस्याओं को हल किया था, इसलिए हमने अपनी स्वयं की लेखा प्रणाली को विकसित करने और लॉन्च करने का फैसला किया। हमारे ईआरपी को एक ही सर्किट में वित्त, लेखा और शाखा रसद को संयोजित करना था। मुख्य सॉफ्टवेयर के रूप में, हमने Microsoft Dynamics 365 - पूर्व डायनेमिक्स AX, जिसे Axapta के रूप में भी जाना जाता है, को चुना।

व्यापार घटक "प्रौद्योगिकी, आउटसोर्सिंग और मानसिकता" लेख में वर्णित है । यहां हम तकनीकी कार्यान्वयन के बारे में बात करेंगे। इसलिए, हमें कई व्यावसायिक प्रक्रियाओं को स्वचालित करने की आवश्यकता है:

आपूर्तिकर्ताओं से माल की खरीद;
एक रूसी कानूनी इकाई को बिक्री;
D365 और Ax2012 के बीच एकीकरण, एक रूसी कानूनी इकाई की लेखा प्रणाली;
;
.

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

हमारे पास समय सीमा थी: पूरे विकास को 3 महीने में पूरा करना आवश्यक था। चूंकि पुराने सिस्टम में कमोडिटी अकाउंटिंग को स्प्रेडशीट में किया गया था, इसलिए ऐतिहासिक डेटा के पूरे सेट को स्थानांतरित करना एक वित्तीय वर्ष के मध्य में एक असंभव कार्य होगा। लेकिन रिपोर्टिंग अवधि की शुरुआत में, यह केवल शेष राशि को स्थानांतरित करने के लिए पर्याप्त है। इस प्रकार, 1 जनवरी, 2019 को लॉन्च करना या इसे एक और वर्ष के लिए स्थगित करना आवश्यक था।

हमारी टीम को D365 में विकास का अनुभव नहीं था। सभी परिस्थितियों के बावजूद, हमने इस परियोजना को जल्द से जल्द शुरू करने की योजना बनाई। आगे, मैं विकास के सभी चरणों का अलग-अलग वर्णन करूँगा। मैं प्रत्येक पुनरावृति पर विस्तार से ध्यान केंद्रित करूंगा: हमें क्या अनुभव मिला और हमने क्या गलतियां कीं।

पहला पुनरावृत्ति, आवेदन संस्करण 7.3 पर संशोधन

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

परीक्षण के लिए, हमने SAT पर्यावरण - मानक स्वीकृति परीक्षण 2-स्तरीय पर्यावरण का उपयोग करने का निर्णय लिया।

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

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

हमारे क्लाउड वातावरण को जीवनचक्र सेवा पोर्टल के माध्यम से प्रबंधित किया गया।

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

D365 आर्किटेक्चर में कोई परत नहीं है, सभी मानक कोड मॉडल में निर्धारित किए गए हैं। संकलित मॉडल वाले पैकेज के साथ एलसीएस पोर्टल के माध्यम से एसएटी पर्यावरण में संशोधन किए गए थे।

– , – , .

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

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

इस तरह के एक सरल संशोधन पर, हमने डी 365 के बुनियादी सिद्धांतों में से एक को देखा - एक बदलाव नहीं, लेकिन मानक वस्तुओं का एक विस्तार।

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

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

पहले पुनरावृत्ति के बाद निष्कर्ष

1. मानक को न बदलें, लेकिन केवल इसका विस्तार करें।

2. यदि हम किसी अन्य मॉडल में इसकी वस्तुओं का उपयोग करते हैं तो मॉडल देखें। यह पिछले संस्करणों से डी 365 मॉडल के बीच अंतर है: एक ऑब्जेक्ट केवल एक मॉडल में मौजूद है।

3. मानक वस्तुओं के गुणों को बदलने में सीमाएँ हैं। मानक क्षेत्रों के सभी गुणों को मानक वस्तुओं के अपने एक्सटेंशन में नहीं बदला जा सकता है। उदाहरण के लिए, PurTTable तालिका का विस्तार LineDisc फ़ील्ड है। हम क्षेत्र और लेबल की दृश्यता को नियंत्रित कर सकते हैं, और अनिवार्य और संपादन योग्य जैसे गुणों को नहीं बदला जा सकता है।

4. D365 में कोई नौकरी नहीं है, सब कुछ कक्षाओं के माध्यम से किया जाता है।

5. हमने मॉडलों को बहुत सूक्ष्मता से हराया, और यह पता चला कि "एक संशोधन = एक मॉडल" का हमारा सिद्धांत काम नहीं करता है।

दूसरा पुनरावृत्ति और एक मॉडल में संक्रमण

दूसरी पुनरावृत्ति की शुरुआत में, हमारे पास दो मॉडल थे जो एक दूसरे को संदर्भित करते थे। इस वजह से, हम इन संशोधनों को स्वतंत्र रूप से स्थानांतरित नहीं कर सकते हैं। इसलिए, हमने एक नए मॉडल में काम करने का फैसला किया, जिसमें सभी मौजूदा संशोधनों को स्थानांतरित करना आवश्यक था।

डी 365 में एक मॉडल एक अलग निर्देशिका में स्थित स्रोत फ़ाइलों का एक संग्रह है। संकलन करते समय, उन्हें एक अलग पुस्तकालय में एकत्र किया जाता है जिसमें अन्य पुस्तकालयों के साथ एक लिंक होता है।

इसलिए, DevBox पर एक मॉडल में विलय करने के लिए एक निर्देशिका से दूसरे में फ़ाइलों को स्थानांतरित करने और पुरानी निर्देशिकाओं को हटाने के लिए नीचे आया।

इसलिए, हमने एक नया मॉडल बनाया, प्रत्येक DevBox पर इसका नवीनतम संस्करण प्राप्त किया, और फिर विकास के वातावरण पर एक मॉडल के ढांचे के भीतर काम करना जारी रखा।

स्वाभाविक रूप से, हमने पहले से ही SAT पर्यावरण पर परीक्षण के लिए कुछ मॉडलों को स्थानांतरित कर दिया है। इसलिए, उन्हें निकालना आवश्यक था, और एक नया जारी करना था।

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

जब मॉडल संयुक्त थे, तो हमने देखा कि प्रत्येक डेवलपर अपने तरीके से वस्तुओं के विस्तार का नाम देता है। हम टेम्पलेट के अनुसार वस्तुओं के नामकरण के नियमों पर सहमत हुए: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension ।

हमने टीम में इस बात पर भी सहमति व्यक्त की कि एक मानक वस्तु के लिए हम केवल एक एक्सटेंशन बनाते हैं और सभी में परिवर्तन करते हैं।

मैंने कुछ दिलचस्प संशोधनों का चयन किया, जो हमने इस स्तर पर बनाई थीं। वे D365 में संभावित विकास दृष्टिकोण दिखाते हैं।

टास्क 1

बिक्री आदेश के लिए चालान की पोस्टिंग में, आदेश से चालान नंबर को प्रतिस्थापित करना आवश्यक था। ऐसा करने के लिए, हमने विस्तार की संभावना के साथ एक मानक वर्ग को परिभाषित किया, जिसने हमें इस संशोधन को करने की अनुमति दी।

हमने मानक SalesInvoiceJourCreate वर्ग में विस्तार किया। उसके getNumAndVoucher () पद्धति में नेक्स्ट है - यह हमारा नया सुपर है, वह मानक विधि कोड को कॉल करने के बारे में बात करता है। मानक कोड को कॉल करने के बाद, हमने वांछित मूल्य के साथ चालान नंबर को बदल दिया।

यह हमारे विकास दृष्टिकोणों में से एक है: एक्सटेंशन का उपयोग करना और मानक कोड के निष्पादन से पहले या बाद में (विकल्प के रूप में - दोनों पहले और बाद में) अपना कोड जोड़ना।

कार्य 2

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

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

संस्करण 7.3 में, हम विधियों को एक मानक प्रपत्र डेटा स्रोत तक विस्तारित नहीं कर सके। फ़िल्टरिंग करने के लिए और इसके लिए एक नया फ़ॉर्म नहीं बनाने के लिए, हमने फॉर्म में एक डेटा स्रोत के रूप में दृश्य जोड़ा।

डेटा स्रोत के लिए तरीकों का विस्तार करने की क्षमता D365 के संस्करण 8.1 में दिखाई दी।

दूसरी पुनरावृत्ति के बाद निष्कर्ष

इस स्तर पर, हमने परियोजना को लॉन्च करने के लिए आवश्यक बुनियादी संशोधनों को विकसित किया है।

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

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

अब यह कैसे काम करता है

अंतिम पुनरावृत्ति में, हमने दो वातावरण जोड़े: निर्माण और परीक्षण। सभी वातावरण कॉन्फ़िगर और सत्यापित किए जाने के बाद, हमने परीक्षण को सरल बनाया और केवल मॉडल के भीतर परीक्षण किए गए संशोधनों को जारी करना सीखा।

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

रिलीज के लिए पैकेज बनाएँ अब एक नए बिल्ड पर्यावरण पर किया जाता है। परीक्षण संशोधनों को संस्करण नियंत्रण प्रणाली में एक नई शाखा में बदलावों (संस्करण नियंत्रण प्रणाली पर अपलोड किए गए परिवर्तन पैकेज) द्वारा हस्तांतरित किया गया था, एक सिद्धांत पर अंतिम से अंतिम तक।

फिर हमने पैकेज को SAT पर्यावरण पर तैनात किया जहां उपयोगकर्ता परीक्षण हुआ, जिसके बाद हमने एलसीएस पोर्टल पर पैकेज को ठेस पर रिलीज करने के लिए निर्धारित किया। इसलिए हम बिल्ड वातावरण का उपयोग करके रिलीज़ प्रक्रिया सेट करते हैं।

और हमने परियोजनाओं को संशोधित नहीं करने का फैसला किया, लेकिन संशोधन के लिए बदलाव, संस्करण नियंत्रण पर अपलोड किए गए।

पहला क्लाउड संस्करण अपडेट

हमने क्लाउड संस्करण पर काम किया, इसलिए हमें नियमित रूप से अपडेट रहने की आवश्यकता थी। पहला अद्यतन संस्करण 7.3 से संस्करण 8.0 तक संक्रमण था। इसमें लगभग दो सप्ताह का समय लगा।

बेशक, हमने अपने लिए मुख्य समस्याएं खड़ी कीं, लेकिन हम जीत भी गए:

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

आज, हमारे सभी वातावरणों को अपडेट करने में लगभग 3-4 दिन लगते हैं और डेवलपर्स की भागीदारी के बिना होता है। हम अद्यतन के रूप में एक ही समय में एक रिलीज़ भी जारी कर सकते हैं, मुख्य बात यह है कि बिल्ड, सैट और ठेस का एक ही संस्करण है।

अपडेट प्रक्रिया में एलएसीएस पोर्टल पर अपडेट पैकेज डाउनलोड करना शामिल है। DevBox और परीक्षण पहले अपडेट किए जाते हैं, फिर बिल्ड को अपडेट किया जाता है, अंतिम SAT और ठेस हैं।

पूरे पहले प्रोजेक्ट के परिणाम

हमने D365 एप्लीकेशन आर्किटेक्चर के निर्माण में अनुभव प्राप्त किया है।
कोड समीक्षा के लिए एक नया दृष्टिकोण विकसित किया।
हमने डेटाबेस को DevBox में स्थानांतरित करने के लिए नियम बनाए (D365 में DevBox पर प्रारंभिक परीक्षण करना महत्वपूर्ण है, और अब हम DevBox पर डेवलपर्स का परीक्षण भी कर रहे हैं)।
D365 में विकास दिशानिर्देश लिखे।
बादल में विकसित करने के लिए सीखा।

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

वित्त और संचालन के लिए Microsoft Dynamics 365 के मंच पर पहली परियोजना का विकास